Most WordPress sites are not actively monitored. They get set up, go live, and then quietly accumulate vulnerabilities — outdated plugins, weak passwords, exposed login pages, no off-site backups — until something breaks or someone gets in.
A security audit changes that. It’s a structured review that surfaces your real risk level before an attacker finds it for you. This checklist covers 15 critical checkpoints. Work through it once, fix what you find, then schedule it quarterly.
Section 1: Access Control (Items 1–4)
1. Audit Your Admin Users
Go to Users → All Users and filter by Administrator role. Remove every account you don’t recognize or no longer need. Former freelancers, old agency accounts, test users — they all represent open doors. Every admin account should be tied to a named person who still needs access.
2. Enforce Strong Passwords
Check that all administrator and editor accounts use long, unique passwords — at minimum 16 characters, never reused from another site. If you’re not sure, trigger a password reset for all admin users. Brute-force attacks against WordPress are fully automated; a weak password is a solved problem for an attacker.
3. Enable Two-Factor Authentication
A strong password alone is not sufficient protection for admin accounts. Enable two-factor authentication (2FA) for all users with administrator or editor roles. Even if a password is compromised through phishing or a data breach elsewhere, 2FA stops the login cold.
4. Limit Login Attempts
WordPress allows unlimited login attempts by default. This makes it trivially easy for automated tools to brute-force your credentials. Implement login attempt limits that temporarily block an IP after 5–10 failed attempts. The SwissWPSuite Security & Firewall module handles this automatically at the WAF level, before requests even reach WordPress.
Section 2: Updates and Software (Items 5–8)
5. Update WordPress Core
Go to Dashboard → Updates. If you’re not on the latest version of WordPress, update now. Security patches are often backported to older versions, but critical vulnerabilities that are actively exploited in the wild require the latest release. There is no legitimate reason to run an outdated WordPress core.
6. Update All Plugins
Outdated plugins are the leading cause of WordPress compromises — responsible for over 50% of successful attacks. Update every plugin. If a plugin hasn’t been updated by its developer in over 12 months and has more than 1,000 active installs, evaluate whether to replace it. Abandoned plugins accumulate unpatched CVEs.
7. Delete Unused Plugins and Themes
Go through your installed plugins and themes. Deactivated plugins still exist on disk and can still be exploited. Delete every plugin and theme you are not actively using. The default WordPress themes (Twenty Twenty-Four, etc.) can stay, but remove anything you installed, tried, and moved on from.
8. Verify Plugin Sources
Every plugin on your site should come from wordpress.org or a reputable premium marketplace (Envato, developer’s official site). Never use “nulled” or cracked versions of premium plugins — they are a primary vector for pre-installed backdoors. If you’re not certain of a plugin’s origin, delete and reinstall from the original source.
Section 3: Configuration and Hardening (Items 9–12)
9. Check File Permissions
Correct file permissions prevent attackers from modifying core files even if they gain limited access. The standard for WordPress: directories should be 755, files should be 644, and wp-config.php should be 600. Check your hosting file manager or run a file permission scan via your security plugin’s audit tool.
10. Disable XML-RPC if You Don’t Use It
XML-RPC (xmlrpc.php) is a legacy WordPress API that is frequently targeted in brute-force and DDoS attacks. If you’re not using Jetpack, mobile app publishing, or another service that specifically requires XML-RPC, disable it via your .htaccess or WAF rules. Most modern WordPress sites have no need for it.
11. Hide Your WordPress Version
WordPress publishes its version number in page source code and the readme.html file. Attackers use this to target known vulnerabilities in specific versions. Remove the version from the <head> tag using remove_action('wp_head', 'wp_generator') in your theme’s functions.php, and delete readme.html and license.txt from your root.
12. Enable a Web Application Firewall (WAF)
A WAF sits in front of your WordPress installation and blocks malicious requests — SQL injection attempts, XSS probes, path traversal attacks — before they ever touch your application. Without a WAF, every one of those requests reaches PHP and takes its chances. The SwissWPSuite WAF uses AI-based traffic analysis to block threats in real time.
Section 4: Data Protection (Items 13–15)
13. Verify Your Backup System
Don’t just assume backups are running — verify. Confirm your backup solution is creating files, that those files are stored off-site (not just on the same server), and that you can actually restore from them. Test a restore on a staging environment at least once per quarter. A backup you’ve never tested is not a backup you can rely on.
14. Enforce HTTPS Everywhere
Check that every URL on your site uses HTTPS, with no mixed-content warnings. Your SSL certificate should be valid and auto-renewing. Verify that wp-config.php has define('FORCE_SSL_ADMIN', true); to ensure admin logins are always encrypted. Mixed HTTP/HTTPS content is both a security issue and a Core Web Vitals flag.
15. Review Database Security
Verify three things: (1) Your database table prefix is not the default wp_ — change it if it is. (2) Your database user has only the permissions WordPress needs — no SUPER or FILE privileges. (3) Direct public access to your database is blocked by your hosting configuration. The database is the crown jewel; protect it accordingly.
What to Do After the Audit
Work through every item on the list and document what you found. For any item you couldn’t address immediately, create a task with a deadline — don’t leave it open-ended.
Then schedule this audit to repeat every quarter. Security is not a one-time configuration. New vulnerabilities are discovered regularly, your site’s software changes, and your team’s access situation evolves. A quarterly audit keeps your risk surface visible and manageable.
If you want the audit to happen automatically — continuously, not quarterly — SwissWPSuite monitors your site in the background, flags changes to core files the moment they occur, and blocks threats before they become incidents.
Frequently Asked Questions
How often should I run a WordPress security audit?
Quarterly at minimum. New vulnerabilities are discovered regularly, your plugin stack changes, and your team’s access situation evolves. Schedule a recurring calendar reminder for the full 15-point audit every three months. Between audits, automated monitoring (file integrity checks, login attempt logs) should be running continuously.
What are the most critical items on a WordPress security audit checklist?
The highest-impact items: (1) audit and remove unnecessary admin accounts, (2) verify all plugins are updated — outdated plugins cause over 50% of WordPress compromises, (3) confirm off-site backups are running and have been test-restored, (4) ensure a Web Application Firewall is active, (5) verify file permissions are correct (755 directories, 644 files, 600 for wp-config.php).
What file permissions should WordPress files have?
Directories should be set to 755, files to 644, and wp-config.php to 600 (readable only by the file owner, not the web server). These permissions prevent attackers from modifying core files even with limited server access. Check via your hosting file manager or run a file permission scan from your security plugin.
Should I disable XML-RPC on my WordPress site?
If you’re not using Jetpack, mobile app publishing, or another service that specifically requires XML-RPC, yes — disable it. XML-RPC is a legacy API targeted frequently in brute-force and DDoS attacks. Most modern WordPress sites have no legitimate need for it. Disable via .htaccess rules or a WAF directive.