Invasion Investigation · Part 1
Start outside the building
You know your site was hacked. The files may already be gone, the passwords already changed. What you don’t know yet is how far it went, and the temptation now is to start digging through your server.
Don’t. Not first.
There’s a check that takes ten seconds, needs no login, no hosting access and no technical skill, and it can be run by someone whose site is still offline. It changes nothing, touches nothing, and tells nobody you’re looking.
Type this into Google:
site:yourdomain.comThat’s it. Replace yourdomain.com with your actual domain, no spaces after the colon.
Why this is the right first move
Investigators approach a scene from the perimeter and work inward, and there are three good reasons for it that apply exactly here.
You can’t contaminate anything. You’re querying Google’s copy of your site, not your site. Nothing on your server is opened, modified or accessed. Every other step in this series costs you something; this one costs nothing.
You don’t announce yourself. If the intruder still has a foothold, they may be watching. Poking at files, installing a scanner or logging into the dashboard tells them you know — and the usual response is to destroy evidence and come back later through a door you haven’t found yet. A Google search is invisible to them.
You find out how big this is before you commit. Nine junk pages and eight thousand junk pages are different problems with different budgets. You want that number before you decide how carefully to move.
From the case file. This is not a theoretical recommendation. The seventeen-month compromise documented throughout this series was discovered by exactly this search — not by a security plugin, not by the hosting company, not by a malware scanner. All three had been running the whole time. It was found in January 2026 by running
site:on a domain and not recognising the results.
How to read the number
The first thing Google shows is an approximate result count. Compare it to the number of pages you believe you have.
Be generous with your own estimate — count posts, pages, categories, tags, attachments and archive pages. A small business site with thirty pages of content routinely and legitimately shows two or three hundred results.
Then look at the gap.
The count is far higher than it should be
This is the classic signature of injected content. Thirty pages of real content and four thousand results means something has been publishing under your domain name.
From the case file. The compromise in this series produced 8,452 spam URLs, discovered across two waves in January. Roughly 4,400 in the first, another 3,100 in the second. The site
The count is far lower than it should be — or you barely appear at all
Just as serious, and a completely different problem. This points at deindexing, an accidental noindex, a robots.txt blocking your own site, or a manual action. Same search, opposite diagnosis, opposite fix.
The count looks about right
Good, and not conclusive. Read the actual results anyway — the count can be normal while the content is not.
How to read the results themselves
The number is the headline. The listings are where the diagnosis is.
Titles in a language you don’t publish in
Your domain’s reputation is being borrowed to rank content in a search market you have nothing to do with. An established domain with years of clean history gets new pages indexed far faster than a throwaway one — which is the entire reason yours was chosen.
URLs with a query string you never created
Look at the address under each result. Something like ?o= or ?n= followed by random characters, on a site that has no reason to use query parameters, is generated content rather than pages anybody wrote.
Note the pattern. You will need it later, and it’s the thing your host or your developer will ask for first.
Results that show “not found” when you click them
The trap. Most owners click one, get a “page not found,” conclude it’s already been cleaned, and stop.
It usually hasn’t been. Pages can be configured to show one thing to search engines and another to people — you’ll see the real page, and Google will see something else entirely. Our existing article on the website redirect hack covers how that selective serving works.
For now: don’t trust what your browser shows you. The next post in this series is about the tool that shows you what Google was actually served.
The right pages, with descriptions that aren’t yours
The URL is genuine, the title and snippet are not. That’s injected content inside real pages rather than new pages added alongside them, and it’s a different cleanup.
Your homepage isn’t first — or isn’t there
Your own homepage should be the top result for a site: search on your own domain. If it’s buried or missing, something is wrong at a level beyond spam pages.
Subdomains and staging sites you’d forgotten
A site: search covers everything under the domain. Old staging installs, development copies and subdomains nobody has looked at in three years will surface here.
Look closely at those. A site nobody maintains, nobody updates and nobody visits is the most attractive place on your hosting account to hide something.
Then check the neighbours
If you host more than one website in the same account — a second business, a church site, an old project, a favour for a relative — run this search on every one of them.
From the case file. The account documented in this series held five domains. The compromise did not stay on the one that was noticed. And the site the intruders actually lived in for five months was not the one that raised the alarm — it was a static brochure site from 2022 that nobody had looked at since, with no dashboard to warn anyone and no owner paying attention.
Sites in the same hosting account share a filesystem. Treating them as separate is a mistake the person who compromised you did not make.
Four more things you can see from outside
The site: search touches nothing at all. These four do reach your own server — they are ordinary page requests, logged like any other visit — so they sit one step further in than everything above. They are still low-risk, they still need no login and no hosting access, and each one answers a question the search results can’t. Run them, and screenshot what comes back.
domain/robots.txt — the crawl instructions your site hands search engines. You are looking for rules you didn’t write, and especially for sitemaps you didn’t create: a sitemap declared here never has to be submitted anywhere, which makes it a quiet way to get thousands of pages discovered.
domain/sitemap.xml — every URL your site is offering up for crawling. Injected pages frequently appear here in plain sight.
domain/wp-json/wp/v2/users — the site’s user accounts, returned through WordPress’s own API. It exposes usernames, including any account created by somebody else. If the request is refused or returns nothing, that isn’t a failed check — it means the endpoint is locked down, which is worth knowing in its own right.
domain/?p=1, then ?p=2, ?p=3 and onward — loads a post by its raw database ID rather than its permalink, which bypasses pretty URLs and any redirect rules sitting in front of them. Walked through a range, it surfaces content that exists in the database but appears in no menu, no sitemap and no listing.
Screenshot each result the same way you screenshotted the search. And note the times — these requests will appear in your own access logs, and Part 3 is about subtracting yourself from that record before you go looking for anyone else.
What this check cannot tell you
The perimeter gives you a list of questions, not a set of answers. Being clear about that is what stops you from over-reading the evidence and building a story you’ll have to unwind later.
A site: search cannot tell you how anyone got in, when it started, whether files are still on your server, whether anything was taken, or whether the site is clean now. It tells you what the outside world can currently see, which is one input of several.
It’s also approximate by design. Google’s result count is an estimate, not a database query. The precise figures come in the next post.
Before you move on, record it
Everything you’re looking at right now is evidence, and some of it will disappear once remediation starts.
Screenshot the result count. Screenshot the first two pages of results, so the titles and URL patterns are captured. Write down the URL pattern — ?o=, ?n=, whatever it is. And note the date and time you ran it.
There is a specific reason to do this now rather than later, and it’s the sort of thing you only learn by getting it wrong.
From the case file. Once the spam URLs in this case were correctly configured to return “gone” rather than serving content, they became unfetchable in a browser — which is exactly what you want, and it also meant the pages could no longer be examined. Twenty-two of them had to be recovered afterwards through Google Search Console’s stored crawl view, pasted into a document one at a time. The countermeasure locked the investigation out of its own evidence.
Screenshot first. Remediate second.
One thing not to do
When you find spam URLs, the intuitive move is to block them in robots.txt. It feels like the fastest way to make them go away.
It is the single most expensive mistake available at this stage. Blocking a URL in robots.txt doesn’t remove it from Google — it stops Google from ever fetching it again, which means Google can never see that it’s gone. The entries freeze in place instead of clearing.
Removal is covered properly in Part 8. For now the instruction is simply: don’t.
What you can do yourself, and what you can’t
You can do all of this. No server access, no credentials, no technical skill. If your host has suspended the site, if you’re locked out, if you’re waiting on a support ticket — you can still run this search and record what it shows.
What needs someone with access is everything that follows from it: reading the server logs, examining files, establishing when it started, and removing what’s there.
That’s not a sales pitch, it’s the honest division. But the check you just ran isn’t a consolation prize either. It’s the first real evidence in the case, and it’s the thing that tells whoever you eventually hire how big the job is.
Google keeps its copy of your site long after the cleanup. Checking what is still indexed under your domain tells you whether the problem is over or only invisible.
Start a Recovery ReviewPaid assessment · scope agreed up front
Next: What Google Search Console Knows That Your Server Doesn’t
Hub: Invasion Investigation Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.