How Do I Harden WordPress Against Hackers?

This is the next step after the fundamentals. If you've already done strong passwords, two-factor on your admin login, automatic updates, and a daily backup — covered in our WordPress security basics guide — good. That stops opportunistic attacks. Hardening is about the layers that stop the determined ones: the bots probing for a weak file permission, an exposed config, or an interface you forgot was even turned on. The good news is that none of it requires you to become a developer. The harder news is that a lot of it lives at the server level, where a cheap shared host usually leaves you on your own.

What "hardening" actually means

Basic security is about locking the front door. Hardening is about assuming someone will eventually rattle the handle anyway, and making sure that even then there's nothing easy for them to grab. Security people call this defense in depth: instead of relying on one wall, you stack several, so a single mistake — one weak password, one outdated plugin — doesn't hand an attacker the whole site. WordPress.org's own hardening guide and the widely cited OWASP Top Ten both frame it the same way: reduce what's exposed, and assume each layer can fail.

The advanced measures (and why each one matters)

1. A web application firewall (WAF)

What it is: a filter that sits in front of your site and inspects incoming traffic, blocking known attack patterns — SQL injection, brute-force login floods, malicious bots — before they ever reach WordPress. Why it matters: a plugin can only react once an attack has already arrived at your site; a WAF stops a lot of it at the door. This is why a firewall is a foundational control in the OWASP Top Ten. A WAF can run at your host, at the edge (a service like Cloudflare), or as part of a security plugin — the highest-value version runs before WordPress even loads.

2. Correct file permissions and a hardened wp-config.php

What it is: file permissions are the rules for who's allowed to read or change each file. The safe defaults are 644 for files and 755 for folders, with wp-config.php locked down even tighter. Why it matters: loose permissions let a single compromised plugin rewrite your core files. Inside wp-config.php — the file holding your database password and site secrets — you also want to regenerate the secret keys (the "salts" that protect login sessions), add define('DISALLOW_FILE_EDIT', true); to turn off the dashboard's built-in code editor (so a stolen admin login can't paste malware straight into your theme), and make sure debug output is hidden from the public so error messages don't leak your file paths.

3. Disable or limit XML-RPC and lock down the REST API

What it is: XML-RPC and the REST API are two doorways WordPress opens for other apps to talk to your site. Why it matters: XML-RPC is an older interface that attackers abuse for brute-force and amplification attacks; most small sites never use it, so disabling it removes a whole attack surface. The REST API is more useful and shouldn't be killed outright, but it should be restricted so anonymous visitors can't enumerate your usernames (a favorite first step before a password-guessing run) or pull data you didn't mean to expose.

4. Security headers (HSTS, CSP, X-Frame-Options)

What it is: short instructions your server attaches to every page that tell the browser how to behave. HSTS forces HTTPS so no one can downgrade visitors to an insecure connection; Content-Security-Policy (CSP) limits which scripts are allowed to run, blocking injected malicious code; X-Frame-Options stops other sites from embedding yours in a hidden frame to trick your users (clickjacking). Why it matters: these close entire classes of attack and are invisible to visitors. You can grade your site's headers for free with Mozilla Observatory, which gives you a letter grade and tells you exactly which headers are missing.

5. Least-privilege user roles and enforced 2FA

What it is: giving every account the lowest role that still lets it do its job — an editor doesn't need Administrator, a guest author doesn't need editor — and requiring two-factor authentication on every account that can. Why it matters: the more Administrators you have, the more keys to the whole building are floating around. Most hacked sites we see have stale admin accounts nobody remembers creating. Trim them, demote everyone who doesn't strictly need full access, and enforce 2FA so a stolen password alone isn't enough to get in.

6. Activity logging and real-time malware monitoring

What it is: a running record of who logged in and what changed, paired with a scanner that watches your files for malicious changes as they happen. Why it matters: the difference between catching a break-in in minutes and discovering it weeks later (after Google has already blocklisted you) is whether anything was watching. Tools like MalCare and Wordfence are common examples of this kind of monitoring — not endorsements, just the category — and Wordfence's published threat reports are a useful read for what's actually being targeted. The key word is active: a scanner that only runs when you remember to click it isn't monitoring.

7. A staging environment and tested off-site backups

What it is: a private copy of your site (staging) where you test updates before they touch the live site, plus backups stored somewhere other than the same server. Why it matters: staging means a bad plugin update breaks the copy, not your business. And a backup only counts if you've actually restored from it once — plenty of owners discover their "backups" were empty or corrupt the day they finally need them. Off-site matters because if your server is compromised, backups sitting on that same server are compromised too.

8. Server and host-level protections

What it is: the defenses that live below WordPress entirely — fail2ban (which automatically blocks an IP address after too many failed logins), account isolation (so a hacked neighbor on shared hosting can't reach your files), and a current, supported version of PHP. Why it matters: no plugin can set these — they're properties of the machine your site runs on. An out-of-date PHP version alone can carry unpatched holes no amount of WordPress hardening will close. This is the layer where cheap shared hosting most often falls short, because these protections cost the host money and effort to provide.

How to check where you stand

You don't have to audit all of this by hand. Paste your address into our free scanner — it checks your HTTPS, security headers, and other surface signals in plain English, so you can see at a glance which of these layers are already in place and which are wide open. No signup.

How to harden WordPress, step by step

Or just hand it to a managed host

Here's the honest part: most of this list is server-level, and doing it well means living in config files, headers, and PHP versions you'll rarely touch again. That's exactly what a managed WordPress host does for you — the firewall, the hardened permissions, the security headers, fail2ban, account isolation, current PHP, and active monitoring all come as part of the service. A cheap shared host won't; it'll keep the lights on and leave the rest to you. We fix and host WordPress sites so this layered hardening is handled by default — and the first fix is free.