Dynamic rendering is, in the SEO sense, a setup in which a server detects crawlers and serves them a server-rendered HTML version, while users get the client-side rendered version. Searches for the term mostly show the graphics technique of the same name in the Vulkan API, which is unrelated. The SEO technique is historical, and Google no longer recommends it.
How does dynamic rendering work?
The web server checks requests, for example by user agent. A request from a crawler that cannot process the JavaScript content is routed to a rendering server, which returns a suitable version such as static HTML. Users and other crawlers are served normally. It can be enabled for all pages or per page.
What does Google say?
Google’s page says dynamic rendering was a workaround and not a long-term solution. It calls it not a recommended solution because it creates additional complexities and resource requirements. Google recommends server-side rendering, static rendering or hydration instead.
On cloaking, Googlebot generally does not consider dynamic rendering cloaking as long as the content served is similar. Serving completely different content, such as a page about cats to users and a page about dogs to crawlers, can be considered cloaking.
| Approach | Where and when is the HTML built? | Content in the delivered HTML? | Google's position |
|---|---|---|---|
| Client-side rendering (CSR) | in the browser with JavaScript; data fetching, templating and routing run on the client | no, only after JavaScript has run | Google renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript |
| Server-side rendering (SSR) | on the server, for each request | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Static site generation (SSG, static rendering) | at build time; usually one HTML file per URL ahead of time | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Incremental static regeneration (ISR) | prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js) | yes, from the cache; the older version is served until regeneration finishes | no specific statement from Google |
| Prerendering | at build time; the client-side app is run and its initial state saved as static HTML | yes (initial state) | Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers |
| Dynamic rendering (this term) | a rendering server builds HTML only for detected crawlers; users get the client-side rendered version | only in the version served to crawlers | Google calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content |
Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .
Example
Request with user agent "Googlebot" → rendering service → finished HTML
Request with a browser user agent → JavaScript application
Both paths should deliver the same content.
Sources
- Dynamic rendering as a workaround – Google Search Centraldevelopers.google.com
- Spam policies for Google web search – Cloakingdevelopers.google.com
Last updated: