Cleaning a hacked website versus rebuilding it
After a compromise the instinct is to clean and carry on. When the entry point cannot be established, a rebuild on a clean stack is the only way to be sure.
The short answer
After a compromise, the instinct is to clean the site and carry on. Sometimes that is right: a well-built, recently backed-up site with a clear entry point can be restored from a known-clean version, patched and monitored in a day. Often it is not: an old, plugin-heavy site with no reliable backup, an unclear entry point and a history of trouble cannot be cleaned with confidence, because you cannot prove what was left behind. A rebuild on a clean, modern stack removes every unknown at once, usually in comparable time, and ends with a better site. The decision rests on four questions.
Clean or rebuild: the four questions
| Question | Points to cleaning | Points to rebuilding |
|---|---|---|
| Do you know how they got in? | Yes, specifically, and it can be closed | No, or “probably a plugin” |
| Do you have a known-clean version to restore? | A tested backup from before the compromise, or a repository with history | No backup, or only backups that may already be infected |
| Is the platform worth keeping? | Modern, maintained, few dependencies, someone owns it | Old, dozens of plugins, abandoned components, nobody owns maintenance |
| Is this the first time? | Yes | It has happened before, or spam keeps returning |
What a proper clean involves
- Contain: take the site offline or behind a holding page; preserve logs and a copy of the compromised state.
- Identify the entry point from logs, file timestamps and known vulnerabilities in what was installed.
- Restore from a known-clean version, not from the current state minus the obvious malware.
- Compare every file against that clean version; anything different is examined.
- Close the entry point: update, remove or replace the component; fix the configuration.
- Rotate every credential the site touched: admin, database, hosting, API keys, email.
- Remove unknown users, tasks and keys; review every plugin and theme.
- Monitor closely for weeks: file changes, new users, outbound traffic, search console warnings.
What a rebuild involves
Export the content: text, images, structure, redirects. Review it, because compromised sites often contain injected pages and links. Rebuild on a static stack with a small, maintained dependency set, in a repository you own, deployed through a pipeline, with monitoring and a network layer in front. Map old addresses to new with redirects so search rankings survive. Retire the old hosting entirely; do not leave the compromised site reachable anywhere. The result has no code in common with what was compromised, and a far smaller surface for next time.
What this means for you
Ask the four questions before anyone starts cleaning. If the entry point is clear, a clean version exists, the platform is worth keeping and it is the first time, clean properly and monitor. If any answer is no, rebuild on a clean stack, carry the content over, and retire the old site completely. Either way, rotate everything and put monitoring in place, because whichever you choose, someone will try again.
Frequently asked questions
The hosting company cleaned the site and it works again. Are we done?
Not until three questions are answered: how did they get in, has that door been closed, and how do you know nothing else was left behind? A clean that removes visible malware without answering those is a pause, not a fix. Reinfection within weeks is the usual result. Ask for the entry point and the evidence.
How long does a rebuild take compared with a clean?
A careful clean of a plugin-heavy site can take days and still leave doubt. A rebuild of a typical business site on a static stack, from existing content and design, takes a similar time or less, and ends with certainty and a better site. For large or complex sites the comparison shifts; for a small business site it favours the rebuild.
Can we keep our content if we rebuild?
Yes. Text, images and structure are exported from the old site, reviewed, and brought into the new one. What is not carried over is the code, the plugins and the database that were compromised. Content is the asset; the code was the liability.
Sources
- web.dev: Help, I think I have been hacked (accessed 2026-09-11)