Restore / Cloaking Remediation DOM Parity Violation Cloaking Remediation. We restore DOM parity between Googlebot and the human user.
Cloaking is conditional DOM serving: the server returns different HTML to Googlebot than to users, typically by User-Agent or IP. We strip the conditional logic at the server or CDN level, verify parity across all affected URLs, and submit the reconsideration request post-fix.
Four facts about cloaking that govern the remediation shape.
The diagnostic primitive is DOM parity. The remediation is removing the conditional serving and verifying parity. Manual action category remediation flows through <a class="prose-link" href="/manual-action-removal/">manual action removal</a>; this page handles the technical fix.
- 01
Cloaking is conditional DOM serving.
The server serves a different HTML DOM to Googlebot than it serves to human users, typically by checking the requester's IP against known Googlebot ranges or evaluating the User-Agent HTTP header. Google detects this by comparing the crawler's session against automated headless-browser sessions simulating standard agents. A mismatch flags the site.
- 02
Sneaky redirects are the JavaScript variant.
The server accepts the initial request and serves a 200 OK with optimized content. JavaScript, meta-refresh, or server-side redirects then send human users (often specifically mobile users) to an unrelated destination. The crawler receives the optimized DOM; the user gets routed elsewhere.
- 03
Third-party ad scripts produce unintentional cloaking.
Sneaky mobile redirects frequently come from unmonitored third-party ad scripts or monetization elements. The webmaster did not author the redirect; the script did. The audit catalogs every third-party script and emulates mobile sessions to surface the offending routing.
- 04
Historical precedent shows the severity.
<span class="cite">February 2006</span>: BMW Germany and Ricoh Germany were entirely removed from Google's index for cloaking and doorway pages. The remediation cycle restored both after the conditional serving was stripped, reconsideration requests were submitted, and DOM parity was verified. The severity is real; the remediation path is documented.
Three phases. DOM parity is the metric throughout.
-
Compare the DOMs.
We fetch the page as Googlebot (configured User-Agent) and as a standard user agent, then compare the rendered DOMs. We also emulate mobile sessions to surface mobile-only routing. The DOM-parity check is the diagnostic primitive for cloaking.
- Fetch as Googlebot User-Agent
- Fetch as standard user agent
- Mobile-emulator session
- Compare rendered DOMs for parity
- Catalog third-party scripts
-
Remove the conditional serving.
We strip conditional serving logic at the server or CDN level. We remove or replace third-party scripts that route mobile users to unrelated destinations. AMP content mismatch cases get fixed at the AMP-vs-canonical parity layer.
- Remove User-Agent / IP conditional serving
- Strip or replace offending third-party scripts
- Verify AMP / canonical content parity
- Re-test DOM parity after each change
-
Submit the request post-fix.
We submit the reconsideration request after DOM parity is verified across all affected URLs. The request documents the conditional serving that existed, the steps taken to remove it, and the outcome verified by parity testing. Googlebot accessibility holds throughout the review.
- Verify DOM parity across all affected URLs
- Author reconsideration request (issue + steps + outcome)
- Submit through Search Console
- Track review response and ranking recovery
Operators ask about the technical fix first.
- 01.
What is the difference between cloaking and sneaky redirects?
Cloaking serves a different DOM to Googlebot than to users at the initial response. Sneaky redirects serve the same DOM and then route the user elsewhere via JavaScript, meta-refresh, or server-side redirect. Same category in the Manual Actions report; the technical fix differs.
- 02.
Are mobile-only redirects always cloaking?
Mobile-only redirects to your own mobile site are not cloaking. Mobile-only redirects to an unrelated destination are. The category is sneaky-mobile-redirects. Third-party ad scripts produce this pattern frequently without the webmaster's intent.
- 03.
What about AMP content mismatch?
AMP pages must have topical and functional parity with their canonical web pages. A mismatch triggers AMP-content-mismatch manual action. The remediation restores parity at the AMP layer or removes the AMP version when parity cannot be maintained.
- 04.
How does Google detect cloaking?
Google compares the crawler's session against automated headless-browser sessions simulating standard user agents. The DOM-parity comparison surfaces conditional serving. Cloaked-image variants (different visuals to Google Images than to users on the page) are detected through the same comparison path.
If your site lost traffic and a DOM-parity audit shows conditional serving, book the remediation.
We catalog every third-party script, strip the conditional serving at the server or CDN level, verify rendered-DOM parity across all affected URLs, and author the reconsideration request to the three-element structure.