WordPress security hardening checklist · scored, with copy-paste fixes
Harden your WordPress site one layer at a time and watch the score climb. There are 34 controls across 7 layers in here: edge and WAF, HTTPS and headers, login, updates, files and wp-config, the database, then backups and monitoring. Every item tells you why it matters, and where it’s actionable it hands you the exact wp-config.php, .htaccess, nginx or WP-CLI line to paste. Your ticks live in your browser. So yeah, close the tab, come back next week, pick up where you stopped.
How to use this checklist
Go top to bottom, or filter down to one layer. Tick an item once it’s actually done on your site and the score jumps right away. Start with the critical ones (login, updates, file editor, uploads, backups), since those move the needle hardest. When an item ships a code block, paste it straight into your wp-config.php or your .htaccess or nginx config, or just run it as a WP-CLI command. Your ticks sit in your browser’s local storage and nowhere else. Nothing gets uploaded. The checklist simply remembers where you stopped.
Why defense in depth beats one security plugin
Install one security plugin, assume you’re covered, move on. That’s the mistake almost everybody makes. Real hardening stacks up in layers. A WAF swats most automated junk at the edge. HTTPS and headers keep data safe in transit. Login controls choke off credential stuffing. Updates, done on schedule, close the holes attackers actually walk through. Get file permissions right and one breach stays boxed in instead of spreading. A least-privilege database account contains it further. And backups plus monitoring are what let you notice the mess and crawl back from it. Honestly, no single one of these is enough on its own. Stacked, though, they turn your site into a far harder target than the millions of soft ones bots scan all day.
The fixes that matter most
Short on time? Do these five. Turn on two-factor auth for every administrator. Switch on automatic updates for minor and security releases. Kill the in-dashboard file editor with DISALLOW_FILE_EDIT. Block PHP execution in wp-content/uploads. And set up automated offsite backups you’ve actually restored once, not just configured and crossed your fingers about. Those five shut the doors behind most real WordPress break-ins. And the break-ins almost always trace back to the same boring trio: a weak login, a plugin nobody updated, an upload nobody locked down.
Frequently asked questions
What is the most important WordPress security setting?
There isn’t one. Sorry, I know that’s not the answer you wanted. The controls that pull the most weight are two-factor auth on admin accounts, plus keeping plugins and core current (auto-updates for minor releases help here), plus offsite backups you’ve test-restored. Most real compromises trace back to a weak or reused admin password, or some vulnerable plugin nobody patched. Cover those layers and you’ve blocked the bulk of what’s coming.
Do I need a security plugin to harden WordPress?
A solid plugin like Wordfence or Sucuri carries the WAF, login limiting, file-integrity scanning and the monitoring side. Useful stuff. But a bunch of the most effective fixes aren’t plugins at all, they’re config you set by hand: HTTPS and security headers, file permissions, DISALLOW_FILE_EDIT, blocking PHP in uploads, a least-privilege database user. This checklist covers both, so you can see where the plugin’s doing the work and where you’re on your own.
How do I disable the WordPress file editor?
Drop define('DISALLOW_FILE_EDIT', true); into your wp-config.php, somewhere above the line that says “stop editing”. That yanks the Appearance and Plugins code editors out of the dashboard, so an attacker who’s hijacked an admin session can’t just inject PHP through the UI. One line. Probably the best return-per-keystroke on this whole list.
How do I stop PHP running in the uploads folder?
You add a rule that flat-out refuses to execute PHP under wp-content/uploads. On Apache, drop a tiny .htaccess in that folder denying access to .php files. On nginx, add a location block that returns 403 for PHP under that path. Either way it kills the classic move of sneaking a disguised PHP shell in through a leaky plugin. The exact snippet’s up in the Files and wp-config layer.
Is hiding the WordPress version or wp-login.php worth it?
It’s decent defense in depth. It is not a stand-in for the real controls, though, and I’d push back on anyone who treats it that way. Hiding the version and moving or locking down wp-login.php cuts the noise from automated scanners and slows a targeted attacker down a bit. Someone determined can still fingerprint the site anyway. So do it after the high-impact stuff (2FA, updates, backups), never instead of it.
Does this checklist send my answers anywhere?
Nope. The whole thing runs in your browser, and your ticked items sit in your browser’s local storage, full stop. Nothing about your site or your progress gets sent anywhere or logged. Hit Reset whenever you want it gone.
Sources & further reading
- WordPress Developer: Hardening WordPress
- WordPress.org: Hardening WordPress (documentation)
- OWASP: Top Ten web application risks
