Cloaking Hacks: When Google Sees a Different Site Than You Do

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Google is telling you your site contains spam. You have checked every page, viewed the source, run a scanner, and found nothing. You are not going mad and Google is not wrong. Your server is making a decision about who is asking before it decides what to send, and you are in the group it shows the clean version to.

What cloaking means here

Cloaking is serving different content to different requesters for the same URL. A legitimate site does a mild version of this all the time — mobile layouts, localized currency, personalized recommendations. The malicious version decides based on whether you look like a search engine, a logged-in administrator, or an ordinary visitor, and serves fundamentally different content accordingly.

On a hacked site the split is usually three ways. Search engine crawlers get keyword-stuffed spam so the pages rank. Ordinary visitors arriving from search get redirected to whatever is being sold. And you — logged in, arriving directly, from a familiar address — get your real site, untouched, which is why everything looks fine from where you are standing.

How the decision gets made

The code checks signals in the request. The user agent string is the crudest and most common, matched against known crawler names. The referring URL is checked to see whether the visit came from a search engine. The IP address may be matched against known crawler ranges, which is more reliable for the attacker. And WordPress login cookies are checked so that administrators see nothing unusual.

The logic itself can sit in several places: a .htaccess rewrite that routes matching requests elsewhere, PHP in the theme or a plugin that swaps the output, or a database-stored injection. That variety is why there is no single file to look for, and why you have to establish the behaviour before hunting the code.

Proving it is happening

Stop trying to reproduce it as yourself. Use Search Console's URL inspection tool and look at the fetched HTML — that is literally what Googlebot received, and if it contains pharmacy text your page does not have, the question is settled. It is the single most useful test available and it takes a minute.

Back it up with a fetch that spoofs a crawler user agent, and another that arrives with a search engine referrer, in a session with no login cookie. Compare all three against what you see normally. Where they differ, you have both confirmation and a strong hint about which signal is being tested. Checking Google's cached version of the page tells you the same story from a different angle.

Finding the code

Once you know which signal triggers it, search for that signal. Code testing user agents will reference the crawler names it matches. Code testing referrers will look for search engine domains. Code checking login state will call the relevant WordPress function. Grep the whole codebase for those patterns and you usually land on it quickly.

Check every .htaccess file, not just the root one, because rewrite-based cloaking is common and copies get dropped throughout the tree. Check the database as well, since injected PHP is not the only option — my guides on hacked .htaccess files and database malware cover both hiding places, and reading obfuscated code covers what to do when you find something unreadable.

Cleaning it out

Remove the cloaking logic and whatever it was serving, then treat the site as fully compromised: replace core, plugins and theme from clean sources, clean the database, delete unrecognized administrator accounts, rotate every credential, and hunt for the persistence that put it there. Cloaking is a delivery mechanism, and it almost always sits on top of a backdoor.

Then verify with the same tool that proved the problem. Re-run URL inspection on several pages and confirm the fetched HTML matches what you see. That is your evidence the fix worked, and you will want it for the next step anyway.

Repairing things with Google

Cloaking is treated seriously, and a manual action is a realistic outcome. If you have one, you will see it in Search Console, and clearing it requires a reconsideration request that explains what happened and what you did — my guide on reconsideration requests covers how to write one that passes.

If spam pages were indexed while this was running, getting them out of the index is the next job, and ranking recovery covers the timeline. If you want this found and proven properly rather than guessed at, that is exactly the kind of case my malware removal service handles.

Common questions

How can I see what Googlebot sees?

Use the URL inspection tool in Search Console and view the fetched HTML from a live test. That is the actual response Google received for that URL. It is far more reliable than any browser check, because it comes from Google's own infrastructure and cannot be fooled by the same checks that fool you.

Why does my site look fine when I check it?

Because you are the one visitor the cloaking code is specifically written to show the real site to. You are logged in, you arrive directly rather than from a search result, and often you visit from a familiar IP address. Every one of those is a signal the code uses to serve you the clean version.

Is cloaking always malicious?

No. Serving different layouts to mobile devices or different currencies by region is normal and permitted. What search engines object to is showing them substantially different content than real visitors get, for the purpose of ranking for things the page does not actually contain. On a hacked site, that is exactly what is happening.

Will I get a manual penalty for this?

It is a real possibility, since cloaking is a direct violation of search engine guidelines. The saving grace is that hacked sites are common and search engines know the difference between a compromised victim and a deliberate spammer. A complete cleanup followed by an honest reconsideration request usually clears it.

Can a security plugin detect cloaking?

Poorly, in general. Plugins scan files and compare against signatures; cloaking is a behaviour that depends on who is asking, and the code implementing it can be small and unremarkable. The reliable detection is external — comparing what a crawler is served against what you see.