Site Hardening
The fire is out. Now close the doors.
You know how they got in. You know how long they were there and what your site was doing for them. The cleanup is done.
The next question is the one every owner asks: how do I make sure this never happens again?
Most answers to that question are a checklist. Update your plugins. Use strong passwords. Install a security plugin. All correct, and all aimed at the most common doors. This series is aimed at the doors that were actually used — and at the ones nobody checks because they aren’t on the server at all.
Outside in
The investigation series approached the scene from the perimeter inward. Hardening works the same way, because whoever controls an outer layer can undo everything you do on an inner one.
Parts 1 and 2 are about ownership. The domain, the accounts, the email addresses and the logins that sit above your server and outrank it.
Part 3 is the edge. The layer your traffic passes through before it ever reaches your host.
Parts 4 to 9 are the server. The hosting account, the files, the permissions, the configuration, and the software you choose to run.
Part 10 is proof. Hardening you can’t verify is hardening you’re only assuming.
The principle
WordPress controls the site. The edge controls the traffic.
Every decision in this series follows from keeping those two jobs separate. Your site decides what its pages are, where they live and where old addresses redirect. The edge decides who gets to knock, how often, and what gets served from cache. When one layer starts doing the other’s job, you end up with rules in two places that disagree — and nobody notices until something breaks.
And one more, which the investigation taught the hard way:
Verify against the live site, never the save button.
A locked-down server can report that a change saved when nothing changed at all. A cache can show you last week’s file while the real one is broken. The only proof that a setting works is what the live site actually returns.
The ten parts
1. Hardening Starts With What You Own, Not What You Install The chain that outranks your server: registrar, DNS, recovery email. Why a free email address is the weakest link, why contact records drift, and why DNS verification beats a file on the server.
2. Who Else Still Has the Keys? Every login that can reach your site, audited after the fact: hosting users, FTP accounts, database access, Search Console users and service accounts, API keys — and the DNS provider login that quietly controls all of them.
3. Let the Edge Hold the Door What a service like Cloudflare should and shouldn’t do. Locking the WordPress login to your own address before a request ever reaches the server, stopping bad bots at the edge, and making sure your robots.txt isn’t served stale from cache after you change it.
4. One Hosting Account, One Target Why a forgotten site in the same account is the easiest way into all of them, and when the right answer is to shut a site down instead of protecting it.
5. Files That Should Never Live on a Web Server Backups, project files, exports and old builds. The category of file that opened the door in the case behind these articles — and how to find what your own software has been leaving behind.
6. File Permissions That Actually Stop Writes Setting them deep enough to matter, and how to check. Including the trap on the other side: a server hardened so well that your own edits silently fail.
7. Locking Down .htaccess Without Breaking Your Site Where the rules belong, why they get rewritten during a compromise, and where robots.txt and .htaccess collide — a blocked address that Google can never see is being refused.
8. Fewer Moving Parts Running WordPress with almost no plugins. Every plugin is someone else’s code with write access to your site; what to replace with a few lines you control, and what to keep.
9. Automatic Updates: Why We Turned Them Off, and What That Costs The trade between an update you didn’t review and a patch you forgot to apply, and how to hold both risks down.
10. Hardening You Can Verify Reading your logs every day. Real search crawlers against impostors, what a probe looks like, and how you know the locks are still holding.
Where this sits
| Stage | Question |
|---|---|
| Emergency Authority | It’s happening now — stop it |
| Invasion Investigation | The fire is out — understand it |
| Site Hardening (you are here) | Stop it happening again |
| Recovering rankings and trust | Get back what it cost |
The investigation series ends with what would have stopped that one intrusion. This series is the full practice behind it.
About the evidence in this series
The examples come from the same compromise documented in the investigation series: five domains in one hosting account, seventeen months. Where a measure is described here, it comes from the author’s own sites — tested against the live site, not taken from a checklist.
Where something turned out to have an innocent explanation, it says so. Not every strange thing during a compromise is part of it, and hardening built on a wrong conclusion protects the wrong door.
A hardened site can still be carrying the old compromise. A recovery review checks what is still reachable, and by whom, before you lock anything down.
Start a Recovery ReviewPaid assessment · scope agreed up front