Table of contents15
The audit took me forty minutes, and it found three problems that a “clean” security scan had missed completely. The site owner’s scanner report said everything was fine — green checkmarks across the board. But their debug.log file was publicly readable and full of database credentials, their SSL certificate expired in nine days, and a former contractor still had an administrator account two years after leaving. None of those are malware. A malware scanner will never flag any of them. And any one of them could have ended the business. The checklist I used that day is the WordPress security audit checklist you are about to learn.
I’m Ryan Clarke, and I perform security audits on WordPress sites for companies that cannot afford surprises. That forty-minute audit changed how I explain my work: a security scan looks for evidence of past attacks, but a security audit looks for open doors before anyone walks through them. They are different jobs, and you need both. Learning to run a proper WordPress security audit checklist on your own site is one of the highest-value skills a site owner can build.
Here is the fear worth sitting with for a moment: most hacked sites I investigate were not hacked through some exotic zero-day vulnerability. They were hacked through something boring and preventable — an old admin account, an outdated plugin, a readable backup file, an expired certificate nobody noticed. The audit exists to catch the boring problems, because the boring problems are what actually get sites hacked.
In this guide I will walk you through a complete DIY security audit in ten ordered steps: reviewing every user account, checking updates and removing dead weight, verifying file permissions and hunting exposed files, hardening your configuration, checking SSL and security headers, securing the database, verifying your backups actually restore, reviewing logs and scanning for malware, auditing integrations and API keys, and documenting who owns what. Follow it top to bottom, in order — the steps are sequenced by attacker value, so the most dangerous gaps get closed first. This is for WordPress site owners who want a professional-grade audit without hiring anyone. Ready? Let’s get started.
One honest note before we begin: an audit finds problems, and finding problems can feel bad. It is not bad — it is the entire point. Every issue you find in this checklist is an attack you just prevented. I would rather you find ten problems today than discover one breach next month.
What You Will Learn in This Guide
- Why a security audit catches things malware scanners never will
- How to audit every user account and apply the principle of least privilege
- How to check updates, remove abandoned plugins, and kill dead weight
- How to verify file permissions and hunt for publicly exposed files
- How to harden wp-config.php and critical configuration
- How to verify SSL, security headers, and database security
- How to prove your backups actually work — not just that they exist
- How to review logs, scan for malware, audit API keys, and document ownership
Ready? Let’s get started.
Before the Audit: What You Need
A good WordPress security audit checklist needs about an hour, a cup of coffee, and access to three things: your WordPress dashboard with an administrator account, your hosting control panel or file manager, and ideally SSH access for the faster checks. If you do not have SSH, every step below still works through the dashboard and file manager — the commands I include are shortcuts, not requirements.
Start a simple document to record your findings — a notes app, a spreadsheet, anything. For each step, write down what you checked, what you found, and what you fixed. This becomes your audit trail, and next quarter when you run the audit again, you will compare against it instead of starting from zero. Professionals document everything; that habit alone puts you ahead of most site owners.
Step 1: Audit Every User Account
I put user accounts first deliberately, because in my experience it is the most commonly skipped step and one of the most valuable. Go to Users, All Users in your dashboard and look at every single account with fresh eyes. Ask three questions about each one: who is this person, do they still need access, and does their role match what they actually do?
What you are hunting for: former employees and contractors who still have accounts (the single most common finding in my audits), accounts with the username “admin” (change it — it is the first username every brute-force bot tries), users with administrator roles who only ever needed to be editors or authors, and any account you do not recognize at all. An unrecognized admin account is a potential breach, not a curiosity — treat it that way.
Apply the principle of least privilege: nobody gets more access than their job requires. A content writer needs an Author role, not Administrator. A developer who finished their contract needs no role at all — remove the account. If you have SSH, this command lists every administrator with their registration dates for quick review:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredThen require two-factor authentication for every administrator and editor account. Passwords get stolen — through phishing, through breaches on other sites, through keyloggers. Two-factor authentication means a stolen password alone is not enough. This one requirement neutralizes the most common account-takeover path on WordPress, and it costs nothing.
Step 2: Check Updates and Remove Dead Weight
Outdated software is the most exploited attack vector in the WordPress ecosystem, full stop. The overwhelming majority of WordPress vulnerabilities live in plugins and themes, not in WordPress core — so this step is really a plugin and theme audit disguised as an update check. Go to Dashboard, Updates and update everything: core, plugins, themes. Then do the harder part.
The harder part is removal. Go through your plugins list and delete — not deactivate, delete — everything you do not actively use. A deactivated plugin still sits on your server with all its code intact, and vulnerable code does not care whether it is activated. I find an average of four to six dead plugins on every site I audit, and every one of them is an unlocked window. Do the same for themes: keep your active theme and one default fallback, delete the rest.
Pay special attention to abandoned plugins — plugins that have not been updated by their developers in over a year. An abandoned plugin will never receive security patches, which means every vulnerability discovered in it stays open forever on your site. If you depend on one, find a maintained alternative now, on your schedule, rather than during an emergency later. Our safe WordPress update checklist shows you how to update without breaking things.
Step 3: Verify File Permissions and Hunt Exposed Files
File permissions decide who can read or change every file on your server, and wrong permissions are silent — nothing looks broken, but the doors are open. The baseline: directories should be 755, regular files 644, and wp-config.php should be stricter at 400, 440, or 600 depending on your host. Anything set to 777 — readable, writable, and executable by everyone — is an emergency. Over SSH, this command finds world-writable PHP files instantly:
find /path/to/wordpress -name "*.php" -perm /o+w 2>/dev/nullAny output from that command is a problem to fix. But permissions are only half of this step. The other half is hunting for files that should never be publicly reachable. Check these right now in your browser: yoursite.com/wp-content/debug.log (debug logs often contain database credentials and API keys — if it loads, delete it and disable debug logging), yoursite.com/readme.html (it advertises your exact WordPress version to attackers), and any wp-config backup copies like wp-config.php.bak (served as plain text, credentials readable by anyone).
This is the step where that “clean scanner report” from my opening story fell apart. Scanners check files for malware signatures; they do not check whether your debug.log is readable or your certificate is expiring. Configuration-level gaps like these are the audit’s home turf. For the full permission model, our WordPress file permissions security guide goes deep.
Step 4: Harden wp-config.php and Critical Settings
Your wp-config.php file holds your database credentials and secret keys — it is the crown jewel of your installation, and the audit must verify it is treated that way. Confirm the file permissions are strict (400, 440, or 600 — never 644 on shared hosting), verify the file has not been moved or duplicated into strange locations, and check that direct browser access is blocked.
Then verify these critical settings inside the file: WP_DEBUG is false on your live site (debug output leaks server paths and database details), DISALLOW_FILE_EDIT is true (this removes the dashboard code editor that attackers use to plant backdoors), and your security keys and salts are unique (if you have ever suspected exposure, rotate them — it logs everyone out, which is exactly the point). If any of these need work, follow the step-by-step process in our hardening walkthroughs before continuing the audit.
Step 5: Verify SSL and Security Headers
SSL certificates expire, and they expire silently until the day visitors see a terrifying browser warning. Check yours now: click the padlock in your browser’s address bar and confirm the certificate is valid, issued to your domain, and not expiring within the next 30 days. Better yet, set up auto-renewal with your host or certificate provider so this never becomes an emergency. Then confirm every page loads over HTTPS with no mixed-content warnings — a single HTTP-loaded script on an HTTPS page undermines the whole thing.
Next, check your security headers — the invisible instructions your server sends to visitors’ browsers. Run your domain through securityheaders.com and note the grade. You want to see X-Frame-Options (clickjacking protection), X-Content-Type-Options: nosniff (MIME-sniffing protection), a Referrer-Policy, a Permissions-Policy, and Strict-Transport-Security (HSTS forcing HTTPS). Most unhardened WordPress sites score D or F here. Our security update analysis covers how core updates interact with these protections, and the headers guide linked in our hardening series walks through the full setup.
Also verify that xmlrpc.php returns 403 or 404 — if it is still wide open, you have a brute-force bypass sitting on your server. Closing it takes fifteen minutes and removes an entire attack class.
Step 6: Secure the Database
The database holds everything — your content, your users, your settings — so the audit gives it its own step. First, confirm your database user is not the root account and does not have more privileges than WordPress needs. A dedicated database user with limited privileges means that even if credentials leak, the damage is contained.
Second, check your table prefix. The default wp_ prefix is known to every automated attack tool. Changing it on an existing site is a delicate operation — it requires renaming every table and updating references — so I am honest that this is obscurity, not armor. It stops automated tools, not targeted attackers. Worth doing on new sites; on existing sites, weigh the risk of the operation against the modest benefit.
Third, look at what is actually in the database. Scan wp_posts for injected script tags, check wp_options for suspicious entries with innocent-looking names, and review the wp_users table once more for accounts the dashboard might not show clearly. Database-level inspection catches the injections that file scans miss — our malware inspection workflow covers the exact queries to run.
Step 7: Prove Your Backups Actually Work
Here is the audit step that makes people uncomfortable: a backup you have never restored is a hope, not a backup. Go to wherever your backups live and verify three things. One: backups are actually running on schedule — check the timestamps, not the green checkmarks. Two: the backup files are complete and downloadable, not zero-byte corpses or corrupted partials. Three: at least one copy lives off-site, physically separate from your server — a backup on the same server as your site dies in the same fire.
The gold standard is a test restore: spin up a staging copy and restore your latest backup into it once per quarter. I know it sounds like work. But every site owner I have met who skipped this step and later needed their backup discovered the problem at the worst possible moment — during the actual emergency. A quarterly restore test takes an hour and buys you certainty. Certainty is what backups are for.
While you are here, verify your backup includes both files and the database, and that you know the restore procedure without having to figure it out under pressure. Write the steps down. Future-you, mid-crisis, will be grateful.
Step 8: Review Logs and Scan for Malware
With the configuration verified, now look for evidence of past or ongoing compromise. Download your recent server access logs and scan for the telltale patterns: repeated POST requests to wp-login.php or xmlrpc.php from the same IPs, requests from countries you have no business with, file uploads to wp-content/uploads you did not perform, and access to admin pages at hours when nobody on your team works.
Then run a malware inspection pass: verify WordPress core checksums, hunt for PHP files in the uploads folder, search for obfuscated code patterns, and check the database for injections. If anything looks wrong, our hacked site recovery guide walks through the full cleanup sequence. The audit’s job here is detection — finding the smoke before you need the fire department.
Bonus Tip: check your domain against blacklists while you are at it. A blacklisted domain means the compromise already happened and search engines know about it — which changes your priority list dramatically. Catching it in an audit is infinitely better than catching it from a client’s angry email.
Step 9: Audit Integrations and API Keys
Every connected service is a door into your site, and most sites accumulate more integrations than anyone remembers. List them all: payment gateways, email services, analytics, social auto-posters, CDN and firewall services, backup destinations, and any third-party API keys stored in your settings or wp-config.php.
For each integration, ask: do we still use this, who owns the account, and what happens if the key leaks? Revoke keys for services you no longer use. Confirm the remaining keys belong to current team members, not to a contractor who left two years ago — the same hygiene as Step 1, applied to machines instead of humans. Rotate any key that has ever been emailed, pasted into a chat, or committed to a repository. Keys in chat logs are compromised keys; treat them accordingly.
Step 10: Document Who Owns What
The final step is the least technical and the most neglected: write down who owns every piece of your site’s infrastructure. Hosting account, domain registrar, DNS provider, CDN, SSL certificate, backup storage, email service, and the WordPress administrator accounts. For each one: the account owner, the login method, and how a successor would gain access in an emergency.
I have seen businesses locked out of their own sites because the only person with the hosting login left the company, and the domain expired because renewal emails went to a dead inbox. None of that is hacking — it is just entropy. Documentation is the cheapest security control in this entire guide, and it protects against the most human failure mode of all: everybody assuming somebody else has it covered.
Your Ongoing Audit Schedule
An audit is not a one-time event — it is a rhythm. Here is the cadence I recommend to clients, based on what actually catches problems without burning you out. Monthly (15 minutes): review user accounts, check for updates, glance at logs for anomalies. Quarterly (one hour): run the full ten-step audit, test-restore a backup, review integrations. Yearly (half a day): rotate API keys and salts, review documentation ownership, reconsider your hosting and backup strategy.
Put the next audit on your calendar right now, before you close this tab. The audit that happens on schedule is the one that works. The audit you meant to do “soon” is the one that never happens — and “soon” is exactly when the boring problems accumulate into a breach.
WordPress Security Audit Checklist: Frequently Asked Questions
My security scanner says the site is clean. Why do I need an audit? Because they check different things. A scanner looks for malware signatures and modified files — evidence of past attacks. An audit checks configuration: expiring certificates, readable debug logs, open xmlrpc.php, stale admin accounts, untested backups. A site can pass every malware scan and still fail an audit badly. Scans are reactive; audits are preventive. You need both.
How long does a full audit take? About an hour once you know the steps, plus the fixes you decide to make. The first audit takes longer because you are learning and documenting. Quarterly follow-ups go much faster since you are comparing against your previous findings instead of starting from zero.
How often should I run a security audit? Monthly for the quick checks (users, updates, log glance), quarterly for the full ten steps, yearly for key rotation and ownership review. High-traffic or e-commerce sites should lean toward the more frequent end. The schedule above balances thoroughness against the reality that you have a business to run.
What is the single most important step in the audit? If I had to pick one, it would be Step 1: the user account review. Stale admin accounts are the most common finding in my audits and the simplest attack path — no vulnerability required, just a forgotten login. It takes five minutes and closes the door attackers check first.
Should I hire a professional instead of doing it myself? This checklist covers what a professional checks at the configuration level, and doing it yourself builds understanding no report can give you. For high-value sites — e-commerce, membership, anything handling sensitive data — a professional audit once a year on top of your own quarterly audits is a reasonable belt-and-suspenders approach. For most small sites, this checklist done honestly is enough.
Final Thoughts: Your WordPress Security Audit Checklist
That forty-minute audit from my opening story did not find malware. It found something more valuable: three boring problems that would each have become an emergency within months. The readable debug log, the expiring certificate, the forgotten admin account — none of them showed up on a scanner, all of them showed up in an audit. That is the whole argument for this checklist in one story.
You now have the complete ten-step workflow: user accounts, updates and dead weight, permissions and exposed files, configuration hardening, SSL and headers, database security, proven backups, log review and malware scanning, integration audits, and ownership documentation — plus a schedule that keeps it all alive. Worked top to bottom, in order, it closes the gaps in the sequence attackers actually exploit.
The honest line: an audit does not make you unhackable. Nothing does. What it makes you is a hard target — the kind of site where the boring doors are closed, the credentials are fresh, and the backups actually restore. Attackers are lazy by economics; they move on to easier prey. Be the site they skip. If you ever do face the worst case, our vulnerability case study shows how fast things move when preparation meets a real incident — and our recovery guide will walk you home.
How many issues did your first audit find? Be honest — tell me in the comments. I read every one, and the most common answer might surprise you.
Published: October 18, 2026 · Updated: October 18, 2026 · By Ryan Clarke
