WordPress Security Checklist: 15 Checks for a Safer Website

October gave WordPress owners three reasons to check their sites: a backdoored Rank Math PRO update, stolen UpdraftCentral keys and WordPress 7.1.4.

The short version: update everything, lock every account that can touch the site, keep a backup you’ve restored, and know who to call when it goes wrong.

Where do the holes come from? Mostly plugins.

Patchstack logged about 11,300 new WordPress vulnerabilities in 2025, and more than 90% of them were in plugins rather than in WordPress or the themes you run on top of it.

Only 6 were in WordPress itself, all low priority, according to Patchstack’s State of WordPress Security in 2026.

Those are reported flaws rather than hacked sites, but they’re a good map of where you should look first, and the checks below follow it.

The 15 checks at a glance

Here are the checks in the order I’d do them. Most take minutes; a few need your host.

#	Check	Where you do it	About
1	Run the latest WordPress	Dashboard > Updates	5 min
2	Auto-update the plugins and themes you trust	Plugins, Appearance > Themes	10 min
3	Delete what you don’t use	Plugins, Appearance > Themes	15 min
4	Run a supported PHP version	Tools > Site Health, your host	10 min
5	Lock the accounts outside WordPress	Host, registrar, email	30 min
6	Audit your users and registration	Users, Settings > General	10 min
7	Unique passwords and two-factor for admins	Users > Profile, a 2FA plugin	20 min
8	Clear out old application passwords	Users > Profile	5 min
9	Throttle logins and decide on XML-RPC	Host, CDN or plugin	20 min
10	Put a firewall in front of the site	Host or CDN	15 min
11	HTTPS everywhere	Host, Settings > General	10 min
12	Turn off the file editor	wp-config.php, your host	10 min
13	Off-site backups and a tested restore	Backup tool, staging	1 hour
14	Watch for changed files and new admins	Scanner, WP-CLI, Users	15 min
15	Write a one-page hack plan	A note outside the site	20 min

Updates and software

1. Run the latest WordPress version

At the time of writing that’s 7.1.4, released October 28, 2026. Only the latest major release is officially supported.

Older branches get fixes “as a courtesy”, with no guarantee and no timeframe, says the supported versions page.

Minor releases install themselves by default. Don’t turn that off.

Check it: Dashboard > Updates should say you have the latest version of WordPress.

2. Auto-update the plugins and themes you trust

Since WordPress 5.5 you can switch on auto-updates plugin by plugin. They’re off until you do.

WordPress then checks twice a day and emails you after every automatic update, failed ones included.

Turn them on for well-maintained plugins. Has one broken your site before? Update that one by hand within a day or two of each release.

But auto-updates carry a risk too: the Rank Math backdoor arrived as an ordinary update.

I’d still leave them on, because an unpatched plugin is the more common problem, and checks 13 and 14 are there to catch the rare bad update before it does real damage.

Check it: look at the Automatic Updates column on the Plugins screen.

3. Delete what you don’t use

A deactivated plugin is still code on your server. If you don’t need it, delete it. Keep one default theme as a fallback and remove the other unused ones.

Then look hard at what’s left. Treat these as warning signs:

• no update in a year or more
• closed on WordPress.org
• no longer sold or supported by its developer

Replace those before a flaw turns up that nobody will fix. Patchstack found that almost half of 2025’s flaws had no fix from the developer when they were made public.

And never install “nulled” (pirated) premium plugins. Someone removed the licence check, and they could’ve added anything else while they were in there.

Check it: for each plugin, can you say what it does on your site and when it was last updated?

4. Run a supported PHP version

WordPress recommends PHP 8.3 or newer on its requirements page. PHP 8.2 stops getting security fixes at the end of 2026.

PHP is your host’s job. October’s PHP2Shell flaws could only be closed by updating PHP itself, so no plugin update would’ve helped.

Check it: Tools > Site Health > Info > Server shows your PHP version; ask your host to upgrade if it’s below 8.3.

Accounts and logins

5. Lock the accounts outside WordPress

Several logins can get around your WordPress password completely:

• the hosting control panel, where anyone can open your files and database
• SFTP or SSH, which edit files directly
• your domain registrar, which decides where your domain points
• the email inbox that receives WordPress password reset links

Whoever controls your reset email controls your site. Give each account a unique password and two-factor authentication, and remove people who no longer work on the site.

Check it: open each provider’s security page and confirm two-factor is on.

6. Audit your users and registration

Every administrator holds a key to the whole site. Most people who write for you only need Editor or Author.

Then open Settings > General. Unless you run a membership site, “Anyone can register” should be unticked. If it’s ticked, the New User Default Role should be Subscriber.

Check it: filter Users > All Users by Administrator and make sure you recognise every name.

If you use WP-CLI, wp user list --role=administrator gives you the same list.

7. Use unique passwords and two-factor for admins

Every privileged account needs a long, unique password from a password manager. Why unique? Credential stuffing turns a leak somewhere else into a working login on your site.

WordPress core doesn’t include two-factor authentication. You add it with a plugin or single sign-on, says the brute force guide.

It also suggests passkeys through a maintained plugin. Require one or the other for every administrator.

Check it: log out, log back in as each admin and confirm you’re asked for the second factor.

8. Clear out old application passwords

Application passwords let apps use the WordPress API as you. They’re easy to forget, and each one works until you revoke it.

Delete any you can’t put a name to. Give integrations their own account with the lowest role that works.

Check it: scroll to Application Passwords at the bottom of Users > Profile.

9. Throttle logins and decide on XML-RPC

Bots try passwords on wp-login.php and xmlrpc.php all day. It’s constant. WordPress.org’s advice is to limit login attempts at your CDN, firewall or web server.

A security plugin is the fallback. A challenge such as Cloudflare Turnstile on the login form slows bots down further.

XML-RPC is an old way for apps to talk to WordPress. Nothing uses it? Disable it.

Jetpack and some mobile apps still rely on it. If yours do, restrict it and rate-limit it instead of switching it off.

Check it: try a few wrong passwords in a private window and confirm you get slowed down or blocked.

10. Put a firewall in front of the site

A web application firewall (WAF) at your host or CDN stops attacks before they reach WordPress. A plugin firewall starts later, on the same server it protects.

Many managed WordPress hosts already include one in your plan, so it’s worth asking yours before you add a second firewall on top. You’ll often find it’s there.

Check it: your host’s or CDN’s dashboard should show the WAF switched on for your domain.

Server and configuration

11. Use HTTPS everywhere

Every page should load over HTTPS, and the HTTP version should redirect to it automatically.

Logins sent over plain HTTP can be read by anyone sitting between your visitor and your server, on the same café Wi-Fi for example.

Check it: type your address with http:// in a private window and confirm it ends up on https://.

Both addresses in Settings > General should start with https too.

12. Turn off the file editor

By default, administrators can edit theme and plugin code from the dashboard. One line in wp-config.php removes that editor for everyone:

define( 'DISALLOW_FILE_EDIT', true );

WordPress.org is honest about the limit. It “will not prevent an attacker from uploading malicious files to your site, but might stop some attacks,” says the hardening guide.

The same guide gives 755 for folders and 644 for files as a baseline. The right permissions depend on your host, so ask them first.

Check it: the Theme File Editor should be gone from the Appearance menu.

Backups and monitoring

13. Keep off-site backups and test a restore

Back up the files and the database. Keep copies outside your hosting account, with several days of history.

A backup on the same server can be lost or infected along with the site. Worse, you might only find out it’s broken on the day you need it.

So restore one. A backup you’ve never restored is a guess. Put it on a staging site and click around.

Check it: your backup tool should show a recent backup that includes the database and the uploads folder.

14. Watch for changed files and new admins

Most hacks show up as changes: a new file, an admin nobody created, a redirect. The Rank Math backdoor, for example, created admins named “wpsupport_” something.

Your host’s malware scan or a scanner plugin can watch for this. Developers can run these WP-CLI commands:

• wp core verify-checksums compares WordPress files with the official copies
• wp plugin verify-checksums --all does the same for plugins from WordPress.org
• wp plugin list --update=available shows plugins still waiting for an update

Premium plugins can’t be checked against WordPress.org, because it doesn’t have their files.

Check it: once a week, look at Users > All Users and your scanner’s latest report.

15. Write a one-page hack plan

When a site gets hacked, people lose hours looking for logins. Write these down somewhere outside the site:

• your host’s support contact and the fastest way to reach them
• where your backups are and how to restore one
• who can reset the hosting, registrar, email and WordPress logins
• who you’d call for a cleanup you can’t do yourself

Check it: hand the page to someone else and ask them to find each thing without your help.

What’s overrated

Some tips fill other checklists but do little on their own:

• Changing the login URL, which WordPress.org says “can reduce noise but should not be your only defense”: fewer bot hits in your logs, same risk.
• Changing the table prefix or hiding your WordPress version, a kind of security through obscurity the hardening guide calls “generally an unsound primary strategy”.
• A security plugin as the whole plan. Backups stay your job.

They’re fine extras. Do checks 1 to 15 first.

If you think your site is already hacked

WordPress.org’s FAQ for hacked sites starts by writing things down. In short:

1. Note what you see, when you noticed it and anything you changed recently.
2. Contact your host. On shared hosting, other sites may be hit too.
3. Scan the site, and scan your own computer, since stolen logins often start there.
4. Take a snapshot of the site as it is, even infected, before changing anything.
5. Reset every login: WordPress users, SFTP, the hosting panel and the database. New security keys in wp-config.php log everyone out.
6. Clean up or restore a backup from before the hack. Then update everything and change the passwords again.

Can’t tell whether it’s clean? Pay for a professional cleanup. A half-cleaned site usually gets reinfected.

Why it matters

Every plugin you install is a supplier you trust with your whole site. October showed that even big names can become the way in, through no fault of yours.

Nobody can make a site unhackable. What you can do is close doors, lock the ones that stay open and keep a way back.

Got one hour today? Do checks 1, 3, 5 and 13.

Updates, fewer plugins, locked accounts and a backup you’ve restored will save you from more trouble than everything else on this list combined, and none of them costs anything but time.

Common Questions

Does WordPress have built-in two-factor authentication?

No. You add two-factor authentication or passkeys with a well-maintained plugin, or through your host or a single sign-on provider, and require it for every administrator.

Do I need a security plugin?

Not always. If your host already gives you a firewall, malware scanning and login limits, a plugin may only duplicate them. Without those, it’s a reasonable way to add scanning and login protection.

Should I disable XML-RPC?

Disable it if nothing on your site uses it. Jetpack and some mobile apps still need it, so if you rely on them, restrict and rate-limit it through your host or firewall instead.