Dynamic rendering SEO used to be a common answer to a common problem: a JavaScript-heavy site whose content crawlers could not reliably see. Serve bots a pre-rendered HTML version, serve people the app, and move on. Google’s guidance has since moved firmly away from it. The question now is not how to set it up, but whether you should be using it at all.
For most sites the answer is no. For a few, it is a reasonable bridge while a proper fix is built. Here is what Google actually says, where the cloaking line sits, and how to tell which group you are in.
What dynamic rendering is
Google’s definition, from its Search Central page “Dynamic rendering as a workaround”: “A dynamic rendering server detects bots that may have problems with JavaScript-generated content and serves a server-rendered version without JavaScript to these bots while showing the client-side rendered version of the content to users.”
The problem it was meant to solve is real. When JavaScript loads content in the browser, that “is called client-side rendering”. Google says it sees this content along with the HTML, but “some pages may encounter problems with content not showing up in the rendered HTML. Other search engines may choose to ignore JavaScript and won’t see JavaScript-generated content.” Our guide to JavaScript SEO covers those rendering problems in more depth.
Google’s stance: a workaround, not a solution
The page opens with a note that leaves little room for interpretation: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.”
It goes on: “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” Note what Google does not say. It does not say dynamic rendering triggers a penalty, and it does not say support will end. “Not a recommended solution” is the phrase, and it is strong enough on its own. The page was last updated on 10 December 2025.
The “additional complexities and resource requirements” are easy to underestimate. You are running a second rendering path that only bots ever see, so nobody on the team notices when it breaks. Every release has to be checked twice, and every bug report raises the question of which version the reporter was looking at. That ongoing cost is the main reason a one-off move to server-side rendering usually works out cheaper.
How it works in practice
The mechanics, as Google describes them, are simple to state. Dynamic rendering “requires your web server to detect crawlers (for example, by checking the user agent).” Crawler requests that need help are “routed to a rendering server. Requests from users and crawlers without JavaScript issues are served normally.” The rendering server “may serve a static HTML version”, and “You can choose to enable the dynamic renderer for all pages or on a per-page basis.”
The current page gives no setup steps, names no rendering tools and lists no user agents, so be wary of any guide that presents a particular service as Google-approved. If you go this route, user-agent detection becomes part of your stack, and our post on the Googlebot user agent explains what you would be matching against.
Where cloaking starts
Serving bots something different from users sounds like cloaking, and Google addresses it directly. “Googlebot generally doesn’t consider dynamic rendering as cloaking. As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking.” But “Using dynamic rendering to serve completely different content to users and crawlers can be considered cloaking.” Google’s example: “a website that serves a page about cats to users and a page about dogs to crawlers is cloaking.”
That parity rule is the whole risk. Over time, the bot version and the app drift apart: a new component ships in the app but not in the pre-render, a price updates in one and not the other. Our guide to cloaking in SEO covers the wider rule. One reassurance from Google: during setup your site “may produce error pages”, and “Googlebot doesn’t consider these error pages as cloaking and treats the error as any other error page.”
Dynamic rendering vs the alternatives Google prefers
The table compares dynamic rendering with the approaches Google recommends. The “who sees what” and “Google’s stance” columns follow Google’s page; the cost and risk columns are our judgement, not Google’s figures.
| Approach | Who sees what | Cost and risk (our view) | Google’s stance |
|---|---|---|---|
| Dynamic rendering | Bots get server-rendered HTML; users get the client-side app | Two versions to keep in sync; drift can become cloaking | “a workaround and not a recommended solution” |
| Server-side rendering | Everyone gets rendered HTML | Engineering work up front; one version to maintain | Recommended |
| Static rendering | Everyone gets pre-built HTML | Suits content that doesn’t change per request | Recommended |
| Hydration | Everyone gets HTML, then JavaScript takes over | Needs framework support | Recommended |
| Client-side rendering only | Everyone gets the app; content appears after JavaScript runs | Some content may not show in rendered HTML; other engines may ignore it | Seen by Google, with possible problems |
Our post on server-side rendering for SEO walks through the preferred route, and if you are on Next.js the Next.js SEO guide covers the rendering options that framework gives you.
When dynamic rendering SEO still makes sense
Google is explicit, in the past tense, about who it was for: “Dynamic rendering was a workaround for indexable, public JavaScript-generated content that changes rapidly, or content that uses JavaScript features that aren’t supported by the crawlers you care about. Not all sites need to use dynamic rendering, and there are better solutions”.
Read as a test, that gives you three conditions. Your content is public and meant to be indexed. It is generated by JavaScript and changes quickly, or relies on features some crawlers you care about do not support. And you cannot move to server-side or static rendering soon. If all three hold, a dynamic renderer on the affected templates can buy time. If any one fails, put the effort into the real fix instead.
If you do run it, treat it as temporary. Enable it per page rather than site-wide where you can, check the bot version against the live page whenever templates change, and keep a date in the roadmap for replacing it. Before anything else, confirm the problem is rendering at all: our explainer on crawlability vs indexability helps you separate a rendering issue from a crawl or index one.
The limitation: Google’s page gives no performance numbers, no rendering-delay figures and no list of crawlers that struggle with JavaScript. Whether dynamic rendering helps your site specifically can only be judged by comparing what bots receive with what users see, on your own pages.
Frequently asked questions
What is dynamic rendering?
A setup where your server detects bots that may struggle with JavaScript and serves them a server-rendered version without JavaScript, while users get the client-side rendered version.
Does Google still recommend dynamic rendering?
No. Google calls it “a workaround and not a recommended solution” and recommends server-side rendering, static rendering or hydration instead.
Is dynamic rendering cloaking?
Not if both versions carry similar content. Google says serving completely different content to users and crawlers can be considered cloaking.
Will dynamic rendering get my site penalised?
Google’s page does not say it causes a penalty. The risk is drift between the bot and user versions, which can cross into cloaking.
The takeaway Dynamic rendering is a bridge, not a destination. Use it only when you can’t yet ship server-side or static rendering, and keep the bot version identical in substance to what users see.
