Is it really time to move on from dynamic rendering for SEO?

Why is Google changing its stance on dynamic rendering?

Dynamic rendering involved serving two versions of a page: a static HTML version for bots and a JavaScript version for real users. Google had presented it as a transitional solution when SSR (server-side rendering) was technically complex to deploy.

But Martin Splitt is firm: it was only a temporary patch. Rendertron, Google's in-house tool for implementing this technique, remains maintained but is no longer actively recommended. The reason? Modern bots, including Googlebot, execute JavaScript efficiently — so the issue lies not with the bot but with the site's architecture.

What does this mean for a JavaScript site?

If your site relies on a heavy JS framework (React, Vue, Angular) and you notice indexing issues, dynamic rendering will only mask the symptom. The real problem? Your JavaScript code is likely blocking the initial rendering, generating errors, or loading critical resources too late.

What holds back Googlebot also holds back your users — degraded loading times, invisible content for several seconds, catastrophic Core Web Vitals. Dynamic rendering creates a divergence between what the bot sees and what the user experiences, which could even verge on unintentional cloaking.

What alternative should be prioritized now?

Google clearly pushes towards server-side rendering (SSR) or hybrid rendering (static site generation + client-side JS hydration). Next.js, Nuxt.js, SvelteKit — modern frameworks make SSR much more accessible than it was five years ago.

The idea: send pre-rendered HTML on the first load, then let JavaScript enrich the client-side experience. Result: Googlebot indexes immediately, users see content instantly, and Core Web Vitals improve mechanically.

• Dynamic rendering is no longer a recommended solution by Google — it's an outdated workaround.
• Rendertron remains maintained but only for legacy compatibility, not for new projects.
• If Googlebot struggles with your JS, your users do too — the issue lies on the front-end, not with the bot.
• SSR or hybrid rendering are the architectures to favor for a modern JavaScript site that is SEO-friendly.
• Unintentional cloaking becomes a real risk if the bot/user versions diverge too much with dynamic rendering.

Is this statement consistent with observed practices in the field?

Absolutely. Since Googlebot moved to evergreen rendering (Chromium 109 at the time of this analysis), instances where dynamic rendering provided measurable gains have evaporated. The audits I conduct on React or Vue sites show that indexing issues rarely stem from the bot itself but from JavaScript errors on the client side — blocking dependencies, slow APIs, failed hydration.

Dynamic rendering masks these issues by serving clean HTML to the bot, but users still suffer from a catastrophic First Contentful Paint (FCP). Google Search Console increasingly raises alerts about "Unindexed content" even on sites using Rendertron, evidence that the technique is no longer reliable.

What nuances should be added to this recommendation?

There are still borderline cases where dynamic rendering may make temporary sense — typically a legacy AngularJS site that cannot be remodeled immediately. But even there, it should be seen as a maximum six-month palliative, not a sustainable architecture.

Beware of the risk of unintentional cloaking as well. If the version served to the bot differs too much from the one served to users (missing content, divergent HTML structure), Google may consider that an attempt at manipulation. [To be verified]: Google has never published a specific threshold defining when a discrepancy leads to cloaking — it’s case-by-case and remains opaque.

In what cases does this rule not apply?

If your site generates 100% server-side content (classic PHP, Ruby on Rails, Django without SPA), this statement does not concern you. Dynamic rendering never made sense for these architectures.

The same goes for sites using static site generation (Gatsby, Hugo, Eleventy) where each page is pre-generated in HTML at build time: zero indexing issues, zero need for workarounds. In fact, that’s one of the reasons why JAMstack exploded in SEO — it solves the problem at the source.

What should you concretely do if your site uses dynamic rendering?

First step: audit the indexing coverage in Google Search Console. Compare discovered, crawled, and indexed pages. If you notice a significant gap, dynamic rendering no longer compensates for your JS's weaknesses.

Next, test the user-side rendering with Lighthouse and WebPageTest. If the FCP exceeds 2.5 seconds or the LCP drags beyond 4 seconds, the problem is not just SEO — it’s UX. Fixing the JavaScript code becomes a priority, not just installing a workaround.

What mistakes should be avoided when migrating to SSR?

Do not abruptly switch the entire site to SSR without testing the impact on server performance. Server-side rendering consumes more CPU resources — if your infrastructure isn’t sized appropriately, you risk degraded response times and a catastrophic TTFB (Time to First Byte).

Another classic trap: forgetting to manage JavaScript hydration on the client side. A poorly configured SSR site can quickly send HTML, then remain inert for several seconds while React or Vue hydrates the DOM. Result: an exploding FID (First Input Delay) and a frustrating user experience.

How can you verify that your new architecture is SEO-friendly?

Use the URL inspection tool in Search Console to compare raw HTML and final rendering. If they are nearly identical, you are on the right track. If Googlebot has to execute tons of JavaScript to display critical content, the problem persists.

Test also in mobile mode with network throttling (slow 3G). If content displays in less than 3 seconds, your SSR works. If it drags, JavaScript is still blocking the initial rendering — back to square one.

• Audit Google Search Console to identify unindexed pages despite dynamic rendering
• Measure FCP, LCP, and TTFB with Lighthouse under real conditions (mobile, 3G)
• Compare raw HTML and final rendering using the URL inspection tool
• Provision server infrastructure to support SSR without degrading TTFB
• Test JavaScript hydration to avoid FID delays on the client side
• Plan a gradual migration (by site section) rather than a big bang