Guru Site HealthSecurity
A WordPress security checklist you can actually finish.
Most security checklists are written by people selling firewalls, and they are long enough that you give up in the middle. This one is ordered by return on effort, and the top half costs you about ten minutes in total.
A note on what this is not. It is not a replacement for backups, and it is not a promise. Almost every WordPress site that gets compromised is compromised through one of three doors: an out-of-date plugin, a weak or reused password, or an account that had more power than it needed. Nearly everything below is aimed at those three.
The ones that matter most
1. Turn on automatic updates for plugins and themes
The single highest-value item on this list, by a distance. The great majority of compromised WordPress sites are running a plugin with a publicly documented vulnerability and an available fix. The exploit is usually automated and indiscriminate — nobody chose your site.
WordPress has supported per-plugin automatic updates since 5.5. Go to Plugins, and in the Automatic Updates column click Enable auto-updates. Do the same under Appearance → Themes.
“Auto-updates break sites.” They occasionally do. But since WordPress 5.6, a failed plugin update is rolled back automatically — core keeps a copy of the previous version and restores it if the update fails. Weigh an occasional rollback against the far more common alternative: a site running a six-month-old vulnerability because updating was somebody’s job and nobody did it.
2. Turn on automatic updates for WordPress core
By default WordPress installs minor releases automatically — the 6.4.1 to
6.4.2 kind, which are mostly security fixes. Major releases usually wait for you. Under
Dashboard → Updates you can switch major releases on too.
3. Audit who has an account, and what they can do
Go to Users and read the list properly. You are looking for three things:
- Administrators who should not be. A person who writes posts needs Author or Editor, not Administrator.
- Accounts belonging to people who left. The developer from two years ago, the agency you stopped using.
- Accounts you do not recognise at all. If you find one of these, treat the site as compromised and change every password.
An Administrator account can install plugins. Installing a plugin is the same as running arbitrary code on your server. That is the whole reason this check is near the top.
4. Check what new registrations become
In Settings → General, if Anyone can register is ticked, look hard at New User Default Role. It should say Subscriber. If a site with open registration has its default role set to Editor, Author, or — it happens — Administrator, then anyone on the internet can create an account that can publish, or install code.
If you do not need public registration, untick the box. If you do need it, make sure the default role is Subscriber.
5. Use unique passwords, and a password manager
Nothing on this page is worth as much as not reusing passwords. WordPress generates strong ones for you when you create a user; the problem is never the generator, it is that people replace the generated password with one they can remember. Use a password manager and let the passwords be unmemorable.
Worth doing, costs a minute each
6. Disable the built-in file editor
WordPress ships with a plugin and theme editor at Tools → Theme File Editor. It lets anyone with admin access edit live PHP from the browser. For an attacker who has got in, it is the fastest route from “logged in” to “running my code”. For you, it is a way to white-screen your site with a typo and no undo.
The usual advice is to add define('DISALLOW_FILE_EDIT', true); to wp-config.php.
That works. It also means editing the one file that, if you get it wrong, takes the whole site down —
which is why Guru Site Health defines the constant from inside the plugin instead, and can switch it back off
again without you touching a file.
7. Stop broadcasting your WordPress version
WordPress adds a <meta name="generator" content="WordPress 6.4.2"> tag to every page,
and appends ?ver= to script and style URLs. This does not make you vulnerable. It makes you
findable — an automated scanner looking for sites running a version with a known flaw can
read it off your home page without trying anything.
Removing it is security through obscurity, and obscurity is not security. But it costs nothing and it takes you out of the cheapest kind of target list. Checking your WordPress version covers how to see what you are currently exposing.
8. Turn off XML-RPC if you are not using it
xmlrpc.php is an older remote-access interface. It is still used by the Jetpack mobile app,
some publishing clients, and a few plugins. If none of those apply to you, it is an open door with no
traffic through it — and historically a popular one for brute-force attempts, because
system.multicall allowed many password guesses in a single request.
Check first whether anything you use needs it. Then disable it.
9. Use HTTPS everywhere, and mean it
Both your WordPress Address and Site Address in Settings → General should start with
https://. Most hosts issue a free certificate now. If yours does not, change host.
10. Limit login attempts
Core does not rate-limit the login form. A plugin that locks out an IP after a handful of failures turns an unlimited guessing game into a finite one. Many hosts now do this at the server level — check before you add a plugin for it.
Worth doing once, then forgetting
11. Keep real backups, somewhere else
A backup stored on the same server as the site is not a backup; it is a second copy of the same accident. You want backups off the machine, taken on a schedule, and — the part everybody skips — restored once, deliberately, to prove they work. An untested backup is a belief, not a plan.
12. Remove plugins and themes you are not using
A deactivated plugin is still code on your server, and in some circumstances still reachable. A deleted plugin is not. Delete what you do not use, including the default themes you will never activate — keeping exactly one spare theme is sensible, keeping four is not.
13. Turn off debug output on a live site
WP_DEBUG_DISPLAY should be off in production. PHP errors printed into the page can disclose
file paths, database structure and more. Log them to a file instead if you need them.
14. Know your file permissions
The conventional answer is 644 for files and 755 for directories, with
wp-config.php tightened to 640 or 600. If anything on your site is
777, fix it today. Most managed hosts handle this for you; most cheap shared hosts do not.
What this checklist deliberately leaves out
Three pieces of common advice are missing on purpose:
- Changing your database table prefix. Widely repeated, almost worthless against a real attack, and a genuine risk of breaking the site during the change.
- Hiding the login page. It reduces automated noise in your logs. It does not stop anyone who has decided to target you, and it will eventually lock out a legitimate user.
- Installing three security plugins. They overlap, they fight, and each one is more code with more surface area. One, or your host’s own protection, is enough.
None of these are harmful exactly. They are just a way of feeling busy while items 1 to 5 go unfinished.
Frequently asked questions
What is the single most important WordPress security step?
Keeping plugins updated. The overwhelming majority of compromised WordPress sites are running a plugin with a publicly known vulnerability for which a fix already exists. Turning on automatic plugin updates removes that whole category, and takes about thirty seconds.
Do I need a security plugin?
Not necessarily, and definitely not three. Core WordPress plus current plugins, strong unique passwords, sensible user roles and real off-site backups covers most of the actual risk. A security plugin adds login rate-limiting and malware scanning, which are useful — but they are an addition to that foundation, not a substitute for it.
Are automatic updates safe to turn on?
For the large majority of sites, yes, and safer than the alternative. Since WordPress 5.6 a failed plugin update is rolled back automatically: core keeps the previous version and restores it if the update fails. If you run heavily customised or business-critical code, use a staging site and test there first.
Should I disable XML-RPC?
If nothing you use needs it, yes. The Jetpack mobile app, some desktop publishing clients and a few plugins rely on it. Check those first. If none apply, it is an interface with no legitimate traffic that has historically been used for brute-force attempts.
Does hiding my WordPress version actually help?
Slightly. It is obscurity, not security — it does not patch anything. What it does is take you out of the cheapest target lists, where automated scanners read the version off your home page and only bother with sites running something known to be vulnerable. It costs nothing, so it is worth doing, but it is not a substitute for updating.
Is changing the wp_ database prefix worth it?
No. It is one of the most repeated pieces of WordPress security advice and one of the least useful. It offers almost no protection against a real attack, and changing it on a live site carries a genuine risk of breaking things. Spend the time on updates and user roles instead.
Find these on your own site in about ten seconds
Guru Site Health runs 32 checks across updates, security, database, media, accessibility and SEO, and gives you one score. Thirteen of the findings can be fixed from the dashboard in one click, and every fix can be undone. It makes no external requests — nothing about your site ever leaves it.