Dynamic Rendering: What It Fixes on a JavaScript Site (and What It Doesn't)
By Toy Wen Da, Co-Founder · Updated · 7 min read · scored 91/100
Dynamic rendering means your server checks whether a visitor is a browser or a search bot, then sends bots a prerendered, static HTML version of the page while humans get the full JavaScript experience. It fixes sites where Googlebot can't read content that only appears after scripts run, but it won't fix every indexing problem.
Before you touch any server code, check what Googlebot sees on the page in question. The free Googlebot Simulator fetches a URL the way Google's crawler does and shows you the rendered HTML, so within a minute you can tell whether your JavaScript content is missing from what the bot receives.
How it works
Detecting the visitor
Your server, or a CDN layer in front of it, inspects the User-Agent header on every request. When the header matches a known crawler such as Googlebot or Bingbot, or increasingly an AI crawler, the request is routed differently from one sent by a regular browser.
Serving two versions of the same page
Human visitors still get your React, Vue or Angular app with all its interactivity. Bots get a prerendered HTML snapshot generated by a headless browser tool like Puppeteer or Rendertron, or by a third-party service such as Prerender.io, and because the snapshot is static, no scripts need to run for the content to be visible.
Why sites need this in the first place
Googlebot can execute JavaScript, but rendering is resource-intensive and happens on a delay, so pages often get crawled once and re-rendered later, which can stall indexing. Most AI answer engines skip JavaScript execution entirely, so a page that depends on client-side rendering may be invisible to them from the start. A page that never gets indexed earns no visibility and no click-through rate at all, let alone a good one.
Fixing it inside your own site, step by step
- Confirm there's an actual gap by fetching the page as a bot and comparing it to what a normal browser loads. If the content matches, you don't need any of this.
- Decide whether the problem affects one template, a section of the site or everything, since that scope determines how much infrastructure work you're signing up for.
- Add user-agent detection at the server or CDN layer, for example a Cloudflare Worker or an Nginx rule, that checks incoming requests against a maintained bot list.
- Route bot traffic to a prerendering service that generates static HTML for each URL and caches it, so you aren't re-rendering on every bot visit.
- Keep the content equivalent: the prerendered version must match what a human eventually sees, with the same text and links and the same structured data.
- Re-test after launch and again after any front-end deploy, because a UI change can silently break what the prerendering service captures.
- Monitor the setup on an ongoing basis. If the rendering service goes down, bots can start receiving blank pages or errors, which can trigger de-indexing fast.
When your own tools are enough, and when they aren't
Checking a single page is a different job from fixing a whole site's rendering.
| Situation | What you're checking | Right tool | Is the free route enough? |
|---|---|---|---|
| One URL looks fine to you but not in Google's index | What Googlebot sees on that page | Googlebot Simulator | Yes, confirms or rules out a rendering gap in minutes |
| Whole site built on React/Vue/Angular with no server rendering | Site-wide crawlability | A full technical crawl plus a rendering audit | No, this is an infrastructure change, not a one-page check |
| A page's mobile layout seems off alongside the indexing issue | Mobile rendering, viewport, usability | Free Mobile-Friendly Test | Yes, for diagnosing the mobile-specific piece |
| Pages were indexed fine, then dropped after a redesign | Recurring regression, not a one-off | Ongoing monitoring plus a review of the prerendering setup | No, a single check won't catch a problem that recurs after each deploy |
A one-off check on a single URL is exactly what the free tools are built for, whereas a recurring, site-wide pattern points to an infrastructure fix, usually involving a developer and a prerendering service.
Comparing it with the alternatives
| Approach | How it works | Best fit | Maintenance load |
|---|---|---|---|
| Dynamic rendering | Serves static HTML to bots, JS app to humans | JS-heavy sites with crawl budget or AI-visibility problems that can't do a full rewrite yet | High, separate rendering pipeline to maintain |
| Server-Side Rendering (SSR) | Server renders HTML on every request, for everyone | New builds or sites with the resources to rebuild their front end | Moderate, one rendering path for all visitors |
| Static Site Generation (SSG) | HTML is built in advance at deploy time | Content that doesn't change per-request, like blogs or marketing pages | Low, rebuild on content change |
| Client-side rendering (no fix) | Browser builds the page from JavaScript, bots get the same | Internal tools, not public search-facing pages | Low effort, high search risk |
Google's own guidance frames the technique as a stopgap rather than where you want to end up, and SSR or SSG are the more durable fixes once you can afford the rebuild.
Is it considered cloaking?
No, as long as you're doing it in good faith. Google's Search Central documentation states that Googlebot generally doesn't treat it as cloaking, provided the rendered content served to bots is equivalent to what human visitors eventually see. The violation isn't that two versions exist but that bots and humans are shown genuinely different content, such as a keyword-stuffed page about running shoes for crawlers while visitors see a page about something else entirely. Keep the substance the same across both versions and you're on the right side of the rule.
Common mistakes
- Treating it as permanent, when it only papers over a crawlability problem and doesn't remove the eventual need for a more crawlable architecture.
- Letting the prerendering service go stale, so that bots see an outdated or broken version of the page whenever it misses a front-end change.
- Relying on a bot list that has gaps, since user-agent detection only works for bots you've listed and a new AI crawler your rules don't recognize gets the raw JavaScript version, which it likely can't read.
- Skipping re-tests after deploys, even though a front-end release nobody re-checked against the bot-facing version is the most common reason a setup like this quietly breaks.
- Applying it to a site that doesn't need it, because small, mostly static sites rarely have a rendering problem worth this much infrastructure.
FAQ
Does dynamic rendering hurt my rankings?
Not by itself. The risk lies in a misconfigured version that serves stale pages or errors and drifts from what human visitors see.
Is dynamic rendering the same as cloaking?
No. Cloaking means serving substantively different content to bots and humans, while this technique serves the same content in a different format, which search engines explicitly allow.
How do I know if my site even needs dynamic rendering?
Fetch a page as Googlebot and compare it to the browser version. If your main content and links are missing from the bot's view, you have your signal.
What's the long-term alternative to dynamic rendering?
Server-side rendering or static site generation, which serve the same rendered HTML to everyone instead of maintaining two separate paths.
Can small business sites ignore dynamic rendering entirely?
Usually, yes. It mainly matters for large, JavaScript-heavy sites with frequent content changes or crawl budget constraints, not for a typical small site built on standard page templates.
Check your page before you build anything
Don't start building a prerendering pipeline on a hunch. Fetch the page in question, see what Googlebot receives, and invest in the infrastructure only if there's a real gap between what bots and humans see. If you want a second set of eyes on what's holding your indexing back, talk to the team and request a sample SEO report.
Sources
About the author
SearchBlueprint researched, wrote and scored this article with the content pipeline our customers run on their own sites. The score in the byline is what our content engine gave this page before it published. Nothing here is reviewed by hand, which is the point: it is the product's output, published where anyone can check it.