Ranking Recovery · Part 4
A report full of red is not always bad
Open Search Console a few weeks after cleaning up a hacked site and the Pages report looks alarming. Thousands of addresses are listed as not indexed. Not found. Blocked. Server error. The natural reaction is to try to make every one of those numbers go down.
That reaction causes real harm, because after a hack some of those errors are precisely what you want. An injected spam page that now returns “not found” is an error in Search Console’s vocabulary and a success in yours. The skill is telling the good errors from the bad ones.
First, sort the addresses into yours and theirs
Every reason in the report covers a list of addresses. Before you read any number, open the list and ask one question: did I create these pages?
- Theirs — addresses the attackers created. For these, you want Google to conclude that they are gone.
- Yours — your real pages. For these, you want Google to index them.
The same status means opposite things depending on which list an address is in. “Not found” on a spam address is the goal. “Not found” on your services page is an emergency.
Google Search Console crawl errors that are good news
Not found (404) — on spam addresses. Google asked for the page and was told it does not exist. It will drop the address after rechecking a few times.
Gone (410) — on spam addresses. Search Console files these under the same “Not found (404)” heading; there is no separate row for 410. The server said the page was removed on purpose. This is the best answer you can give, and Google acts on it sooner than on a 404.
Crawled – currently not indexed, on spam addresses. Google fetched the page and chose not to keep it. Fine.
A rising count in these rows, made up of addresses you did not create, means the cleanup is being seen. Leave it alone. Do not press Validate Fix on them. There is nothing to fix, and the validation will simply fail and send you an email saying so.
The ones that are bad news
Server error (5xx). The server failed to answer properly. On your own pages, this stops them being indexed. On spam addresses it is worse than it looks, because a server error tells Google the problem is temporary and to keep the address and try again later.
From the case file. The rule that returned 410 for the spam addresses on this domain broke on 1 March and began returning a server error instead. For a stretch, every request for a spam address was answered with “something went wrong, come back later” — the opposite of “gone.” The owner did not notice at first, because his browser kept showing him working pages from a cache. A removal rule that fails this way does more damage than having no rule at all.
Soft 404. The page says “not found” to a human but the server reports success. Google does not trust it either way. After a hack this has two common sources: the attackers’ own cloaking, and an owner who redirected spam addresses to the homepage.
Blocked by robots.txt — on spam addresses. This looks like protection. It is a freeze. Google is forbidden to fetch the address, so it never sees that the page is gone, and the entry stays in its records indefinitely.
From the case file. This domain carried a robots.txt rule blocking the spam pattern for months. Several hundred addresses sat in the blocked row for the whole of that time, unable to clear. The rule was taken out in late August, with a comment left in the file explaining why it must never be put back. Where robots.txt and server rules collide is covered in the hardening series.
Page with redirect — on spam addresses. A redirect says the content moved. It did not move. It never should have existed.
Errors on your own pages
Now turn to the list that is yours. Any of these on a real page needs attention.
- Not found (404) on a page that should exist: the cleanup deleted or renamed something it should not have, or a rule is catching too much.
- Blocked by robots.txt: a rule written to stop the spam is also stopping your pages.
- Excluded by ‘noindex’ tag: attackers sometimes add this to your real pages. Security plugins and maintenance modes do too.
- Alternate page with proper canonical tag / Duplicate: your page is pointing at another address as the original. Check that the canonical address is one you chose.
- Crawled – currently not indexed on a real page: Google saw it and passed. This is usually about the page being thin, not about the hack.
How to check what the server really answers
Search Console shows what Google saw the last time it looked, which may be weeks ago. To know what is true now, ask the server directly.
Your browser is the wrong tool for this. It shows cached copies, follows redirects without telling you, and may be treated differently because you are logged in. Use something that reports the raw status code: Search Console’s own live test on the URL inspection page, or a header-checking tool that lists each hop and its code.
Check three kinds of address every time: one spam address (expect 410), one real page (expect 200), and one address that never existed (expect 404). If all three answer as expected, the rules are doing what you think.
The Validate Fix button
For errors on your own pages that you have repaired, Validate Fix asks Google to recheck that group. It is worth pressing once the repair is confirmed on the live server.
It is not instant. Validation can take two weeks or more, and it fails as a whole if even one address in the group still has the problem. Do not press it hopefully. Check the live answers first.
Reading the trend, not the total
The totals in this report will stay large for a long time. What tells you whether recovery is working is direction.
- Spam addresses moving out of “indexed” and into “not found”: good.
- The “not found” total itself slowly shrinking months later, as Google stops listing addresses it has given up on: good.
- Your real pages moving from not-indexed reasons into “indexed”: good.
- Anything growing under Server error, Soft 404 or Blocked: stop and find out why.
Take a dated screenshot of the report once a week. The movement is too slow to notice day by day and obvious when you lay two months of screenshots side by side.
One row that means nothing
Discovered – currently not indexed is the row that worries owners most and matters least for spam. It lists addresses Google knows about and has not fetched. For injected addresses, that is simply the queue. They will be requested eventually, answered with “gone,” and moved to Not found. A large number here after a spam hack is normal and needs no action.
If the report shows server errors or blocked addresses and you cannot tell which rule is responsible, a Recovery Review reads the live responses address by address and traces each one to the rule producing it.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Google Search Console Removals Tool: What It Does After a Hack, and What It Does Not
Next: Google Search Console Request Indexing: Getting Your Real Pages Back
Hub: Ranking Recovery Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.