WordPress runs a large share of the web, which is exactly why it is probed around the clock by automated bots looking for a stale plugin or a weak password. The good news is that the attacks are overwhelmingly opportunistic — they move on the moment your site stops being the easy target. This is the WordPress security checklist I actually work through when I harden a site, in the order I do it, so a small business can close the doors that matter in an afternoon rather than waiting for the breach that forces the issue.
Why WordPress sites get attacked
It is rarely personal. The vast majority of WordPress compromises come from bots scanning for known vulnerabilities in outdated plugins, brute-forcing the login page, or exploiting a site running a “nulled” (pirated) theme with a backdoor baked in. Core WordPress is well maintained; the risk almost always lives in the ecosystem around it and in the login page. Understanding that shapes the whole approach — you are not trying to stop a determined human adversary, you are trying to be enough of a nuisance that automated tooling gives up and moves to the next target.
The WordPress security checklist
These are the controls I check on every hardening review. None of them require a developer, and together they eliminate the overwhelming majority of real-world attacks.
- Update everything, on a schedule — core, themes, and plugins. An unpatched plugin is the single most common way in; enable auto-updates for anything you cannot review weekly.
- Delete what you do not use — deactivated plugins and themes still ship exploitable code. If it is not active, remove it entirely rather than leaving it dormant.
- Enforce strong logins and MFA — long unique passwords plus two-factor authentication on every administrator account. This one control defeats almost all brute-force attempts.
- Limit login attempts — lock out or throttle repeated failed logins so bots cannot grind through password lists against your site all night.
- Apply least privilege — most people who “need admin” actually need Editor or Author. Every extra administrator is an extra full set of keys to lose.
- Disable the built-in file editor — set
DISALLOW_FILE_EDITso a stolen admin session cannot rewrite your theme’s PHP straight from the dashboard. - Put a firewall in front — a web application firewall (via a security plugin or your CDN) blocks known attack patterns before they reach WordPress at all.
- Force HTTPS and add security headers — TLS everywhere, plus headers like HSTS and a content-security-policy to shut down whole classes of injection and hijacking.
- Keep tested, off-site backups — automated backups stored somewhere other than the server itself, and restored at least once so you know they actually work.
Lock down the login page first
If you only do one thing this week, do this. The login page is where the constant, boring, automated pressure lands, and it is the cheapest thing to defend. Turn on two-factor authentication for every admin, rename the default admin username to something non-obvious, and throttle failed attempts. Moving the login URL away from /wp-admin and /wp-login.php will not stop a targeted attacker, but it quietly removes your site from the field of view of the mass scanners that only look at the default paths — which is most of them. These are small changes with an outsized effect on the attack traffic you actually see in your logs.
A step-by-step hardening workflow
When I harden a live site, I follow this order deliberately — back up before you change anything, and verify at the end rather than assuming.
- Take a full backup — files and database, stored off the server, before you touch a single setting.
- Update core, themes, and plugins — get everything current, then remove anything inactive.
- Secure the logins — enable MFA, enforce strong passwords, limit attempts, and audit who really needs admin.
- Add the firewall and headers — turn on a WAF and set your security headers and HTTPS enforcement.
- Harden the configuration — disable file editing, tighten file permissions, and confirm backups are running automatically.
- Verify it — run a malware and vulnerability scan, and check the site still works for real users. A control you have not confirmed is a guess.
Hardening an existing site is only half the picture — the other half is not introducing weaknesses in the first place. If you are building or rebuilding, my guide to secure web development covers baking these protections in from the start, and website security and SEO explains why the two reinforce each other rather than competing for budget.
Common mistakes to avoid
- Running nulled plugins or themes — pirated premium code frequently ships with a hidden backdoor. You are not saving a licence fee, you are pre-installing the breach.
- Storing backups on the same server — if the server is compromised or fails, so are the backups sitting next to the site. Keep a copy somewhere else.
- Treating it as set-and-forget — a site hardened last year and never updated since is not hardened today. New plugin vulnerabilities appear constantly.
- Hoarding admin accounts — old developer and agency logins that were never removed are a favourite way in. Review the user list and revoke what is stale.
Keeping it hardened
Security on WordPress is a habit, not a one-off — a monthly update-and-review rhythm keeps you off the easy-target list far more reliably than any single plugin. If you would rather hand that off, or want someone to run this WordPress security checklist against your site and confirm the backups actually restore, take a look at my services or get in touch — I would rather help you close the gaps now than clean up after a compromise later. If you are hiring for the maintenance instead, my notes on hiring a freelance web developer will help you pick someone who takes this seriously.