Cleaning in place assumes you can identify every malicious change and trust what remains. A rebuild starts with verified software and imports assessed business data, making the trust decision explicit.
Choose based on scope, provenance and recurrence—not simply which option appears faster.
Rebuild after high-privilege compromise
Stolen hosting/server/deployment access can change WordPress, configuration, cron and backups. If system packages or root-level controls changed, rebuild the server through the infrastructure owner as well.
An administrator-only compromise may still require application rebuild if plugins/files were uploaded. Record capabilities actually used.
Do not treat a password reset as a code integrity check.
Rebuild when provenance is missing
If custom plugins/themes have no trusted repository, commercial package versions are unknown or core files were manually edited, there is no reliable baseline for what "clean" means.
Reimplement required custom behaviour from specification or reviewed source. Do not carry unexplained code forward because the design depends on it.
Inventory owners and licences for future maintenance.
Rebuild after repeated reinfection
When files, users or redirects return after documented cleanup, persistence or stolen access remains. Repeating scans/deletions without expanding scope increases downtime and erases evidence.
Freeze the incident state, check database/cron/hosting/DNS/email and rebuild across the confirmed boundary.
Monitor recurrence triggers in isolation before reopening.
Rebuild widespread database or upload corruption
Mass injection across options, posts, page-builder templates and custom tables may make row-by-row confidence impractical. Executable files mixed through uploads/backups create similar uncertainty.
Create a fresh schema/application and import validated content through supported tools. Preserve orders/users only with relationship and security review.
Do not delete all customer media/content merely to simplify the job.
Compare risk, time and evidence
Estimate the time to establish trust, not only to make pages load. Cleaning may be quicker when one well-evidenced file changed; rebuilding may be faster when hundreds of unknown differences need review.
Score access level, persistence, data integrity, code provenance, backup quality and reinfection history. Document who accepts residual risk.
Do not let sunk custom-development cost force untrusted code back into production.
Consider business continuity
Estimate rebuild time, safe maintenance/fallback routes, recent orders/leads and integration testing. A rushed in-place cleanup can reopen sooner but fail again during sales activity.
Prioritise a static information page and controlled order/lead handling while the trusted build is prepared.
Communicate verified status, not optimistic completion times.
Define what will be imported
Separate trusted code, reviewed custom code, database content, media and current business transactions. Record acceptance rules for each.
Do not import wp-config.php, plugin binaries, cache, backups or scheduled tasks wholesale. Rotate every secret the compromised environment could read.
Keep an exclusion list with owners.
Preserve SEO and integration continuity
Keep canonical URLs, redirects, structured data, media references and language paths where they are legitimate. Rebuild sitemaps and return correct 404/410 for hacked URLs.
Inventory analytics, Search Console, SMTP, CRM, payment and webhook ownership before replacement. Issue new secrets and test sandbox endpoints.
A secure rebuild should not silently break lead/order measurement.
Build a clean environment
Use supported PHP/WordPress, verified packages, separate site credentials, least privilege, MFA and protected backups. Restrict public access until tests pass.
Recreate configuration from documented values and inspect DNS/CDN/tag-manager/payment accounts. A new WordPress root on a compromised hosting account is not a full rebuild.
Automate repeatable deployment where practical.
Plan rollback without restoring risk
The rollback target should be safe maintenance or the last verified clean release, not the compromised root. Record document-root/DNS changes and prevent two writable stores from accepting orders simultaneously.
Preserve recent transactions during cutover and assign an owner for reconciliation.
Test before and after release
Verify roles, login, forms, checkout sandbox, webhooks, cron, mail, redirects, uploads, cache, mobile/languages and backups. Run original incident indicators and recurrence cycles.
After switch, monitor file/database/account changes, outbound mail and provider alerts. Retain old evidence isolated.
Request an emergency rebuild when trust boundaries or custom provenance are unclear. Share architecture, inventories and managed access—never archives, malware, private keys or customer databases publicly.