Most WordPress security problems are not caught by anything sophisticated. They are caught by a competent person spending fifteen minutes looking. The vast majority of compromises happen on sites where nobody is looking at all — where login pages are open to the world, plugins are years out of date, and the only line of defence is the hope that no automated scanner ever notices the site exists.
You do not need to be a developer to spot the most common WordPress vulnerabilities. You need a small checklist and a few minutes. What follows is a self-audit any site owner can run today, on their own site, without installing anything new and without touching code.
Why a manual check is worth doing
The argument for automated security tools is reasonable, and most serious sites should have one running. But automated tools tend to catch a known list of problems, and they miss the kinds of issues a human notices straight away — the unused admin account belonging to the developer who left two years ago, the contact form that does not require any verification, the plugin nobody remembers installing.
The five-minute check that follows is not a substitute for a proper security setup. It is a way of finding the obvious problems, the ones that account for the overwhelming majority of compromises on small and mid-sized sites.
Step 1: Look at who has access
The first place to look is the user list. In WordPress admin, go to Users → All Users. You are looking for two things.
First, the list of administrators. Every account with the Administrator role can install plugins, edit code, change settings, and add new users. Each of those accounts is a key to the front door. The question to ask of every administrator account is: does this person still need access? Former staff, former agency contacts, the freelancer who built the site three years ago — these accounts often remain long after the relationship has ended.
Second, look for accounts you do not recognise. On a site that has been compromised, the attacker often adds an administrator account of their own. These accounts have unfamiliar usernames, sometimes with email addresses on unusual domains. If you see one, that is not a security check finding — that is an active incident.
Two practical actions for this step. Remove every administrator account that is not currently needed. Demote anyone who only edits content to the Editor role.
Step 2: Check the username “admin”
If your site has a user account with the username “admin,” that account is the first target of every automated brute-force attempt against WordPress. Attackers do not need to guess the username; it is the default name they try first, every time, on every site.
WordPress now warns against creating an account called “admin” on new installs, but older sites very often still have one. The fix is straightforward: create a new administrator account with a different username, log in as the new account, and delete the old “admin” account (transferring any content it owns to your new account when prompted).
This single change cuts a significant percentage of the brute-force traffic against your site.
Step 3: Look at the plugin list
Go to Plugins → Installed Plugins. Three things to check.
First, the version status. Anything marked as “update available” should be updated. Anything that has not been updated by its developer in over a year is at higher risk of containing an unpatched vulnerability — WordPress shows a warning to that effect on the plugin page when the gap becomes long enough.
Second, the active vs. inactive count. An inactive plugin is still installed on the server. It is still loaded into the file system. It can still be exploited if it contains a vulnerability, because attackers will probe the URL pattern of any known plugin regardless of whether it is active. Delete every inactive plugin that you do not have a specific reason to keep.
Third, look at the list itself with fresh eyes. Plugins accumulate. Most WordPress sites contain at least two or three plugins that nobody on the current team can remember installing, and which are not actually being used. Each one is an attack surface. Removing them costs you nothing.
Step 4: Look at the theme list
Themes work the same way. Go to Appearance → Themes. WordPress will usually have one active theme, and often several inactive themes sitting alongside it — the default Twenty Twenty-Whatever themes shipped by WordPress, plus any themes the site went through in earlier redesigns.
Like inactive plugins, inactive themes still exist on the server and can still be exploited. Keep one default WordPress theme installed as a fallback and delete the rest. Your active theme should be updated to its latest version.
Step 5: Verify your login page actually has protection
Try to log out and visit /wp-login.php on your own site. Two things to look for.
First, is there any form of brute-force protection in place? If you can submit the login form repeatedly with wrong passwords and nothing happens — no captcha, no lockout, no rate limit — then anyone on the internet can do the same thing automatically. WordPress does not provide this protection by default, so you need a security plugin (Wordfence, Solid Security, and Limit Login Attempts Reloaded are common ones) or a service like Cloudflare’s bot protection.
Second, is two-factor authentication enabled for administrator accounts? If a password gets leaked, two-factor authentication is the difference between an incident and a near-miss. Several free plugins add this.
Step 6: Check that you actually have a working backup
This is the security check that catches site owners off guard the most often. The first question is: is there a backup running at all? The second question, which more people fail: is it stored somewhere other than the same server as the site?
A backup on the same server is not a backup. If the server is compromised, the attacker has access to the backup files. If the host has a problem, the backup goes with the site. A real backup lives elsewhere — a separate storage service like Amazon S3, Google Cloud, Dropbox, or a dedicated backup service.
The third question is: when was the last backup actually verified to be restorable? An untested backup is a hopeful assumption.
Step 7: Look at the front page through fresh eyes
Open the public homepage of the site in an incognito browser window. Scroll all the way to the bottom. Look at the very bottom of the page, just above the closing footer. This is where SEO-injection attacks place their content — invisible or barely visible links to gambling, pharmacy, or counterfeit sites.
If you see anything you did not put there, the site has been compromised. The check sounds primitive, and it is, but it catches a very common attack pattern that many site owners miss because they only ever look at their site logged in, where the injection is suppressed.
While you are at it, check the page source — right-click, View Source — and look for unfamiliar links or scripts near the footer or in the header.
Step 8: Check the SSL certificate
Try visiting your site with “https://” in front of the address. Make sure the browser shows a padlock icon and no warning. A site without working SSL is bleeding trust with every visitor, and is also more vulnerable to certain kinds of attack in transit.
While you are looking, click the padlock and check when the certificate expires. Many SSL incidents on small sites happen because nobody noticed an expiration date approaching.
What to do with what you find
The five-minute check is meant to be findable. If you have run it on a site that has never been audited, you have probably found at least three things to fix. Treat them as a short list. Most of the fixes are quick — removing accounts, deleting unused plugins, updating versions, installing a security plugin, configuring backups properly.
A few of them may surface a problem big enough to need help. An unfamiliar administrator account, unexplained code in the footer, or a backup situation that has been broken for months are not five-minute fixes. But knowing they exist is the first step. The thing this check is designed to avoid is the situation where the problem is real, ongoing, and undiscovered.
The short version
Most WordPress compromises happen on sites where nobody is paying attention. A fifteen-minute self-audit — covering users, plugins, themes, login protection, backups, the public front page, and SSL — catches the overwhelming majority of common issues without any technical expertise. None of it requires installing new tools or touching code. It just requires the discipline to look. Run it once a quarter. Most of the time you will find nothing. Once in a while, you will be very glad you looked.
