A WordPress security audit sounds like something a consultant does with a clipboard and a large invoice. It does not have to be. If you can find your way around the WordPress dashboard, you can run a solid audit yourself in an afternoon.
The idea is simple: look at your site the way an attacker would, find the weak spots, and fix them before someone else finds them. This guide gives you the steps in a sensible order, explains each one in plain English, and ends with a checklist you can keep and reuse.
Make a coffee. Open a note to jot down what you find. Let's go.
Before You Start Your WordPress Security Audit
A little preparation saves a lot of panic.
Take a backup first. You will be removing users and plugins, and you want a way back if something breaks. If you do not have a recent backup, make one now. Our backup strategy guide explains what a good one looks like.
Use staging for risky changes. A staging site is a private copy of your site where you can try things safely. Most good hosts offer one in a click.
Block out the time. For a small site, about three to four hours is realistic. Bigger sites take longer, mostly because there is more to look through.
Write things down. Keep a note of what you find and what you change. This becomes your record for next time.
WordPress Security Audit, Part One: Outside View, Users and Plugins
Step 1: Run a Quick Outside Check
Start from the outside. Run the free security check on your site. It looks at your site the way a visitor or a bot would and gives you a first list of things to follow up.
Pro tip: screenshot your results and your Stack Guard score before you change anything. A before-and-after is satisfying, and useful proof if someone asks what you did.
Treat the results as a starting point, not a verdict. An outside check cannot see inside your dashboard, which is why the next steps go inside.
If you use Stack Guard Free, the dashboard also shows a security score built from 14 checks. Each one tells you what is on, what is off and what to do about it. It is a handy before-and-after: note the score now, and check it again at the end of your audit.
Step 2: Review Users and Roles
Users are one of the biggest and most overlooked risks. Go to Users in your dashboard and read down the list slowly.
For each person, ask:
- Do I know who this is?
- Do they still work with us?
- Do they need this role?
Remove accounts that nobody recognises or needs. Before deleting a user who owns content, WordPress will ask you who should inherit it, so pick a sensible account.
Then look at roles. Administrators can do anything, including install code. Most people need far less. An editor can publish posts without being able to install plugins. Give the least power that gets the job done.
Look out for a user called admin. It is the first name bots try. If you have one, create a new administrator with a different name, log in as that person and remove the old one. Our article on changing the WordPress admin username walks through it safely.
Stack Guard's user security console shows each user's role, password age and two-factor status at a glance, and Pro flags administrators who have not signed in for 90 days.
Step 3: Check Plugins and Themes
Plugins and themes are the usual way in, so give them real attention. Go to Plugins, then Installed Plugins.
Remove What You Do Not Use
If a plugin is deactivated, it still sits on your server, and some vulnerabilities can be reached even when a plugin is switched off. Delete anything you are not using. Do the same for old themes. Keep one default theme as a fallback, and your active one.
Check Each One Is Still Looked After
For each plugin, look at its page on wordpress.org, or the developer's site. When was it last updated? Does the developer respond to questions? A plugin with no updates for a couple of years is a risk, because new flaws will never be fixed. Look for a maintained alternative.
Check for Known Vulnerabilities
Vulnerabilities in plugins are published, and attackers use those lists. Our article on WordPress plugin vulnerabilities explains how this works. Stack Guard Pro flags plugins and themes that are several versions behind the latest release, which is where known weaknesses live, so you know which ones to look up first.
Only Install From Trusted Sources
Download plugins from wordpress.org or from the developer directly. Avoid "nulled" copies of paid plugins. They are free for a reason, and the reason is usually that someone added something nasty.
Step 4: Confirm Updates Are Current
Go to Dashboard, then Updates. Check WordPress core, plugins and themes. Update what is waiting.
Also check your PHP version. PHP is the language your server uses to run WordPress, and old versions stop receiving security fixes. Your host usually lets you change it from their control panel. Stack Guard's versions overview shows your WordPress, plugin, theme and PHP support dates in one place.
If you are worried about updates breaking things, update on staging first, then repeat on the live site. For an extra layer of safety, take a backup before each round.
The official WordPress hardening handbook is blunt about this: older versions no longer get security fixes. It also recommends considering automatic updates, which is worth a look for small plugins.
Part Two: Sign-In, Backups and HTTPS
Step 5: Test Your Sign-In Security
Your sign-in page is the front door, so check the lock.
Passwords. Are all admin and editor passwords long and unique? A password manager makes this painless. You can check whether a password appears in known breaches at Have I Been Pwned without sending it in full.
Two-factor. Is it on for every administrator? It asks for a code from your phone on top of the password, so a stolen password is not enough. See the two-factor guide.
Lockouts. Does your site stop repeated failed attempts? Open a private window and try wrong passwords a few times on a test account. You should be blocked after a few tries.
Error messages. Do wrong usernames and wrong passwords give the same vague message? If not, attackers can confirm which usernames exist.
The login address. Can you move or hide
wp-login.php? It will not stop a determined attacker, but it removes a lot of bot noise. Our hide wp-login guide covers the options.Sessions. How long does a forgotten browser stay signed in? By default it can be days. Our guide to WordPress auto logout shows how to shorten it.
Stack Guard Free handles most of this: a custom sign-in address, a generic error, authenticator and email two-factor, per-IP lockouts and breached-password checks.
Step 6: Check Your Backups, Then Test a Restore
This is the step most audits skip, and it is the one that saves your business.
Find Out What You Have
Where do your backups live? How often are they made? How far back do they go? If the answer to "where" is "on the same server as the site", that is not enough. If the server fails or is hacked, the backups can go with it.
Make Sure One Is Fresh
Take a new backup now, so you know the process works and you have a current copy.
Actually Restore One
Key takeaway: a backup only counts once you have restored it. Testing a restore on staging is the cheapest insurance in this whole audit.
If you have never restored it, you do not know it works. Restore it on staging, or a spare install, and check the site loads, you can log in, images appear and forms work. If it fails, you have just learned something very valuable while it is cheap.
Stack Guard Free makes manual full or database-only backups that are verified before they count, and every restore is staged and checked before anything live changes. You can then keep the result or roll back within seven days. Backup schedules, retention and Google Drive backups are coming soon, so today they are manual. Our guide on how to restore WordPress from a backup covers the process step by step.
Step 7: Check HTTPS and Security Headers
HTTPS is the padlock in the address bar. It encrypts traffic between your visitor and your site, including passwords. Visit your site with http:// at the front. It should jump to https://. If it does not, follow our article on how to force HTTPS in WordPress.
Next are security headers, small instructions your site sends to browsers about how to behave. They protect against things like your pages being embedded in a malicious site. Our security headers guide explains them in detail.
Stack Guard Free can set the basic headers: X-Frame-Options, Referrer-Policy, Permissions-Policy and cross-domain policy. Pro adds HSTS (which tells browsers to always use HTTPS) and a Content Security Policy builder.
Part Three: Malware and Logs
Step 8: Run a Malware Scan
Now look for anything that should not be there. Run a scan with a tool you trust. Check that WordPress core files match the official copies, scan plugins and themes, and look at the uploads folder, where PHP files should rarely live.
If you find something, do not panic and do not start deleting at random. Note what it is, take a backup of the current state for evidence, and follow our guide to recover a hacked WordPress site. Our article on scanning WordPress for malware explains what findings mean.
Stack Guard Free runs manual scans with malware signatures and a core file integrity check, and each finding can be reviewed or ignored. Pro adds scheduled scans and file change monitoring, so you hear when a file changes that you did not change.
Step 9: Read the Logs
Finally, look at what has been happening. An activity log shows sign-ins, setting changes, lockouts and more. You are looking for patterns that do not fit.
Questions to ask:
- Were there sign-ins at odd hours, or from places you do not work?
- Did a user change a setting they should not have?
- Are there many failed attempts against one username?
- Did a new admin account appear that you did not create?
Stack Guard Free keeps core events for 7 days in its activity log. Pro keeps them for 90 days, with search, filters and CSV export, which is handy when you need to answer "when did this start?".
Also check that alerts reach a real inbox. Send a test, and confirm it does not end up in spam.
Your WordPress Security Audit Checklist
Here is the whole audit in one table. Copy it into a document and tick it off. Date it, and next time you will see what changed.
| Area | What to check | Done |
|---|---|---|
| Outside view | Run the free security check, note the results | |
| Users | Remove unknown or former users, trim admin roles, retire the admin username | |
| Plugins | Delete unused ones, check each is maintained, check for known vulnerabilities | |
| Themes | Remove unused themes, keep the active one and one default | |
| Updates | WordPress, plugins, themes and PHP are current | |
| Passwords | Every admin and editor has a long, unique password | |
| Two-factor | On for all administrators | |
| Lockouts | Repeated failed sign-ins get blocked | |
| Backups | Fresh backup, stored off the server | |
| Restore test | A backup restored successfully on staging | |
| HTTPS | HTTP redirects to HTTPS, no mixed content warnings | |
| Headers | Basic security headers are set | |
| Malware | Scan run, core files verified, findings reviewed | |
| Logs | Reviewed for odd sign-ins and changes | |
| Alerts | Test email arrives in a real inbox | |
| Owner | Someone is named to repeat this regularly |
After the Audit
Fix the highest-risk items first. Anything involving outdated software, shared admin accounts or no tested backup should go to the top of the list. Smaller improvements can wait for next week.
Then put the next audit in the calendar. A full pass once or twice a year, plus a ten-minute monthly look at updates, users and backups, keeps you well ahead of most sites. For a deeper set of fixes to apply, the WordPress hardening checklist is the natural next read, and if you are still weighing tools, our guide to the best WordPress security plugin shows how to compare them.
If you manage sites for clients, the same steps scale well, and they make a natural core for WordPress care plans. You can find more on that in our agency security guide.