The first hour is about reducing harm and preserving options. Do not start by deleting random files. Confirm the symptom, protect visitors if necessary, preserve a backup/evidence copy and secure the access path before broad cleanup.
Confirm the business impact
Check whether the site is down, redirecting, serving fake CAPTCHA/downloads, showing spam pages, affecting checkout or only showing a warning. The safest response depends on what visitors are exposed to.
Preserve evidence and a rollback point
Create a copy of the current files and database before cleanup. Record timestamps, warning messages, suspicious users and relevant hosting/security logs. Evidence becomes much harder to reconstruct after files are overwritten.
Restrict dangerous behavior if needed
If visitors are exposed to malware, phishing or checkout skimming, temporarily restricting public access can be safer than leaving the compromised flow live while troubleshooting.
Secure privileged access
Review WordPress administrators and hosting/SFTP/SSH access. Disable clearly unauthorized accounts and prepare to rotate credentials after the attacker’s active access path is controlled.
Do not trust the visible symptom
A redirect, injected script or spam page may be generated from a database option, MU plugin, cron event or hidden backdoor. Treat the visible payload as the starting point of investigation.
Prepare the recovery scope
List WordPress core, active theme, plugins, MU plugins, custom code, CDN/WAF, external scripts and neighboring sites under the same hosting account. This map helps avoid cleaning one layer while another reintroduces the infection.
If the site is currently redirecting visitors, serving malicious downloads, showing fake verification pages or affecting checkout, prioritize visitor safety and preserve evidence before aggressive cleanup.
Related WP•FIX resources
FAQ
Should I take the site offline immediately?
Only when the current behavior is dangerous enough to justify the business impact. Malicious downloads, phishing and payment-data risk are strong reasons to restrict affected traffic.
Should I update all plugins during the incident?
Capture evidence first. Updates may be part of remediation, but broad changes can overwrite useful timestamps or make the original entry point harder to identify.
Can I delete unknown admin users?
Clearly unauthorized accounts should be controlled, but preserve evidence about when/how they were created before deleting them.
What if I cannot access wp-admin?
Hosting, filesystem, database and logs are often enough to begin incident response.
Need help recovering a hacked WordPress site?
Send the URL, visible symptoms and any hosting or Google warning text.
Open an incident