The WordPress Security Audit Checklist I Use for New Client Sites

When a new client hands me their WordPress site, I don’t start by fixing the thing they asked about. I start with a security audit. It’s not because I expect every site to be hacked. It’s because I need to know what I’m taking responsibility for, and because problems found early are much cheaper to fix than problems found during an incident.

Over the years, this audit has settled into a checklist. It covers the areas where I most often find trouble: user accounts, outdated or risky plugins, configuration mistakes, exposed files, weak server settings and backups that don’t really exist.

Here’s the full checklist. You can run most of it yourself, even without deep technical knowledge, and the parts that need server access are clearly marked.

Before you start

Take a full backup of files and database, and store it off the server. An audit sometimes uncovers things that need immediate action, and you want a safe restore point before changing anything.

Also gather access: WordPress admin, hosting control panel, SFTP or SSH, DNS and domain registrar. If you can’t get access to something, write that down. Missing access is itself a finding.

1. Ownership and access

• Who owns the domain, hosting and DNS accounts? They should be in the business’s name.
• Who has access to each account, and do they still need it?
• Are passwords stored securely, in a password manager the business controls?
• Is two-factor authentication enabled on the hosting, registrar and DNS accounts?

A site is only as secure as the accounts that control it. A compromised registrar or hosting account can bypass every WordPress protection.

2. WordPress user accounts

• List all users and their roles.
• Count administrators. More than two or three is a warning sign.
• Look for accounts you can’t explain, especially administrators with odd usernames or email addresses.
• Check whether “Anyone can register” is enabled, and what the default role is.
• Check whether two-factor authentication is enforced for privileged roles.
• Look for shared accounts used by multiple people.

3. WordPress core

• Which version is running? Is it the latest, or at least a supported recent version?
• Do core files match official checksums?

Any mismatch needs investigation before anything else.

4. Plugins and themes

This is where I find the most problems.

• List every plugin with its version and status.
• Identify plugins with available updates.
• Identify deactivated plugins and unused themes. They should usually be removed.
• Check each plugin against a vulnerability database for known issues.
• Check whether any plugin has been closed on WordPress.org or abandoned by its developer.
• Look for nulled premium plugins or themes, which often contain malware.
• Verify repository plugins against checksums.

For premium plugins, confirm the licence is valid and updates are being received. An expired licence often means the plugin hasn’t been updated in years.

5. Signs of existing compromise

Before hardening anything, make sure the site isn’t already infected:

• PHP files in the uploads folder.
• Recently modified PHP files that don’t match a known update.
• Obfuscated code in themes, plugins or the site root.
• Unfamiliar .htaccess rules, including in subfolders.
• Suspicious scheduled tasks.
• Spam pages in Google results for site:yourdomain.com.
• Unknown owners in Google Search Console.

If you find evidence of compromise, stop the audit and switch to incident response. Hardening an infected site just locks the attacker in.

6. wp-config.php

• Is file editing disabled with DISALLOW_FILE_EDIT?
• Is debug display off on production?
• Are security keys and salts set and unique?
• Is the file protected with restrictive permissions?
• Does it contain anything unexpected, such as injected code or extra include statements?

7. File permissions and ownership (server access)

• Directories should generally be 755, files 644, and wp-config.php more restrictive.
• Nothing should be 777.
• Ideally, the web server can only write where needed, mainly uploads and cache folders.

Any world-writable files or directories need fixing.

8. Exposed files and information

Check whether these are publicly accessible, by visiting them in a browser:

• Backup files in the web root, like .zip, .sql, .tar.gz or .bak.
• .env or other configuration files.
• .git directories.
• debug.log in wp-content.
• Directory listings in uploads or plugin folders.
• phpinfo files left over from troubleshooting.

I regularly find database backups sitting in the web root, downloadable by anyone who guesses the filename. That’s an instant data breach waiting to happen.

9. Login and authentication

• Is there rate limiting or brute force protection on the login page?
• Is XML-RPC blocked if not needed?
• Are application passwords in use, and are they all still needed?
• Is the site using HTTPS for logins, with FORCE_SSL_ADMIN set?

10. Server and PHP configuration (server access)

• Is PHP a currently supported version?
• Are dangerous PHP functions restricted where appropriate?
• Is PHP execution blocked in the uploads folder?
• Is the server operating system receiving security updates?
• Are unused services and open ports closed?
• Is SSH secured with key-based authentication?

PHP versions that have reached end of life no longer get security fixes. Running one is a real risk.

11. HTTPS and security headers

• Is there a valid SSL certificate with automatic renewal?
• Does HTTP redirect to HTTPS everywhere?
• Are there mixed content warnings?
• Are basic security headers present, like X-Content-Type-Options, X-Frame-Options or a frame-ancestors policy, Referrer-Policy and Strict-Transport-Security?

You can check headers quickly:

12. Firewall and protection layers

• Is there a web application firewall, cloud or server-level?
• If using a cloud WAF, is the origin server locked down so it can’t be bypassed?
• Is there malware scanning?

13. Backups

• Are backups automated?
• Are they stored off the server, with separate credentials?
• Do they include both files and database?
• How much history is kept?
• When was a restore last tested?

The last question is the most revealing. Many sites have backups that have never been tested, and some discover during an emergency that their backups were incomplete or failing.

14. Monitoring and logging

• Is there uptime monitoring?
• Is there file integrity monitoring?
• Is there an activity log recording logins and changes?
• Are access and error logs retained long enough to investigate incidents?
• Is Google Search Console set up, with alerts going to someone who reads them?

15. Third-party integrations

• Which external services have access to the site, through API keys, application passwords or connected accounts?
• Are those integrations still used?
• Are API keys stored securely, rather than in public files?

16. Email security

• Does the domain have SPF, DKIM and DMARC records?
• Does WordPress send email through an authenticated SMTP service?

Proper email authentication protects your domain from being spoofed in phishing emails and improves deliverability.

Writing up the findings

After the audit, I write a short report that groups findings by severity:

• Critical: needs fixing today, such as signs of compromise, exposed backups or plugins with actively exploited vulnerabilities.
• High: fix within a week, such as excess administrators, outdated PHP or no off-site backups.
• Medium: fix within a month, such as missing headers or no file monitoring.
• Low: nice to have improvements.

Each finding includes what was found, why it matters and how to fix it. Clients appreciate clear priorities more than a long, unsorted list.

Repeat the audit after big changes

An audit is a snapshot. Migrations, redesigns, new plugins and staff changes all alter the picture. Schedule a short re-audit after any major change, and keep your previous report so you can see what improved and what slipped back.

Frequently asked questions

How often should I audit my site?

A full audit when you take over a site or after any security incident, and a lighter review every three to six months. Ongoing monitoring covers the gaps in between.

Can I run an audit without server access?

You can cover users, plugins, settings, exposed files, headers and Search Console from the dashboard and browser. Server access is needed for file permissions, PHP configuration and deeper malware checks.

What’s the most common critical finding?

Outdated plugins with known vulnerabilities, followed closely by too many administrators and backups stored only on the same server.

Should I fix everything at once?

Fix critical issues immediately, then work through the rest in priority order. Making many changes at once makes it harder to identify the cause if something breaks.

Final thoughts

A security audit gives you a clear picture of where a WordPress site stands and what needs attention. Work through ownership, users, core, plugins, configuration, server settings, backups and monitoring in a consistent order, write down what you find and fix it by priority. Most sites have a handful of serious issues that take an afternoon to resolve, and resolving them changes the site from an easy target into a well-defended one.