Dynamic rendering means detecting a bot and serving it a pre-rendered, static HTML version of a page while human visitors get the normal JavaScript app. It was a popular workaround for years, but in 2026 it is a legacy stopgap, not a recommended strategy. Google now calls it a workaround it does not endorse for the long term, and AI crawlers make the case against it even stronger. If your site depends on it, this guide explains what it does, why it is fading, and what to do instead.
How dynamic rendering works
A JavaScript-heavy site sends the browser a nearly empty HTML shell and builds the real content on the client after scripts run. Search bots and AI crawlers that do not fully execute JavaScript see the empty shell and miss the content — a problem we cover in depth in why JavaScript-only websites are invisible to AI.
Dynamic rendering patches this by putting a middleware layer (often a headless-browser service like a Rendertron or a hosted prerender provider) in front of the site. When an incoming request has a bot user-agent, the middleware runs the JavaScript itself, captures the finished HTML, and returns that static snapshot to the bot. Real users bypass the middleware and get the live app. The bot gets readable content; the user gets interactivity.
Why it is falling out of favour
Three shifts pushed dynamic rendering into legacy status:
- Google renders JavaScript now. Googlebot uses an evergreen rendering engine and processes JavaScript in a two-wave indexing pass. Dynamic rendering was designed for an era when it did not. For Google specifically, a well-built JS site can often be indexed without it.
- It is fragile and hard to maintain. You are running a second rendering pipeline whose only job is to serve bots. It breaks silently, adds infrastructure cost, and drifts out of sync with the real site. Debugging why a snapshot differs from the live page eats engineering time.
- AI crawlers mostly do not render at all. GPTBot, ClaudeBot, PerplexityBot and most AI fetchers pull raw HTML and do not execute JavaScript. If your snapshot logic only targets Googlebot's user-agent, these bots still get the empty shell — and you vanish from AI answers even while ranking fine in Google.
There is also the cloaking worry. Serving different content to bots than to users is risky territory. Dynamic rendering stays on the right side of the line only when the bot's snapshot matches what users eventually see. The moment the two diverge, you are cloaking, and that can cost you.
What to do instead
The durable fix is to render your content on the server so everyone — users, Google, and every AI crawler — receives the same complete HTML on the first request. The trade-offs between the approaches are laid out in our guide to server-side vs client-side rendering, but the short version is:
- Server-side rendering (SSR) builds the full HTML on each request. Best for content that changes often or is personalised.
- Static site generation (SSG) builds HTML at deploy time. Ideal for blogs, docs and marketing pages that do not change per user.
- Hybrid frameworks like Next.js, Nuxt and Astro let you choose per route, so you server-render the pages bots need and hydrate interactivity on top.
With any of these, the content lives in the initial HTML response. No bot detection, no snapshot service, no divergence between what humans and machines see. That is the whole point: one source of truth that every reader can parse.
If you cannot migrate right away
Rebuilding rendering is a real project, and sometimes dynamic rendering has to stay for one more quarter. If so, treat it as life support, not a solution. Make sure your bot detection covers the full modern list — not just Googlebot but the AI fetchers too, which you can identify from your access logs as described in our server log analysis guide. Verify regularly that the snapshot content matches the live page, and put the SSR or SSG migration on the roadmap. Every month you run a parallel bot-only pipeline is a month of avoidable fragility.
Want to know whether bots currently see your real content or an empty shell? Run the free CheckMy.site scanner — it fetches your pages the way a non-rendering crawler does and shows you exactly what they get.