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 six areas: user accounts and permissions, plugin and theme inventory, login security configuration, file and database access, core and plugin update status, and a malware scan. 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.
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. The guide on how to add HTTP security headers in WordPress covers how to implement the key ones without a plugin.
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.
Conclusion
Review users, audit plugins, check login security, apply updates, run a malware scan, verify file permissions, and check your security headers. A thorough run-through takes an hour or less 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 complete website building guide covers each stage in sequence.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.