WordPress Security Checklist Worth Running on Every Site

WordPress security has a reputation for being complicated. It isn't. The vast majority of WordPress compromises come from a small number of well-understood failure modes, each with a documented preventive measure. A site that implements the basic 20-item checklist below is more secure than 95% of WordPress sites on the public web.

The reason most sites don't implement these basics isn't difficulty — most steps take 1-3 minutes. It's that the checklist gets distributed across dozens of articles, each covering 2-3 items in isolation, so the full picture is hard to assemble.

The 20 items, in execution order

1. Update WordPress core. Settings → Updates. WordPress auto-updates minor releases by default; major releases require manual approval. Keep current.

2. Update all plugins. The single most common WordPress attack vector is unpatched plugin vulnerabilities. Plugins → Updates. Apply all available updates.

3. Update all themes. Same logic. The active theme and any installed themes can have vulnerabilities. Update them all.

4. Delete unused themes. Inactive themes can still be exploited if they have vulnerabilities. Keep only the active theme and one default (Twenty Twenty-Four) as a fallback. Delete others.

5. Delete unused plugins. Inactive plugins shouldn't be exploitable but the files exist on the server and can be exploited if the server file system is compromised. Delete unused plugins entirely.

6. Change the default admin username. If you have a user named "admin" or "administrator," create a new admin user with a different username and delete the old one. Default usernames are the first thing brute-force attacks try.

7. Enforce strong passwords. Users → Profile. Set a password that's at least 12 characters with mixed case, numbers, and symbols. Use a password manager.

8. Enable two-factor authentication. Install "Two Factor" (free, by the WordPress core team) or use Wordfence's 2FA module. Configure for all admin and editor accounts.

9. Limit login attempts. Wordfence does this by default in its free tier. Configure for 5 failed attempts per 30 minutes per IP.

10. Disable XML-RPC if you don't use it. XML-RPC is rarely needed in 2026 and is a common attack target. Install "Disable XML-RPC" plugin or add a few lines to .htaccess.

11. Disable WordPress file editing in the admin. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php. This prevents an attacker who gains admin access from editing PHP files directly.

12. Enable security plugin's malware scanner. Wordfence, Solid Security, or MalCare. Schedule weekly scans.

13. Configure security plugin's web application firewall. All three above have WAF modules. Enable with the recommended settings.

14. Verify HTTPS is enforced site-wide. Settings → General. WordPress Address (URL) and Site Address (URL) should both start with https://. Force HTTPS redirect in .htaccess if not already done.

15. Enable HSTS header. Strict-Transport-Security: max-age=31536000; includeSubDomains. This tells browsers to always use HTTPS for your domain.

16. Set up automated backups. UpdraftPlus or BlogVault. Configure to back up daily to off-site storage (Dropbox, Google Drive, S3). Test the restore process at least once.

17. Enable Akismet for spam protection. WordPress ships with Akismet pre-installed; you need to activate it and provide an API key (free for personal sites).

18. Review user accounts and remove unused ones. Users page. Delete any old admin or editor accounts that aren't actively used. Reduce privilege of contributor or author accounts as appropriate.

19. Check file permissions. Directories should be 755, files should be 644. Files set to 777 are a red flag and indicate a misconfiguration or compromise.

20. Subscribe to vulnerability alerts. Sign up for WordFence's blog, the WPScan vulnerability database newsletter, or the Patchstack newsletter. Get alerts when plugins you use have new vulnerabilities published.

Specific operational tip not in the main checklist

Test the recovery scenario before you need it. Pick one of your backups, restore it to a staging site, and verify the restore works. Most site owners discover their backups are broken in the moment they need them, not before. The 30 minutes to test a backup restore preemptively saves the 8 hours of disaster recovery the first time you need a real restore.

This applies whether your backup tool is UpdraftPlus, BlogVault, or your host's built-in backup. The provider doesn't run restore drills for you. Run one yourself.