Your WordPress site is hacked: the 24-hour recovery playbook

A practical 24-hour playbook for recovering a hacked WordPress site, in the order our team actually runs it.

If you have just realised your WordPress site is hacked, take a breath. The first hour matters, but you have time to do this right. The damage from rushing is usually worse than the damage from the hack.

Here is the order we run it on every hacked-site recovery engagement. It is not optional and the steps are not parallel — they build on each other.

Hour 0–1: contain the damage

Before you investigate anything, stop the bleeding.

Your WordPress site shouldn't be a side-project.

Plugin updates, backups, security, and emergency response — handled by senior engineers, on a fixed monthly fee. Your site runs. You go back to your business.

  • Take the site offline or display a maintenance page. Yes, this hurts SEO and conversions for a few hours. It hurts a lot less than a customer landing on a site serving malware.
  • Change the WordPress admin password from a clean device, not the one you usually log in from.
  • Rotate hosting and database passwords too. Attackers often pivot between admin, FTP, and database access.
  • Disable WordPress XML-RPC if you do not actively need it. It is a common pivot vector.

Hour 1–4: identify the entry point

You cannot clean what you do not understand. Cleaning the symptoms without finding the root cause is how sites get re-hacked within a week.

  • Check the modification dates on every PHP file in the WordPress root, wp-content/, and wp-includes/. Anything modified outside your normal deploy window is suspect.
  • Check user accounts. Look for admin users you did not create. Roles can be modified after the fact too.
  • Read the access log around the suspected breach time. Look for repeated POST requests to wp-login.php, xmlrpc.php, or theme/plugin files.
  • Check for unfamiliar scheduled tasks (cron entries) and database options.

Hour 4–12: clean and rebuild

Now the actual cleaning. The temptation to "just delete the bad files" misses the point — the attacker put back doors in places you have not looked yet.

  • Replace WordPress core, every plugin, and every theme from clean source. Do not keep the existing files and "scan" them. Replace them.
  • Restore the database from the most recent known-clean backup if you have one. If not, manually inspect every administrator user, every option ending in _options, and every active plugin row.
  • Delete unfamiliar files outside the standard WordPress folders entirely. There is no good reason for a random PHP file to live in /wp-content/uploads/.

Hour 12–24: harden and notify

You are not done when the site loads again. You are done when the next attempt fails.

  • Force every user to reset their password.
  • Install or re-configure a security plugin with active scanning, login attempt limiting, and file-integrity monitoring.
  • Submit the site to Google Search Console for security review if it was flagged with a "deceptive site" warning. Most flags clear within 72 hours of a clean re-scan.
  • If customer data was potentially exposed, notify customers and your hosting provider in writing within 24 hours. Document what happened, what you did, and what you changed.

What this looks like if you outsource it

If this is your first WordPress hack, the time investment is brutal — a typical first-time owner spends 12–20 focused hours doing this poorly, then re-does it three weeks later when the back doors fire again.

The recovery service we run does the entire 24-hour playbook above and includes a 30-day re-infection warranty. If anything from the original compromise resurfaces in the first month, we clean it again at no charge.

Your WordPress site shouldn't be a side-project.

Plugin updates, backups, security, and emergency response — handled by senior engineers, on a fixed monthly fee. Your site runs. You go back to your business.

If this was useful, share it: Copied