Site Hardening · Part 3
The layer in front of your server
For most small sites, every visitor goes straight to the hosting server. Every bot, every scanner, every login attempt lands on the same machine that serves your pages, and your server has to deal with all of it.
A service like Cloudflare changes that. Your domain points at it instead, and it passes requests on to your host. That puts a layer in front of the server — the edge — where requests can be answered, slowed or refused before your site ever sees them.
Used well, it is the cheapest door you can put on a website. Used carelessly, it becomes one more place where rules live that nobody remembers writing.
One rule that decides everything else
WordPress controls the site. Cloudflare controls the traffic.
WordPress decides what your pages are, where they live, and where an old address redirects. Cloudflare decides who gets to knock, how often, and what can be served from its cache. No redirects at the edge. No blocking inside WordPress that the edge could do earlier.
The reason is practical. When the same job is done in two places, the two places eventually disagree, and the one you forgot about wins.
From the case file. During the recovery, a redirect loop appeared that no file on the site could explain. The rule turned out to live in the hosting company’s domain settings — a third place, outside both WordPress and the site’s own configuration. The server logs show it: more than ten thousand redirects on the home page in a single day, against a normal few hundred. The owner could edit the rule but not delete it, and stopped the loop by changing it. Every rule you let live somewhere unexpected is a rule you will one day be hunting for.
Lock the login at the edge
This is the single most useful edge rule for a WordPress site: the login page and the dashboard answer only to your own internet address. Everyone else is refused by Cloudflare before the request reaches your server.
It does what a hidden login address only pretends to do. Moving the login page hides it; this refuses it. Automated password guessing stops completely, because it never arrives. Your server stops spending effort on it, and your logs stop filling up with it.
Why at the edge and not in the server’s own configuration file? Because the edge is outside anything an intruder with file access can reach. In this case the intruders had write access to the server for seventeen months, and the site configuration files were rewritten repeatedly. They never had the Cloudflare account. A rule stored there can’t be quietly edited by someone inside your hosting.
From the case file. The owner tested his rule the way it should be tested: from outside. He connected through a VPN, so the request came from an address that wasn’t his, and the login page refused him. When his home address changes, he updates the one rule. That is the whole maintenance cost.
And he goes one step further. He doesn’t use the WordPress login page at all — he reaches the dashboard through his hosting company’s account. So the page the edge is guarding is one nobody legitimately uses. Anything that reaches it is, by definition, someone who shouldn’t.
Stop bots before they cost you anything
Your robots.txt file is a request. It tells well-behaved crawlers where you’d prefer they didn’t go, and it is ignored by everything that isn’t well-behaved. It is not a lock, and Part 7 covers what goes wrong when people treat it like one.
The edge is where refusal actually happens. Cloudflare can challenge or block traffic by country, by known bad networks, by behaviour, or by the name a crawler gives itself — and verify that a crawler claiming to be Google really is Google. Impostors are common, and they give themselves away by what they ask for: real search crawlers request pages, sitemaps and images; fakes wearing the same name go looking for login pages and hacking tools.
Start with the defaults, turn on bot protection, and add rules one at a time, testing each from outside. An edge rule you haven’t tested is an assumption.
Don’t let the cache lie to Google
Caching is half of what the edge is for — a copy of a file served from nearby is faster than a fresh one from your server. It is also the easiest way to serve an old version of something that matters.
From the case file. When the owner measured his own domains, the robots.txt file on three of them was being served from Cloudflare’s cache with a four-hour lifetime. Change the file on the server, and for up to four hours Google could still be handed the old one. During a cleanup — when robots.txt decides which of your addresses Google may even check — four hours of the wrong instructions is a real cost.
He wrote a single rule telling Cloudflare never to cache robots.txt, tested it on one site first, and confirmed the file then came fresh from the server every time. The sitemaps turned out to need nothing: WordPress builds them on request, so Cloudflare was already fetching them fresh.
The general lesson is the one this series keeps coming back to: check what the live site actually returns. A cached file looks identical to a current one until you look at the headers.
What the edge can’t do
Be honest about the limit. Cloudflare sits in front of your website — the pages people and crawlers request. It does not sit in front of file transfer, your hosting control panel, your database, or your email.
The intrusion in this case never touched the website’s front door. It used a file-transfer login. No edge rule anywhere would have stopped it, which is why auditing the keys comes before this part, and why the hosting account comes after it.
The edge is a strong door on one entrance. It is not a wall around the building.
An edge rule protects the door it stands in front of and nothing else. Finding which door was actually used is what tells you whether the edge is enough.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Who Else Still Has the Keys? Auditing Every Login to Your Website
Next: One Hosting Account, One Target: The Dormant Site Problem
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.