WordPress Development
WordPress Security Audit: A Complete 6-Layer Checklist for Every Site
A WordPress security audit systematically reviews every layer of your site’s security posture. Here is the complete 6-layer framework to run annually or after any security concern.
A WordPress security audit is a systematic review of every layer of your site’s security posture: server configuration, software versions, user credentials, file permissions, plugin vulnerabilities, and monitoring coverage. Running one annually — or after any security incident — is the most reliable way to stay ahead of the attack vectors that compromise WordPress sites.
When to run a WordPress security audit
- Annually: as part of your site maintenance calendar, run a full audit every 12 months
- After a security incident: if your site has been hacked, defaced, or you suspect compromise, a full audit identifies the entry point and remaining vulnerabilities
- After major plugin or theme changes: adding new plugins or switching themes introduces new code that warrants security review
- After team changes: when team members leave, audit user accounts and revoke access
- Before launching a new site: a pre-launch security audit prevents launching with known vulnerabilities
Layer 1: Hosting and server audit
Go to Tools › Site Health › Info › Server. PHP versions below 8.1 are end-of-life and no longer receive security updates. Contact your host to upgrade if you are running PHP 7.x.
Visit http://yourdomain.com (without the s). It should redirect to https://yourdomain.com automatically. Test with Chrome DevTools to confirm no mixed content warnings.
Go to your browser address bar on your site, click the padlock, and check certificate validity dates. An expiring certificate causes visitors to see browser security warnings.
Does your host provide: daily automated backups? Malware scanning? Web application firewall? DDoS protection? If not, consider supplementing with security plugins or switching to managed WordPress hosting.
Layer 2: WordPress core, plugins, and themes
| Check | Status indicator | Action if failing |
|---|---|---|
| WordPress core version | Dashboard shows ‘WordPress X.X.X is available’ | Update immediately |
| Plugin versions | Dashboard › Updates shows plugin count | Update all — test on staging first |
| Theme versions | Dashboard › Updates shows theme count | Update active theme (child theme preserved) |
| Deactivated plugins | Plugins list shows inactive plugins | Delete all — inactive plugins are still attack vectors |
| Unused themes | Appearance › Themes | Delete all except active theme and its parent |
| Plugin sources | All plugins from WordPress.org or known commercial sources | Flag and investigate any unknown plugin sources |
Layer 3: User account audit
Go to Users › All Users, filter by Administrator role. Every account should belong to a current, active team member. Delete or demote any accounts that should not have admin access.
In your user list, check whether any account uses the username ‘admin’. If one exists and it is your admin account, create a new admin account with a different username, migrate your content to it, and delete the ‘admin’ account.
Check Editor, Author, and Contributor accounts for former employees or collaborators who no longer need access. Delete accounts or reset passwords for any account whose owner you cannot identify.
If you can see password strength indicators in User profiles, check that all admin accounts are using strong passwords. Consider requiring password resets for all admin accounts as part of the audit.
If 2FA is not yet enabled for administrator accounts, install WP 2FA and require it for all admin roles as part of the audit remediation.
Layer 4: File permission audit
Incorrect file permissions are a common attack vector. Access your server via FTP/SFTP or your hosting control panel and verify:
- WordPress directories: should be 755 (owner can read/write/execute; group and others can read/execute)
- WordPress files: should be 644 (owner can read/write; group and others can read only)
- wp-config.php: should be 600 (owner can read/write; nobody else can access)
- .htaccess: should be 644
- Your hosting control panel may have a ‘Fix file permissions’ tool that applies correct permissions automatically
Layer 5: Malware and vulnerability scan
Install Wordfence Security and run a full scan from Wordfence › Scan. The scan checks all WordPress files against known good versions and identifies modified, suspicious, or malware-infected files.
Go to sitecheck.sucuri.net and enter your URL. This external scan checks for malware in your page source, blocklist status, and website reputation issues — things an internal scan might miss if malware is hiding from admin access.
In Search Console, go to Security & Manual Actions. This reports any security issues Google has detected: malware, phishing, social engineering content, or deceptive pages.
Use MXToolbox (mxtoolbox.com/blacklists.aspx) to check whether your domain is on any email or web blocklists. Blocklisted sites experience degraded email deliverability and browser security warnings.
Layer 6: Security configuration audit
- Login URL: is /wp-admin and /wp-login.php accessible from any IP? Consider restricting via WPS Hide Login or IP allowlisting.
- XML-RPC: is XML-RPC enabled? If you do not use the WordPress mobile app or any XML-RPC-dependent service, disable it. Check via xmlrpc.php — it should return a 403 or 404.
- Directory listing: visit yourdomain.com/wp-content/uploads/. If you see a file directory listing rather than a 403 error, directory listing is enabled on your server — a security risk. Add ‘Options -Indexes’ to your .htaccess.
- WordPress debug log: verify WP_DEBUG_LOG is not set to true on a production site. Debug logs can contain sensitive information visible to anyone who can access the log file URL.
- Database prefix: the default WordPress database table prefix is wp_. Changing this is a minor security improvement — it makes automated SQL injection attacks slightly harder.
Security audit checklist summary
After completing the audit, document findings and prioritise remediation:
- Critical: outdated PHP, malware detected, compromised user accounts, missing HTTPS. Remediate immediately.
- High: outdated WordPress core or plugins, deactivated plugins present, admin username in use, missing 2FA. Remediate within 7 days.
- Medium: unused themes present, incorrect file permissions, XML-RPC enabled unnecessarily. Remediate within 30 days.
- Low: default database prefix, directory listing enabled, no login URL obfuscation. Remediate in next maintenance cycle.
Need a professional WordPress security audit?
Simple Automation Solutions performs WordPress security audits and implements remediation for businesses worldwide — identifying vulnerabilities before attackers do.
Frequently asked questions
How long does a WordPress security audit take?+
A basic self-conducted audit following a checklist takes 2-4 hours for a standard business website. A more thorough audit including manual code review of custom themes and plugins, penetration testing of forms and user registration flows, and server configuration analysis takes 8-16 hours and typically requires professional security expertise. An annual maintenance-level audit (updating software, reviewing users, running automated scans) takes 1-2 hours once you have established the workflow.
Should I hire a professional to audit my WordPress site’s security?+
For sites handling sensitive customer data (payment information, health information, legal documents), a professional security audit is appropriate. Automated scanning tools catch known vulnerabilities but miss logic flaws, insecure custom code, and configuration issues that require human expertise to identify. For standard business brochure sites and blogs, a thorough self-conducted audit using the framework above is adequate. For WooCommerce stores and membership sites, consider a professional audit annually.
What should I do if the Wordfence scan finds malware?+
Do not panic. First, take the site offline if it is actively serving malware to visitors — enable maintenance mode. Second, take a complete backup including the database. Third, follow Wordfence’s guided remediation — it identifies specific infected files and allows you to restore them from known-good versions or delete them. Fourth, change all passwords (WordPress admin, FTP, database, hosting) immediately. Fifth, investigate the entry point — which plugin, theme, or credential was compromised. Sixth, apply the hardening measures above. Seventh, run a second scan after remediation to confirm clean.
