Cloaking in SEO: what it is, when Google penalises it and what does not count

Cloaking means showing a search engine's crawler different content from what someone sees when they open the same page in a browser.

Google treats it as spam and penalises it with a dedicated manual action, the one that appears in Search Console as cloaking and/or sneaky redirects: while it is active, the affected pages are demoted or removed from results, and lifting it requires a reconsideration request. There is, however, a second side to the question that most guides leave out. There are at least four situations in which serving different content to Googlebot and to users is not cloaking, and Google has written them down in its own documentation.

How it works, technically

The mechanism is always the same: the server looks at something in the incoming request, decides whether the caller is a person or a bot, and returns one of two versions of the page. What changes from one variant to the next is the parameter it looks at.

• User agent. The server reads the string that identifies the client and serves the cloaked version when it recognises Googlebot or Bingbot.
• IP address. The choice is made on the source IP, checked against lists of known crawler addresses.
• HTTP_REFERER header. The page changes depending on whether the visitor arrives from a search or types the URL. This is the variant that makes the problem invisible to the site owner, who usually comes in from bookmarks or the address bar.
• Accept-Language header. A different version is served when the header is missing or matches what a crawler would send. Googlebot, incidentally, sends HTTP requests without setting Accept-Language.
• JavaScript. The content is swapped after load, on the assumption that the crawler will not run the script. This worked much better fifteen years ago.

The Wikipedia entry still discusses cloaking in relation to Adobe Flash components, a technology retired on 31 December 2020. That says a lot about how dated some of the material on this subject is, and how closely cloaking is tied to the era when crawlers read little more than raw HTML. It is still one of the most cited black hat techniques, alongside keyword stuffing and hidden text, with which it is often combined.

What Google does not consider cloaking

This is the difference between a penalised site and a site that is simply doing its job. Responding differently to different requests is how the web ordinarily works: it becomes cloaking when the aim is to deceive. The table collects the cases Google has documented explicitly, one way or the other.

Practice	What Googlebot gets	What the person gets	Is it cloaking?	Google reference
Dynamic rendering with equivalent content	HTML pre-rendered on the server	Client-side rendered version	No	Dynamic rendering as a workaround
Dynamic rendering with different content (Google's example: a page about dogs for crawlers, one about cats for users)	Page A	Page B	Yes	Dynamic rendering as a workaround
Paywall declared with isAccessibleForFree and hasPart structured data	Full article	Preview and subscription prompt	No	Flexible sampling
Paywall without structured data	Full article	Only the paywall	Yes	Flexible sampling
Content adapted by country, with Googlebot treated like a visitor from the area it comes from	What a user in that location would see	Local content	No	Locale-adaptive pages
Full-size image disabled by responding 200 or 204 with no content when the referrer is a Google domain	Thumbnail generated during crawling	Full image	No	Manual Actions report
Text or keywords inserted into the page only when the request comes from a search engine	Extra text	Nothing	Yes	Spam policies

The dynamic rendering row is the one that sets the general rule. Google's documentation says that if dynamic rendering produces similar content it is not treated as cloaking, and that error pages caused by a misconfiguration are not cloaking either. It becomes cloaking when the two versions no longer have anything in common, which is where the dogs and cats example comes from. The same document warns that dynamic rendering is a workaround, not a recommended solution.

The two paywall rows deserve an extra note, because they concern anyone publishing content reserved for subscribers or behind a registration. Google asks you to mark the protected sections with schema.org structured data: isAccessibleForFree set to false and the relevant portion identified with hasPart.cssSelector. The markup exists precisely to distinguish a declared paywall from an attempt at cloaking. The same flexible sampling guidance suggests news publishers stay between 6 and 10 free articles per user per month, and notes that satisfaction among visitors arriving from search starts to drop sharply when the paywall appears on more than 10% of views.

Geolocation is the case that raises the most doubts in technical meetings. Google writes that when Googlebot appears to come from a particular country it should be treated like any other user from that location: if you block US visitors and let Australian ones through, your server must block Googlebot when it comes from a US IP and let it through when it comes from an Australian one. Consistency is the test, not uniformity.

What happens when Google notices

The Manual Actions report in Search Console has a dedicated entry, triggered when the site shows users pages different from those shown to Google, or redirects them somewhere other than what the search engine found. There is a second, less well known one reserved for images: it applies when the images shown in results do not match those on the page, for example because Google is served an image covered by a block of text. In that case the only permitted exception is disabling the embedded link as described in the table above.

Manual actions do not expire on their own. They have to be fixed at the source; then you request a review from the report and wait for Google's message in Search Console. Alongside this there is the algorithmic side, which produces no notification at all: no email, no warning, just rankings going down. When a site loses visibility for no obvious reason, it is worth ruling out cloaking before going back over the usual ranking factors.

The most common case is not deliberate

In its spam policies Google makes a point worth spelling out in full: when a site is hacked, attackers often use cloaking precisely to make it harder for the owner to spot the intrusion. The pattern is always the same. The regular visitor sees the site intact, the crawler sees injected spam pages, and the redirect to the target site fires only for people arriving from a search result. Google classes these conditional redirects, which change based on referrer, user agent or device, among the hacked content spam techniques.

On WordPress the way in is almost always an out-of-date plugin or a weak password, and the damage is measured in months of lost traffic before anyone notices. If the doubt concerns a site that brings in revenue, an external technical check costs far less than recovering from a penalty: it is part of what we do in our SEO services.

How to check your site in half an hour

1. URL Inspection in Search Console. Run a live URL test and open the rendered HTML. If it contains links, text or whole blocks that are not on the page, you have found the problem without looking any further.
2. Compare the server's responses. Request the same URL with a browser user agent and with Googlebot's, then repeat with and without a Google referrer. Three different responses for the same page are a signal that needs explaining.
3. Check who really is Googlebot. Reverse DNS lookups are the documented method for telling the real crawler apart from anyone copying its user agent string. It also helps you avoid the opposite mistake: blocking the genuine crawler by accident because you think it is an impostor.
4. Open the Security issues report. This is where Google flags that the site may have been hacked, and it is separate from the Manual Actions report. The practical recovery steps are in web.dev's guide to hacked sites.
5. Make robots.txt and meta robots consistent across languages and versions of the same page. Google asks for this explicitly and refers to the Robots Exclusion Protocol, standardised in RFC 9309. Different rules for different languages produce mismatches that look very much like cloaking.

The target has moved

Google's spam policies, updated on 2 September 2026, no longer talk only about positions in the SERP: the definition of spam now also covers attempts to manipulate Search's generative AI answers. The mechanics of cloaking have not changed at all; the recipient has. Anyone serving one version to the crawlers that feed generative answers and another to people is doing exactly what was done with Googlebot twenty years ago, and the test for which side of the line you are on is the same: if the version meant for the bot exists to make it believe something the visitor will not find, it is cloaking, whatever the brief calls it.

Frequently asked questions about cloaking