Dynamic rendering is a set-up in which your server detects whether a request comes from a search engine crawler or a person, and sends crawlers a fully rendered HTML snapshot of the page while people receive the normal JavaScript application. It was introduced as a workaround for sites whose content only appears after JavaScript runs in the browser.
How dynamic rendering works
A site built with client-side rendering sends the browser a nearly empty HTML file plus a bundle of JavaScript, which then fetches and builds the content. Googlebot can run JavaScript, but rendering is resource-heavy and can be delayed, and many other crawlers, including several AI and social media bots, do not run it at all. They see the empty shell.
With dynamic rendering, a rule on the server or CDN checks the user agent. If it matches a known bot, the request is passed to a prerendering service, either a headless browser you host or a commercial service, which loads the page, waits for the JavaScript to finish and returns the resulting HTML. Snapshots are usually cached so the bot gets a fast response. Everyone else gets the JavaScript version as normal.
Why it matters
For a business with a large JavaScript site that cannot be rebuilt quickly, dynamic rendering can be the difference between product or listing pages being indexed and not. A UK property portal or a booking platform built as a single-page app might find that only a fraction of its pages show up in search, and dynamic rendering can get those pages indexed long before a rebuild would be ready.
The catch is that Google’s own documentation describes dynamic rendering as a workaround rather than a recommended long-term solution, and advises server-side rendering, static rendering or hydration instead. It adds a second system that can fail on its own, it increases complexity for every release, and it creates a standing risk that the version bots see drifts away from what users see.
That last point is where it touches spam policy. Serving crawlers different content from users is cloaking. Dynamic rendering is acceptable only because the content is meant to be the same. If the snapshot shows text, links or prices that the live page does not, you have crossed the line, even by accident.
Common mistakes
- Stale snapshots. Cache rules that keep a week-old copy mean bots see old prices, sold-out stock or removed pages.
- Silent failures. When the prerender service times out, some set-ups hand crawlers an empty page, and indexing drops without anyone noticing.
- Incomplete bot lists. Only matching Googlebot leaves Bingbot, AI crawlers and link preview bots seeing the empty shell.
- Missing metadata. Title tags, canonicals and structured data injected late by JavaScript sometimes do not make it into the snapshot.
- Using it on a new build. If you are choosing a framework today, pick one that renders on the server from the start.
How to act on it
First, find out whether you need it. Use URL Inspection in Search Console and view the crawled page’s HTML: if your main content and links are present, Google is rendering the site and dynamic rendering adds little. Fetch the same URL with JavaScript disabled to see what non-rendering bots get.
If content is missing, the better fix is usually server-side rendering or pre-generated static pages, which most modern frameworks support. Where that is months away, dynamic rendering can bridge the gap: set it up, compare bot and user versions on a sample of templates, log prerender errors and plan its removal. Diagnosing this properly is part of technical SEO, and the wider topic is covered under JavaScript SEO.