JavaScript SEO in 2026: Rendering, Crawling, and the RSC Era

When Googlebot encounters a page, it does two passes. The first pass crawls the raw HTML — fast, immediate. The second pass renders the JavaScript and re-indexes — delayed, sometimes by days or weeks, sometimes never if the rendering queue is backed up or the page fails to render. Pages that depend on client-side JavaScript to render their primary content sit in 'rendered but not indexed' purgatory until the second pass completes.

The practical implication: any content that needs to rank (titles, descriptions, body copy, internal links, structured data) should be present in the initial HTML, not injected by client-side JavaScript. The first-wave HTML is what gets indexed quickly; the second-wave rendered content is what eventually catches up — sometimes. Sites depending on client-side rendering for indexable content consistently see indexation delays of 7–60 days versus equivalent server-rendered sites.

Bingbot's JavaScript rendering capability is meaningfully behind Googlebot's — it renders JavaScript on a smaller subset of pages, with a slower queue and a higher failure rate. The various AI assistant retrieval bots (ChatGPT's web crawler, Perplexity's, Claude's web access, Google AI Mode's retrieval) are even more variable. Some render JavaScript reliably; some don't render it at all and rely on the initial HTML.

The structural consequence: a site that depends on client-side rendering for its content might be indexable by Google after the second-wave delay, but invisible to Bing, weakly cited by AI assistants, and missing from DuckDuckGo entirely. Server-side rendering or static generation is the only rendering strategy that produces consistent indexation across the full crawler ecosystem in 2026.

Four rendering strategies dominate modern frameworks. The right choice depends on content freshness requirements and traffic patterns.

• Server-side rendering (SSR): the page is rendered to HTML on the server for every request. Fresh content, full crawler compatibility, but higher server cost and slower TTFB than static. Right choice for personalised, frequently-updated, or auth-gated content.
• Static site generation (SSG): the page is rendered to HTML at build time and served as a static file. Fastest TTFB, lowest server cost, fully crawlable. Right choice for marketing pages, blog posts, documentation — anything that doesn't need to be personalised per request.
• Incremental static regeneration (ISR): SSG pages that revalidate on a schedule or on-demand. Combines static performance with content freshness. Right choice for high-traffic content that needs occasional updates (e-commerce category pages, news archives).
• Client-side rendering (CSR): page shell loads first, JavaScript fetches and renders content. Fast initial load of the shell, but indexable content depends on JavaScript execution. Right choice for application UI behind authentication where SEO doesn't matter.

Next.js's App Router (introduced in 13.4, mature by 14.x and now the default) uses React Server Components (RSC) by default — components render on the server, send their HTML output to the client, and only opt into client-side rendering when explicitly marked with 'use client'. This produces a default behaviour that's friendly to crawlers: the rendered HTML is in the response, no JavaScript execution required.

Practical implications: server components can fetch data directly without an API round-trip, the rendered HTML includes the fetched content, and the client-side JavaScript bundle is smaller because non-interactive components never ship to the client. For SEO purposes the App Router is consistently a stronger starting point than the Pages Router. Sites built on the older Pages Router with heavy client-side data fetching often benefit from migrating to the App Router specifically for the indexation improvements.

Partial Pre-rendering (PPR) — Next.js's 2024–2025 evolution of static generation — combines static and dynamic rendering on the same page. The static shell pre-renders at build time; dynamic components stream in at request time. The result: fast initial response with crawler-friendly static content, plus per-request personalisation where needed.

For SEO this is meaningful because it removes the historical trade-off between crawler-friendly static rendering and per-request dynamic content. Personalised greeting, fresh prices, real-time inventory — all can stream into a page that still serves a fully-rendered static shell to crawlers. Adopting PPR (or the equivalent patterns in other frameworks like Remix and SvelteKit) is one of the higher-ROI technical SEO investments for sites currently using SSR-everywhere.

Across the JavaScript-heavy site audits we run, a small set of failure modes accounts for the vast majority of indexation problems.

• Title tags and meta descriptions injected by client-side JavaScript: present in the rendered DOM but absent from the initial HTML. Google may eventually pick them up after second-wave rendering; Bing and AI crawlers usually never do.
• Internal links rendered as onclick handlers or React Router Link components without proper href attributes: invisible to crawlers, breaking site discoverability.
• Infinite scroll or click-to-load content: content past the initial fold is invisible to crawlers that don't execute JavaScript or don't simulate user interaction. Pagination or 'load more' buttons with crawlable hrefs solve this.
• Soft 404s: client-side error states that return an HTTP 200 with 'Page not found' rendered in the body. Crawlers see 200, index the empty page, and miss the actual error signal.
• Single-page-app routing without proper status codes: a real 404 or 410 should return an HTTP 404 or 410, not a 200 with a JavaScript-rendered error message. Server configuration is the fix.

Three layers of testing catch most JavaScript SEO problems. (1) View Source in the browser to see what's in the initial HTML — anything missing here depends on JavaScript rendering. (2) Google Search Console URL Inspection tool to see what Googlebot actually rendered, with the 'Test Live URL' option to see real-time rendering. (3) Manual testing with curl --user-agent to simulate Bingbot or other crawlers without JavaScript execution — what comes back is what those crawlers see.

The diagnostic question that matters: 'if JavaScript never executed on this page, would my content still be there?' If yes, the page is robustly crawlable. If no, the page is at the mercy of each crawler's JavaScript execution capability — Google often handles it, Bing often doesn't, AI bots are inconsistent, and the indexation profile suffers accordingly.