WordPress security hardening: a practical checklist for 2026

Short answer: outdated plugins, reused passwords and forgotten admin accounts are all risks to review. Good WordPress security hardening comes down to a few habits: keep everything updated, remove what you don't use, lock down logins and file editing, stop PHP from running in the uploads folder, and keep off-site backups you have restored. Use this checklist to review the installation and plan the changes it needs.

Cleaning up infected WordPress sites is part of my work. Start with an inventory of installed code and account access, then record how you will detect a problem and recover from it.

Start with a read-only review

Before changing anything, find out where you stand. If you have WP-CLI (opens in a new tab) on the server, these read-only commands tell you a lot:

# Are core files exactly what WordPress.org shipped?
wp core verify-checksums

# Same check for plugins from the WordPress.org directory
wp plugin verify-checksums --all

# Who can change everything?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# What is out of date?
wp plugin list --update=available
wp theme list --update=available

Any checksum mismatch, admin you don't recognise or plugin that is years behind goes straight to the top of your to-do list.

The WordPress hardening checklist

1. Put wp-config.php to work

These constants restrict selected dashboard actions and connection behavior:

// Nobody edits PHP from the dashboard. Deploy changes instead.
define( 'DISALLOW_FILE_EDIT', true );

// Always use HTTPS for the admin area.
define( 'FORCE_SSL_ADMIN', true );

// Allow automatic minor core updates (security releases).
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

If you also deploy plugins through Git or a pipeline, DISALLOW_FILE_MODS blocks installing and updating from the dashboard too. Only enable it if something else keeps your plugins updated.

Rotate your salts whenever you suspect a leak. This signs everyone out:

wp config shuffle-salts

2. Stop PHP from running in uploads

The uploads folder should only ever contain media. On Apache, add an .htaccess file inside wp-content/uploads:

<FilesMatch "\.(?:php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

On Nginx, add this to the server block:

location ~* /wp-content/uploads/.*\.(?:php[0-9]?|phtml|phar)$ {
    deny all;
}

3. Tighten logins

• Turn on two-factor authentication for every account that can publish or manage plugins.
• Give people the lowest role that works. Editors rarely need to be administrators.
• Limit login attempts at the web application firewall or with a well-maintained plugin.
• If nothing uses XML-RPC (Jetpack and some older integrations still do), block xmlrpc.php at the server.

4. Set sane file permissions

A common baseline is 755 for folders and 644 for files, with wp-config.php readable only by the account PHP runs as (640 or 600, depending on your host). Never use 777.

5. Add security headers

Headers cost nothing and block common browser-side attacks. Start with X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a frame-ancestors rule (or X-Frame-Options) and HSTS once the site is fully on HTTPS. A Content Security Policy is the strongest of all, but test it carefully, because page builders often rely on inline scripts.

For the details, see which WordPress security headers to set and how to test them safely.

If a site is already infected

1. Take a full copy first (files and database). You'll want it for investigation.
2. Put up a maintenance page or block traffic while you work.
3. Reinstall core and every plugin and theme from clean sources. Don't try to "fix" infected copies.
4. Search for PHP files that shouldn't exist, especially in uploads, and check mu-plugins and .htaccess.
5. Review scheduled tasks with wp cron event list. Malware likes to schedule its own return.
6. Remove unknown admin users, then reset every password and shuffle the salts.
7. Update everything, then find the entry point. If the entry point remains open, the site can be compromised again.
8. Request a review in Google Search Console if the site was flagged.

If the site is already compromised, follow the step-by-step guide to cleaning a hacked WordPress site.

Keep it that way

Hardening needs review as plugins, accounts and hosting change. Subscribe to a vulnerability feed such as Wordfence Intelligence, WPScan or Patchstack, and check it against the plugins you run. Once you look after more than a handful of sites, automate that check. That is exactly why I built Fleet Sentinel.

---

Need a hand hardening or cleaning a site? Check my maintenance & security service or get in touch directly. Hardening and malware cleanup are a regular part of my work.