Rebuild or Clean? Making the Call on a Hacked Site

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Somebody has told you to nuke it and start over, somebody else has told you a cleanup is fine, and both sound plausible. The honest answer is that it depends on a small number of specific factors, and most sites should be cleaned. But not all of them, and knowing which case you are in saves you either a lot of money or a lot of repeat visits.

Why cleaning is usually right

A competent cleanup removes the infection while keeping your content, your URLs, your rankings, your customizations and your customer data exactly where they are. It is faster, cheaper, and carries far less risk of breaking something that currently works.

The argument against cleaning is usually stated as never being able to be sure you got everything. That concern is legitimate in principle and overstated in practice: core, plugins and themes get replaced wholesale from clean sources rather than repaired, which means the only judgement calls are in your uploads, your custom code and your database. That is a tractable surface, not an unknowable one.

When rebuilding is genuinely better

A few cases, and they are fairly clear when you are in one. When the site was already due for replacement — running an obsolete theme, abandoned plugins, an ancient PHP version — the cleanup money is better spent on the rebuild you were going to need anyway.

When the compromise is old and deep, with months of undetected access and multiple layers of persistence, the effort of proving a cleanup complete can exceed the cost of starting fresh. When the site is small enough that rebuilding is genuinely quick. And when the site has been cleaned repeatedly and keeps coming back — though before concluding that, read my guide on reinfection loops, because the cause is often a neighbouring site or a credential rather than anything you failed to clean.

What rebuilding does not solve

This is the part that gets missed and it is the reason people rebuild and get hacked again a fortnight later. A rebuild replaces the site; it does nothing about the entry point.

If the compromise came through stolen credentials, the new site is reachable with the same credentials. If it came through another site in the same hosting account, the new site sits next to the same infected neighbour. If it came through a compromised hosting account, the attacker still has the account. And if you migrate your database across to preserve your content, you may migrate the infection with it. Rebuilding without identifying the entry point is an expensive way to change nothing.

The factors that actually decide it

How much custom work exists. A site with heavy customization, a bespoke theme and years of configuration is expensive to rebuild and straightforward to clean. A simple brochure site on a standard theme is quick to rebuild either way.

How long the compromise ran, since a hack caught in a week is a much smaller surface than one that ran for months. Whether your content is separable from your infrastructure. Whether the stack is current or overdue for replacement anyway. And what your backups look like — a verified clean backup from before the compromise changes the arithmetic considerably, which my guide on backups versus cleanups covers.

The middle path

Often the best answer is neither extreme. Keep the database after cleaning it properly, and rebuild the file side from clean sources — fresh WordPress, fresh plugins from the repository, fresh theme, with only genuinely custom code reviewed and carried across by hand.

That gets most of the confidence of a rebuild while preserving your content, your URLs and your rankings. It is what a thorough cleanup largely amounts to anyway, and framing it that way makes the scope clearer than arguing about labels.

Making the decision

Ask three questions. Do I know how they got in, and can I close it? Is my stack current, or was this site due for replacement regardless? How much of what exists is genuinely irreplaceable custom work?

If you can close the entry point and the site has real value in its current form, clean it. If the stack was overdue and the entry point is closed either way, rebuild and get something maintainable. If you cannot identify the entry point at all, neither option is safe yet, and that is the thing to solve first — which is where my malware removal service starts, because the answer determines everything else.

Common questions

Is rebuilding safer than cleaning?

Only in specific circumstances, and less often than people assume. A rebuild does not address the entry point, and if you migrate the database to keep your content you can carry the infection across. A competent cleanup that replaces core, plugins and themes from clean sources gets you most of the same assurance.

Will I lose my rankings if I rebuild?

You risk it. Changed URLs, changed content and changed structure at the moment search engines are re-evaluating your site after a hack is a difficult combination. If you do rebuild, keep the URL structure identical and the content substantially the same to minimise the disruption.

Can I keep my database and rebuild everything else?

Yes, and it is frequently the best approach. Clean the database properly, then rebuild the file side from fresh sources with only genuinely custom code reviewed and carried over. You keep content, URLs and rankings while eliminating any doubt about the files.

My site has been cleaned three times and keeps getting hit. Should I rebuild?

Not yet. Repeated reinfection almost always means the entry point was never found — commonly another site in the same hosting account, a stolen credential, or persistence in a place nobody checked. Rebuilding without answering that question just gives you a new site with the same open door.

How do I decide if I cannot tell how they got in?

That is the thing to resolve before choosing. Neither cleaning nor rebuilding is safe while the entry point is unknown, because both leave it open. Work through your logs and file timestamps, or get someone to, and make the decision once you have an answer.