Why hardening pays off (the uncomfortable numbers)
WordPress runs a huge share of the web, which makes it a constant target — but most breaches exploit basics, not clever zero-days. Patchstack’s State of WordPress Security in 2025 found 96% of newly disclosed vulnerabilities were in plugins, and Sucuri’s Hacked Website Report found 39% of compromised CMS sites were running outdated software when they were infected. Translation: keep your software current and your logins tight and you have already closed the most-used doors — which is why a focused plugin audit is one of the first things we do.
Hardening follows the official WordPress hardening guidance, which groups the work into access, software, and recovery. None of it is exotic — it is discipline, applied consistently.
Access hardening
Most preventable incidents begin with access — a guessed password, a shared login, or an old agency account nobody removed. Lock the front door first.
- Require strong, unique passwords and two-factor authentication for every admin.
- Remove old users, former agency accounts, and shared logins.
- Apply least privilege — give each person only the role they actually need, not admin “to be safe.”
- Protect the login page from brute-force attempts with rate limiting or a login firewall.
- Avoid the obvious “admin” username and change defaults attackers script against.
Software hardening
Outdated software creates known, publicly documented openings — and attackers scan for them automatically. Keep the stack current, but do it safely so an update never takes the site down.
- Keep WordPress core, themes, and plugins updated — this is the single highest-impact habit.
- Remove abandoned or unused plugins and themes entirely, don’t just deactivate them.
- Test risky updates on staging before they touch the live site.
- Watch for host-driven PHP and database version changes that can break or expose the site.
- Use a current, supported PHP version, since old PHP is itself a security liability.
File and server hardening
Beyond logins and updates, a few server-level habits remove easy footholds attackers rely on.
- Set correct file and folder permissions so files cannot be edited by the wrong process.
- Protect or relocate wp-config.php and disable file editing in the dashboard where appropriate.
- Serve the whole site over HTTPS with a valid SSL certificate.
- Remove leftover database tools, debug logs, and backup files from public folders.
Recovery hardening
Perfect prevention does not exist, so a genuinely hardened site also has a clean way back. That means frequent off-site backups you have actually tested, malware cleanup that fixes the root cause rather than just deleting symptoms, and one clear answer to “who fixes this at 1am?” A backup you have never restored is a hope, not a plan — and the “who fixes this” answer is exactly what an ongoing WordPress care plan exists to be.
Threat → hardening move
The most common ways business WordPress sites get hit, and the single move that closes each one.
| Common threat | What it exploits | Hardening move |
|---|---|---|
| Brute-force login | Weak or reused admin passwords. | Strong passwords + 2FA + login rate limiting. |
| Plugin vulnerability | An outdated or abandoned plugin. | Keep plugins current; remove unmaintained ones. |
| Stale admin account | An old user nobody removed. | Regular access reviews; least privilege. |
| Malware reinfection | Cleanup that ignored the root cause. | Patch the entry point, then restore from clean backup. |
| Outdated core/PHP | Known, published vulnerabilities. | Safe, tested updates on a schedule. |
Hardening mistakes that leave the door open
- Installing a security plugin and assuming the job is done — it monitors, it does not maintain.
- Leaving former staff or agency accounts active long after they are needed.
- Delaying updates out of fear of breakage, instead of testing them on staging.
- Keeping backups on the same server as the site, where an attacker can reach both.
- Cleaning malware off the files but never finding and patching how it got in.
How we keep a site hardened over time
In our experience managing sites, hardening is not a project you finish; it is a posture you maintain. The work that actually prevents incidents is unglamorous and repetitive — reviewing who has access, keeping software current, confirming backups restore, and watching for the early signs of trouble. That is precisely the work that gets dropped when a business is busy, which is why most breaches we see trace back to a lapsed routine, not a sophisticated attack. Pair this checklist with our WordPress maintenance checklist for the full operating rhythm.
- Review admin users and roles on a schedule, not just when someone leaves.
- Apply tested updates promptly rather than letting them pile up.
- Keep off-site backups and periodically prove a restore actually works.
- Monitor for malware and unusual admin activity so problems surface before customers see them.
Frequently asked questions.
What is the first WordPress security step?
Lock down admin access: strong unique passwords, two-factor authentication, no shared users, and removal of stale accounts. Most preventable incidents start with a login someone could guess or that should have been deleted.
Do security plugins replace maintenance?
No. Security plugins help monitor and block threats, but they do not apply updates, test them, keep backups, or review who has access. Those still need a person. A plugin is a smoke alarm, not a fire brigade.
How often should I update WordPress for security?
Promptly, on a regular cadence, with risky updates tested on staging first. Sucuri found 39% of hacked CMS sites were running outdated software when they were breached, so letting updates pile up is one of the biggest avoidable risks.
Is WordPress itself insecure?
WordPress core is not the main risk — Patchstack’s 2025 data attributes under 1% of new vulnerabilities to core, versus 96% to plugins. The security of your site mostly comes down to how you manage plugins, access, and updates.
Research sources.
This guide was checked against current platform and search documentation before publication.