Unexpected redirects, unknown administrators or injected spam deserve a coordinated incident review. Save the observed evidence and involve your host early, especially where orders or customer accounts are involved.
Recovery needs containment, trusted files and data, repaired access and verification under the original failing conditions.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Evidence | Immediate priority | Recovery check |
|---|---|---|
| Harmful redirects or content | Protect visitors and preserve URLs | Logged-out and affected-device comparison. |
| Unknown users or access | Review accounts and sessions | Authorized access only after cleanup. |
| Files return after removal | Unresolved entry point | Accounts, related sites and persistent jobs. |
| Proposed backup restore | Confirm a clean date and preserve legitimate recent data | Business records and affected content. |
Preserve the evidence before cleaning
Incident record: note symptom, first observed time, affected URL, recent changes and containment actions. Label the current evidence backup as potentially compromised. Keep it private and separate from a trusted restore point.
Record the affected URLs, redirect destinations, warning text, unfamiliar users, and the time you noticed them. Keep relevant hosting and access logs. A private copy of the current files and database can support investigation, but label it as potentially compromised and do not treat it as a clean restore point.
A redirect may appear only for logged-out visitors, search traffic, or particular devices. Compare those conditions without following suspicious destinations or bypassing browser warnings. Give the investigator the observed pattern rather than relying only on how the page looks to an administrator.
If visitors could be exposed to harmful content, work with the host to restrict the affected service or show a safe maintenance page. On a business site, consider how containment affects orders and communications so important records are preserved.
Review access as well as files
Check WordPress users, hosting accounts, SFTP access, application passwords, and other integrations. An unfamiliar administrator is one sign, but a legitimate account with stolen credentials may leave no new user behind.
From a trusted device, secure the accounts involved and revoke unauthorized sessions or access with the provider’s help. A site cleanup can fail if the same compromised account can immediately upload another payload. Keep recovery access available while changes are made.
The likely entry point also needs attention: an outdated vulnerable extension, an untrusted package, reused credentials, or another site in the account may be involved. Treat that as a question for evidence, not a conclusion based solely on the first infected file.
Restore trusted components without losing site data
- Establish the incident scope with the host or responder.
- Preserve evidence and legitimate recent data.
- Restore reviewed files and database content from trusted sources.
- Repair the entry point and unauthorized access.
- Verify the original symptoms and normal business functions.
A clean package from WordPress.org or the developer can replace compromised core, plugin, or theme files. Custom code needs review separately. Compare the installation with the expected package contents, including unfamiliar files that a normal update may not remove.
The database can hold injected scripts, spam posts, altered options, or unauthorized users. Cleaning only PHP files does not address those changes. Upload directories, scheduled jobs, and configuration files also deserve inspection.
A known-clean backup may be the best recovery route, but its date matters. A backup made after the compromise can restore the same infection. A much older backup can remove recent orders or content. Plan how to preserve legitimate recent data before replacing the live database.
Check related sites and connected services
If several sites share one hosting account, ask the provider whether the incident affects more than one installation. Restoring one site while another remains compromised may allow the problem to return, depending on account isolation and access permissions.
Review email sending, payment integrations, and other services for unexpected activity. Preserve the records needed to establish what occurred. If personal data may have been exposed, obtain appropriate professional advice about the response rather than assuming a visible cleanup settles every obligation.
Update the repaired components and remove unused, untrusted packages once their role is understood. Keep only the access that the site actually needs. WordPress’s hardening guidance is useful here, but settings should fit the hosting arrangement rather than being copied indiscriminately.
Verify the cleanup under the original conditions
Check the affected URLs as a logged-out visitor and review redirects, page source, users, scheduled jobs, and fresh logs. A scanner result is useful evidence, but no single green result proves every component is clean.
Test ordinary business functions too. A recovered homepage is not enough if forms, checkout, or transactional messages stopped working during containment. Monitor for returning files or accounts, which can indicate an unresolved entry point.
If Google Search Console reported a security issue, follow its review process after the relevant problem is actually resolved. A security review and ordinary indexing are separate processes; repeated indexing requests do not remove a malware warning.
For the recovery framework, see WordPress’s hacked-site guidance and hardening documentation. Keep your own incident notes, clean backup date, and access changes together so a later recurrence can be investigated efficiently.
Confirm recovery beyond one scanner result
Review affected pages, users, scheduled work, redirects and fresh logs. Test forms and other normal functions, and check that suspicious changes do not return. If Search Console reports a security issue, use its security review process after remediation. Keep the clean restore date and confirmed scope in incident notes.