Recover a suspected hacked WordPress site by preserving evidence, containing further access and restoring a clean, verified service through an authorised plan. Record the symptoms before changing files. Keep the recovered copy, access review and public checks connected so the site owner can understand what was restored and which questions still need investigation.
Start with what has actually been observed: an unexpected redirect, an unfamiliar account, changed content or a warning from a relevant service. Record the affected URL and context. Give one person responsibility for coordinating the response so parallel changes do not obscure the evidence or leave conflicting recovery copies.
What should be preserved before cleaning begins?
WordPress’s hacked-site guidance provides the starting point. WordPress’s recovery guide starts actionable work with documentation. The incident notes should record when the issue was noticed and its timezone. Retain the observation itself alongside the time, including the route or account context needed to understand it.
The guide asks about recent plugin, theme or widget changes. The guide recommends recording the host environment. Gather that context from the actual maintenance record and hosting owner. A recent change is useful evidence to investigate, while its timing alone does not establish the cause.
The guide recommends preserving another snapshot before cleaning. Agree where the affected material will be retained and who may access it. Keep the preserved copy distinct from the clean recovery target so a later reviewer can examine what was observed without confusing it with the version intended for service.
Record the scope of the retained material. Files, database content and relevant logs may answer different questions. Ask the responsible operator to identify what is available and preserve it through the approved incident process, with sensitive information handled in the appropriate private location.
How should containment be coordinated?
Name the person who can authorise changes to the site, hosting and access routes. Write the immediate objective and affected scope before changing shared infrastructure. The hosting owner may need to assess whether another site or service is involved, while the application maintainer investigates the WordPress installation.
Changing WordPress secret keys can end existing logged-in sessions. Treat that documented mechanism as part of an access plan with the responsible operator. Review the actual accounts and access paths in use, and retain the evidence and timing of approved changes so the response remains traceable.
WordPress’s hardening guide describes broader containment. Separate databases and users are a documented containment strategy for multiple installations. Assess the actual hosting arrangement with its owner rather than assuming that one site’s administration boundary describes the whole environment.
Keep essential communication and recovery access available through an agreed route. The people responding need to know who is making each change and how to report a new observation. Avoid scattering instructions across informal messages that nobody has reconciled with the incident record.
| Recovery question | Evidence or decision to retain | Responsible role |
|---|---|---|
| What was observed? | Symptoms, affected route and time context | Incident coordinator |
| What is preserved? | Identified snapshot and relevant records | Hosting or backup owner |
| What access changes are approved? | Scope, authorisation and resulting state | Access owner |
| Which copy will be restored? | Provenance and clean-state review | Recovery maintainer |
| What proves service is usable? | Public and administrative verification results | Site owner and maintainer |
This original worksheet makes evidence, action and accountability visible together. Use it to coordinate the response, adding the exact requirements and tools appropriate to the installation being recovered.
How should a clean recovery copy be selected?
The hardening guide recommends regular backups and awareness of the installation’s state. Use the backup record to identify the candidate copy and its provenance. Ask what evidence supports its suitability and which content or operating changes occurred after it was taken.
A familiar backup date alone does not answer whether the copy is suitable. Review the candidate with the incident context and inspect it in the agreed recovery arrangement. Record the component sources, relevant configuration and unresolved evidence before deciding that it can become the service copy.
The hardening guide advises keeping WordPress updated. Plan applicable updates and compatibility checks with the maintainer as part of recovery. Keep the intended component state explicit so the restored site does not inherit an unexplained combination of old and replacement files.
WordPress distinguishes external remote scans from application-level scans. Record which checks were used and what each could inspect. Combine those observations with the file, database and access review needed for the actual incident, rather than treating one scan result as an explanation of the entire event.
Which checks should precede a return to normal service?
Define representative public journeys and administrative tasks before restoring the service route. Include the affected URL and any essential enquiry, sign-in or content workflow relevant to the site. Retain the observed result and environment for each check so the site owner can assess what was verified.
Review access again after the recovery work. Confirm the intended accounts and operational routes through the approved process, with the responsible owner checking the resulting state. Keep that review tied to the recovered environment rather than assuming that a change on a temporary copy reached every destination.
Agree how new observations will be monitored and escalated after return to service. Name the person receiving reports and the material they need to investigate them. Record remaining uncertainty clearly, especially where evidence about the original entry path is incomplete.
Original preserved-copy and clean-restoration exercise
Use a fictional compromised-site scenario in an isolated environment, with invented content and no live customer data. Prepare an affected sample copy and a separately identified recovery candidate. The exercise follows the response record, approved containment and the checks for returning the sample service.
First, document the sample symptom, time context and relevant recent change. Identify the preserved copy and ask another reviewer to distinguish it from the recovery target using the record alone. Resolve any ambiguity in naming or provenance before continuing.
Next, follow the approved sample access and restoration plan. Retain the actions taken and inspect the resulting state. Keep any diagnostic finding separate from the recovery decision so the team can explain both without confusing an observation with a conclusion.
Finally, perform the agreed public and administrative checks on the restored sample. Have the site owner review the evidence and remaining questions with the maintainer. Assign follow-up investigation and monitoring ownership, retaining the exercise record for the next recovery review.
For related work, see WordPress and hosting. Get started with the observed symptoms, available backups and the people responsible for access and recovery.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.