Site Hardening · Part 10
Hardening you haven’t checked is a guess
Nine articles of locks, rules and settings. Every one of them was tested against the live site when it was put in place. None of that tells you whether it is still working today.
Settings get reset by hosts. Rules break quietly. Caches hide failures. Someone finds a door you didn’t know about. The only thing that tells you how safe a site is right now is a record of what is actually happening to it — and that record is your server’s access log.
After the hardening, the log check is what verifies it.
Why the log, and not the dashboards
Search Console is invaluable, but it is slow. Its reports lag by days, sometimes weeks, and they show what Google has recorded, not what is happening now. A security plugin shows what it was built to look for. A hosting dashboard shows what the host chooses to summarise.
The access log is different. Every request to your site — every visitor, crawler, scanner and intruder — is written down with the time, the address, what was asked for and what your server answered. It is the closest thing you have to the ground truth.
From the case file. The owner now pulls the logs for every one of his sites every day. Not as a crisis measure — as the routine that tells him the hardening is holding.
Know your visitors by name
Most of the traffic to a small site isn’t people. It is crawlers, and the useful ones announce themselves. Google alone sends several, each with a job: the main smartphone crawler, a desktop crawler, an image crawler, and a separate inspection tool that appears whenever someone uses Search Console to test a page.
Knowing them by name turns a wall of text into a story. You can see when Google checks your sitemap, which pages it returns to, and whether it has picked up a change you made.
But names are easy to fake, and fakes are common. They give themselves away by behaviour. Real search crawlers ask for things that matter to search — pages, sitemaps, images, robots.txt. Impostors wearing the same name go looking for login pages, configuration files and the names of well-known hacking tools. When the doubt matters, check the address: a genuine Google crawler’s address traces back to Google, and a fake’s doesn’t.
What to check every day
A daily look doesn’t mean reading every line. It means asking a few questions the log can answer in minutes.
- Is the door holding? With the login locked at the edge, as Part 3 describes, login attempts should be refused before they ever reach the server. A successful login request from an address that isn’t yours is the most important line you can find.
- Is anything answering that shouldn’t exist? A request for a file you don’t have that comes back as a success means a rule you didn’t write is answering it.
- Who is sending data in? Requests that post data to unusual files — anything other than your forms and WordPress’s own handlers — deserve a look.
- Are the gone pages still gone? Addresses you removed should keep answering the way you set them to. A change is a broken rule.
- Is anything spiking? A sudden jump in errors or redirects is a symptom, even when every page looks fine in a browser.
From the case file. Two failures in this recovery showed up in exactly this way. A redirect loop created in the host’s own settings produced more than ten thousand redirects on the home page in one day, against a normal few hundred. And a rule meant to tell Google that spam pages were permanently gone broke and began answering with server errors instead — invisible in the browser, because the pages being checked came from a cache. The log shows both. The screen showed neither.
Read before you conclude
The log records everything, which means it records your own software too. The skill is not spotting something strange. It is finding out what the strange thing is before deciding.
From the case file. Three of the most alarming patterns in this investigation turned out to be innocent:
- More than two hundred unusual requests from eighteen addresses, looking exactly like a backdoor being used, were a security plugin’s own scanner — switched on forty-one seconds earlier in the same log.
- Hundreds of requests to oddly named temporary files were the hosting company’s single sign-on and installer, working exactly as designed.
- A steady stream of “page gone” responses that looked like Google dropping spam pages was almost entirely the site’s own scheduled-task system hitting a rule. Real crawler traffic was a small fraction of it.
Each one was more convincing than the truth. That is why the rule from the investigation series applies here too: label what you know against what you are guessing, and check the guess before you act on it.
Ask your site the way Google asks it
The log records what happened. Sometimes you need to ask a question yourself — and ask it the way a search engine would, not the way your browser does. Your browser keeps copies of pages, remembers redirects, and tells the server it is an ordinary visitor. Every one of those habits can hide the answer you are looking for.
Chrome has a tool built in that anyone can use, with nothing to install:
- Right-click the page and choose Inspect, then open the Network tab.
- Tick Disable cache and Preserve log, then reload the page. You now see what the server actually says, not a stored copy — and if the address redirects, every step stays on the list.
- Click the first row, the page itself. Status shows the real answer: 200 for a working page, 301 for a redirect, 410 for gone on purpose — or a 500 hiding behind a page that looks fine. Under Response headers,
locationshows where a redirect goes, andcf-cache-statusshows whether Cloudflare answered from its own copy (HIT) or asked your server (DYNAMIC or MISS). - To ask as Google: open the three-dot menu in that panel, choose More tools → Network conditions, untick the default user agent and pick Googlebot. Reload and compare.
If your site gives Googlebot a different answer from the one it gives you, that is what cloaking looks like. The compromise behind these articles sent crawlers one way, ordinary visitors another, and visitors arriving from a search result somewhere else again. The redirect hack described in the Emergency Authority series works the same way.
From the case file. The owner uses his own version of this: the ProVAE URL Redirect Tracer, a small in-house program that asks for an address as Googlebot, Bingbot or an ordinary browser, arriving with or without a search engine as the referrer, and lists every hop with its response code. It is how he caught the broken rule described in Part 7 — the server answering with an error while the browser still showed a working page.
Check the files as well as the traffic
The log tells you who came and what they asked for. It doesn’t tell you whether a file on the server changed. For that you need the baseline from Part 9: a record of every file taken while the site is known to be good.
Most guides say to record each file’s size and date. Those help, but both can be faked. From the case file. The intruders in this compromise backdated their own cleanup script to 2021 and backdated a server configuration file as well, so a list sorted by date would have shown them as old and harmless.
A hash can’t be backdated. It is a fingerprint calculated from a file’s contents; change one byte and the fingerprint changes completely. The owner keeps a small hashing program off the server. When he wants a baseline, he drops it into a folder, it records a hash for every file, and it comes straight back off — a program that maps every file on your site is exactly the kind of file Part 5 says must never be left behind.
Run it again later and compare the two lists. Every difference is a file that changed, and on a site where nothing changes without the owner’s knowledge, every difference is a question with an answer he should already know.
Or let a tool do the reading
A shameless plug, and an honest one. This investigation was cracked by reading logs by hand, line by line, for weeks. That work is now a program.
ProVAE Security grew directly out of this case. It reads a site’s access logs and produces two reports from one scan. The incident report shows every address, what it asked for and when — probes, spoofed crawlers, requests to files that shouldn’t answer. The SEO report shows what search engines actually did: which pages verified crawlers fetched, which they never touched, and how much of the traffic was real visitors rather than bots.
It checks that a crawler claiming to be Google really is Google before counting it. And it follows the rule this series has argued for all along: it shows what happened and leaves the judgement to you. No verdicts — just the record, organised.
If your logs are sitting unread, ask about a log review.
Keep the record
Hosts usually keep logs for somewhere between a week and a month, then delete them.
From the case file. The earliest log that survived in this investigation began seventeen months after the intrusion started. That single gap is why the entry point remains the best-supported explanation rather than a proven fact. The evidence that would have settled it had been deleted long before anyone knew to look.
So take the logs off the server as you go, and keep them. Daily copies on your own drive cost almost nothing. They turn tomorrow’s question — when did this start? — into something you can answer.
Where the series ends
The site is yours, the keys are accounted for, the doors are locked, and the log confirms it every day. That is what hardening is for: not a site that can never be attacked, but one where you would know within a day if it were.
What hardening can’t do is repair what the compromise already cost. The spam addresses still sitting in Google’s index, the trust the domain lost and the rankings that went with it live in someone else’s system, and no setting on your server reaches them.
But the same log that verifies the hardening is also where recovery shows up first. Every step you take to repair search damage has a date, and Google’s response to it — which pages it comes back for, which it drops, how often it returns — is written in the log long before Search Console catches up. That is what the SEO side of ProVAE Security is for: your actions on one side, Google’s behaviour on the other, on one timeline.
That timeline is the next series: recovering rankings and trust.
A log can confirm the locks are holding, or show that something slipped past them. A recovery review reads the logs with you and separates what is harmless from what isn’t.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Automatic Updates: Why We Turned Them Off, and What That Costs
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.