Is client-side routing really compatible with Google indexing?

What is client-side routing and why is Google talking about it?

Client-side routing refers to navigation within a web application without a full page refresh. Modern frameworks like React, Vue, or Angular load an initial HTML shell and then use JavaScript to dynamically update the content displayed based on the visited URL.

This approach historically posed an SEO challenge: Googlebot must execute JavaScript to discover the actual content. For years, the community has wondered about Google's ability to crawl these architectures — and about the indexing delays caused by JavaScript rendering.

Martin Splitt's statement clarifies the official position: yes, it is supported. But “supported” does not mean “without risk.” The nuance lies in “verifying that the content is correctly visible.”

What do “isomorphic pages” and “rehydration” mean?

Isomorphic applications (or universal) use the same JavaScript code on both the server-side and client-side. The server generates a complete HTML on the first load (Server-Side Rendering, SSR), and then the browser “rehydrates” this structure by attaching JavaScript event handlers.

This architecture offers the best of both worlds: immediately crawlable HTML for Googlebot and a smooth user experience without full reloads. Next.js, Nuxt.js, or SvelteKit implement this pattern by default.

However, rehydration can introduce bugs if the server content differs from the client content. Google sees the server HTML first, then potentially a different JavaScript rendering — creating a discrepancy that Googlebot might interpret as unintentional cloaking.

Why does Google insist on testing tools?

Because JavaScript rendering remains a two-step process for Google: first crawl the initial HTML, then queue for rendering. This delay can range from a few seconds to several days depending on the site's crawl budget.

Tools like the URL Inspection Tool in Search Console or the mobile-friendly test allow you to see exactly what Googlebot sees after JavaScript execution. This is the only reliable way to detect issues with missing content, invisible links, or improperly injected meta tags.

• Supported client-side routing: Googlebot executes JavaScript and can navigate between SPA views
• SSR and rehydration compatible: Google indexes the initial HTML content and updates it after JS execution if needed
• Mandatory verification: Implementation bugs (faulty lazy loading, blocked navigation) go unnoticed without explicit testing
• Variable rendering delay: JavaScript content can be indexed with several days of latency on low crawl budget sites
• Insufficient server logs: A successful crawl in logs does not guarantee that JavaScript rendering extracted the visible content

Is this claim aligned with field observations?

Yes and no. Google can technically crawl client-side routing — this has been documented since the adoption of Chromium for rendering. But “can” does not mean “always indexes correctly.”

In practice, poorly configured SPAs suffer from recurring indexing issues: orphan pages that are never discovered, dynamic content not indexed, poorly defined canonical URLs. Client-side routing works… when all conditions are met. A single weak link (overly aggressive lazy loading, JS timeout, broken simulated navigation) and indexing fails silently.

What nuances is Google omitting in this statement?

Google does not specify the performance constraints that directly impact crawling. If JavaScript rendering consumes too many resources (CPU time, memory), Googlebot may give up before the content becomes visible. [To be verified]: what is Googlebot's exact tolerance for rendering that exceeds 5 seconds?

Another gray area: dynamically generated links by JavaScript. Google claims it can follow them, but many tests show that links that appear after user interaction (infinite scroll, onclick) remain invisible to Googlebot. The announced “compatibility” thus depends on the implementation pattern — and Google does not provide a comprehensive list.

In what cases does this rule not fully apply?

Sites with constrained crawl budgets (millions of pages, low authority) will see their JavaScript content indexed with sometimes prohibitive delays. Google prioritizes static HTML crawling — JS rendering comes second.

Poorly configured hybrid architectures — a mix of SSR and CSR without consistency — create conflicting signals. If the server HTML displays content A and the JS replaces it with content B, Google may index A, B, or neither based on the crawl timing. Let's be honest: this statement does not cover these edge cases, which are often frequent in production.

What concrete actions should be taken to secure indexing?

The first step: systematically test each key template with the Search Console URL Inspection Tool. Compare the raw HTML (under the “More Info > View Crawled Page” tab) with the final rendering. Any discrepancy indicates a potential issue.

Next, implement continuous monitoring of JavaScript rendering. Tools like Oncrawl or Botify allow you to crawl your site as Googlebot would, executing JS. If a page becomes orphaned in a JS-enabled crawl, it's an alert signal.

Prefer as much as possible Server-Side Rendering or static site generation (SSG) for critical content. Client-side routing can handle secondary navigation, but SEO landing pages must serve complete HTML from the server response. This is the only way to ensure fast and reliable indexing.

What implementation errors block indexing?

The most common mistake: meta title/description tags injected only on the client side. Google crawls the initial HTML before JS — if these tags are missing initially, they may never be indexed even if JS adds them later.

Another classic pitfall: navigation links generated by JavaScript events (onclick without a real href). Googlebot does not click — it analyzes the DOM. A link without a valid href attribute remains invisible, regardless of the announced JS compatibility.

Excessive lazy loading is also a problem. If critical content appears only after a simulated scroll that Googlebot does not execute, it will never be crawled. The directive loading="lazy" on above-the-fold images delays the complete rendering unnecessarily.

How can I check that my site meets Google’s requirements?

Use the mobile-friendly test (formerly Mobile-Friendly Test) which shows the final JavaScript rendering and lists blocked resources. Complete with the structured data testing tool to verify that your JSON-LD is well injected and parseable.

Analyze your server logs to identify URLs crawled by Googlebot, then cross-reference with the pages actually indexed in Search Console. A significant disparity indicates a problem with rendering or insufficient content post-JS.

Implement a staging test plan before every major deployment: full JS-enabled crawl, comparison of DOM HTML vs. JS, verification of Core Web Vitals (JS rendering directly impacts LCP and CLS). These optimizations can be complex to orchestrate alone — working with an SEO agency specialized in modern JavaScript architectures can accelerate compliance while avoiding costly implementation pitfalls that hurt organic traffic.

• Test each critical template with the Search Console URL Inspection Tool
• Ensure that title, meta description, and H1 are present in the initial HTML (before JS)
• Make sure all navigation links have a valid href attribute
• Avoid lazy loading on above-the-fold content
• Implement SSR or SSG for high-stakes SEO pages
• Monitor discrepancies between crawled pages and indexed pages