Restore / Research / Cloaking Cloaking Reference Cloaking. Conditional DOM serving by IP or User-Agent. Detection runs on rendered-DOM mismatch.
The server checks the requester's identity (IP or User-Agent) and returns a different rendered DOM to Googlebot than to users. Google's detection compares the crawler's session against headless-browser sessions simulating standard user agents from non-Googlebot IPs. The cloaking manual-action category lands when the mismatch is detected.
What 'cloaking' actually names
Cloaking is the specific violation where a server conditionally serves a different rendered DOM to Googlebot than it serves to human users. The conditional logic typically evaluates the requester's IP address against a database of known Googlebot IPs, or it evaluates the User-Agent HTTP header for the Googlebot signature. The crawler reads optimized content; users see something else.
The violation is the conditional serving rather than the content variation itself. Returning a mobile-optimized DOM to a mobile user-agent is not cloaking. Returning a translated DOM to a Spanish-language Accept-Language header is not cloaking. The distinguishing test is whether the variation is presented to all comers including the crawler (acceptable) or whether the crawler is selectively shown content the users will never see (cloaking).
The category name in the Search Console Manual Actions report reads cloaking for the standard HTML pattern. Variants get their own category lines: cloaked-images for obscured or mismatched thumbnails served to Google Images, AMP-content-mismatch when an AMP page lacks topical or functional parity with its canonical version.
How Google detects the mismatch
Google's detection compares the rendered DOM from Googlebot's session against rendered DOMs from headless-browser sessions that simulate standard user agents from non-Googlebot IPs. The comparison is structural: the crawler reads the DOM Google would index; the simulated session reads the DOM users would receive. A material mismatch triggers an automated flag and often a manual review.
The detection runs continuously across the index. Operators cannot evade detection by switching the conditional from User-Agent to IP, because the simulation rotates through IPs that read as standard residential or mobile-carrier addresses. Operators cannot evade detection by checking for JavaScript execution capability, because the simulation executes JavaScript with the same engine Google's renderer uses.
Once the flag fires, the manual review confirms the pattern and the action lands in Search Console with the category line named. The historical reference point for severe enforcement is February 4, 2006, when Google removed BMW Germany and Ricoh Germany from its index for deceptive cloaking and doorway pages. Both sites were restored after the conditional serving logic was removed and reconsideration requests were submitted.
Cloaking versus sneaky-redirects, side by side
The two violations sit adjacent in the manual-action taxonomy and confuse operators reading the Manual Actions report for the first time. Cloaking serves a different rendered DOM to the crawler than to users; the crawler reads an optimized page that the users never see. Sneaky-redirects serves the same DOM to both, then redirects users after the response via JavaScript, a meta-refresh tag, or a server-side conditional redirect; the crawler sits on the page, and the users are routed elsewhere.
The remediation surfaces overlap. Both fixes require auditing the conditional-serving layer (script tags, server rules, CDN logic) and restoring parity between the crawler's experience and the users' experience. The reconsideration request authoring differs per category line. Cloaking SEO covers the parent hub on conditional DOM serving end to end; sneaky redirect fix covers the sibling category remediation; why did my website disappear from Google rank covers the severe-enforcement deindex pattern these categories can produce.
The diagnostic in front of any cloaking remediation runs at SEO Penalty Removal. The full per-category remediation engagement is manual action removal.
What operators ask when the report flags this category.
- 01.
What is cloaking in plain terms?
A server conditionally serves a different rendered DOM to Googlebot than it serves to human users. The crawler reads optimized content; users see something else. The conditional check usually evaluates the requester's IP against a database of known Googlebot IPs or the User-Agent HTTP header.
- 02.
How does Google detect cloaking?
Google compares the rendered DOM from the crawler's session against headless-browser sessions simulating standard user agents from non-Googlebot IPs. A mismatch triggers an automated flag and often a manual review. Detection runs continuously across the index.
- 03.
What is the difference between cloaking and sneaky-redirects?
Cloaking serves a different rendered DOM to the crawler than to users. Sneaky-redirects serves the same DOM, then redirects users after the response via JavaScript, meta-refresh, or server-side conditional logic. The two manual-action categories sit adjacent in the taxonomy; the remediation surfaces overlap. Sneaky redirect fix covers the sibling category.
- 04.
Are there variants beyond the standard HTML pattern?
Yes. Cloaked images serve obscured or mismatched thumbnails to Google Images while users see a different visual. AMP content mismatch fires when an AMP page lacks topical or functional parity with its canonical web page; the AMP version drops from Search. Each variant is its own category line in the Manual Actions report.
- 05.
What happens when a manual action for cloaking fires?
The action lands in the Search Console Manual Actions report with the category line named. Severe cases historically produced complete removal from the index. The remediation is removing the conditional serving logic at the server or CDN level, restoring DOM parity, and filing the reconsideration request for the category. The manual action removal engagement runs the remediation.
If the Search Console Manual Actions report flags a cloaking category and you need the rendered-DOM mismatch audited before remediation, book the diagnostic.
We crawl the affected surface from Googlebot and from simulated standard user agents on non-Googlebot IPs, identify the conditional-serving logic per URL, scope the parity restoration across the full affected surface, and author the reconsideration request to the category.