Search “how to harden WordPress” and you will drown in advice: rename your database prefix, move wp-config.php, hide the login URL, add twelve headers, edit a dozen files. Some of it helps. A lot of it is busywork that feels productive but barely moves your actual risk — and a few bits can quietly break your site. This guide cuts the list down to the changes that measurably shrink your attack surface or stop real attacks, in the order they matter.
The guiding principle: harden where attacks actually land. The overwhelming majority of WordPress compromises are automated and opportunistic — bots probing known plugin vulnerabilities, hammering the login, and scanning for files you left exposed. You do not need to defend against a targeted nation-state. You need to be a harder, quieter target than the millions of sites next to you.
1. Shrink the attack surface
Every plugin, theme, and default feature you run is code an attacker can target. The single biggest cause of hacked WordPress sites is a known vulnerability in an out-of-date plugin — so the highest-value hardening you can do is also the most boring:
- Update everything, promptly. Core, plugins, themes. Most exploited vulnerabilities already had a patch out when the site was breached.
- Delete what you don’t use. Deactivated plugins and unused themes still sit on disk and can still be exploited. Remove them, don’t just switch them off.
- Install from sources you trust. Nulled or pirated plugins are the classic delivery vehicle for backdoors.
Then close the default behaviours WordPress ships with that most sites never use — the file editor, XML-RPC, user enumeration, the exposed version number, pingbacks. Each one hands attackers either a way in or free reconnaissance. We walk through all five, and why they matter, in one-click hardening: the settings every site should lock down.
2. Lock down the login
Your login page is the most-attacked URL on the site. Bots guess thousands of username-and-password combinations against it around the clock. Three changes neutralise almost all of that noise:
- Turn on two-factor authentication for every account that can reach the dashboard. A stolen password is worthless without the second factor, and 2FA defeats credential-stuffing outright — the single most effective login control you can enable.
- Rate-limit login attempts. Stop the same source trying password after password. This is what turns a brute-force run from a threat into background noise.
- Use real admin hygiene. No account named
admin, unique strong passwords, and the smallest number of administrators you can get away with.
Hiding the login URL is fine as a noise-reducer, but treat it as a convenience, not a control — it is security through obscurity and does nothing once the real URL is discovered. The 2FA and rate-limiting above are what actually protect the account.
3. Fix your file and server posture
A handful of server-side settings close off the ways attackers escalate a foothold into full control:
- Correct file permissions: directories
755, files644, andwp-config.phplocked down to640or tighter. Never777anything. - Disable PHP execution in uploads. Your
/wp-content/uploads/folder should hold media, never run code. Blocking PHP there stops a huge class of “upload a shell” attacks dead. - Add the security headers that pull their weight: HSTS,
X-Content-Type-Options,X-Frame-Options(or a frame-ancestors policy), and a Referrer-Policy. Skip the elaborate Content-Security-Policy unless you are prepared to maintain it — a broken CSP causes more support tickets than it prevents breaches. - Serve everything over HTTPS and redirect HTTP. In 2026 this is table stakes, not hardening.
4. Assume something will still get through
Hardening reduces the odds of a breach; it never makes them zero. A brand-new vulnerability in a plugin you trusted can undo a perfect checklist overnight. So the last layer is detection: you want to know the moment a file changes that shouldn’t.
An integrity scanner does this by comparing your core, plugin, and theme files against known-good versions — the official WordPress.org checksums plus a baseline of your own files — and flagging anything added, altered, or injected. That is how you catch a backdoor or a redirect injection in hours instead of discovering it when Google blacklists you. It is also far harder to fool than a signature scanner, which can only match malware it already recognises.
The gap a checklist can’t close
Here is the uncomfortable part. Everything above — every toggle, every permission, every security plugin — runs inside WordPress. By the time that code executes, PHP has already booted WordPress and started handing the incoming request to your plugins. If one of those plugins has a vulnerability, the malicious request often reaches the vulnerable code before any of your in-dashboard protections get a look at it. You hardened the house, but the attacker was already through the door when the alarm armed.
Closing that gap takes a different kind of layer: a firewall that inspects every incoming request before WordPress loads your other plugins, and blocks the malicious ones at the door — including attacks aimed at a plugin flaw that has not been patched yet. That is the one piece a hardening checklist structurally cannot provide, because a checklist is made of things that run too late.
To be clear about scope: an application firewall defends the application layer — the HTTP requests hitting your site. It is not a substitute for a secure host, and it will not help with stolen FTP or SSH credentials or a compromised database password. Those stay on your hardening list. But for the attacks that actually hit WordPress sites — the automated probes against plugin vulnerabilities, injection attempts, and login abuse — inspecting the request before your plugins run is the layer that catches what hardening leaves open.
The short version
If you do nothing else, do these, in order: update everything and delete what you don’t use; turn on 2FA and rate-limit the login; fix file permissions and block PHP in uploads; run integrity scanning so you know when something changes; and put a request-inspecting firewall in front of it all so the attacks that beat your checklist get stopped before they reach your plugins.
DefendMyWP does all five in one place — one-click hardening, built-in two-factor authentication, an integrity scanner that checks against official WordPress.org hashes, and an application firewall that inspects every request before your other plugins load. The checklist, automated, with the layer the checklist can’t give you.
