Is prerendering for bots cloaking? Dynamic rendering and Google's rules
Prerendering and cloaking in brief
Prerendering, also called dynamic rendering, is not cloaking when bots get the same content people see. Cloaking is showing search engines different content from what people get, to manipulate rankings.
Prerendering changes how a page is built, not what it says. A headless browser runs the page's JavaScript, and bots receive the finished HTML that a visitor's browser would build. See Prerendering. Google says it directly: "Googlebot generally doesn't consider dynamic rendering as cloaking."
EdgeComet serves bots shared copies of each page, one per device type, and records which copy each bot got. That record lets you check this on your own site.
The risk comes from what a site serves, not from the technique. A prerendered page that differs from the visitor's page in what it says can be cloaking, however it was built.
What Google and Bing say about cloaking
Both search engines define cloaking by what bots and people get, not by how the bot's copy is built.
Google's spam policies define cloaking as "presenting different content to users and search engines with the intent to manipulate search rankings and mislead users." Its two examples (Google spam policies):
- "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".
Google's dynamic rendering page applies this to prerendering (Google Search Central):
- "As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking."
- Error pages produced while you set it up are not cloaking. Google "treats the error as any other error page."
- "Using dynamic rendering to serve completely different content to users and crawlers can be considered cloaking. For example, a website that serves a page about cats to users and a page about dogs to crawlers is cloaking."
Bing's Webmaster Guidelines list cloaking among practices that "reduce ranking eligibility and grounding visibility, across Bing and Copilot experiences": "Sites should not rely on cloaking or serving materially different experiences to crawlers and visitors." The same guidelines tell you to avoid "Hiding critical content behind client-side rendering" (Bing Webmaster Guidelines).
Google calls dynamic rendering a workaround: what that means
Google's word "workaround" is about engineering cost, not about penalties. The same Google page that calls dynamic rendering a workaround also says it is not cloaking.
Google's full sentence: "Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements." Instead, Google recommends "server-side rendering, static rendering, or hydration."
The complexities are those of running a second way to build every page:
- Render servers to run, with headless browsers and enough capacity for crawl peaks.
- A cache of rendered pages, kept current when the pages change.
- Bot detection at your CDN or server, kept up to date as new crawlers appear.
- Checks that the bot's copy still matches the visitor's page.
How to choose:
- You can build or migrate to server-side rendering or static generation: do it. It is the native fix, and every bot and visitor gets the same HTML from your server.
- The site renders on the client and a rewrite is not planned: prerendering gives bots complete HTML now, without touching the app. Google's JavaScript guide still calls this a good idea: "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."
"Not all bots" includes AI crawlers. The AI fetchers EdgeComet tested read only the HTML document, with no JavaScript. See Do GPTBot, ClaudeBot and other AI bots run JavaScript? EdgeComet runs the render servers, the cache, the refreshes and the monitoring that Google describes as the cost, as a managed service.
When prerendering becomes cloaking
Prerendering becomes cloaking when the bot's copy says something the visitor's page does not. Two patterns cross the line:
- Content for bots only. Text, keywords or links added to the bot's copy that visitors never get. This is Google's "Inserting text or keywords" example.
- A different page. Bots and visitors get different topics, offers or products at the same URL, Google's cats and dogs example.
Some differences are not cloaking but still cost you, because bots index the wrong version:
- A failed or partial render. A consent wall, a login redirect, a timeout or a script error leaves bots an empty or partial page. Google treats a failed render as an error page, not as cloaking, but it indexes what it got. See Fix blank, partial or slow prerendered pages.
- An old copy. A cached copy rendered before your last change shows the old price or text until it refreshes. See How soon bots get a change.
Changes that keep the content the same are safe: removing executable scripts after the render, serving a mobile layout to mobile crawlers, and adding the tags that describe the page, such as a title or a canonical.
How EdgeComet keeps the bot's copy the same as the visitor's page
EdgeComet builds the bot's copy from the same URL a visitor loads and serves one copy to every bot that matches the same device profile. It adds no content of its own: only the Edge SEO rules you write change the page.
- The visitor's page, rendered. On a Cache + Render website, EdgeComet loads the URL in headless Chrome, waits for the page's network requests to settle and captures the HTML. With Strip Scripts on, the default, it removes executable scripts after the render and keeps JSON-LD structured data. The text, links and tags stay as the browser built them. See Prerender JavaScript pages for search and AI bots.
- One copy per device profile, not per bot. Each dimension has its own copy of each page, mobile or desktop, and every bot that matches it gets that copy. By default, Googlebot Smartphone, ChatGPT-User and ClaudeBot all read the same mobile render. See What bots receive.
- Server-rendered sites skip the render. In Cache-only mode, bots get your server's HTML from the cache, unchanged.
- Edge SEO picks pages, not bots. Edge SEO rules choose pages by URL and page content, never by user agent, and every bot that requests a matching page gets the change. The optional snippet applies the same changes for visitors. See Is Edge SEO cloaking?
- Copies refresh when pages change. Smart Re-cache re-checks pages bots request as often as they change, and feed changes reach bots at high priority. See How EdgeComet keeps cached pages fresh.
- A record of what each bot got. Every request is logged with the bot, the copy it got and the time. With that record you can show that Googlebot, Bingbot and the AI bots read the same page.
URL rules can treat one bot differently on some paths, with a longer render timeout, a cache setting or a block. They change how a page is delivered, not what it says.
How to check that bots get what visitors see
Compare the copy bots receive with the page in your browser:
- Open the copy bots get. In EdgeComet, open Page Analysis for the URL and go to the Cache tab. Rendered shows the page, HTML shows its tags and Markdown shows its text. See See the cached HTML bots receive.
- Open the page as a visitor. Load the same URL in a browser and compare the main text, prices, links and headings.
- Check which bots got it. In Data Explorer > Bot log, add the filter URL Contains the page's path. Each row shows the bot, the time, the page size and how EdgeComet served it. See See every Googlebot and AI bot request in the Bot log.
- Compare with and without JavaScript. jsbug.org, EdgeComet's free tool, loads a URL with and without JavaScript and highlights the differences in text, links and SEO tags.
Google's own view comes from URL Inspection in Search Console with Test live URL, which shows the HTML Google's renderer produced.
Common questions
Will Google penalize my site for prerendering?
Not for the technique. Google says it does not view dynamic rendering as cloaking as long as it "produces similar content." What Google acts on is a bot's copy that differs from the visitor's page in what it says. See When prerendering becomes cloaking.
Does Google still support dynamic rendering?
Yes. Google no longer recommends it as a long-term setup, but it still documents how dynamic rendering works and states that it is not cloaking. See Google calls dynamic rendering a workaround.
Is serving prerendered pages to AI bots cloaking?
Not when AI bots get the page people see. Bing's guidelines apply the same cloaking rule to grounding results in Copilot. The AI fetchers EdgeComet tested read only the HTML document, which makes a complete first response the only version of a JavaScript page they see. See Do GPTBot, ClaudeBot and other AI bots run JavaScript?
Is removing scripts from the bot's copy cloaking?
No. EdgeComet removes executable scripts after the page has rendered, and the content they built stays in the HTML. JSON-LD structured data is kept. Bots get the page they would build themselves, without running the code again.
Is a cached copy that is older than the live page cloaking?
No, an old copy is not an attempt to mislead. It still costs you: bots index the old price or text until the copy refreshes. Turn on Smart Re-cache and see How soon bots get a change.
Is Edge SEO cloaking?
No, when bots and people get the same content. Edge SEO changes tags that describe the page, and rules that change visible text need the snippet for visitors. See Is Edge SEO cloaking?
Are SEO split tests cloaking?
Not when every bot and visitor gets the same version of a given page. Edge SEO split tests divide pages into a test group and a control group, not users or bots. See Run SEO split tests.