WordPress Hardening Checklist for 2026

WordPress hardening is the process of reducing a site's attack surface and limiting what an attacker can do if they get in. It covers WordPress settings, user accounts, plugins, file permissions, the web server, the operating system and monitoring. No single control makes a site secure; the layers together make a compromise much harder.

Most of the compromised WordPress sites we clean were not broken into by anything exotic. They had an outdated plugin, a reused admin password, PHP running in the uploads folder, or several sites sharing one system user so that one infection spread to all of them. Every item in this checklist closes a door we have seen attackers walk through.

The checklist is ordered by priority. If you only have an hour, work through the first two sections. If you have just cleaned up a hack, do all of it before you consider the site back in service, and read why malware keeps coming back first.

Keep as few administrators as possible, give each person their own account with the lowest role they need, require two-factor authentication for every privileged user, and use long, unique passwords from a password manager. Then remove old accounts and review the admin list regularly, because rogue administrators are a common backdoor.

# Review every administrator, and when they were created
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

7  wp-support-admin   support@mail-helpdesk[.]example   2026-08-14 03:11:52
1  sarah.acme         sarah@acme-shop.co.uk             2021-04-02 09:15:10

• Two-factor authentication for administrators, editors and shop managers.
• Login rate limiting at the web server, firewall or with a reputable plugin.
• Separate accounts for each developer, agency and contractor, removed when their work ends.
• No shared "admin" login passed round by email or chat.

Disable the built-in theme and plugin file editor, force HTTPS for logins and the dashboard, keep automatic updates on for minor core releases, and use fresh, unique security keys and salts. Add these to wp-config.php and restrict the file's permissions so other users on the server cannot read it.

# Stop the dashboard being used to write PHP
define( 'DISALLOW_FILE_EDIT', true );

# Force HTTPS for the admin area
define( 'FORCE_SSL_ADMIN', true );

# Keep minor core updates automatic
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

# Replace salts after any compromise (generates new keys in place)
wp config shuffle-salts

If you manage deployments through version control, you can go further with DISALLOW_FILE_MODS, which also blocks plugin installation and updates from the dashboard. Only do this if updates are handled some other way, or the site will quietly fall behind.

Also disable XML-RPC if nothing you use needs it (some mobile apps and older integrations do), and turn off directory listing on the web server.

Directories should normally be 755 and files 644, with wp-config.php tighter at 640 or 600. Files should be owned by the site's own system user, not shared with other sites. Most importantly, block PHP execution in wp-content/uploads, the most common place attackers drop webshells.

# Typical permissions for a single-site install
find /var/www/example.co.uk -type d -exec chmod 755 {} \;
find /var/www/example.co.uk -type f -exec chmod 644 {} \;
chmod 640 /var/www/example.co.uk/wp-config.php

# Warning signs
-rwxrwxrwx 1 www-data www-data  2291 wp-config.php
-rw-r--r-- 1 www-data www-data 18342 wp-content/uploads/2026/08/cache.php

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }
location ~ /\.(?!well-known) { deny all; }

The right values can vary with your hosting setup, particularly where PHP runs as a different user from the file owner. The principle stays the same: the web server should be able to read your code, and write only where WordPress genuinely needs to. Our webshells guide explains why uploads matter so much.

On a VPS or dedicated server, use SSH keys instead of passwords, disable direct root login, run a firewall that only allows the ports you need, keep the operating system patched, and give each site its own system user and PHP-FPM pool so one compromised site cannot write into the others.

PasswordAuthentication yes
PermitRootLogin yes

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3

# Allow only SSH, HTTP and HTTPS inbound
ufw default deny incoming
ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp
ufw enable

# Review scheduled tasks and enabled services regularly
crontab -l -u www-data
systemctl list-unit-files --state=enabled

Why per-site isolation matters is explained in VPS security: why one hacked site infects the rest. The PatientZero Harden playbooks apply these server controls consistently across every site.

The complete checklist below covers updates, accounts, configuration, files, server, backups and monitoring. Work through it top to bottom, tick off each item, and repeat the review every quarter and after any change of developer, hosting or major plugin. Each item is a control we check during a PatientZero security audit.

Updates and software

• WordPress core is on a supported, current version
• All plugins and themes are updated, ideally within days of security releases
• Unused plugins and themes are deleted, not just deactivated
• No nulled or pirated plugins or themes are installed
• PHP is on a version that still receives security support
• Core and plugin files pass wp core verify-checksums and wp plugin verify-checksums --all

Accounts and access

• Administrator list reviewed; unknown or old accounts removed
• Every user has the lowest role they need
• Two-factor authentication enforced for all privileged users
• Login attempts rate-limited
• Hosting, SFTP, database and DNS accounts use unique passwords and two-factor where available
• Search Console and analytics owners reviewed

Configuration and files

• DISALLOW_FILE_EDIT set to true
• HTTPS enforced site-wide with a valid certificate
• Security keys and salts unique, and rotated after any incident
• Database user has privileges for its own database only
• File permissions 755 for directories, 644 for files, 640 or 600 for wp-config.php
• PHP execution blocked in wp-content/uploads
• Directory listing disabled; hidden files such as .git and .env not web-accessible
• XML-RPC disabled if not needed
• Security headers set (Content-Security-Policy, X-Content-Type-Options, Referrer-Policy)

Server

• SSH key authentication only; root login disabled
• Firewall allows only required ports
• Operating system security updates applied automatically or on a schedule
• Each site runs as its own system user with its own PHP-FPM pool
• Crontabs, systemd services and SSH authorized_keys reviewed for unknown entries
• No unexpected remote-access or VPN software installed

Backups and monitoring

• Automated daily backups of files and database
• Backups stored off-server, with more than one restore point
• A restore has been tested within the last quarter
• File-integrity monitoring alerts on new or changed PHP files
• Uptime, blacklist and Search Console security alerts monitored
• Logs retained long enough to investigate an incident

Hardening drifts. Plugins are added, developers change, server settings are relaxed to fix a problem and never put back. Keep a site hardened by monitoring continuously for new files, users, cron jobs and configuration changes, re-running the checklist quarterly, and treating any unexplained change as a possible incident.

PatientZero does this for you. Every Single Site plan (£99 a month, plus a one-off £129.99 security audit and setup) starts with a full audit against this checklist, applies Harden playbooks, and then provides 24/7 monitoring with unlimited malware removal if anything does get through. There is no contract and you can cancel at any time. Server, multi-site and agency plans cover every site on a server.

See pricing, learn about our hardening service, or start with our security triage to see where your site stands today.