How to run a WordPress security audit (step by step)

By the WPMate team · September 8, 2026 · 9 min read

A WordPress security audit is a structured review of everything that could let an attacker in: the software you run, the people who can log in, the files on the server and the settings that hold it together. It's different from following a list of tips. An audit produces a written record of what you found, what you fixed and what you decided to accept, so the next audit is faster and nothing slips through.

If you want a list of individual fixes, our WordPress security checklist covers fifteen of them. This guide is about the process: how to scope a WP security audit, work through it in order and turn findings into actions.

Before you start: scope and a record

Decide what's in scope. For most owners that's one production site, but be explicit about the rest: a staging copy, a second site on the same hosting account, an old subdomain you forgot about. Attackers often get in through the forgotten one, and sites sharing a hosting account can sometimes reach each other's files.

Then open a document or spreadsheet with four columns: item, finding, severity and action. Every step below adds rows. When you're done, that document is your audit.

Finally, take a fresh backup before you change anything. Audits often lead to deleting plugins or editing configuration, and you want a clean point to return to.

The WordPress security audit, step by step

Step 1: Build an inventory

You can't secure what you haven't listed. Record:

• WordPress core version and PHP version.
• Every plugin, active and inactive, with its version.
• Every theme, including the ones you're not using.
• Hosting provider, where DNS is managed, and who has access to each.
• Anything outside WordPress that touches the site: a CDN, a form service, a payment gateway, an external backup service.

This is the slowest manual part of any WordPress audit, and the part tools help with most. More on that below.

Step 2: Check versions and abandoned plugins

Go through the inventory and mark anything with an update available. Outdated plugins are a leading way into WordPress sites, so treat pending updates on active plugins as high severity.

Then look for software that's worse than outdated: abandoned. On WordPress.org, each plugin page shows when it was last updated and which WordPress version it was tested with. A plugin that hasn't been touched in a couple of years won't get fixes when a vulnerability is found. Also note plugins that have been closed or removed from the directory, which can happen for security reasons. For each abandoned plugin, the action is "replace or remove", not "update".

Inactive plugins and unused themes go on the list too. Their files are still on the server. Unless you have a reason to keep one, the action is "delete".

Step 3: Review users and roles

Export or read through Users in wp-admin and ask, for each account: is this a real, current person, and do they need this role?

• Remove accounts for former staff, freelancers and agencies.
• Downgrade people who only write or edit content to Editor or Author.
• Flag any account named "admin" and any unexpected administrator you don't recognize. An administrator nobody can explain is a possible sign of compromise.
• Check Settings, General: if anyone can register, the default role should be Subscriber.

Step 4: Passwords and two-factor authentication

Confirm administrators use unique passwords stored in a password manager, and that two-factor authentication is enabled for them. WordPress doesn't include 2FA by itself, so note which plugin or host feature provides it. Don't forget the accounts around WordPress: hosting control panel, SFTP, database, domain registrar and DNS. A stolen hosting login bypasses every WordPress setting.

Step 5: File integrity

WordPress.org publishes checksums for every core file. Comparing your files against them shows whether any core file was modified or is missing. WP-CLI can do this with wp core verify-checksums, and several security plugins and audit tools do the same.

Next, look in wp-content/uploads for PHP files. That folder should hold media, not code. A PHP file there is a classic sign that someone uploaded a backdoor. Modified core files or PHP in uploads move the audit from "tidy up" to "possible incident": restore from a known-clean backup or bring in your host or a security professional, then change every password.

Step 6: Configuration

Check the settings that quietly widen your attack surface:

• Debug mode. WP_DEBUG should be off on production, and wp-content/debug.log shouldn't be publicly downloadable.
• File editing. The built-in theme and plugin editor should be disabled with DISALLOW_FILE_EDIT in wp-config.php.
• XML-RPC. If no service you use needs it, disable it.
• PHP version. Confirm it still receives security support.

Step 7: SSL and security headers

Confirm the certificate is valid and not close to expiry, both site addresses in Settings use https://, and plain HTTP redirects to HTTPS. Then check response headers with your browser's developer tools or an online header checker. Common ones to look for are Strict-Transport-Security, X-Content-Type-Options and a sensible Content-Security-Policy or X-Frame-Options. Headers are usually set at the server, CDN or with a plugin, so the action is often a ticket to your host.

Step 8: Backups and a restore test

A backup you've never restored is a hope, not a plan. Check that backups run automatically, include both files and database, are stored off the server and are kept long enough to go back before a compromise that went unnoticed for weeks. Then do a test restore to a staging site and note how long it took. If it fails or takes all day, that's a high-severity finding.

Audit logs: what they are and why you need one

A WordPress audit log, also called an activity log, is a record of who did what on the site and when: logins and failed logins, posts published or deleted, plugins installed or activated, users created, settings changed. WordPress doesn't keep a detailed log like this out of the box; you add one with a plugin or get it from your host or management tool.

It matters for two reasons. During an audit, it answers questions like "who created this administrator?" or "when was this plugin installed?". After an incident, it helps you work out how far back to restore. Note in your audit whether you have a log, how long it keeps entries and who reviews it.

If you use an AI assistant or other connected tools, they should keep their own record too. WPMate, for example, keeps an activity log of every action your assistant takes on your sites.

Turning findings into a fix list

Sort your rows by severity. A simple scale works:

For every finding, write an owner and a date. For anything you choose not to fix, write why. "We keep XML-RPC because the mobile app needs it" is a decision; leaving it unrecorded is an oversight.

How often to run a WordPress security audit

A full audit once a quarter suits most business sites. Run one extra whenever something significant changes: a new developer or agency, a redesign, a migration to new hosting, or a security incident. Between audits, a quick weekly check of pending updates and new user accounts catches most problems early. Agencies managing many sites usually find the inventory step is where the time goes, so it pays to automate it.

Speeding up the inventory with an AI-run audit

Steps 1, 2, 5 and parts of 3 and 6 are mostly reading: listing versions, comparing checksums, checking settings. That's work an assistant connected to your site can do in a minute. With WPMate connected to Claude or ChatGPT, the security_audit tool checks updates, inactive plugins and unused themes, core file checksums, PHP in uploads, debug and file-editing settings, XML-RPC, the table prefix, admin accounts, open registration, HTTPS and PHP version, and ranks findings as critical, high, medium or low.

The audit is read-only. It doesn't install, update or delete anything, or change settings. You still apply updates in wp-admin after a backup, and the human parts of the process, such as deciding who should have access, testing restores and reviewing headers with your host, remain yours. It also isn't a malware scanner or firewall. See what the security audit checks for the full list.

If you look after several sites, our guide to managing multiple WordPress sites covers keeping audits consistent across all of them.

Frequently asked questions