Is your pre-rendering actually working?
Dynamic rendering fails silently by design — it only ever runs for bots, so when it breaks your site looks perfect and your traffic quietly falls. This fetches your page as both and tells you which copy the crawler actually got.
The five things this can tell you
Every result is one of these, and each has a different fix and a different level of urgency.
Server-rendered
Crawler and browser get the same complete HTML. Nothing to maintain, nothing that can break for bots only. This is the outcome worth engineering towards.
Dynamic rendering
The crawler gets substantially more content than the browser receives up front — the pre-render path is intercepting bot user-agents and working. Fine, but it is a second system that only bots exercise, so monitor it.
Client-rendered
Both responses come back near-empty alongside a heavy script load. Google may still index this on its second rendering pass. No AI crawler will — they read the HTML and stop.
Inverted
The crawler gets less than the browser. Usually a CDN rule, WAF or bot-mitigation product serving crawlers a challenge or a stripped page. Almost never intentional, and invisible from a browser.
Divergent
Both get content but they disagree — different status codes, or different amounts with neither an empty shell. Worth understanding before deciding whether it matters.
Where the line on cloaking actually sits
Serving a crawler a pre-rendered copy of the same page is explicitly permitted — it is the whole premise of dynamic rendering. What is not permitted is telling the crawler something different: a different title, a different canonical, a different destination, a different status code. This tool reports those separately from the rendering verdict, because a site can be doing pre-rendering correctly and still be tripping a cloaking signal through a template that drifted.
Frequently asked questions
Does this tool render JavaScript?
No, and it does not need to. The question it answers is not "what does this page look like once JavaScript runs" — your browser already tells you that. It is "does the crawler receive different HTML from the browser, and is the crawler's copy the complete one?" Both halves come from two plain fetches with different user-agents. Rendering would tell us about the version we already know is fine.
What is dynamic rendering?
Serving crawlers a pre-rendered, fully-formed HTML version of a page while browsers get the JavaScript app. It was Google's official recommendation for JavaScript-heavy sites for several years and is now described as a workaround rather than a long-term solution. It still works. The problem is that it creates a second rendering path only bots ever exercise, so when it breaks nothing on your site looks wrong and traffic simply falls.
Googlebot renders JavaScript now. Why does any of this matter?
Two reasons. Google renders on a second pass that is queued rather than guaranteed, so client-rendered content is indexed later and less reliably — which on a large or frequently-updated site is a real cost. More decisively, no AI crawler renders at all. GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot take the raw HTML and stop. Whatever this tool shows in the Googlebot column is, near enough, everything the AI engines have to work with.
Is serving crawlers different HTML cloaking?
Not by itself. Google is explicit that serving a crawler a pre-rendered copy of the same page is allowed — that is the entire premise of dynamic rendering. The line is substance. Same content, more completely rendered, is fine. A different title, a different canonical, a different destination or a different status code is not, and the tool flags those separately from the rendering verdict for exactly that reason.
The tool says my crawler copy has fewer words than the browser copy. What causes that?
Usually not a pre-render service at all. The common cause is bot mitigation — a CDN rule, a WAF or a security product serving crawler user-agents a challenge page, a rate-limit response or a stripped version. It is almost never anybody's intention, and because it only affects bots, nobody notices until rankings move. Check your CDN and firewall rules before you look at application code.
What should I do if my page is fully client-rendered?
Server-render or statically generate the main content so it is in the initial HTML. Every modern framework supports it, and it benefits real users on slow connections as much as it benefits crawlers. Pre-rendering for bots only is the fallback when the application genuinely cannot be changed — it works, but it is a second system to maintain and monitor, and it fails silently.
Why does it ask for a content-heavy page?
Because the verdict comes from comparing how much content each response carries, and a homepage or a redirect page may legitimately be short in both. A blog post, a product page or a service page gives the comparison something to measure. Test one page from each template you use — these setups are template-level, so one product page tells you about all of them.
Related tools and reading
A rendering bug looks like nothing at all.
No error, no alert, no visible change. Just a slow decline that gets blamed on an algorithm update eighteen months later. Find it now instead.
Get a Free Technical Audit