There’s a classic time for a site to go down: three in the morning. Not because the attacker chose to be cruel, but because the attack is automated — a bot sweeping the internet around the clock, finding a vulnerable plugin version and exploiting it. Teams with a security on-call notice and react. Teams without one, an ordinary small business, wake up to a defaced site, a checkout that’s down, or Google flagging the domain as dangerous.
This isn’t another “20 WordPress security tips” list where tip number 1 carries the same weight as number 20. It’s a checklist ordered by real risk — what actually prevents the three-a.m. incident, in the order you should do it, for people without an on-call team. If you only have time for the first three items, do the first three. They cover most of the risk.
Essential WordPress security is the minimum set of controls — vulnerability patching, login protection and guaranteed recovery — that stops a known flaw from becoming an incident while no one is watching.
Why order matters more than quantity
The mistake in generic lists is treating everything as equally urgent. Changing the database table prefix and installing 2FA sit side by side, as if they protected against the same thing. They don’t. One shuts the door bots actually break down; the other is marginal hygiene.
Security is risk management, and risk is probability times impact. What we should attack first is what has both high probability and high impact — and in the WordPress world, that’s no mystery. Ecosystem security research in 2025 is consistent: the overwhelming majority of successful compromises came from vulnerable plugins and themes, not WordPress core, according to Patchstack’s State of WordPress Security whitepaper. That’s why the order of this checklist isn’t arbitrary.
Priority 1: vulnerability patching (plugins and themes)
If you do only one thing, do this. The most-exploited attack surface of a WordPress site is the sum of its outdated plugins and themes — each one third-party code that may carry a publicly disclosed flaw.
The problem with CVE disclosure is that it’s a double-edged sword: the moment a vulnerability goes public, bots get a specific target and start sweeping the internet for sites that haven’t applied the fix yet. The WordPress ecosystem gets new vulnerabilities disclosed week after week, and the window between disclosure and mass automated exploitation is short.
What to do, in order:
- Reduce the surface. Every installed plugin is a risk. A plugin you don’t use — deactivate it and remove it; a deactivated plugin still has code on the server.
- Prefer what’s maintained. A plugin with no update in a year is debt waiting to come due. Before installing, check the date of the last release.
- Apply security patches fast, with staging. Speed can’t break the site. Update in a test environment, confirm the checkout and forms survived, and only then promote to production.
- Monitor disclosures. You don’t need to read a bulletin every day if a maintenance service does it for you — but someone needs to be watching.
This work is tedious, repetitive and never “finished” — and that’s exactly why it’s the part most missing from an abandoned site. It’s the core of ongoing WordPress maintenance: not a one-off service, but the habit that stops debt from turning into a crisis. Installing plugins with no criteria, by the way, is a version of the problem I describe in vibe coding: don’t ship the weekend project — third-party code nobody reviewed going straight into production.
Priority 2: hardened login and 2FA
After patching, the most-tried door is the obvious one: the login screen. The brute-force attack — a bot testing thousands of username-and-password combinations — is cheap, tireless and, in 2025, grew sharply with automated botnets. It needs no vulnerability; it needs only a weak password and time.
Hardening the login is fast and pays off enormously:
- Two-factor authentication (2FA). It’s the most valuable piece. Even if the password leaks, the bot doesn’t have the code on your phone. Minutes of setup that break most credential attacks.
- No
adminusername. It’s every bot’s first guess. Use usernames that aren’t guessable. - Strong, unique passwords with a manager. Reusing a password hands over several accounts at once when one leaks.
- Rate limiting. Blocking an IP after N failures turns brute force into wasted time for the attacker.
- Least privilege on roles. Not everyone needs to be an administrator. Editors edit, authors publish, admins administer. A compromised account with a minimal role does minimal damage.
This priority connects to the broader principle of secure architecture for sensitive data: give each person only the access they need.
Priority 3: WAF and edge hardening
Only after patching and login comes the application firewall (WAF). The order is deliberate: a WAF is a great layer, but it mitigates the risk — it doesn’t replace applying the fix. A site with a WAF and a vulnerable plugin is still a vulnerable site.
A WAF blocks known attack patterns (injection, attempts to exploit common flaws) before they reach your WordPress. There are two levels:
- Security plugin firewall: runs inside WordPress. It already raises the bar considerably and, for many SMBs, is enough as a first layer.
- Edge WAF (CDN/proxy level): blocks the attack before it touches PHP. It’s the next layer, warranted when the site is critical to revenue.
The reference catalog of web application risks is the OWASP Top 10 — worth knowing the categories, because a WAF is precisely a defense against them. Complement it with basic hardening: enforce HTTPS, disable file editing from the dashboard (DISALLOW_FILE_EDIT), block PHP execution in the uploads folder, and keep PHP on a supported version. Putting a site live without these layers is a classic case of the risks of shipping apps to production unprepared.
Priority 4: backup with a tested restore
Backup doesn’t prevent the breach. It determines whether the breach is a disaster or an inconvenience. That’s why it’s a security priority, even as the last line of defense — when everything else fails, it’s the backup that gives you the site back.
There’s only one rule, and almost everyone ignores it: a backup you’ve never restored is an assumption, not a guarantee. Plenty of people discover the backup was corrupt or incomplete exactly on the day they needed it. The honest backup checklist:
- Automatic and frequent, with enough retention to roll back to a point before the compromise.
- Off the server. A backup on the same server that went down goes down with it. Store it elsewhere.
- Restore tested periodically. Restore into a test environment and confirm the site comes up functional. Without that test, you have a file, not a plan.
The checklist, ordered by risk
Here’s the summary to pin to the wall — in the order that protects most per unit of effort:
| # | Control | Against what | Effort |
|---|---|---|---|
| 1 | Patch plugins/themes + reduce surface | Attack vector #1 | Recurring |
| 2 | 2FA + hardened login | Brute force and leaked credentials | Low, one-time |
| 3 | WAF (plugin, then edge) | Known automated attacks | Medium |
| 4 | Backup with tested restore | The worst case | Low, recurring |
| 5 | HTTPS + hardening (versions, permissions) | Residual surface | Low |
| 6 | Least privilege on users | Compromised account | Low |
Notice that the cheapest and most valuable items are at the top. SMB security almost never fails for lack of the exotic defense — it fails because of the plugin nobody updated and the login with no second factor.
What’s not worth your time (right now)
Just as important as what to do is what not to prioritize, so you don’t spend your limited energy in the wrong place:
- Renaming the login URL (
/wp-adminto something else): it’s “security through obscurity.” It bothers a dumb bot, not a good one. Do it after items 1 to 4, not before. - Changing the database table prefix: marginal benefit on a new site, risk of breakage on an existing one.
- Stacking five security plugins: they conflict, add weight and give a false sense of protection. One good one, well configured, is worth more.
None of these is useless — but putting them ahead of patching and 2FA is rearranging the deck chairs while the front door is unlocked.
Who does this while you’re asleep?
The three-a.m. incident has that name for a reason: it gives no warning and keeps no business hours. The checklist above drastically reduces the odds of it happening — but someone has to execute and, above all, maintain it. Patching isn’t a one-off event; it’s a weekly habit. A backup is only worth it if the restore was tested. A WAF needs someone watching the alerts.
For an SMB with no security team, the honest question isn’t “do I know how to do this?” — it’s “will this become nobody’s job?” WordPress security is the kind of important work that’s almost never urgent, until the day it becomes urgent and expensive. If it makes more sense to outsource that discipline to people who monitor disclosures and patch with staging, that’s exactly what we offer in WordPress maintenance. The goal is simple: that the three-a.m. incident never happens — and, if something does, that a tested backup is waiting.
Frequently asked questions
What is the number one risk for a WordPress site?
Outdated plugins and themes with a known vulnerability. 2025 security research shows the vast majority of successful WordPress compromises came from extensible components — plugins and themes — not the core. That’s why patching comes before anything else on the checklist.
Does 2FA on login really make a difference?
It does, and it’s one of the best cost-benefit trade-offs there is. Brute-force attacks on WordPress grew sharply in 2025, driven by automated bots. A second factor breaks the attack even when the password leaks, because the bot doesn’t have the code on your phone. It’s a few minutes of setup that shuts the most-tried door.
Does a security plugin replace a WAF?
Partially. Popular security plugins include an application firewall, but they run inside WordPress, after the request has already arrived. An edge WAF blocks the attack before it touches PHP. For most SMBs, the plugin firewall already raises the bar a lot; an edge WAF in front is the next layer when the site is business-critical.
Does backup count as security?
It counts as your insurance against the worst case. It doesn’t prevent the breach, but it’s what turns a disaster into an inconvenience. There’s only one rule: a backup you’ve never restored is an assumption, not a guarantee. Test the restore periodically, or you only find out it failed on the day you need it most.
How often should I update WordPress?
Critical security patches as fast as possible — ideally with staging so you don’t break the site. Routine updates on a weekly or biweekly cycle. The WordPress ecosystem discloses vulnerabilities every week, and the window between the disclosure of a flaw and mass automated exploitation tends to be short.
I’m a small business — am I really a target?
Yes, and probably more than you think. Most WordPress attacks aren’t targeted — they’re bots sweeping the entire internet for any site running a known vulnerable version. To the bot, your size doesn’t matter; whether you patched does. Being small doesn’t hide you, it just leaves you with no on-call when the incident arrives.