Dynamic Rendering

Dynamic rendering is a technique where a website detects search engine crawlers and serves them a pre-rendered, static HTML version of a page, while human visitors get the normal JavaScript-powered version. Google once suggested it for JavaScript-heavy sites but now describes it as a workaround, not a long-term solution.

Written by Paul Hoda, SEO consultant since 2005. Last updated 8 November 2026.

How dynamic rendering works

  1. A request arrives at the server.
  2. The server checks the user agent to see whether it is a known bot, such as Googlebot or Bingbot.
  3. If it is a bot, the request goes to a rendering service, often a headless browser such as Puppeteer or a commercial pre-rendering tool, which runs the JavaScript and returns finished HTML.
  4. If it is a human, the normal client-side rendering version is served.

Pre-rendered pages are usually cached, so the service does not have to render every page on every bot request.

Why it was used

Some years ago, search engines handled JavaScript poorly. Sites built as single page applications often had content that crawlers could not see. Dynamic rendering gave bots a readable version without rebuilding the site. Google publicly documented it as an option for this situation.

Google’s current position

Google’s documentation now says dynamic rendering is a workaround and not a recommended solution, because it creates extra complexity and resource demands. Google instead recommends server-side rendering, static rendering or hydration, which serve the same complete HTML to everyone.

Google has also said that dynamic rendering is not considered cloaking, as long as the content bots receive is similar to what users see. Serving bots completely different content would be cloaking and would break Google’s spam policies.

Problems with dynamic rendering

  • Two versions to maintain: bugs can appear in one version and not the other, and they are easy to miss because humans never see the bot version.
  • Bot detection gaps: new or less common crawlers, including many AI crawlers, may not be recognised and receive the empty JavaScript shell.
  • Stale caches: bots may be served out-of-date prices, stock or content.
  • Performance and cost: rendering services add infrastructure and can slow responses to crawlers, which may affect crawl budget on large sites.
  • No user benefit: visitors still get the slower client-side experience.

When it might still be reasonable

Dynamic rendering can be a short-term bridge for a large JavaScript site that cannot move to server rendering yet, for example while a rebuild is planned. If you use it:

  • Keep the bot and user content equivalent.
  • Include all major search engine and AI crawler user agents.
  • Refresh cached snapshots whenever content changes.
  • Test regularly with the URL Inspection tool and a crawler set to a bot user agent.
  • Plan the move to SSR or static generation as the permanent fix.

For most new projects, building with server rendering from the start avoids the need for dynamic rendering entirely. JavaScript SEO covers the full range of options.

Further reading: Google on dynamic rendering.

Key Takeaways

  • Dynamic rendering serves pre-rendered HTML to bots and JavaScript to users.
  • Google now calls it a workaround rather than a recommended solution.
  • It is not cloaking if bots and users get equivalent content.
  • Maintaining two versions creates bugs, stale content and missed crawlers.
  • Server-side rendering or static generation is the better long-term fix.

Related Terms

Not sure how your own site measures up? Request a free SEO review, or keep learning in the SEO Encyclopedia.