SSR vs CSR vs ISR: how rendering impacts SEO

Google can render JavaScript. This has been true since 2019, when Googlebot upgraded to an evergreen Chromium-based renderer. It is also largely irrelevant to the rendering strategy decision, because "can render" and "will render quickly and completely every time it crawls" are different statements. The rendering strategy you choose determines not whether Google can see your content, but how reliably, how quickly, and with what edge cases it sees your content.

If you're building on a modern framework — Next.js 14+, Astro, Remix, or any framework that offers rendering strategy choices — the SEO implications of that choice deserve the same attention as the UX implications. This guide covers each rendering mode, what Google actually encounters in each, and the decision framework for choosing between them. For the broader headless CMS context, the Headless CMS SEO guide covers how rendering fits into the larger picture.

The four rendering modes, defined

Rendering strategy conversations suffer from imprecise terminology. Here are the precise definitions as they apply to what search engines encounter.

Server-side rendering (SSR)

The server generates complete HTML on every request. The browser (or crawler) receives a fully-rendered document. JavaScript then "hydrates" the page, attaching event listeners and making it interactive. The critical SEO fact: the HTML in the initial response contains all content. No JavaScript execution is required to see it.

What Google sees: Complete content on first request. No rendering delay. No execution dependency. This is the most reliable rendering mode for SEO.

The cost: Every request hits the server. No CDN caching of HTML (unless you add a caching layer). Higher Time to First Byte (TTFB) than static files because the server must render the page before responding.

Client-side rendering (CSR)

The server sends a minimal HTML shell — typically a <div id="root"></div> and a bundle of JavaScript. The browser downloads and executes the JavaScript, which generates the page content in the DOM. The initial HTML response contains no meaningful content.

What Google sees: Googlebot receives the minimal HTML shell. It then queues the page for rendering, which happens in a separate rendering phase using a headless Chromium instance. This rendering may happen seconds, hours, or days after the initial crawl. When it does render, Googlebot typically sees the same content a user sees — but the delay and the dependency on JavaScript execution introduce failure modes.

The cost for SEO: Delayed indexation (content isn't visible until the render phase completes). Risk of incomplete rendering if JavaScript errors occur, if external API calls fail, or if the rendering budget is exhausted. Client-side rendered content that loads behind user interactions (click to expand, infinite scroll, tab navigation) may never be rendered by Googlebot because it doesn't interact with pages the way users do.

Incremental Static Regeneration (ISR)

Pages are generated at build time as static HTML. After deployment, pages are re-rendered in the background on a configurable schedule or on-demand via webhook triggers. Visitors always receive the cached static version while re-rendering happens asynchronously.

What Google sees: Static HTML with complete content — identical to SSG from the crawler's perspective. The content might be up to one revalidation interval out of date. For a 60-second revalidation interval, the maximum staleness is 60 seconds — effectively real-time. For a 24-hour interval, Googlebot might see yesterday's content.

The cost: Complexity. The revalidation logic adds a moving part that can fail. If revalidation errors silently (the background re-render fails but the stale cache remains), the page serves progressively more outdated content without any visible error. The Jamstack SEO best practices guide covers ISR failure modes in detail.

Streaming SSR (the fourth option)

React Server Components and streaming SSR (available in Next.js 14+ App Router, Remix, and React 19+) represent a rendering mode that most SEO guides don't address because it doesn't fit neatly into the SSR/CSR/ISR taxonomy.

How it works: The server starts sending HTML immediately — beginning with the static shell and streaming additional content as each component resolves. A Suspense boundary shows a fallback (a loading spinner or skeleton) until the component's data is ready, then the fallback is replaced with the actual content via a script injection.

What Google sees: This is the nuanced part. Google's renderer processes the streamed response and sees the final content — not the loading fallbacks. But there are edge cases. If a Suspense boundary never resolves (because the data fetch times out on the server), the fallback remains in the HTML. If the fallback is a loading spinner with no text content, Google sees a loading spinner where content should be.

When to use it: Streaming SSR is excellent for pages with mixed data requirements — a product page where the product details render immediately but reviews load asynchronously. The SEO risk is limited to the content inside Suspense boundaries. Keep critical SEO content (title, description, H1, primary body content) outside Suspense boundaries.

What Google actually does with each mode

The theoretical differences above are less important than the practical question: what does Google's indexing pipeline actually do?

The two-phase crawling model

Google's indexing pipeline has two phases, as documented in their JavaScript SEO guide:

1. Crawl phase: Googlebot fetches the URL and receives the initial HTML response. For SSR and ISR pages, this HTML contains all content. For CSR pages, this HTML is the empty shell.

2. Render phase: For pages that need JavaScript rendering, Googlebot queues them for processing by the Web Rendering Service (WRS), which runs a headless Chromium. The render phase is resource-constrained — Google processes billions of pages and prioritizes rendering based on page importance.

The practical impact: SSR and ISR pages are indexed based on the crawl phase alone. CSR pages must wait for the render phase. The render phase introduces latency (seconds to days), resource constraints (not all pages get rendered), and execution dependencies (JavaScript must succeed).

The rendering gap

The interval between crawl and render for CSR pages is the "rendering gap." During this gap, the page is in Google's index but with incomplete or no content. Google may:

• Show the page in search results with a missing or default meta description
• Rank the page based on the HTML shell content (which is essentially nothing)
• Not show the page at all until rendering completes

For new pages on low-authority sites, the rendering gap can extend to days or weeks. For established pages on high-authority sites, rendering typically happens within hours. This is why CSR is particularly punishing for new sites — the headless CMS SEO audit guide covers how to detect rendering gaps.

The decision framework

Choosing a rendering strategy for SEO isn't about picking the "best" option. It's about matching the strategy to the page's content characteristics.

The framework-agnostic rule

If a page should appear in search results, its primary content should be in the initial HTML response. This is the one rule that applies regardless of framework, rendering mode, or architecture. SSR, SSG, and ISR all satisfy this rule by default. CSR violates it by default. Streaming SSR satisfies it for content outside Suspense boundaries.

Common mistakes

Using CSR for public content pages. Single-page applications (SPAs) that render everything client-side are the most common rendering-related SEO failure. This was excusable in 2018 when framework options were limited. In 2026, every major framework offers SSR or SSG. Using CSR for pages that should rank in search is a choice, not a constraint — and it's the wrong choice.

Assuming ISR pages are always fresh. ISR serves cached content until revalidation completes. If revalidation fails silently, the cached version can be days or weeks old. Monitor your revalidation logs. If you're using on-demand revalidation via webhooks, monitor webhook delivery reliability.

Mixing rendering strategies without a clear policy. Hybrid rendering (different strategies for different pages) is powerful but requires documentation. When a team of five developers can set rendering mode per route, and there's no policy documenting which mode to use when, you end up with a site where some pages are SSR, some are CSR, some are ISR with different intervals, and nobody knows which is which. Audit the rendered output — not the code — to see what Google actually encounters.

Ignoring hydration mismatches. When SSR content and the hydrated client content differ — because data changed between server render and client render, or because the server and client environments produce different output — React logs a hydration mismatch warning. These warnings are also SEO signals: Google's WRS may see different content depending on when it renders the page. Fix hydration mismatches; they're not just DX issues.

How to audit your rendering strategy

You can audit rendering strategy without reading the source code. The process is mechanical:

1. Fetch the page with JavaScript disabled. Use curl or a browser with JavaScript off. If the content is visible, the page is SSR or SSG. If you see an empty shell or loading spinner, the page is CSR.

2. Fetch the page with JavaScript enabled. Use a headless browser (Puppeteer, Playwright) or Google's URL Inspection tool in Search Console. Compare the rendered DOM against the initial HTML. Content that appears only after JavaScript execution is client-rendered.

3. Check response headers. x-nextjs-cache: HIT indicates an ISR page served from cache. x-vercel-cache: STALE indicates a revalidation is in progress. These headers (which vary by framework and hosting platform) tell you whether you're looking at static, ISR-cached, or dynamically rendered content.

4. Compare crawl data with rendered data. In Evergreen, the content audit table shows the content as the crawler sees it. If the crawler sees different metadata or content than what appears in the browser, there's a rendering strategy issue.

The JavaScript rendering audit checklist covers this process in full detail. The Next.js SEO audit checklist covers framework-specific rendering configuration.

FAQ

Does Google penalize client-side rendering?

No. Google doesn't penalize any rendering strategy. But CSR pages face structural disadvantages: delayed indexation, execution dependency, and incomplete rendering risk. These aren't penalties — they're consequences of the rendering model.

Is ISR always better than SSR for SEO?

Not always. ISR serves cached (potentially stale) content, which is a problem for time-sensitive pages. SSR guarantees fresh content on every request but adds server load and TTFB. For content that changes less than daily, ISR is typically better. For content that changes per-request (search results pages, real-time data), SSR is correct.

Do React Server Components affect SEO?

React Server Components themselves are server-rendered and produce HTML in the initial response — they're SEO-positive. The risk is in Suspense boundaries: if critical content is wrapped in Suspense with a loading fallback, Google might see the fallback instead of the content if the server-side data fetch times out.

How Evergreen surfaces rendering issues

The content audit table in Evergreen captures the initial HTML response for every page — the same response Googlebot receives in the crawl phase. If a page's content audit shows missing titles, empty H1s, or thin content, but the page looks fine in a browser, you have a rendering gap.

Combining the crawl data with Lighthouse performance scores reveals a second pattern: pages with good content but poor TTFB are likely SSR pages with slow data fetches. Pages with great TTFB but missing content are likely CSR pages with JavaScript-dependent content.

See your rendering modes in one view. Start free →

Related resources

• Headless CMS SEO: the complete guide — the parent pillar for rendering strategy context
• Jamstack SEO best practices for 2026 — SSG-specific rendering patterns
• JavaScript rendering audit checklist — the full rendering audit process
• Next.js SEO audit checklist — Next.js-specific rendering configuration
• Headless CMS SEO audit — auditing rendered output across CMS platforms