Site Hardening · Part 7
The most powerful file you never read
On most shared hosting, a small file called .htaccess decides how the server treats every request that reaches your site. It can redirect addresses, refuse visitors, change what counts as a program, and send different visitors to different content. WordPress writes a few lines into it, and most owners never open it again.
That makes it the ideal place to hide something. A file that can change what your site does, which nobody reads, is the most valuable file on the server to an intruder.
What it was used for here
From the case file. The operation behind these articles ran its whole disguise from a .htaccess file. A few lines checked who was asking. Search engine crawlers were quietly routed to a page generator that produced the spam. Ordinary visitors were shown the normal site — or, for the spam addresses, a “page not found” message that still told the server everything was fine. The intruders’ own comment in the file described it: a 404 for humans.
The same file carried a list of the intruders’ own tools, exempted from every rule, so their programs kept working while everything else was rewritten. And during the fighting, .htaccess files across the account were changed again and again.
So the first rule of hardening this file is simple: know exactly what yours says, keep a known-good copy off the server, and compare. A difference you can’t explain is a finding, not a mystery.
Where the rules belong
Part 3 set out the division: WordPress controls the site, the edge controls the traffic. .htaccess sits between them, and it should carry only what has to happen on the server itself.
- Yes: WordPress’s own rewrite block. Refusing to run PHP in folders that should never hold it. Protecting the configuration file and other sensitive files from direct requests. Permanent responses for addresses that are gone for good.
- Better at the edge: blocking countries, bots and login attempts, which can be refused before they cost your server anything.
- Better in WordPress: ordinary redirects for pages that moved.
From the case file. After the top-level file was rewritten repeatedly, the owner stopped relying on it alone and pushed protective rules down into the folders of each site. An intruder who changes one file no longer changes everything.
The right response matters
When you take spam addresses away, what the server says about them decides how fast search engines let go.
From the case file. The owner’s first move when he found the spam addresses was a rule sending them all to the home page. It killed the spam instantly — and confused Google, because every one of thousands of spam addresses now answered as a working page. It was the right move for the first hour and the wrong one for the months after: addresses that answer as working pages don’t drop out of the index, and every one of them had to be turned around again later. The logs showed the requests kept coming. He changed the rule so those addresses answered 410 Gone: the page existed, it has been removed on purpose, and it isn’t coming back. That is the response that lets a search engine drop an address with confidence.
Then the rule broke. For a stretch it answered with a server error instead — which tells a search engine the problem is temporary and to keep the address. He didn’t notice at first, because the browser kept showing him working pages from a cache. What gave it away was his own redirect tracer — a small program that asks the server directly and shows the response code at every step. Where the browser showed a working page, the tracer showed the server answering with an error. That is why Part 6 ends where it does: after any change, check the live response, not the save and not a cached copy.
One more honest note. The rule that finally worked on his host doesn’t look like the textbook version, and every tool he has shown it to has tried to “correct” it. Hosts differ in how they process these files. A rule is right when the live server returns the right answer, not when it looks right on paper.
Where robots.txt and .htaccess collide
This is the mistake that turns a good cleanup into a permanent problem.
robots.txt tells search engines which addresses not to request. .htaccess decides what the server says when an address is requested. Use both on the same addresses and they cancel out: a blocked address is never requested, so the search engine never hears that it’s gone. It stays in the index exactly as it was, and there is no way for the 410 to reach it.
From the case file. That is what happened to a block of spam addresses on this site. They were refused properly by the server and blocked in robots.txt at the same time, and for months they sat frozen in Search Console under “Blocked by robots.txt.” The fix was to remove the block and let Google come and hear the answer. The owner left a comment in the file itself saying exactly why the block must never come back.
The wider lesson for hardening: robots.txt is not a security control. It is a public file, it is only a request, and anything you list in it is advertised to every reader. Protect sensitive files on the server. Use robots.txt only to guide crawlers you want. How that frozen block was finally cleared belongs to the next series, on recovering rankings and trust.
A short routine
- Open every .htaccess file on the account and read it. Every line should be explainable.
- Keep a dated copy of each known-good version on your own computer.
- Compare against those copies on a schedule and after any support work.
- After every change, request the affected addresses live and check the response code.
- Never block in robots.txt an address you are trying to make a search engine forget.
A single rule in the wrong place can hide a compromise for months or freeze it in search results. A recovery review reads every rule on the account and checks what the live server really answers.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: File Permissions That Actually Stop Writes
Next: Fewer Moving Parts: Running WordPress With Almost No Plugins
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.