WordPress security in 2026: the checklist we would apply if we had to
We do not build on WordPress, but many businesses run it. The twelve measures that matter most, in order, and the point where a rebuild is the cheaper fix.
The short answer
We do not build business websites on WordPress, and we have written about why. But a great many businesses run it, some of them our clients before they moved, and the practical question is what to do about the site you have today. The answer is a short checklist applied in order, because most WordPress compromises come through the same few doors: outdated plugins and themes, weak or reused admin passwords, and add-ons nobody remembers installing.
Work through the twelve measures below. If you get to the end and find the site is old, plugin-heavy and unowned, the honest conclusion may be that a rebuild costs less than keeping it safe.
The checklist, in order
- Update everything, now and on a schedule. Core, themes, plugins. Security updates within days; the rest weekly; backup first. Assign an owner.
- Put the plugins on a diet. Delete, not just deactivate, anything unused. Replace abandoned plugins, meaning no update in a year, with maintained alternatives or nothing. Fewer plugins is the single largest risk reduction available.
- Two-factor on every admin account. An authenticator app or a hardware key. This alone stops a stolen password from being enough.
- Strong, unique passwords everywhere. Admin accounts, hosting, database, the registrar. A password manager makes unique realistic.
- Least privilege. Nobody has administrator who does not need it. Remove old accounts: former staff, former agencies, the developer from three years ago.
- Backups that are tested. Automated, stored away from the server, with a restore actually performed once. An untested backup is a hope.
- A network layer in front. DNS and traffic through a service that filters attacks, applies rate limits and hides the server’s address.
- Harden the login. Rate-limit attempts, move or protect the login path, disable XML-RPC if nothing uses it, and never leave “admin” as a username.
- File permissions and ownership set correctly, so the web server cannot rewrite its own code.
- Disable file editing from the dashboard. One line in the configuration removes a favourite tool of attackers who get in.
- Security headers on every response: HSTS, a content security policy suited to the site, frame and content-type protections.
- Monitoring. Uptime, file changes, new admin users, outbound email volume. A compromise you notice in an hour is an incident; one you notice in six months is a disaster.
Where security plugins fit
A well-chosen security plugin adds visibility: login attempts, file changes, known vulnerable versions. Used that way it is useful. What it does not do is update your plugins, choose your passwords or remove the admin account of the agency you left. And it is itself code with its own history of vulnerabilities. Basics first, plugin for visibility second, configured deliberately rather than left on defaults.
When the checklist is not enough
If the site depends on abandoned plugins for core functions, if the theme is a custom build from years ago that no update survives, if every update round breaks something, and if nobody in the business owns maintenance, then the ongoing cost of keeping WordPress safe exceeds the cost of moving. A static rebuild removes the database, the plugin surface and the admin panel from the attack surface altogether, and maintenance becomes a fraction of what it was.
What this means for you
Open your WordPress dashboard and count: plugins, their last update dates, admin accounts, pending updates. That count tells you where you stand. Apply the twelve measures in order, assign an owner for the weekly routine, and add monitoring so a problem is noticed in an hour, not months. If the count is alarming and nobody can own the routine, put the money toward a platform that does not need it.
Frequently asked questions
Is WordPress insecure?
The core is maintained and patched quickly. The risk is the ecosystem around it: tens of thousands of plugins and themes of varying quality, installed and then forgotten. A WordPress site with few plugins, prompt updates and proper access control is reasonably safe. Keeping a site in that state is the hard part.
Which security plugin should we install?
Start with the basics in this checklist; a plugin does not fix missing updates or weak passwords. If you want one for visibility and login hardening, choose a widely used, actively maintained one, configure it deliberately, and remember it is one more piece of code to keep updated.
How often should a WordPress site be updated?
Security updates within days of release, everything else weekly, with a backup before each round and a check after. That cadence needs an owner. A site nobody updates for months is the typical starting point of a compromise.
Sources
- WordPress developer documentation: Hardening WordPress (accessed 2026-09-11)
- OWASP Top 10 (accessed 2026-09-11)