In short. Dynamic rendering routes selected crawlers to rendered HTML; Google recommends other approaches and assesses cloaking by content similarity.

Definition: Dynamic rendering routes selected crawler requests to a rendering server that supplies HTML with JavaScript-generated content already rendered, while users receive content rendered in their browser. As of 17 October 2026, Google describes it as a workaround with additional complexity and resource requirements.

Key facts

Google's dynamic rendering documentation recommends other rendering approaches for a long-term solution.
Google's JavaScript SEO basics explains that Google executes JavaScript and uses the rendered HTML for indexing.
The web.dev article Rendering on the Web defines server-side rendering as generating HTML on the server and static rendering as generating it at build time.
Google's URL Inspection help distinguishes information about the indexed page from a live test of its current version.

How does crawler-specific routing work?

Google's dynamic rendering guide describes detecting crawlers, for example through their user agent, an identifier in the request. Requests from crawlers with JavaScript compatibility problems go to a rendering server. Other requests follow normal handling.

The following routing summary matches Google's static-HTML example:

User or crawler without JavaScript issues -> normal response
Crawler with JavaScript issues -> rendering server -> static HTML

The renderer can operate across the site or on selected pages. Google identifies public, indexable content that changes rapidly or uses unsupported JavaScript features as cases for this workaround.

Google's recommended alternatives are explained in the web.dev rendering overview. Server-side rendering generates a page's HTML in response to navigation. Static rendering prepares HTML files ahead of requests. Hydration runs browser scripts to add application state and interactivity to server-rendered HTML.

These choices affect how content reaches users as well as crawlers. The same overview identifies tradeoffs: generating HTML on the server takes time, while static rendering requires individual HTML files for the site's possible URLs.

When can different responses become cloaking?

Google's dynamic rendering guidance makes content similarity the condition for Googlebot, Google's search crawler, to accept the arrangement without treating it as cloaking. Here, cloaking means serving completely different content to users and crawlers. Google's example is a page about cats for users and dogs for crawlers.

The same guidance says that error pages produced while setting up dynamic rendering receive ordinary error-page treatment. The distinction concerns the content served, beyond the routing decision itself.

How can a website check the rendered content?

Google's JavaScript SEO documentation recommends examining rendered HTML through URL Inspection or the Rich Results Test. It says content absent from the rendered HTML cannot be indexed by Google. It also states that Google Search skips JavaScript from blocked files or blocked pages.

The URL Inspection instructions describe opening View tested page after a live test. The More info panel exposes resources and JavaScript output. The Screenshot tab shows the page as Google-InspectionTool sees it and requires a successful live fetch. Comparing this output with the browser version checks whether the intended content survives rendering.

FAQ

Does Googlebot require dynamic rendering to read JavaScript?

Google's JavaScript SEO basics says Google Search runs JavaScript with an evergreen version of Chromium. Dynamic rendering addresses compatibility problems for selected crawlers.

Does a successful live test prove that my page is indexed?

Google's URL Inspection help says a live test confirms whether Google-InspectionTool can access your page for indexing. Other conditions still apply before a page enters Google's index.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer