Practical security advice for website owners
Hacked WordPress Site: Repair It or Rebuild on a Clean Installation?
Security guidance · References checked 2 November 2026
In this guide
When a WordPress website is hacked, a complete rebuild can sound like the safest answer. Sometimes it is appropriate. Sometimes a focused recovery preserves valuable work with less disruption. Neither choice is reliable if it ignores compromised accounts, unreviewed data or the business activity that must continue.
Decide from the evidence, maintainability and recovery requirements. The goal is a trustworthy working system with a documented scope, not simply a new theme or an empty installation labelled “clean”.
Establish what can be trusted
Inventory the hosting, domain, administrator accounts, software sources, custom code and backups. Identify which components have reliable reference copies and which have an uncertain history. Record the incident symptoms and available evidence without assuming a specific attack technique.
A familiar design does not establish that its underlying code is trustworthy. Equally, a heavily customised site is not automatically beyond repair. A qualified assessment should explain which parts can be verified or replaced and where confidence is limited.
The WordPress hacked-site guidance provides general recovery context. It does not require every owner to rebuild, nor does it certify a repaired installation. Your decision needs the actual site’s condition and business requirements.
When targeted recovery may fit
Repair may be practical when the affected scope is understandable, trusted software can be obtained and the important data and customisations can be verified. The plan should include the access and configuration changes needed to reduce the chance of recurrence.
Ask how the provider will address files, relevant database content and any affected functionality. Replacing a single component may be enough for a specific finding, but it should not be presented as whole-site recovery without an appropriate investigation.
Compare the verification work as well as the editing time. A fast visual repair that leaves forms, orders or privileged access untested may not meet the business’s requirements. The proposal should state the evidence you will receive and the remaining limits.
| Decision area | Targeted recovery | Clean rebuild |
|---|---|---|
| Trusted components | Verify or replace affected components | Install trusted components and review migrated material. |
| Business records | Preserve and verify legitimate current data | Plan migration, cutover and reconciliation. |
| Acceptance | Test incident symptoms and key workflows | Test recovery scope plus migration, URLs and required features. |
When a clean rebuild deserves consideration
A rebuild may be sensible when software provenance is unreliable, abandoned dependencies dominate the site, essential custom code cannot be maintained or the repair would leave an unmanageable system. A broader redesign can also be a separate business choice.
Do not turn uncertainty into an automatic upsell. Ask the developer to explain why rebuilding is preferable, which risks it addresses and which remain outside it. A new installation on a still-compromised hosting account does not solve that account problem.
Define whether the quote covers recovery, content migration, redesign, new functionality and maintenance. These are distinct deliverables even if one provider performs them. An inexpensive rebuild that omits the business’s required workflows is not an equivalent alternative.
Plan what will be migrated
Separate public content, media, business records, settings, users and custom code. Each category needs an appropriate review and transfer method. Blindly importing the old database or copying every plugin directory can carry the uncertainty into the new environment.
Preserve valuable URLs and content where practical. If addresses change, create a reviewed redirect map and check internal links. Do not promise that a rebuild will preserve every search position or immediately restore rankings after an incident.
Use the WordPress migration guidance to understand platform considerations, while following the actual host and application requirements. A normal migration procedure still needs adaptation when the source installation may be compromised.
Protect ongoing orders and enquiries
Decide what happens while the new environment is prepared. If the old site continues receiving legitimate business records, define a cutover and reconciliation process. Launching an older database copy can silently lose recent orders, registrations or quote requests.
Identify the integrations that should remain live and those that must be disabled in the build environment. Use sandbox payments and controlled notifications for testing. A copied production configuration should not send duplicate customer messages or capture real payments.
Agree downtime, rollback and communication with the owner. Keep a responsible person available during launch. A technically successful file transfer is not a complete launch if the business cannot receive enquiries afterwards.
Secure access around the launch
Review hosting, domain, deployment and administrator access before treating the new environment as trusted. Rotate affected credentials through a coordinated process, revoke obsolete access and document the intended recovery route.
Use current supported software from trusted sources and limit installed components to what the site needs. Keep licences and vendor ownership under an arrangement the business understands. A rebuilt site should be maintainable by the next authorised developer, not dependent on undocumented archives.
Confirm backup storage and restoration arrangements for the new environment. Do not leave exported databases or migration packages publicly accessible after launch. Recovery preparation should not create another exposure.
Compare acceptance tests before deciding
Both approaches need tests tied to the original symptoms and business functions. Check relevant page types, mobile layouts, navigation, forms, account access, stored records and supported sandbox checkout where applicable. Inspect metadata, canonical URLs and redirects where the migration changes them.
Record the test outcomes and unresolved issues. A rebuild offers an opportunity to reduce complexity, but it is not a guarantee against future compromise. Maintenance, access control and appropriate monitoring still require ownership after handover.
Ask the provider to present repair and rebuild options with scope, exclusions, dependencies, expected deliverables and an honest estimate. Do not compare only a cleanup starting price with a full redesign price; the included work differs.
Get an assessment before committing
Send the public URL, symptoms, important workflows and any known problems with the software or hosting. Explain whether the existing design must be preserved and whether the site is still processing business activity. Keep credentials and private databases out of the initial enquiry.
NithuDev can discuss the recovery requirements and whether focused repairs or a separate redevelopment project fits them. The useful first outcome is an agreed plan that protects legitimate content and makes the scope clear, with additional work approved before it is charged.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.