How to Do a WordPress Security Audit for Your Website

Most WordPress security problems aren’t the result of sophisticated attacks. They come from outdated plugins sitting unattended for months, user accounts with admin access that were never removed, weak passwords on accounts no one monitors, and settings that were configured at launch and never reviewed. A security audit is a systematic check of all of these things — not a one-time setup task, but a periodic review to catch the gaps that accumulate over time.

You don’t need specialist tools or deep technical knowledge to run a basic audit. The checks covered here can be done through the WordPress dashboard, your hosting control panel, and a free security plugin. Running through them every three to six months keeps your site in significantly better shape than most WordPress sites on the web.

Quick Answer

A WordPress security audit covers eight areas: user accounts and permissions, plugin and theme inventory, login security configuration, core and plugin update status, a malware scan, file and database permissions, HTTP security headers, and backup verification. Work through each area methodically, fix what you find, and document the date so you know when the next audit is due.

Why Regular Audits Matter

Initial security hardening — strong passwords, a firewall, two-factor authentication — covers the obvious entry points. But a site’s security posture degrades over time. Plugins are installed and forgotten. Users are added for a project and never removed. An update is skipped once, then twice, and suddenly a plugin is three major versions behind with known vulnerabilities. None of this is visible without actively checking.

A periodic audit catches these gradual issues before they become exploitable. The goal isn’t to achieve perfect security — that doesn’t exist — but to make your site a harder target than most, so that automated attacks and opportunistic scans move on to easier options.

Step-by-Step Audit Checklist

Step 1: Review User Accounts and Permissions

Go to Users → All Users in your WordPress dashboard. Review every account:

• Remove any accounts that belong to people who no longer need access — former contractors, old clients, test accounts.
• Check that every admin-level account belongs to someone who genuinely needs that level of access. Most contributors, editors, and clients should be on lower roles.
• Look for any accounts you don’t recognise. An unknown admin account is a serious red flag and may indicate the site has already been compromised.
• Verify that your own admin account uses a strong, unique password and has two-factor authentication enabled.

The principle here is minimum necessary access — every account should have only the permissions it actually needs. An editor who can publish posts doesn’t need admin access to the site settings.

Step 2: Audit Your Plugin and Theme Inventory

Go to Plugins → Installed Plugins and review the full list:

• Deactivate and delete any plugins you’re not actively using. Inactive plugins still represent a potential attack surface if they have vulnerabilities.
• Check the “last updated” date for each active plugin. A plugin that hasn’t been updated in over a year may be abandoned — check the plugin page on WordPress.org for its active installation count and whether it’s been tested with your current WordPress version.
• Look for plugins from unknown sources. Plugins installed outside the WordPress.org repository or without a reputable vendor should be reviewed carefully.

Do the same for themes under Appearance → Themes. Delete any themes you’re not using, including the default WordPress themes if you’ve switched away from them permanently.

Step 3: Check Login Security Configuration

Review the controls you have in place to protect the WordPress login page:

• Login attempt limiting: Confirm a plugin is active that blocks repeated failed login attempts. Without this, brute force attacks can run indefinitely. The guide on how to limit login attempts in WordPress covers the setup.
• Two-factor authentication: Verify that 2FA is enabled on all admin accounts. If it’s only on your account, check whether other admin users have it active.
• Login URL: If you’ve changed the default login URL away from /wp-admin/ or /wp-login.php, confirm it’s still working correctly and that the old URLs redirect or return a 404.
• Default “admin” username: Confirm no account uses the username “admin” — this is the first username automated attacks try.

Step 4: Verify Core and Plugin Updates

Go to Dashboard → Updates and check whether anything is pending. All pending updates should be applied — outdated software is the most common entry point for successful attacks.

If you find a long backlog of updates, note which plugins are furthest behind. A plugin that’s multiple major versions behind warrants extra scrutiny — check whether there are any known vulnerabilities for the installed version using the WPScan vulnerability database or the plugin’s changelog. Apply updates in the correct order: plugins first, themes second, WordPress core last.

Step 5: Run a Malware Scan

Install and run a security scanner if you don’t have one active. Wordfence Security is the most widely used option — the free version scans your files, themes, and plugins for known malware signatures, modified core files, and suspicious code.

Review the scan results carefully. Warnings about modified core files are worth investigating — WordPress core files shouldn’t be modified, and changes can indicate tampering. False positives do occur, but any result flagging injected code or unknown files in core directories should be treated seriously until ruled out. If a scan does turn up a genuine infection, the guide on how to remove malware from a WordPress website walks through cleaning it up and closing the entry point.

Step 6: Check File Permissions and Database Access

File permissions control who can read, write, and execute files on your server. Incorrect permissions — particularly world-writable files or directories — can allow attackers to modify site files if they gain any foothold.

The standard WordPress permission recommendations are: directories set to 755 and files set to 644. The wp-config.php file, which contains your database credentials, should be set to 600 or 640. Your hosting control panel’s file manager shows current permissions, or you can check via FTP. Most security plugins also flag obvious permission problems in their scan results.

For database access, check that your WordPress database user has only the permissions it needs — typically SELECT, INSERT, UPDATE, DELETE, and a few others for core functionality. Full database admin access for the WordPress user is unnecessary and increases risk if credentials are ever exposed.

Step 7: Review HTTP Security Headers

Security headers are server-level instructions that tell browsers how to handle your site’s content — preventing clickjacking, controlling what resources can load, and blocking certain types of injection attacks. They’re easy to overlook because they have no visible effect on the site but make a real difference to the browser-level attack surface.

Check your current headers using a free tool like securityheaders.com, which grades your implementation and lists what’s missing. A guide covering the key HTTP security headers and how to implement them without a plugin is worth keeping on hand for this step.

Step 8: Confirm Your Backup Strategy

A security audit that never checks backups is only half finished. If every other check in this list fails and the site is compromised anyway, a working backup is what actually gets you back online — everything above this step reduces the odds of an incident, but only a backup gives you a way out of one.

• Confirm backups are actually running. Check your hosting control panel or backup plugin for the date of the most recent successful backup, not just whether the feature is turned on. A backup schedule that silently stopped running months ago is a common finding on sites that assumed “set up once” meant “working forever.”
• Check where backups are stored. A backup stored on the same server as the site it protects doesn’t help if that server is compromised, taken offline, or the hosting account itself is the thing that’s breached. Offsite storage — a separate cloud storage provider, not just a different folder on the same host — is what makes a backup a genuine recovery option rather than a false sense of security.
• Test the restore process, not just the backup file. A backup that has never actually been restored is unverified. Once or twice a year, restore a recent backup to a staging environment and confirm the site comes back up correctly — this is the only way to know the backup is actually usable before you need it under pressure.
• Check the retention period. If an infection or bad edit isn’t noticed for a few weeks, a backup schedule that only keeps the last 3–7 days won’t have a clean version to restore from. Match your retention window to how often the site is actively checked, not just to the default the plugin or host shipped with.

A Worked Example: Auditing a Two-Year-Old Client Site

A freelancer inherits a client’s WordPress site that’s been live for two years with no formal audit ever run. Working through the checklist above in order: Step 1 turns up an admin-level account still active for a web developer who finished the original build eighteen months earlier and was never removed — downgraded to no access, since the relationship has ended. Step 2 finds three plugins that were installed for a one-off promotion and never deactivated, one of which hasn’t been updated in over a year — all three are deleted rather than just deactivated. Step 3 confirms there’s no login-limiting plugin active at all, so one is installed and configured the same session. Step 4 shows twelve pending plugin updates, applied in the standard order. Step 5’s malware scan comes back clean. Step 8 is where the real gap turns up: backups are technically “on,” but the most recent successful one is four months old, because a plugin conflict silently broke the backup job without sending any failure notice. Fixing that single item — not the missing 2FA, not the stale plugins — turns out to be the most consequential outcome of the whole audit, since it’s the difference between a future incident being a recoverable inconvenience and a total loss.

Practical Tips

Set a recurring calendar reminder for your audit — every three months for active sites, every six months for lower-traffic sites. Without a scheduled prompt, audits tend to get deferred indefinitely.

Keep a simple log of what you checked and when. A spreadsheet with the audit date, each area reviewed, and any issues found gives you a historical record that’s useful if something does go wrong.

Don’t wait for the audit schedule if you add a new plugin, onboard a new user, or make significant site changes. Those are also moments to run through the relevant checks — new plugins should be verified, new users should be assigned the right role, and any changes to the site structure should be reviewed for security implications.

Common Mistakes

Treating the initial setup as permanent. Security hardening done at launch is a starting point, not a permanent solution. Sites change, plugins are added, users come and go — the audit catches what the initial setup didn’t anticipate.

Ignoring scan warnings without investigating. Security scan results are sometimes flagged as low priority and dismissed. Any warning about modified core files or unknown injected code deserves investigation before being cleared.

Leaving unused plugins installed but deactivated. Deactivated plugins still exist on the server and can contain vulnerabilities. Delete them if you’re not using them.

Assuming backups are fine because the setting is turned on. A backup schedule can silently fail for months without any obvious symptom — the only way to know it’s actually working is to check the date of the last successful run and, periodically, to restore from it.

File permissions and database access, user roles, HTTP security headers, and your SSL certificate’s validity are all worth a specific look during this same pass — each is a small check on its own, but skipping any one of them leaves a gap the rest of the audit won’t catch. The same applies to active monitoring: an audit is a periodic snapshot, while monitoring alerts you the moment something suspicious happens between audits, such as a modified core file or a new admin account appearing without warning.

If a security scan uncovers suspicious access, or you find yourself unable to reach your dashboard during an audit, resolving login issues — from redirect loops to full admin lockouts — is usually the first thing to sort out before continuing the rest of the checklist.

DIY Audit vs. Hiring a Security Specialist

The checklist above is genuinely enough for most sites, most of the time — a personal blog, a small business site, or a portfolio with no signs of compromise doesn’t need outside help to run through these eight steps every few months.

Bring in a specialist instead of self-remediating when the audit turns up active compromise rather than just neglect: unfamiliar admin accounts you can’t attribute to anyone, injected code you don’t understand well enough to safely remove, the site flagged on a search engine blacklist, or repeated reinfection after you’ve already cleaned it once. Removing malware without identifying how it got in the first place often leaves the same entry point open, and a site that keeps getting reinfected after DIY cleanup is the clearest sign the audit has found something beyond a routine fix. An incident response specialist can also help if the site handles payment data or customer records, where a breach carries compliance obligations a routine audit checklist isn’t designed to cover.

Conclusion

Review users, audit plugins, check login security, apply updates, run a malware scan, verify file permissions, check your security headers, and confirm your backups actually work. A thorough run-through takes an hour or two and catches the kind of gradual security drift that makes sites vulnerable over time. For the full initial setup — hardening your site from scratch rather than auditing an existing one — the guide on how to secure a WordPress website covers the foundational steps. For everything involved in building and maintaining a WordPress website, the step-by-step guide to building a WordPress website covers each stage in sequence.