Hacked pages only Google can see: the spam injection your visitors never notice

One of the most common website compromises is invisible by design. The site looks fine to you and fine to your visitors, while it quietly serves hundreds of spam pages to search engine crawlers under your domain name.

The attack is called a spam injection, and the pages it plants follow a familiar pattern: casino and gambling pages, pharmacy pages, counterfeit designer goods. They are attached to your domain — yourdomain.com/some-path you never created — and Google indexes them the same way it indexes everything else on your site. The injected code checks who is requesting each page. A search engine crawler gets the spam; an ordinary browser gets your normal site, or nothing at all. That trick is called cloaking, and it is the reason the owner of a compromised site can browse it top to bottom and find nothing wrong.

Meanwhile the cost lands on the site's reputation. Google's picture of the domain now includes hundreds of pages about topics the site never chose, searchers occasionally land on them, and the domain's standing in search absorbs the association. None of that is visible from a browser window.

Why can I not see the hacked pages on my own website?

Because the injected code checks who is asking before it answers. When the request comes from a search engine crawler, the compromised site serves the spam pages; when it comes from an ordinary browser, it serves the normal site or a not-found page. This is called cloaking, and it is a deliberate feature of the attack: an infection nobody sees is an infection nobody cleans, so it stays profitable for longer.

It helps to understand what the attacker is actually after, because it explains the odd shape of the attack. The spam pages are not aimed at your visitors at all. They exist to rank in search results, and ranking is easier on a domain that search engines already trust. A freshly registered spam domain starts from nothing; your established domain carries years of accumulated authority. The injection borrows that authority — your domain does the ranking, and the spam pages harvest the clicks and pass them onwards.

Cloaking serves the same goal. If the spam were visible, a visitor would notice within days and the site would get cleaned. Served only to crawlers, the infection can run for months, which is precisely the point. The one audience that must see the pages for the scheme to work — the search engines — is the one audience the owner never browses as.

Where it shows up first: your own search data

There is one place the infection cannot hide, and it is a place many site owners never open: the search performance data for their own domain. Google Search Console records every query the domain appeared for and every URL that received impressions and clicks. Cloaking fools browsers, but it cannot fool this report — if Google is indexing spam under your domain, the spam shows up here as impressions and clicks you cannot account for.

The signature looks like this: queries you would never target — casino terms, pharmacy terms, brand names of products you do not sell — and, next to them, landing URLs you do not recognise as pages you ever created. Both halves matter. Odd queries landing on your real pages are a curiosity; odd queries landing on paths that should not exist are the alarm.

This is one more reason the Search Console reports deserve a regular look even when nothing is wrong — the same data answers the everyday questions about which numbers actually matter, and as a side effect it is the earliest available warning that something has been planted on the domain.

Are strange search queries in Search Console proof my site is hacked?

No. A single odd query usually has a benign explanation, and that should be considered first. Words mean different things across languages — a Danish heritage site legitimately ranks for "slot", which means castle in Danish and looks like gambling in English. A blog post can legitimately mention a medicine name. What warrants a closer look is a cluster: many unfamiliar queries, landing on URLs you do not recognise, around a topic your site has never covered.

The benign cases are worth spelling out, because accusing your own site of being hacked on the strength of one strange word leads to wasted evenings. A page can rank for a query it merely mentions in passing: an article that once discussed a painkiller in the context of, say, sports injuries will pick up impressions for that medicine's name, and that is ordinary search behaviour, not an infection. Cross-language collisions are just as ordinary. A query that reads as gambling, pharmaceuticals or luxury goods in one language can be an entirely innocent word in another, and Google serves your pages to searchers in many languages whether you planned for that or not.

So the test is never a single data point. It is the combination: dozens or hundreds of unfamiliar queries rather than one; landing URLs you cannot match to any page you published; and a subject area — online casinos, prescription drugs, replica goods — that your site has never written a word about. One leg of that tripod is noise. All three together are worth investigating the same day.

How do I check what Google actually sees on my site?

Use the URL inspection tool in Google Search Console and run the live test, which fetches the page as Googlebot and shows you what it received. Compare that with what an ordinary browser gets for the same URL. If the two differ substantially — spam text, links or whole pages that only exist in the Googlebot version — the site is cloaking, and on a site you never configured to do that, it points to a compromise.

Take one of the suspicious URLs from the performance report and inspect exactly that. A cloaked page typically returns a 404 or a redirect to your front page when you open it in a browser, and a full page of spam when fetched as Googlebot. Seeing the two side by side removes the doubt in a way no amount of staring at the query list can.

The server tells the rest of the story. Look for files modified recently when you have not changed anything: PHP files with names that imitate legitimate ones or sit in upload directories where no code belongs, and changes to .htaccess, which is a favourite place to hide the rules that route crawler traffic to the spam. Most hosting providers also offer a malware scan, and it is worth running — it inspects the files on disk directly, which is the one vantage point cloaking cannot deceive.

How do hacked spam pages get onto a website?

Most often through an outdated plugin, theme or CMS with a known vulnerability, or through stolen credentials — an admin or FTP password captured elsewhere and reused. That access is used to place a small backdoor file, and the backdoor generates or serves the spam pages. This is why deleting the spam pages alone fixes nothing: the backdoor that created them is still there and will recreate them.

The entry point matters more than the spam, because the spam is only the symptom. On WordPress sites in particular, the overwhelmingly common route in is a plugin or theme that has not been updated since a vulnerability in it became public — the same pattern covered in is my WordPress site secure?. Fixing the visible damage while leaving the vulnerable component in place invites the identical infection back, often within days.

How do I remove hacked spam pages from Google?

Clean the infection first — the injected files and the backdoor that placed them — because Google keeps indexing spam that is still being served. Then request removal of the spam URLs in Search Console and ask for your legitimate pages to be recrawled. Keep watching the query data for weeks afterwards: reinfection through the same unpatched hole is common, and the spam queries fading out is your confirmation that the clean-up held.

In practice the order is: update or remove the vulnerable plugin, theme or CMS component; change the passwords that could have been the way in; remove the injected files and the backdoor, restoring from a clean backup if you have one; and only then turn to the search side, using Search Console's removals tool for the spam URLs and reinspecting your real pages. The index catches up on its own after that — the injected URLs start returning genuine 404s, get recrawled, and drop out.

The monitoring afterwards is not optional politeness; it is the part that catches the second infection. The query report that raised the alarm is also the report that confirms the recovery: spam impressions should taper off over the following weeks, and a fresh batch of unfamiliar queries is the earliest sign that the door was not fully closed.

What to do this week

Open your Search Console performance report and read the query list with the cluster test in mind: not "is any query odd?" but "are there many odd queries, on URLs I do not recognise, about a topic I have never covered?". If the answer is no — and for most sites it is — you have spent ten minutes and gained a baseline, which is what makes the report readable next month. If the answer is yes, run the live URL inspection on one of the unfamiliar URLs today and let the Googlebot-versus-browser comparison settle it.

TrustCtrl watches this data continuously, because the whole character of the attack is that it appears between the moments anyone looks. It reads your search query data for exactly this signature — clusters of unfamiliar queries and unrecognised URLs in topics your site has never covered — and applies the same caution described above, so that a castle is never reported as a casino. It sits alongside the rest of the site checks, from certificate expiry to whether AI crawlers can reach you, so the warning arrives even in the months when nobody opens the report.