The key takeaway: WordPress hardening isn't a single fix but a layered checklist spanning access control, software hygiene, server-level configuration, network protections, and ongoing monitoring — each layer closes a different category of risk, and skipping one leaves a gap the others don't cover.
Why a Checklist, Not a Single Fix
We covered the specific vulnerabilities that actually compromise WordPress sites — outdated plugins, weak credentials, SQL injection, XSS, XML-RPC abuse — in our guide to common WordPress vulnerabilities. Hardening is the proactive counterpart: a structured set of configuration choices that reduces the attack surface before any specific vulnerability is even in play, organized here by layer so nothing gets missed.
Access Control Hardening
- Enforce two-factor authentication for every account with publishing or admin access, not just the primary administrator.
- Apply least-privilege roles — give each user (and each client, if the site is agency-managed) the lowest WordPress role that lets them do their actual job, rather than defaulting everyone to Administrator.
- Remove unused accounts immediately when a team member or client relationship ends, rather than leaving a dormant account with standing access.
- Limit login attempts to slow down automated brute-force tools targeting wp-login.php.
- Rename or restrict the default "admin" username if it's still in use, since it's the first username automated attacks try.
Core, Plugin, and Theme Hygiene
- Enable automatic updates for WordPress core, plugins, and themes wherever the update carries low regression risk, and test the rest on a staging copy before pushing to production.
- Audit installed plugins quarterly, removing anything not actively used — an inactive plugin with a known vulnerability is still exploitable in some attack chains even when deactivated.
- Check a plugin's vulnerability history and maintenance activity before installing it, favoring actively maintained plugins with a clean disclosure record over abandoned ones.
Server and File-Level Hardening
- Set file permissions to 644 for files and 755 for directories, per WordPress's own hardening documentation, with wp-config.php locked down further since it holds database credentials directly.
- Disable file editing from wp-admin by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php, which removes the built-in theme/plugin editor that gives an attacker with admin access a direct path to executing code.
- Disable directory browsing on the server so a misconfigured folder doesn't expose a raw file listing to anyone who requests it directly.
- Change the default database table prefix (wp_) during installation or via a migration tool, removing one assumption some automated SQL injection attempts rely on.
- Disable XML-RPC unless a specific plugin (most commonly Jetpack) or mobile app actively requires it.
Network-Level Protections
- Enforce HTTPS sitewide, redirecting all HTTP traffic, since an unencrypted connection exposes login credentials and session cookies to anyone on the same network.
- Add a web application firewall (WAF), either through a CDN-level service or a security plugin, to block known attack patterns before they reach WordPress itself.
- Set security headers — Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security — which most CDNs and some security plugins can apply without touching WordPress's own code.
Monitoring, Logging, and Backups
- Enable file integrity monitoring so an unexpected change to a core file or an unfamiliar file appearing in wp-content triggers an alert rather than going unnoticed.
- Schedule regular malware scans, using a security plugin or an external scanning service, rather than only checking after something already looks wrong.
- Keep automated, offsite backups on a schedule that matches how frequently the site actually changes, and periodically test that a backup actually restores rather than assuming it works.
- Subscribe to a vulnerability disclosure feed like WPScan or Patchstack so a newly disclosed plugin vulnerability is known within hours, not discovered after exploitation.
Full Checklist at a Glance
| Category | Key Actions |
|---|---|
| Access control | 2FA, least-privilege roles, remove unused accounts, limit login attempts |
| Software hygiene | Auto-updates, quarterly plugin audit, check vulnerability history before installing |
| Server/file config | 644/755 permissions, disable file editing, disable directory browsing, change table prefix, disable XML-RPC |
| Network protection | Enforce HTTPS, add a WAF, set security headers |
| Monitoring & backups | File integrity monitoring, scheduled malware scans, tested offsite backups, vulnerability feed subscription |
The Compliance Angle: Hardening Isn't Just a Security Nice-to-Have
For agencies and businesses operating in the EU, hardening measures increasingly overlap with regulatory obligations rather than being purely optional best practice. The EU Cyber Resilience Act requires manufacturers of products with digital elements — which extends to commercial WordPress plugins and themes under specific conditions — to meet baseline cybersecurity requirements and handle vulnerability disclosure responsibly throughout a product's life, not just at launch.
The technical hardening steps above (updates, access control, vulnerability monitoring) directly support the security side of that obligation, though full compliance also requires separate documentation — a vulnerability disclosure policy, a software bill of materials, and conformity records — that hardening alone doesn't produce. This is the specific gap our Erdo CRA Compliance plugin is built to help track: scanning a site against CRA, GDPR, and NIS2 requirements and generating the documentation a hardening checklist doesn't cover on its own.
Common Hardening Mistakes
- Treating hardening as a one-time setup task rather than a recurring review, letting user accounts and plugin lists drift out of a secure state over months.
- Installing a security plugin and considering the checklist complete, when server-level file permissions and access control decisions still need to be handled independently.
- Hardening the live site directly for changes like disabling file editing or restricting permissions, without testing on staging first in case a plugin depends on the disabled functionality.
- Never testing that backups actually restore, discovering a corrupted or incomplete backup only during an actual incident.
- Applying every hardening step except updates, when outdated software remains the single most exploited entry point regardless of how hardened everything else is.
Wrapping Up
In short, WordPress hardening works as a layered checklist rather than a single action — access control, software hygiene, server configuration, network protection, and ongoing monitoring each close a different category of risk, and for EU-facing sites, several of these steps now double as groundwork for regulatory compliance rather than optional best practice. Reviewing the full list quarterly, rather than setting it up once and assuming it holds, is what keeps a hardened site actually hardened as time passes.