WordPress security checklist 2026 (interactive, scored)

Score your site

Each item has a weight from 1 to 5 based on how much risk it removes. The items marked critical are the ones that most often decide whether a site gets compromised, or whether it can recover. Tick what’s already true. The score bar stays visible as you scroll, and the footer lists your three biggest gaps.

Server & PHP: the layer most checklists skip

WordPress is a set of PHP files. The PHP runtime that executes them, the web server and the operating system sit underneath, and a bug there sidesteps everything you configure inside WordPress. That’s exactly what happened with PHP2Shell in October 2026: two critical PHP bugs that could let an attacker run code without logging in. The fix was a PHP update; no WordPress setting or plugin could do it.

So the first two items carry the most weight: run a supported PHP branch (8.3, 8.4 or 8.5; 8.2’s security support ends on 31 December 2026), and know who patches it. Here’s how to check and update your PHP version, and what to ask your host if they manage it.

$ sudo apt install unattended-upgrades$ sudo dpkg-reconfigure --priority=low unattended-upgrades# PHP-FPM keeps old code loaded until it restarts — check after updates$ systemctl status php8.3-fpm

Updates

Plugins are where most WordPress vulnerabilities are found, simply because there are so many of them, written by teams of every size. The defence is boring and effective: update quickly, and turn on auto-updates for plugins from developers you trust. WordPress.org’s hardening guide is direct about core too: older versions aren’t maintained with security updates.

If updates scare you because they break things, that’s a staging problem, not a reason to stop updating. Most hosts offer one-click staging.

Logins & users

Two-factor login is the single best protection for the admin itself: a stolen or reused password is no longer enough. Pair it with unique passwords from a password manager, a limit on login attempts, and as few administrators as possible. Editors can publish everything; few people need to install plugins.

Two quieter ones: application passwords (used by apps and integrations) bypass two-factor by design, so revoke the ones nobody uses; and XML-RPC is a legacy API that’s a favourite for brute-force attempts, so block it unless something you use needs it.

Plugins & themes

Every plugin is code from another team running inside your site. Deactivated plugins are still files on disk, so delete what you don’t use. Prefer plugins that were updated in the last year, and never install “nulled” copies of premium plugins: they’re a well-known way of distributing backdoors.

A useful exercise: list your plugins and write next to each one what job it does. You’ll usually find two that do the same thing and one nobody remembers installing.

Backups & monitoring

Backups are what turn a hack from a disaster into an annoying afternoon. They need to live off the server (a backup on the compromised server can be deleted or infected too), go back at least 30 days (compromises are often noticed late), and be tested. WordPress.org’s hardening guide also recommends keeping snapshots over time and checking their integrity.

Monitoring is how you find out quickly. Verify the site in Google Search Console, set up an uptime monitor, and make sure your host keeps access logs long enough to investigate. If something does go wrong, follow our hacked-site recovery checklist.

Hardening

These are lower-weight because they limit damage rather than prevent entry, but they’re cheap. All come from WordPress.org’s own hardening guide.

# Stop theme and plugin files being edited from wp-admindefine( 'DISALLOW_FILE_EDIT', true );

$ find . -type d -exec chmod 755 {} \;$ find . -type f -exec chmod 644 {} \;

Also ask your host whether PHP execution is blocked in wp-content/uploads. Many managed hosts already do it; on your own Nginx or Apache server it’s a two-line rule.

The other approach: have less to secure

Look at the checklist again and count the items that exist because of what WordPress runs on: patching PHP, updating PHP plugins, blocking XML-RPC, blocking PHP in uploads, permissions on PHP files. Roughly a third of the list is about keeping a PHP application safe on a shared server.

Presscomet takes a different route. It keeps the WordPress admin, editor, URLs and REST API but runs on Node.js with no PHP runtime, so those items don’t apply: there’s no PHP to patch, no xmlrpc.php endpoint, and no third-party PHP plugins. Login limiting and authenticator-app two-factor are part of the bundled Security plugin, and backups of the single database file are built in.

Curious how your site would look? Run the free site check: it only reads your public site.