Is Showing Different Content to Bots Versus Users Always Cloaking?

By ScaleGrowth Digital Editorial

No. The question conflates three distinct practices that Google treats differently: cloaking, which is a policy violation; dynamic rendering, which Google deprecated in 2024 but still tolerates; and bot-specific rate-limiting or security responses, which are required at infrastructure layers and have nothing to do with content equivalence. The test for cloaking is not “does the bot see something different from a user”. The test is “does the content shown to the bot deceive the ranking signal about what the user will see”. This piece walks the line between the three, with the specific evidence patterns that distinguish a compliant dynamic render from a cloaking violation.

The Three Things Often Confused

Cloaking, as Google defines it in its spam policies, is the practice of presenting different content or URLs to human users and to search engines for the purpose of manipulating search rankings. The phrase “for the purpose of manipulating” is load-bearing. A divergence between the bot view and the user view is not cloaking unless that divergence is engineered to mislead the ranking decision.

Dynamic rendering is a separate practice. A site detects a crawler and serves a pre-rendered HTML version, while serving the JavaScript-heavy SPA to humans. Google formally deprecated dynamic rendering as a recommendation in 2024, but the practice itself is not a policy violation. The compliance test is content equivalence: the pre-rendered version must contain the same primary content, the same primary entity, the same primary claim as the rendered SPA. If those match, Google does not treat it as cloaking.

Bot-specific responses at the infrastructure layer (WAF rules blocking known scraper agents, rate limits on aggressive crawlers, 403s for unidentified bots) are required for site security and have no implication for ranking. Google’s own crawler must reach a 200 response; what an unrelated crawler receives is the site operator’s choice.

The Cloaking Test in Plain Terms

Google’s spam guidance walks through three patterns that count as cloaking. The first is keyword-stuffed HTML served to crawlers and a clean, human-facing layout served to users. The second is a topical content swap where the bot sees content about Topic A and the user sees content about Topic B. The third is redirect behaviour that varies by user-agent, sending bots to an indexable page and users to a different commercial destination.

None of these are about the technical mechanism of serving different bytes. All three are about whether the served content misrepresents the page to the ranking system. The mechanical fact that a CDN serves a cached HTML snapshot to one user-agent and a fresh server-render to another is policy-neutral. The question is whether the content matches.

The Practitioner’s Equivalence Test

The working test on an audit is straightforward. Pull the HTML the bot receives, pull the rendered DOM a human receives after JavaScript executes, and compare on five axes: primary heading, first paragraph, primary entity name, primary commercial claim, and schema markup. If all five match, no cloaking concern exists regardless of how different the byte counts are. If any of the five diverge, the page is at risk.

On an Angular 17 SPA fintech with roughly 5,000 pages we audited, the pre-JavaScript word count on most pages was approximately one word. The post-JavaScript word count averaged 1,200. Googlebot, which executes JavaScript with measurable delay and at variable success, was reading near-empty HTML shells on many crawls. The site was not cloaking in the policy sense, because no deception was occurring, but the asymmetry between what the bot could reliably index and what humans saw was creating real ranking loss. The fix was server-side rendering, which collapsed the asymmetry by making the bot view and the user view match at the byte level. The same audit also found 0 Open Graph tags across 3,677 pages and a robots.txt that was being served as Angular HTML because of a Router intercept bug. These were render-gap issues, not cloaking issues, but they had the same downstream effect: the bot was reading something the user was not.

Where Sites Cross the Line by Accident

The most common accidental cloaking pattern we see is geo-or-cohort personalisation that goes too deep. A page that serves a regional currency on the user view and a default-region currency on the bot view is fine. A page that swaps the entire product list based on user IP and serves a different product list to the bot view is at risk, because the indexed product list does not represent what the user lands on.

The second pattern is paywall handling. Flexible sampling under the Google News protocol is explicitly permitted: bots receive the full article up to a quota, users hit a paywall after one or two views. Operators that exceed the sampling quota or that serve a different article body to the bot, on a paid-content site, are at risk.

The third pattern is bot-specific WAF responses that overcorrect. A WAF that 403s Googlebot because of an aggressive fingerprint rule has not cloaked, but it has functionally hidden the page from the index. The remedy is reverse-DNS verification of the bot before the WAF rule fires. On a major BFSI lender audit we ran, 71 percent of crawled pages were returning 403 because of a translation tool sitting in front of the WAF and rejecting bots indiscriminately. The audit deliverable included a 16-sheet Drupal-specific roadmap with explicit Akamai cache rules to release the bot blockade.

Five Scenarios, Five Verdicts

What Googlebot Verification Actually Looks Like

The reliable check is reverse-DNS. The full process: resolve the IP requesting your page to a hostname, confirm the hostname is in the googlebot.com or google.com domain, then resolve that hostname back to an IP and confirm it matches the original. This protects against forged user-agent strings. The same process applies to Bingbot (under search.msn.com), Applebot (under applebot.apple.com), and the major AI crawlers including GPTBot, ClaudeBot, and PerplexityBot, all of which publish their hostname ranges. Cloudflare, Akamai, and Fastly all expose this verification as a built-in directive; the operational cost is low.

A claim that “the WAF blocks Googlebot” should never be made from a curl test originating from a non-Google IP. A 406 or 403 from a curl call only proves the WAF rejects unknown sources. The verification requires either GSC URL Inspection reporting the same 403, or vendor server logs showing the Googlebot/2.1 user-agent from a verified Google IP receiving a non-200. Anything else is misdiagnosis.

Practitioner Takeaway

1. Run the five-axis equivalence test on any page that serves bots and users differently. Heading, first paragraph, primary entity, primary claim, schema. Match on all five and the divergence is policy-neutral.
2. Verify bot identity by reverse DNS before any WAF rule fires. Forged user-agent strings are common; verified IPs are not.
3. Audit the 4xx response codes returned to verified bots quarterly. 71 percent 403 rate is real; we have measured it. The remediation is at the WAF and CDN layer, not in the page templates.
4. Move SPA stacks to server-side or static rendering. Pre-render dynamic rendering still works, but the maintenance overhead exceeds the cost of a proper SSR migration on most stacks now.
5. Distinguish render-gap from cloaking when you talk to engineering. The fix is different. Render-gap is a delivery issue. Cloaking is a policy issue. Conflating the two delays the right fix.

For deeper diagnostics on render gaps, see our technical SEO practice. The schema-equivalence pattern referenced above is documented in the schema-for-AI primer. SPA-specific render and indexing failures are covered in the SaaS growth engineering overview, where the Angular 17 audit pattern recurs frequently.

Frequently Asked Questions

Is dynamic rendering still allowed by Google?

Yes, although Google deprecated it as a recommendation in 2024. The practice is not a policy violation when the bot view and the user view contain equivalent primary content. Google now recommends server-side rendering or static generation as the preferred approach, but existing dynamic-rendering setups are not penalised solely for using the technique.

What is the single clearest test for whether a page is cloaking?

Fetch the page as Googlebot, render the page as a logged-out user in a clean browser, and compare the primary heading, first paragraph, primary entity name, primary commercial claim, and schema markup. If all five match, no cloaking concern exists. If any diverge, the page is at risk.

Can a WAF block Googlebot accidentally?

Yes, and we see it frequently. On one major BFSI lender, 71 percent of crawled pages were returning 403 because of a translation tool fronting the WAF that rejected bots indiscriminately. The remedy is reverse-DNS verification of the bot before the WAF rule fires. The diagnostic must use GSC URL Inspection or verified server logs, not a curl test from a non-Google IP.

Does showing localised currency to users count as cloaking?

Localisation that varies a price display, a currency symbol, or a regional phone number is policy-neutral provided the underlying product, claim, and primary content stay the same. The risk threshold is when the entire product list, the entire offer, or the primary entity changes between the bot view and a user view, because that misrepresents the indexed content.

Can A/B testing be configured to avoid cloaking risk entirely?

Yes. Server-side cohorting on a single canonical URL with bots pinned to the control variant, where the variants alter visual treatment or CTA copy but share heading, body, and schema, falls within the published guidance. Client-side variant injection that rewrites the indexed content carries higher risk and is best avoided on SEO surfaces.

If you are uncertain whether a current configuration counts as cloaking, request a technical SEO review. The deliverable is a per-URL equivalence verdict, a bot-verification audit, and the remediation roadmap if any divergence is flagged.

Request a cloaking-risk audit

{
“@context”: “https://schema.org”,
“@graph”: [
{
“@type”: “Article”,
“headline”: “Is Showing Different Content to Bots Versus Users Always Cloaking?”,
“description”: “The practitioner answer to when bot-vs-user content divergence counts as cloaking, with the five-axis equivalence test and verdict table.”,
“author”: {“@type”: “Organization”, “name”: “ScaleGrowth Digital Editorial”, “url”: “https://scalegrowth.digital/about/”},
“publisher”: {“@type”: “Organization”, “name”: “ScaleGrowth Digital”, “logo”: {“@type”: “ImageObject”, “url”: “https://scalegrowth.digital/logo.png”}},
“mainEntityOfPage”: “https://scalegrowth.digital/why-is-showing-different-content-to-bots-versus-users-always-cloaking/”,
“datePublished”: “2026-09-11”,
“dateModified”: “2026-09-11”
},
{
“@type”: “FAQPage”,
“mainEntity”: [
{“@type”: “Question”, “name”: “Is dynamic rendering still allowed by Google?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes, although Google deprecated it as a recommendation in 2024. The practice is not a policy violation when the bot view and the user view contain equivalent primary content. Google now recommends server-side rendering or static generation as the preferred approach.”}},
{“@type”: “Question”, “name”: “What is the single clearest test for whether a page is cloaking?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Fetch the page as Googlebot, render the page as a logged-out user in a clean browser, and compare the primary heading, first paragraph, primary entity name, primary commercial claim, and schema markup. If all five match, no cloaking concern exists.”}},
{“@type”: “Question”, “name”: “Can a WAF block Googlebot accidentally?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. On one major BFSI lender, 71 percent of crawled pages were returning 403 because of a translation tool fronting the WAF that rejected bots indiscriminately. The remedy is reverse-DNS verification of the bot before the WAF rule fires.”}},
{“@type”: “Question”, “name”: “Does showing localised currency to users count as cloaking?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Localisation that varies a price display, currency symbol, or regional phone number is policy-neutral provided the underlying product, claim, and primary content stay the same. The risk threshold is when the entire product list or primary entity changes.”}},
{“@type”: “Question”, “name”: “Can A/B testing be configured to avoid cloaking risk entirely?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. Server-side cohorting on a single canonical URL with bots pinned to the control variant, where variants alter visual treatment or CTA copy but share heading, body, and schema, falls within the published guidance.”}}
]
}
]
}