Dynamic Rendering

Written by Cobus van der Westhuizen, reviewed by Wynand van der Westhuizen, fact-checked by Lenata Oosthuizen. Last reviewed July 2026. Editorial policy.

What Is Dynamic Rendering?

Dynamic rendering sits between server-side rendering and client-side rendering as a pragmatic middle ground. It works by inspecting the user-agent of each incoming request.

When the request comes from a known search engine crawler such as Googlebot, Bingbot, or a social media bot, the server responds with a pre-rendered, fully formed HTML snapshot of the page.

When the request comes from a regular browser, the server responds with the normal JavaScript bundle that builds the page client-side.

This technique is useful when a website has been built primarily as a client-side application using a framework like React or Angular and is experiencing indexing issues.

Rather than rebuilding the entire architecture, the development team can add a rendering service, such as Puppeteer, Rendertron, or a commercial pre-rendering provider, and configure the server to route crawler traffic through it.

The crawler sees a complete HTML document and indexes it without delay, while human users continue to experience the rich JavaScript application they are accustomed to.

Google has officially endorsed dynamic rendering as a workaround for JavaScript SEO challenges. It documented the approach in its developer guidelines and noted that it is a reasonable solution for complex JavaScript applications where full server-side rendering would require substantial engineering effort.

Importantly, dynamic rendering is not cloaking. Cloaking involves serving fundamentally different content to crawlers and users to deceive search engines. Dynamic rendering serves the same content in two different technical formats, which Google explicitly allows.

The trade-off is maintenance overhead. You need to keep the pre-rendered snapshots in sync with the live content. If your site updates frequently and the rendering service caches snapshots for too long, crawlers may index outdated content.

Many pre-rendering services allow you to configure cache expiry per URL pattern or invalidate snapshots when content is published, which mitigates this risk for SEO-critical pages.

Dynamic Rendering In Practice

A South African comparison website for motor insurance built its frontend as a single-page Angular application for a fast, interactive quoting experience.

When the team audited their coverage in Google Search Console, they found that many informational pages, including car insurance guides and FAQ articles, were either not indexed or had been indexed with missing content.

The JavaScript was not being executed by Googlebot before indexing, so Google only saw the bare HTML shell.

Rather than migrating to a different framework, the team set up a dynamic rendering pipeline using a self-hosted Rendertron instance. Crawler traffic is now routed to Rendertron, which executes the JavaScript and returns fully rendered HTML.

Human traffic bypasses Rendertron and receives the standard Angular bundle. Within two months, Google Search Console showed the previously missing pages appearing as correctly indexed with full content. Organic impressions for the informational content increased noticeably.

For any Johannesburg or Cape Town-based business operating a JavaScript-heavy site that struggles with indexing, dynamic rendering is a faster path to recovery than a full architectural rebuild.

What dynamic rendering is

Dynamic rendering is a technique where a website serves different versions of a page depending on who is requesting it: a pre-rendered, fully-built HTML version to search engine crawlers (and other bots), and the normal client-side JavaScript version to human users. It was devised as a workaround for the SEO challenges of JavaScript-heavy sites: because crawlers can struggle with, or be slow at, rendering JavaScript to see content, dynamic rendering detects a crawler and serves it a version with the content already rendered into HTML (via a pre-rendering service), ensuring the crawler sees the full content without having to execute the JavaScript itself, while human users get the interactive JavaScript experience. The aim is to make JavaScript-dependent content reliably visible to search engines that might otherwise render it poorly or slowly, addressing render-budget and JavaScript-indexing concerns. Importantly, dynamic rendering serves different content to bots and users for the legitimate purpose of helping crawlers see the same content users get, which distinguishes it from cloaking (serving deceptively different content to manipulate rankings). Understanding dynamic rendering matters because it was a recognised solution for JavaScript-SEO problems, but also because Google's guidance has shifted: Google now generally regards dynamic rendering as a workaround rather than a recommended long-term solution, preferring server-side rendering or static generation, so knowing what dynamic rendering is, and where it stands, helps a business make sound decisions about rendering strategy for a JavaScript-heavy site.

Dynamic rendering, cloaking and alternatives

Two questions commonly arise about dynamic rendering: whether it counts as cloaking, and whether to use it versus other approaches. On cloaking: dynamic rendering is not cloaking when done properly, because the intent and effect are to serve crawlers the same content that users see, just pre-rendered so the crawler can read it reliably, whereas cloaking deceptively serves crawlers different content from users to manipulate rankings, which violates Google's guidelines. The distinguishing line is deception, dynamic rendering aims to give crawlers an accurate, equivalent view of the content, so provided the pre-rendered version genuinely matches what users get, it is a legitimate technique and not cloaking; serving crawlers materially different or misleading content, however, would cross into cloaking and breach guidelines. On alternatives: Google's current guidance treats dynamic rendering as a workaround rather than a recommended long-term solution, and generally favours server-side rendering (SSR) or static generation, where the server delivers rendered HTML to everyone (users and crawlers alike), avoiding the need to serve different versions at all and eliminating the maintenance and risk of a separate pre-rendering path. So for a site with JavaScript-SEO challenges, the preferred solutions today are usually SSR or static/pre-rendering that serves rendered HTML universally, with dynamic rendering considered more of a legacy or interim measure. For a South African business with a JavaScript-heavy site facing indexing concerns, the sound approach is generally to make important content available in rendered HTML through server-side or static rendering, which serves users and crawlers the same rendered content cleanly, rather than adopting dynamic rendering as a long-term fix; where dynamic rendering is already in use, ensuring the crawler version genuinely matches the user version keeps it legitimate. The key points are that dynamic rendering, done honestly, is not cloaking, but that current best practice favours SSR or static rendering over it as the durable solution.

FAQ