Dynamic Rendering in 2026 — a 1500-word summary
Companion to the May 2026 cross-bot audit
What dynamic rendering is
Dynamic rendering is the practice of detecting a crawler by User-Agent and serving it a server-rendered HTML snapshot of a page, while serving human visitors the client-side JavaScript application. The page that the bot sees is the same page the user will eventually see — but the bot receives it as one complete HTML response, with no JavaScript execution required.
The architecture, in one diagram:
HTTP request
│
▼
crawler detection (User-Agent and/or IP)
│
├── is bot ─────► prerendered HTML snapshot ─► crawler
│ (Puppeteer/Chrome ran it earlier; cached)
│
└── is human ───► client-side SPA bundle ─► browser
(browser runs the JS, hydrates the page)Both branches converge on the same DOM. The distinction is when the JavaScript ran — for bots, on a server in advance; for users, in their own browser at view time.
Where it came from
Google introduced dynamic rendering as a recommended SEO pattern in 2018 at I/O. The motivation: Googlebot at the time used a two-stage indexing pipeline. The HTML crawl happened immediately; the JS rendering happened on a deferred queue that could take days or weeks to clear. Sites with substantial JS — most of the modern web — were indexed slowly and incompletely. Dynamic rendering let webmasters sidestep the second stage by giving Googlebot a pre-cooked HTML response that needed no JS execution.
The same pattern was adopted broadly: Prerender.io (the commercial service), Rendertron (Google's open-source helper), Netlify's prerendering option, Cloudflare's "Always Online", Fastly's snapshot caching, and a long tail of in-house implementations. By 2020 the majority of large JS-heavy sites had some form of dynamic rendering in production.
Why Google deprecated it in 2024
Two shifts pushed dynamic rendering off the recommendation list:
1. Googlebot's renderer evolved. Google's Web Rendering Service moved from a delayed-queue model to near-real-time rendering. The advantage of dynamic rendering — "Google can't render my JS in time" — became weaker. 2. The split-content failure mode became visible. When the bot and user versions of a page drifted — typically because the prerender service's headless browser was running a slightly old build, or because A/B-test logic ran in the SPA but not in the snapshot — search results began to surface content that no longer existed in the live app. Google's spam team formally took the position that "the same content for both" was a stronger recommendation than "the same workaround in place".
The official guidance since 2024 has been: migrate to SSR or SSG. Generate the HTML server-side as part of the application's normal response. Do not maintain a separate snapshot pipeline that can drift.
Why it came back in 2025–2026 under different names
Three things happened that changed the calculus:
AI bots showed up — and they don't render JavaScript
GPTBot, ClaudeBot, PerplexityBot, and the live-retrieval counterparts (ChatGPT-User, Claude-User, Perplexity-User) all crawl HTML without executing JavaScript in their default fleet. Vercel's analysis of 500 million+ AI-bot fetches in 2025 showed zero JS execution by the training crawlers. The live-retrieval bots use headless browsers sometimes, but they treat JS rendering as optional rather than required.
This breaks the Google-2024 assumption that "everyone renders JS now". A site that ships a CSR-only SPA is invisible to AI crawlers regardless of how well-architected its Webpack bundle is. The old dynamic-rendering pattern — "render JS server-side and cache it for crawlers" — is exactly the right solution for AI bots in 2026.
CDN and edge platforms made it cheap
Cloudflare Workers + KV, Fastly Compute@Edge, Akamai EdgeWorkers, and Vercel's edge-prerendering integration all let you run a headless browser (or a pre-rendered output cache) at the edge, keyed to the request URL. The infrastructure cost of "render once, serve to crawlers" dropped to cents per thousand pages. The operational cost of maintaining a separate snapshot service became nominal.
The audit data shows it's widely practiced today
Our May 2026 audit of the top 100 e-commerce sites found five sites serving bot UAs substantially more content than they serve real users — at ratios from 3× (uniqlo) through 5× (coupang, canadiantire) to 7–8× (shopping.yahoo.co.jp) to 30× at amazon.co.uk. The full v1 audit found a 700× ratio at baidu.com. These are not minor implementation details; they are full prerendered HTML versions of pages whose user-facing version is a shell.
How dynamic rendering compares to SSR / SSG / hydration in 2026
| Approach | When HTML is built | What bots see | What users see | Operational cost |
|---|---|---|---|---|
| CSR-only SPA | Never on server | Empty shell + scripts | App after JS runs | Lowest |
| SSR | Per request, server-side | Full HTML | Same full HTML, then hydrate | Highest (per request) |
| SSG | Build time | Static file | Same static file | Lowest (CDN) |
| Hybrid / ISR | First request → cache, revalidate | Cached SSR | Same cached SSR | Medium |
| Dynamic rendering | Background headless browser | Pre-rendered snapshot | Live SPA | Two pipelines |
The trade-off has not changed since 2018: dynamic rendering is the retrofit solution, available to sites that can't migrate quickly to SSR or SSG. The criticism remains the same: it's two pipelines and they can drift. The defense remains the same: it's one weekend of work and you keep the SPA you already have.
When dynamic rendering still makes sense in 2026
Three contexts:
1. You have an existing CSR SPA you cannot migrate quickly. Your team is on a Vue 2 or Angular 1.x app that ships a meaningful product, you have AI-shopping visibility goals this quarter, and you cannot do a Next.js migration in time. Run dynamic rendering for six months. Migrate underneath. 2. You operate multiple customer sites and want one platform-level solution. The PrerenderProxy use case: a small team operates prerendering for ten or twenty external sites. Building SSR into each is impossible; running one edge prerender service is tractable. 3. The site is genuinely too complex to SSR. Real-time collaboration apps, IDE-style interfaces, games. The HTML content you want bots to see is the marketing/catalog metadata; the live app is a different surface. Dynamic rendering at the crawler-facing URL while shipping the app at the app-facing URL is a defensible separation.
When it does not
1. You're starting a new site. Build SSR or SSG from day one. 2. Your bot version is materially different from your user version. Drift will happen and Google will eventually catch it. 3. You're using UA detection alone. Spoofable in seconds. Verify reverse-DNS against vendor-published hostnames.
The audit data, restated
Our 100-site e-commerce audit found:
- 14 sites are doing SSR-for-everyone correctly. They show the same
HTML to every UA. This is the recommended path.
- 5 sites are doing dynamic rendering — the deprecated technique —
with bot UA receiving 3× to 30× more content than the user UA.
- 62 sites have turned on a one-click "block AI bots" WAF rule that
forecloses both the SSR-for-everyone path and the dynamic-rendering path for AI crawlers specifically. These sites are voluntarily invisible to AI-driven shopping.
The 5 dynamic-renderers and the 14 SSR-everyone sites are both doing substantively the same thing — serving a bot-readable HTML response. The 62 WAF-blockers are doing neither.
PrerenderProxy's position
PrerenderProxy is an open custom-built dynamic-rendering layer running at the Fastly edge. It detects crawler UAs, hands them to a Puppeteer rendering service running in Docker, caches the result, and serves the cached HTML to subsequent crawler requests at edge cache hit speeds (0.03s typical). It exists for the first use case above: a site that needs bot visibility today and a migration runway.
The audit shows the broader pattern PrerenderProxy fits into. The question is not "is dynamic rendering OK?" — Google's answer is explicitly "prefer SSR". The question is "given that 60+% of large e-commerce sites are blocking AI bots wholesale and another 5% are still using the deprecated technique, what does the bridge look like for a site that wants AI visibility now and a clean SSR migration next year?". Dynamic rendering, done carefully, is that bridge.
The two non-negotiables:
1. The bot version must be the same content as the user version. No different prices, no different copy, no different products. The bot HTML is the server-rendered output of the same component tree that the user would hydrate. 2. The verification must be reverse-DNS, not UA. UA-only allowlists are spoofable. Every reputable bot publishes the hostnames its requests resolve from; verify against those.
If your stack can honor both rules, dynamic rendering remains a valid 2026 pattern. If it cannot, migrate to SSR — there is no third path that survives an SEO audit.