WordPress Post-Hack Security: The 12 Steps That Stop the Second Hack

Why the cleanup is not the end of the incident

A malware cleanup answers one question: “what malicious code can we find right now?” It does not answer the questions that determine what happens next — how the attacker got in, what they took, what access they still hold, and whether anything survived the sweep. Attackers know most site owners stop caring the day the warnings disappear, so they plant multiple backdoors and return weeks later, often with automated tooling that re-tests every site they have ever compromised.

This is why sites that get hacked once so often get hacked again: the visible infection was treated, the compromise was not. The steps below are the difference, grouped into the order you should do them.

Phase 1 — Lock the attacker out (day one)

Assume the attacker still has at least one working set of credentials. Until everything is rotated, nothing else you do is reliable.

1. Rotate every WordPress password. Every administrator and editor account, without exception — including accounts belonging to former staff and old agencies, which are better deleted outright.

2. Rotate the credentials WordPress itself uses. The database password in wp-config.php, and fresh WordPress salts so every existing login cookie — including the attacker’s — is invalidated instantly.

3. Rotate hosting and transfer credentials. Hosting control panel, SFTP/SSH, and any deployment keys. If the attacker reached the hosting account rather than just WordPress, cleaning WordPress alone achieves nothing.

4. Rotate API keys and integration secrets. Payment gateways, transactional email, CRM connections, backup services — any secret stored in the site’s files or database should be treated as read by the attacker.

5. Audit the user table. Look for administrator accounts you do not recognise, recently changed email addresses on legitimate accounts, and users with roles higher than they need. Attackers routinely create innocuous-looking admin users as a fallback, with names like “wp_support” or copies of real staff names.

Phase 2 — Close the door they used (week one)

6. Identify and patch the entry point. If your cleanup provider cannot tell you how the attacker got in, that is a red flag — root-cause identification is the difference between a professional recovery and a cosmetic one. The most common entry points are a vulnerable plugin or theme, a brute-forced or reused password, and a compromised neighbouring site on the same hosting account.

7. Remove what you do not use. Every deactivated plugin and unused theme is attack surface that nobody is watching. Delete them — deactivated is not safe, deleted is.

8. Harden the obvious weak points. Enforce two-factor authentication on all admin accounts, disable XML-RPC if nothing depends on it, and disable file editing in the dashboard. None of this requires a developer, and together it closes the routes most automated attacks try first.

9. Reset your backup regime. Your existing backups may contain the infection — and the backdoors. Take a fresh, verified-clean full backup immediately after the cleanup and hardening, store it off the server, and mark older backups as suspect so nobody innocently restores the compromise back onto the clean site.

Phase 3 — Watch for what the cleanup missed (days 1–30)

10. Run daily integrity and blocklist checks. File-integrity monitoring catches new or modified files — the signature of a surviving backdoor being used. Blocklist monitoring catches Google flagging the site before your customers tell you about it. A free scan is a reasonable spot check; during the 30-day window you want it happening automatically, every day.

11. Review what search engines see. Check Google Search Console for security issues, unfamiliar sitemaps, unauthorised owners, and indexed URLs you did not create — SEO-spam infections are frequently invisible in the browser and obvious in the index. If the site was blocklisted, confirm the review request went through and the warning cleared.

12. Complete your data-breach assessment. UK businesses have 72 hours from becoming aware of a qualifying breach to notify the ICO, so this cannot wait until the technical work is done. Our guide to whether a hacked website needs reporting to the ICO walks through the assessment — and document your reasoning even if you conclude no report is required.

The uncomfortable truth about post-hack discipline

Almost nobody sustains this manually. The first week after a hack, everyone checks everything. By week three, the daily checks are weekly. By month two, the site is exactly as unwatched as it was before the incident — except now it is on lists of previously compromised sites that attackers actively revisit.

That is the honest argument for putting a hacked site on a monthly plan rather than a good-intentions checklist: not that the tasks are difficult, but that they only work when they happen every day, indefinitely, including the weeks nobody is thinking about security. It is also why we back every recovery we perform with a 30-day reinfection guarantee — the reinfection window is when protection earns its keep.

If your cleanup is done and you want the post-hack window covered properly — monitoring, hardening, and a team already familiar with incident response if anything resurfaces — a security retainer exists for exactly this situation.