Invasion Investigation · Part 2
Still outside the building
Part 1 gave you an approximate number and a look at what the world can see. This gives you the exact figures, the date it started, and — the part most people never realise is available — copies of the pages themselves, stored by Google.
And it’s still perimeter work. You’re reading Google’s records about your site, not your site. Nothing is touched, nothing is modified, and nobody watching your server sees you do it.
There’s a reason to do this before anyone starts cleaning: Search Console holds evidence that never existed on your server at all. The damage a compromise does to your presence in search isn’t a file. Clean the server perfectly and you will still have no idea what happened here.
One prerequisite, and it’s the bad news first
You need a verified property. If Search Console was never set up for the domain, you can verify it today — but you’ll only get data from this point forward, and the historical record you actually need can’t be recovered.
If that’s your situation, skip to Part 3 and note it as a permanent gap in the case. Then set it up anyway, for every domain you own, before you finish reading.
From the case file. The compromise documented in this series ran across five domains in one hosting account. The site the intruders actually operated from — the one that hosted the machinery for five months — was a static brochure page nobody had looked at since 2022. A dormant site with no dashboard, no update prompts and nobody watching is the ideal place to work from, which is exactly why it was chosen.
Verifying a dormant site takes ten minutes and costs nothing. It is the cheapest insurance in this entire series.
What to look at, in order
1. Pages — and the two numbers that matter
Open Pages (formerly Index Coverage). You get two totals: indexed, and not indexed.
Most people read the second number as good news. It isn’t, and understanding why is the single most useful thing in this post.
From the case file. The final split was 900 indexed against 7,552 not indexed — 8,452 spam URLs in total.
“Not indexed” here mostly means discovered but never fetched. Google learned those URLs existed, from links, and never requested them.
That sounds harmless. It’s the harder half of the problem.
When you clean up, you’ll configure the spam URLs to return “gone.” That works — for URLs Google asks about. Google can’t receive an answer to a question it never asks. For thousands of URLs that were only ever discovered, there is no request for your server to respond to, so there’s nothing your fix can do. They sit in the record until Google decides on its own to check.
That asymmetry — not Google being slow or stubborn — is why index damage outlives the infection by months.
Export both lists. Filter for the URL pattern you identified in Part 1 and count each category separately. Those two numbers are your actual damage assessment.
2. The index chart — your intrusion date, timestamped by someone else
Above the table is a graph over time. On a compromised site it usually has a wall in it: a near- vertical rise where thousands of URLs appear at once.
That wall is dated, and the date came from a third party you don’t control and can’t have influenced. It’s often the single most reliable timestamp in the whole investigation.
From the case file. Two waves. 3–4 January, roughly 4,400 URLs discovered and 900 indexed. Then 7–8 January, about 3,100 more discovered and none indexed at all — Google had recognised the pattern in the interval and stopped ingesting.
Read which series the wall appears in. Here it was overwhelmingly in the not-indexed line, and that detail settled an argument: it ruled out a theory that the attacker had pushed URLs directly through Google’s indexing tools, because that method would have driven the indexed line instead. One chart, read carefully, eliminated a wrong conclusion.
3. Soft 404 — the cloak, detected for you
Under the not-indexed reasons, look for Soft 404.
Google reports this when a page displays a “not found” message while the server reports success. It’s a contradiction, and Google flags it automatically.
It’s also the exact signature of a page configured to show one thing to search engines and another to people. In Part 1 you may have clicked a spam URL and got “page not found.” This report is where you find out whether that was true or theatre.
You get this for free, with no server access, on a report Google generated without being asked. Our existing article on the website redirect hack explains the mechanism behind it.
4. Sitemaps — files you didn’t submit
Open Sitemaps. This lists what has been submitted for your site, and anything here you didn’t put there is not ambiguous. A sitemap is a direct instruction to crawl a list of URLs, and it’s one of the fastest ways to get thousands of pages discovered.
But an empty report is not an all-clear, and this is the part worth understanding.
From the case file. Nothing hostile ever appeared in this account’s Sitemaps report. The attacker’s sitemaps — twenty of them — were declared in a
robots.txtfile on the server instead, which gets them crawled without anyone submitting anything. That single file did more work than every link on the site combined, and Search Console’s submitted-sitemaps list stayed clean throughout.
So check the report, and then read your actual robots.txt — covered in Part 5. The two are different questions and only one of them shows up here.
5. Enhancements — what the pages claimed to be
If your site has never used structured data, this section should be empty. On a compromised site it frequently isn’t.
From the case file. Search Console had validated Product snippets, Merchant listings and Review snippets against markup nobody at the business had written. Every fabricated page carried star ratings between 4.3 and 4.9 and review counts ranging from 816 to over 9,000.
The structured data was well-formed, so it passed validation. Google was serving rich results — star ratings, prices, availability — for products that did not exist, from a business that had never sold them.
Check that these reports are clean now. Fabricated review markup validated against your domain is a trust problem that outlives the files by a long way.
6. URL Inspection — read the page Google was actually served
This is the tool almost nobody uses, and on a cloaked compromise it’s the only way to see the truth.
Paste one of the spam URLs into the inspection bar at the top. Then open View Crawled Page.
You are now looking at what Googlebot received — not what your browser gets. If the two differ, you’ve proven the cloak without touching your server.
From the case file. Twenty-two spam pages in this investigation survive only because they were retrieved this way. By the time anyone needed to examine the content, the URLs had been correctly configured to return “gone” and could no longer be fetched in a browser at all. The stored crawl was the last copy in existence, and each page had to be pulled out one at a time.
7. Users and permissions — the one that survives a rebuild
Settings → Users and permissions. Look at every account with access.
An intruder who verifies ownership of your property keeps reading your search data indefinitely. That access lives at Google, not on your server, so it survives a full wipe, a migration to new hosting, and every file you delete.
Almost nobody checks this. It takes fifteen seconds.
8. Security Issues
Google’s own verdict, and where a manual action would appear. If you’re in the middle of the emergency rather than the aftermath, our article on what happens after a Google malware warning covers the recovery sequence and why requesting a review too early makes things worse.
Export everything, today
Search Console data decays. Performance data rolls off at sixteen months, and the coverage reports are a live view rather than an archive — what they show today is not retrievable next year.
Export the Pages report, both categories. Export the performance data. Screenshot the index chart, the enhancement reports and the sitemaps list.
Do this before remediation, for the same reason as Part 1: your own fix can put the evidence out of reach.
The one thing not to do
You now have a list of spam URLs and an obvious-looking way to make them disappear: block them in robots.txt.
Don’t. Blocking a URL doesn’t remove it — it prevents Google from ever fetching it again, which means Google can never learn that it’s gone. Given what we covered about discovered-but-never-fetched URLs, this takes the harder half of your problem and makes it permanent.
Removal is Part 8. The instruction here is only: not this.
What this still can’t tell you
You now have exact numbers, a start date from an independent source, evidence of cloaking, and copies of the pages. That’s a great deal for work that touched nothing.
It still can’t tell you how they got in, what’s on your server now, or whether it’s over. Those answers live inside, and the next post is the last one that stays outside.
What you can do yourself, and what you can’t
All of this is yours to do, provided the property was verified. No server access is needed at any point, and the exports are the single most useful thing you can hand to whoever cleans up.
What isn’t yours is acting on it — configuring status codes, removing files, or fixing the mechanism that generated the pages. Nothing in Search Console changes your website.
If you take one action from this article, make it the ten minutes to verify every domain you own, including the ones you’d forgotten about. In this case the forgotten one was where they lived.
Back: How to See What Google Has Indexed on Your Site
Search Console keeps a record of the compromise long after the files are gone. Reading what it is still holding against you is part of getting the site back.
Start a Recovery ReviewPaid assessment · scope agreed up front
Next: How to Read Your Server Access Logs After a Hack → — the last step outside the building, why the response code matters more than the request, and the reason to download them today even if you won’t read them for a week.
Hub: Invasion Investigation Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.