WordPress Malware Recovery Checklist: Evidence, Cleanup and Verification
A successful restore and a clean homepage are only part of malware recovery. The response also needs an owner, preserved evidence, a review of the suspected entry point and verification of the site’s important workflows. This checklist helps a business coordinate that work with its host and maintainer.
If you only have an unexplained timeout or server error, first use the website down troubleshooting checklist. Record the observations rather than labeling every outage a hack. If a provider has flagged harmful activity or restricted the account, start its incident process promptly.
1. Open an incident record and name the responder
WordPress’s hacked-site guidance recommends documenting symptoms, observation time and timezone, and recent changes. It also recommends contacting the hosting provider and preserving a copy before cleanup. Include the affected URLs, warning text, provider reference and actions already taken. Keep sensitive logs in an approved private channel.
Ask who leads the response and who can authorize containment, cleanup and replacement of live data. Use the support-ticket checklist for evidence and the security responsibility guide to identify uncovered work. A developer, host and security specialist may have different responsibilities.
2. Agree on containment and preserve recovery choices
Ask the responder which restrictions are necessary to limit harmful activity and what those restrictions mean for customers. Record the time, reason and reversal criteria for each action. Preserve the current state and available logs under appropriate access controls; label a potentially infected copy so nobody mistakes it for a clean recovery point.
Do not override a host’s suspension or remove protections to make the homepage accessible. Ask what evidence and verification the provider requires before service can resume. If the response requires expertise beyond the site’s maintainer, establish that assistance before attempting destructive cleanup.
| Decision | Evidence needed | Approval owner |
|---|---|---|
| Restrict affected services | Observed behavior and the responder’s containment proposal. | Incident lead and business owner. |
| Choose a backup | Candidate date, known symptoms and inspection results. | Responder and owner of current business data. |
| Replace or clean components | Affected scope and a trusted replacement or remediation plan. | Qualified maintainer or cleanup service. |
| Restore live data | Expected gap in content, orders, users or other transactions. | Business owner; relevant integration owners. |
| Reopen the site | Cleanup evidence, access review and workflow results. | Incident lead, with provider clearance if required. |
3. Inspect the recovery point before replacing production
The newest backup is not automatically the best choice. Ask the responder whether the compromise may predate the first visible symptom. Inspect candidate copies in an appropriately isolated environment, and record why the chosen point is suitable. Review backup retention and the restore rehearsal checklist for availability and verification.
For a store, agree how to reconcile newer orders, payments and customer activity before a database restore. Use the WooCommerce order recovery guide. Do not replay a payment or fulfilment action simply because its local record is absent after recovery.
4. Ask for cleanup evidence and an access review
Have the responder explain what was inspected, what was changed, what remains uncertain and how the suspected entry point was addressed. Include account access, installed components and the relevant hosting environment in that discussion. Arrange credential and session handling through the incident lead, using a trusted device and supported procedures.
For technical maintainers, WP-CLI core checksum verification compares core files with WordPress.org checksums. Plugin checksum verification checks plugins against WordPress.org checksums where available. A checksum result has a defined scope: it does not establish that the database, uploads, custom code or entire server are clean. Ask what additional investigation covers those areas.
5. Verify recovery and follow up on search warnings
Check the workflows customers rely on: authorized login, forms, transactional email, checkout and scheduled work as applicable. Record the test result and remaining issues. Review relevant monitoring and alert recipients with the uptime monitoring checklist; availability monitoring alone does not certify security.
If Google reports a security issue, follow its Security issues report guidance. Its example URLs may be incomplete. Fix all reported issues across the site, test the fixes and request a review when that work is complete. A review request does not guarantee immediate removal of warnings.
Close the incident with a usable handover
Keep the timeline, chosen recovery point, data reconciliation, cleanup scope, test results and follow-up owners together. Set a review date for unresolved work. Read WAF versus malware scanning before treating a new firewall or scan subscription as a complete recovery plan.
Keep restoration and incident closure separate
A hypothetical restore removes visible unwanted content but leaves the suspected access route unreviewed. Record that as an unresolved incident item rather than declaring recovery complete. Ask the responder to explain cleanup scope, access changes and remaining uncertainty, then verify business workflows. Reconcile newer records before replacing live data and retain the provider’s reopening conditions where service was restricted.
Sources and scope
Official WordPress, WP-CLI and Google documentation checked October 5, 2026. This is HRL’s coordination checklist, not a diagnosis of a particular incident or a report of cleanup performed by HRL.