WordPress Security Hardening: The 2026 Checklist
WordPress powers a huge chunk of the web and, being popular, is a huge target. Most compromises exploit old, known bugs — here is what to lock down first, in order.
Keep everything updated
The overwhelming majority of WordPress compromises are not clever zero-days — they exploit vulnerabilities that were patched months earlier on sites that never applied the update. That makes patching the single highest-impact thing you can do. Enable automatic updates for WordPress core, and for plugins and themes wherever your workflow allows. Core minor releases are safe to auto-apply; for major releases and plugins, run a staging copy of the site and let updates land there first, then promote weekly. A staging environment is not a luxury here — it is what lets you patch quickly without fear of a broken layout. Delete, don't just deactivate, any theme or plugin you are not using. Deactivated code still sits on disk and can still be exploited through a direct request. The default Twenty-something themes you don't use, that abandoned plugin from a past experiment — remove them. A smaller footprint is a smaller attack surface.
Treat plugins as supply chain
Every plugin you install is third-party code running with full access to your site and database. The WordPress ecosystem's greatest strength — tens of thousands of plugins — is also its biggest risk, because a single vulnerable or abandoned plugin can compromise the whole site. Before installing anything, check three signals: when it was last updated, how actively it is maintained, and how it handles reported vulnerabilities. Prefer plugins with a recent release date and a real team behind them over a clever one-off that hasn't been touched in two years. Fewer, well-maintained plugins beat a pile of overlapping ones. Audit what you already have and remove anything redundant. Two plugins doing similar jobs double your exposure for no benefit. When a plugin is abandoned by its author, treat that as a security event and find a maintained replacement — unmaintained code does not get patched when the next vulnerability is found, and attackers scan specifically for known-vulnerable plugin versions.
Harden the login
The wp-login.php page is the front door, and it is hammered constantly by automated brute-force bots. Harden it on several fronts. First, enforce strong, unique passwords and enable multi-factor authentication on every account that can publish or administer — MFA alone defeats the vast majority of credential-stuffing attacks. Second, never use admin as a username, and make sure your public author slugs don't reveal login names. Third, rate-limit or lock out repeated failed logins, either with a hardening plugin or at the edge with Cloudflare, so bots can't try thousands of passwords. Moving the login to a non-default path or putting HTTP basic auth in front of wp-login.php and wp-admin cuts the automated noise dramatically. Finally, apply least privilege: give each person the lowest role that lets them do their job. Not everyone needs Administrator. An editor who only writes posts should be an Editor, so a compromised account does less damage.
Add security headers
Security response headers are cheap, powerful, and best applied at the web server or CDN layer rather than through a plugin — because a plugin can be disabled or fail, while server config keeps enforcing. Start with HSTS to lock the site to HTTPS, X-Content-Type-Options: nosniff to stop MIME sniffing, and a Referrer-Policy such as strict-origin-when-cross-origin. Add frame-ancestors (via Content-Security-Policy) or X-Frame-Options to prevent clickjacking. A full Content Security Policy is more work on a themed WordPress site because of inline scripts, so roll it out in report-only mode first, as you would on any site. If you sit behind Cloudflare, you can add most of these in one place and keep them consistent across the whole domain. Then verify: run the site through Website Auditor and confirm each header is present and correctly configured. The scanner will flag a missing HSTS, a weak Referrer-Policy, or a policy that still allows framing.
Lock down files and database
A few file-system and database changes close common escalation paths. Disable the built-in theme and plugin file editor by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php — that alone stops an attacker who gains admin access from injecting PHP through the dashboard. Set correct file permissions: directories 755, files 644, and wp-config.php locked down to 640 or stricter. Block direct execution of PHP in the uploads directory at the server level, so a maliciously uploaded file cannot be run. Move or protect wp-config.php, and keep it out of any web-accessible backup. On the database, change the default wp_ table prefix on new installs to make blind SQL injection slightly harder, use a dedicated database user with only the privileges WordPress needs, and never reuse that password anywhere. None of these is a silver bullet on its own, but together they raise the cost of turning a small foothold into full control.
Backups and monitoring
Assume that one day something will get through, and make sure that day is a minor inconvenience rather than a catastrophe. Automated, off-site backups are the foundation: schedule regular backups of both files and database, store them somewhere separate from the server, and — critically — test a restore. A backup you have never restored is a hope, not a plan. Add monitoring so you learn about trouble before your visitors do. File-integrity monitoring flags unexpected changes to core files; uptime and malware scanning catch defacements and injected spam. One well-known security plugin that bundles a firewall, malware scan and hardening is enough — running five overlapping ones adds load and confusion without adding protection. Finally, treat security as ongoing. Review users and plugins quarterly, watch for abandoned dependencies, re-run an external scan after major changes, and keep your staging-test-patch loop tight. WordPress security is not a one-time checklist you complete; it is a small, regular habit that keeps a popular target from becoming an easy one. Work the checklist in priority order and you get most of the benefit for a fraction of the effort: patch everything, prune unused plugins and themes, put MFA and rate-limiting on the login, add security headers at the edge, lock down file and database access, and keep tested off-site backups. None of it is exotic, and none of it requires a big budget — WordPress security is far more about consistent hygiene than about any single tool. Run an external scan after each major change, and you will catch the regressions before an attacker does.
Frequently asked questions
- One is plenty. A single well-known plugin that bundles a web application firewall, malware scanning and hardening covers most needs. Running several overlapping security plugins adds server load and conflicting rules without meaningfully improving protection.
- Prefer the web server or your CDN (such as Cloudflare). A plugin can be deactivated, break on an update, or fail silently, whereas server-level configuration keeps enforcing the headers regardless of what happens inside WordPress.
- Keep core, themes and plugins updated. Most WordPress hacks exploit known vulnerabilities that already had a patch available. Automatic updates plus a staging-test-promote workflow closes that gap faster than any other single measure.
- Match the frequency to how often the site changes — daily for an active store or blog, weekly for a mostly-static site — store copies off the server, and test a full restore periodically so you know the backups actually work.