Cloaking in SEO: What Counts, What Does Not, and How Google Catches It

Cloaking is showing search engines one version of a page and human visitors another, in order to manipulate rankings. Google’s spam policies put it in one sentence: cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users. Two clauses in that sentence do all the work, and almost every argument I have with a client about cloaking is really an argument about one of them.

The first is different content. The second is with the intent to manipulate. Serving different content is not automatically cloaking. Paywalls, geotargeting, A/B tests, personalisation and mobile-specific markup all serve different bytes to different requests, and none of them is a violation. What makes it cloaking is that the difference is keyed to whether the requester looks like a search engine, and that the difference exists to change how you rank.

Google’s own examples

Worth quoting, because they are narrower and more concrete than the folklore. Google gives two examples of cloaking:

• Showing a page about travel destinations to search engines while showing a page about discount drugs to users.
• Inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor.

Note what the second example keys on: the user agent. That is the historical mechanism and it is the one most inherited cloaking scripts still use, because they were written years ago and nobody has touched them since.

The six variants I actually find

When a site lands on my desk with a suspected cloaking problem, it is almost never someone who decided to cloak last week. It is a plugin, a theme, an old CDN rule, or a previous agency’s leftovers. This is the table I work from.

Google treats sneaky redirects, hidden text and doorways as their own named policies rather than as cloaking, and the distinction matters when you are reading a manual action notice, because the notice names the policy. Operationally they are the same family: the crawler and the visitor are being given different experiences on purpose.

On the redirect variant, Google’s wording is specific: sneaky redirecting is doing this maliciously in order to either show users and search engines different content or show users unexpected content. It names desktop users getting a normal page while mobile users are redirected to a spam domain. That mobile-only shape is the one that goes undetected longest, because the people checking the site are sitting at desks.

What is not cloaking

This is where most of the fear lives, and most of it is unfounded. None of the following is cloaking, and I have had to talk clients down from breaking working sites over all of them.

The test that settles it

One question, and it has never failed me: if Googlebot identified itself as an ordinary browser, would this page change?

If the answer is no, you are not cloaking, whatever else the page is doing. If the answer is yes, you are, and the fact that your intentions were good does not survive contact with the policy, because the policy is written around what the configuration does rather than what you meant by it. A developer who added a crawler exception in 2019 to stop bots hammering a slow endpoint has created a cloaking configuration even though nobody involved was trying to manipulate anything.

How to check your own site in twenty minutes

1. Run the URL Inspection live test in Search Console on your ten highest-value URLs and read the rendered HTML, not the summary.
2. Fetch the same URLs as an ordinary browser and diff the two. Any difference in body copy, headings or links is the finding.
3. Repeat with a spoofed Googlebot user agent from your own machine. If that output matches Search Console but not your normal browser, the rule is keyed to user agent.
4. Repeat from a different network. If user-agent spoofing alone does not reproduce it, the rule is keyed to IP, which is the harder variant and almost always deliberate.
5. Test on a real phone, not a resized window. Mobile-only redirects are invisible to desktop emulation in a surprising number of cases.
6. Search your codebase for user agent string checks, and your CDN and server config for crawler rules. This is where inherited cloaking lives.
7. Check the Manual Actions report. If something is already there, the policy it names tells you which variant you are looking for.

Where this sits against the update calendar

Cloaking is a spam policy, so it is enforced by manual action and by the spam updates rather than the core updates. If you are trying to date a drop, the 2026 ranking updates published on Google’s own status dashboard are the reference. I checked these on 22 September 2026.

Note the rollout lengths. Spam updates land in hours or a couple of days. Core updates take a fortnight. If your traffic fell off a cliff inside twenty-four hours, a spam update or a manual action is the far likelier cause, and cloaking belongs on the shortlist. If it drifted down over two weeks, you are probably looking at a core update instead, and I set out how to tell those apart in manual action penalty or algorithmic demotion.

Fixing it

Remove the conditional logic rather than softening it. Half-fixing a cloaking rule, so that the crawler now gets something merely similar rather than something different, leaves you with the same violation and a harder story to tell in a reconsideration request. Delete the user agent check. Delete the IP rule. Serve one page to everyone and let the rankings settle where the page honestly deserves.

If a manual action is attached, fix first and file second, with the specific configuration named and the date it was removed. If there is no manual action and the loss was algorithmic, the fix is the same and the recovery is slower, which is the general pattern I set out in Google penalty recovery.

One last thing worth saying, because it is the most common real-world origin of a cloaking problem: inherited infrastructure. The same way a private network decays quietly under a new owner, as I described in why every PBN decays, a cloaking rule left in a CDN config outlives everyone who understood it. In regulated verticals this is routine, and I covered what survives enforcement there in iGaming SEO after the spam updates. Before you inherit a site, diff it as a crawler and as a human. It takes twenty minutes and it has saved clients of mine entire quarters.

Royking Niba is an SEO and GEO consultant specialising in penalty and spam-update recovery, with more than 8 million organic visits recovered for clients. Policy wording and the update timeline in this article were checked against Google’s published documentation and status dashboard on 22 September 2026.