Restore a Backup or Clean a Hacked WordPress Site?

One of the first decisions after a WordPress compromise is also one of the most misunderstood:

should we restore a backup, or should we clean the current site?

People often talk about that as if one option is obviously correct.

It is not.

The right answer depends on when the compromise happened, what the site does, what changed since the last clean backup, and how much confidence you need afterwards.

When restoring a backup is often the better move

Rollback is usually attractive when:

  • you have a known-clean backup from before compromise
  • the site is mostly brochure content or low-change publishing
  • there is little business data at risk between the clean backup and now
  • the compromise is broad enough that proving a manual cleanup would take more time than restoring safely

In those cases, rollback is not laziness.

It is often the cleanest risk-reduction move.

If you can return to a trusted state quickly, that is usually better than trying to surgically remove malware from an environment nobody really trusts anymore.

When manual cleanup makes more sense

Manual cleanup becomes more attractive when rollback would create serious operational damage.

Typical examples:

  • WooCommerce stores with recent orders
  • membership sites with new users or subscription changes
  • lead-generation sites with important form submissions
  • custom operational platforms where records changed after the backup point
  • sites where the available backups may already be contaminated

In those cases, “just restore yesterday’s backup” may sound neat but be commercially reckless.

A cleanup path can be slower and more technical, but still safer for the business.

The question is not just security. It is data loss.

This is where teams often get stuck.

Security people lean toward rollback because it gives a clearer clean-state story.

Operations people resist rollback because they do not want to lose fresh transactions, leads, or content.

Both instincts are reasonable.

That is why the decision should be framed as:

  • how trustworthy is the current environment?
  • how trustworthy is the backup?
  • what would rollback destroy?
  • what would manual cleanup leave uncertain?

That is a technical and business decision together.

If you need the underlying workflow around that choice, the WordPress incident response process page explains how I approach triage before deciding on restore, cleanup, or escalation.

Cases where rollback is overrated

Rollback is not automatically the “professional” answer.

It becomes less attractive when:

  • you do not know exactly when the compromise started
  • the backup chain itself may include the infection
  • the site has changed significantly since the clean point
  • integrations, orders, or customer data would need painful reconciliation afterwards

In those cases, rollback can simply move you to an older version of a still-messy situation.

Cases where cleanup is overrated

On the other hand, teams sometimes cling to cleanup because they do not want the inconvenience of rollback.

That is dangerous too.

If the site was broadly compromised through a malicious plugin update, hidden backdoor, or unknown credential exposure, doing “just enough cleanup” may leave you with false confidence.

If you have a genuinely clean restore point from before the compromise window, restoration may still be the smarter choice.

A practical decision framework

Ask these questions:

1. Do we have a backup we actually trust?

Not just a backup that exists.

A backup from before the incident, with enough confidence that it was not already contaminated.

2. What business data would we lose?

Orders, registrations, leads, content edits, support activity, bookings, subscriptions.

If rollback destroys important records, cleanup becomes more attractive.

3. How deep does the compromise look?

If you are seeing hidden admin users, wp-config.php edits, mu-plugins, redirects, or SEO spam, assume the cleanup needs to be real incident work rather than a quick plugin reinstall.

4. How quickly do we need confidence?

Sometimes the right choice is the one that gets the business to a trusted state fastest.

That might be rollback.

Or it might be a controlled cleanup because rollback creates too much operational fallout.

WooCommerce changes the answer

This is worth calling out separately.

WooCommerce cases often push the decision away from simple rollback because the site keeps accumulating commercially important data.

That includes:

  • recent orders
  • order status changes
  • customer accounts
  • coupon activity
  • plugin-driven automation
  • shipping or fulfillment state

That does not mean stores should never roll back.

It means the cost of rollback is usually higher, so the decision deserves more care.

What people should not do

A few common mistakes:

  • restoring a backup without checking whether it predates the compromise
  • updating the compromised plugin and assuming cleanup is done
  • deleting obvious malicious files while ignoring hidden persistence
  • choosing rollback or cleanup based only on convenience

Those are the decisions that create repeat incidents.

The honest answer

There is no universal rule.

If you have a known-clean restore point and little business data to lose, rollback is often the safer answer.

If the site is a live business system and rollback would cause bigger damage than a controlled cleanup, manual cleanup may be the better move.

The key is to decide deliberately, not emotionally.

If you need help deciding

If you are in the middle of that decision now, the most relevant next pages are:

Because once a WordPress incident becomes real, the question is not “which option feels simpler?”

It is “which option gets us back to a trustworthy production state with the least total risk?”