Dynamic Rendering

Dynamic Rendering: definition and why it matters

Dynamic rendering means detecting who's requesting a page and serving prerendered static HTML to bots while serving the normal JavaScript app to human users. It was Google's recommended bridge for JavaScript-heavy sites that couldn't be indexed reliably. The honest stakes: Google now calls dynamic rendering a workaround and a last resort, not a long-term solution, and openly steers teams toward server-side rendering instead. If you're choosing an architecture today, don't start here.

It still has a narrow role, buying time for a legacy SPA you can't rebuild this quarter, but treat it as scaffolding you'll remove, not a foundation you'll keep.

How the user-agent switch actually works

The mechanism is user-agent sniffing at the edge or in middleware: crawler requests get routed to a prerenderer (like a headless Chrome service) that returns fully rendered HTML; everyone else gets the live app.

Incoming request
      │
      ▼
Is the User-Agent a known bot? ──── No ──► Serve the normal JS app (CSR)
      │                                     (browser runs the bundle)
     Yes
      │
      ▼
Route to prerenderer (headless Chrome) ──► Serve fully rendered static HTML
      (Googlebot, Bingbot, etc.)           (content already in the markup)

// Simplified Express middleware doing the UA switch
const BOT_UA = /googlebot|bingbot|duckduckbot|slurp|baiduspider|yandex/i;

app.get('*', async (req, res, next) => {
  if (BOT_UA.test(req.get('user-agent') || '')) {
    const html = await prerender(req.originalUrl);  // headless render
    return res.send(html);                          // bot gets static HTML
  }
  return next();                                     // human gets the SPA
});

Serving different HTML to bots and users sounds like cloaking, and the only reason it isn't is that the content must be equivalent. Serve bots different or "better" content and you're in cloaking territory, which is a policy violation. That thin line is one big reason Google backed away from recommending it.

Dynamic rendering vs. the alternatives

Notice that SSR and SSG serve the same HTML to everyone, so there's no cloaking gray area and one code path to maintain. That's the whole argument for skipping dynamic rendering.

How to check if a site is using (or needs) dynamic rendering

1. Compare bot vs. user responses. Fetch the page twice: curl -A "Googlebot" URL and curl -A "Mozilla/5.0" URL. If the bot version has full content and the user version is an empty shell, the site is dynamically rendering.
2. Confirm content equivalence. The two responses must carry the same content. If the bot version has extra keywords or different copy, that's cloaking, fix it immediately.
3. Test with Search Console URL Inspection. View the rendered HTML Google actually got. Confirm it matches what users see.
4. Check the prerenderer's freshness. Prerender caches go stale. Verify bots aren't being served week-old snapshots of changed pages.
5. Plan the exit. If you find dynamic rendering in place, scope the migration to SSR/SSG. It's a bridge, not a destination.

Common mistakes and how to fix them

• Serving bots different content than users. That's cloaking and a policy violation. Fix: guarantee content equivalence, or move to SSR where the question disappears.
• Treating dynamic rendering as permanent. Google positions it as a stopgap. Fix: schedule the SSR/SSG migration and sunset the bot path.
• Stale prerender cache. Bots index outdated pages. Fix: invalidate snapshots on content change and cap cache age.
• Incomplete bot list. Missing AI crawlers or Bingbot means those bots get the empty shell. Fix: prefer a rendering approach that doesn't depend on maintaining a UA allowlist at all.
• Prerenderer timeouts dropping content. Slow renders return partial HTML. Fix: monitor render success; but really, this fragility is why SSR wins.

FAQ

Is dynamic rendering still recommended?

No. Google now describes it as a workaround and a last resort, and recommends server-side rendering or static generation instead. It still works as a temporary bridge, but it's not the approach to design around today. Our JavaScript rendering diagnosis guide covers when a stopgap is defensible.

Is dynamic rendering considered cloaking?

Not if the content served to bots and users is equivalent. It crosses into cloaking the moment you serve bots different, keyword-stuffed, or "optimized" content. That risk is inherent to the two-path design and is a strong reason to prefer SSR.

What should I use instead of dynamic rendering?

Server-side rendering (per request) or static site generation (at build time). Both serve the same content-filled HTML to everyone, eliminate the cloaking gray area, and mean one code path. See server-side vs client-side rendering for SEO.

When is dynamic rendering still acceptable?

As a short-term bridge for a legacy JavaScript app you genuinely can't re-architect yet, while you plan a migration. Treat it as scaffolding with a removal date, not a permanent fixture. Our prerendering as a stopgap piece frames the exit strategy.

Do AI crawlers work with dynamic rendering?

Only if you've added their user agents to your bot list, and that list is a maintenance treadmill as new AI crawlers appear. A rendering approach that serves everyone real HTML sidesteps the problem entirely, which is another point for SSR.