Most hacked WordPress sites we recover share the same five mistakes: an outdated plugin, an admin account named "admin" with a weak password, file editing left enabled, no off-site backup, and a hosting account that hasn't been patched in years. None of these requires sophistication to exploit — most compromises come from automated scripts running known exploits at scale.
Here is the 12-step checklist we run on every site we manage. If you run a WordPress site, this is the bar.
The checklist
1. Run a supported PHP version
PHP 7.x is end-of-life and unpatched; PHP 8.1+ is the current baseline. Sites on dead PHP branches are walking targets because every known vulnerability stays exploitable forever. Check your version in your host's dashboard and upgrade — a responsible host makes this a one-click job, and tests staging first.
2. Keep core, themes, and plugins current
The overwhelming majority of WordPress compromises exploit known vulnerabilities in plugins and themes — ones with published fixes that were never applied. Updates are not optional hygiene; they are the security control. If you can't update promptly, at minimum subscribe to vulnerability feeds (Wordfence and Patchstack publish them) and treat "exploited in the wild" advisories as same-day events.
3. Kill the "admin" user
A username of admin hands attackers half the credential pair. Create a new administrator account with an unguessable name, reassign all content to it, and delete the old one. Pair this with strong, unique passwords — a password manager, not your memory.
4. Enforce two-factor authentication for every privileged account
2FA on all administrator and editor accounts. It is the single highest-leverage control on this list: credential stuffing and phishing stop dead at a TOTP prompt. Free plugins (Two Factor, WP 2FA) cover this; there is no cost argument against it.
5. Put the site behind a web application firewall
A WAF blocks exploit attempts before they reach WordPress — SQL injection, path traversal, and the constant bot-probe traffic. Cloudflare, Sucuri, or your host's firewall. Virtual patching via WAF also buys you time when a plugin vulnerability drops before an update is available.
6. Disable the built-in file editor
WordPress ships with an in-dashboard editor that lets admins modify theme and plugin PHP directly. If an attacker gets an editor-level session, that's a remote code execution endpoint you handed them. One line in wp-config.php closes it: define('DISALLOW_FILE_EDIT', true);
7. Lock down file permissions
Directories at 755, files at 644, wp-config.php at 600 or 640. World-writable files and directories are a common finding in post-breach forensics — and they're usually the result of a hosting migration gone wrong or a plugin that "fixed" a permissions error the lazy way.
8. Change database table prefix and audit DB credentials
The default wp_ prefix makes SQL injection attacks marginally easier to script. More importantly: the database password in wp-config.php should be unique to that site, rotated if it ever appeared in a log or a migration export, and never shared across sites.
9. Backups: off-site, automated, tested
A backup on the same server is not a backup — ransomware and wipers take the whole directory. Automated daily backups stored off-server (or with your provider), with retention long enough to catch slow-burn compromises, and — the part everyone skips — a tested restore. An untested backup is a hope, not a control.
10. Monitor file integrity
Malware typically enters as small modifications to legitimate files: a line of obfuscated PHP in functions.php, a rogue file in uploads. File integrity monitoring (Wordfence, Sucuri, or host-level scanning) alerts on unexpected changes. Daily scans minimum; catch an injection on day one and cleanup is trivial, catch it on day thirty and the whole install may be compromised.
11. Audit user accounts and unused code quarterly
Every dormant admin account is an unmonitored entry point; every abandoned plugin is unpatched attack surface. Quarterly: delete users who no longer need access, remove deactivated plugins and unused themes entirely (not just deactivate — delete), and review what's left against what you actually use.
12. Watch uptime and traffic anomalies
Compromised sites often show symptoms before anyone gets an alert: sudden traffic spikes (your server is spamming or mining), unexpected redirects, Google flagging the site, or the site going down when injected code breaks. Uptime monitoring plus a monthly glance at traffic patterns catches these early.
What to do if you're already compromised
Don't panic-edit. Take the site offline or into maintenance mode, preserve a copy of the infected files for forensics, and rebuild from the last known-clean backup after closing the entry point. If the entry point isn't obvious, restoring without finding it just resets the clock — the attacker still has the door. That investigation is most of what we do when clients arrive with a hacked site; the fix is usually one of the five mistakes at the top of this article.
If you'd rather never find out what a compromise feels like, our managed plans run this checklist as baseline — updates tested before deployment, daily off-site backups, security monitoring with humans who answer. See pricing or run the free AI Visibility Audit to check the other half of modern site hygiene: whether AI systems can even see your site at all.