A WordPress security checklist should cover logins, updates, plugins, backups, the PHP version, security headers, staging sites and forms. In my experience the biggest risks are weak logins, outdated or abandoned plugins and missing backups, so fix those first before buying another security product. This is the checklist I run on client sites, with the projects each item came from.
Security headers have their own guide: how to add HTTP security headers to WordPress. This post covers everything around them.
Where do WordPress sites usually get attacked?
Most attacks are automated. Bots scan the web for login pages, known plugin vulnerabilities and forms they can abuse. They are not looking for you in particular. They are looking for anyone who left a door open, which is why the basics matter more than anything clever.
How do you protect WordPress logins?
- Two-factor login for every admin. On Sun Shoppers, a grocery marketplace with vendor accounts, I set up Wordfence with two-factor login.
- As few admin accounts as possible. Give editors the Editor role and shop staff the Shop Manager role. Remove accounts for people who have left.
- Strong, unique passwords stored in a password manager, never shared in a chat.
- Limit login attempts, which most security plugins do.
- Phone OTP where it helps. On IPL Biologicals customers and admins log in with an SMS code instead of a password.
How do you keep plugins and themes safe?
- Remove what you do not use. I removed a leftover WooCommerce install from the Raasa launch page because it added weight and attack surface for no benefit.
- Avoid abandoned plugins. If a plugin has not been updated in a long time, look for a maintained alternative.
- Customise in a child theme. Sun Shoppers is built as a child theme, so theme updates can be applied without wiping customisations. A site that cannot be updated soon becomes a site that is not updated.
- Pin versions on high-stakes sites. On the Janssen Neuroscience build, WordPress core, the theme and every plugin were installed through Composer with pinned versions, so updates were a reviewed change rather than a click in the admin.
- Turn off the file editor in the admin, so a stolen login cannot edit theme or plugin code:
// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );
What should the full checklist include?
| Area | Check | Example |
|---|---|---|
| Logins | Two-factor for admins, few admin accounts | Wordfence two-factor on Sun Shoppers |
| Updates | Core, theme and plugins kept current, backup first | Monthly cycle on retained sites |
| Plugins | Unused plugins removed, abandoned ones replaced | WooCommerce removed from Raasa |
| Backups | Off-site, with a tested restore | UpdraftPlus to Google Drive on Sun Shoppers |
| PHP | A supported version | PHP 8.0 to 8.3 on Samko Holdings and Crowne Plaza |
| Headers | HSTS, CSP, X-Frame-Options and the rest | My HTTP Security Header plugin |
| Activity log | Who changed what, and when | WP Activity Log on Samko Holdings |
| SSL | HTTPS everywhere, certificate auto-renewing | Part of every build |
| Staging | Hidden from search, ideally password-protected | Staging de-indexed on Wow Vastra |
| Forms | Spam protection on every route into your inbox | Junk-lead source removed on Easy Parenting Hub |
Why do backups and PHP versions count as security?
Because recovery is part of security. If the worst happens, a clean backup from before the problem is what gets you back online. Store backups off the server, so a hosting failure or a compromised account does not take them too, and test a restore at least once.
PHP matters for the same reason updates do. Old PHP versions stop receiving security fixes. On Samko Holdings and Crowne Plaza London Kingston, moving from PHP 8.0 to 8.3 also fixed a form bug caused by the host's cache layer, and it kept both sites on a supported version.
Scan before you fix
Run your site through my free HTTP Security Header Scanner first. It grades the site from A+ to F and shows which headers are missing, so you fix what is actually wrong.
The scanner is described in the HTTP Security Header Scanner case study.
How do you run this checklist on an existing site?
- 1
Take a full backup
Files and database, stored off the server, before touching anything.
- 2
Audit users
Remove old accounts, downgrade roles, switch on two-factor for admins.
- 3
Audit plugins
Delete unused ones, replace abandoned ones, then update the rest.
- 4
Check PHP and SSL
Move to a supported PHP version on staging first, and confirm HTTPS everywhere.
- 5
Add headers
Scan, switch on the safe headers and add Content-Security-Policy last, with testing.
- 6
Check forms and staging
Add spam protection, then hide staging from search.
- 7
Schedule the next check
Security is a monthly habit, not a one-off job.
Who should look after this?
If nobody on your team owns it, it will not happen. This checklist is the security half of a maintenance retainer, which I describe in what a WordPress maintenance retainer covers. I run it on client sites through my hosting migrations, DNS and maintenance retainers service. Send me your site and I will reply with what I would fix first.
