← Back to blog

Technical SEO · July 12, 2026 · 8 min read

Server-Side Rendering vs Static Generation for SEO: A Next.js Decision Guide

Compare SSR vs static generation SEO trade-offs in Next.js — crawlability, Core Web Vitals, and when to use SSG, ISR, or SSR for rankings.

By FluxWriter Team

Choosing the right rendering strategy is one of the most consequential decisions you make when building a Next.js site — and getting SSR vs static generation SEO wrong can cost you rankings before you write a single word of content. Google's crawler has improved over the years, but rendering mode still directly affects crawl budget, Core Web Vitals, and how quickly new content gets indexed.

What's Actually at Stake for SEO

Search engines care about two things during rendering: can they see your content, and how fast does it load? Rendering strategy controls both. The three main options in Next.js — Server-Side Rendering (SSR), Static Site Generation (SSG), and Incremental Static Regeneration (ISR) — make different trade-offs on those axes, and the right choice depends on your content's update frequency, traffic volume, and infrastructure tolerance.

SSR (Server-Side Rendering)

With SSR, Next.js renders HTML on each request at the server level. Googlebot receives fully formed HTML, which eliminates the JavaScript-rendering delay that tanks so many SPAs in the index.

When SSR wins for SEO:

• Pages with user-specific content that must be fresh on every load (dashboards, authenticated feeds)
• Real-time data where stale HTML would be misleading
• Pages where query-string parameters control the content (faceted search, filters)

The crawl budget problem: Every Googlebot hit triggers a server render. For large sites with thousands of pages, this adds up. Google's crawl budget is finite, and slow server response times reduce how many pages get crawled per day. A server responding in 400ms burns crawl budget faster than one serving pre-built HTML in 30ms.

Core Web Vitals: SSR pages typically have higher Time to First Byte (TTFB) than static pages because rendering happens at request time. Google uses TTFB as a component in Largest Contentful Paint (LCP) calculations. Amazon Web Services data shows that every 100ms of latency reduces sales by 1% — the same logic applies to SEO rankings, where LCP is a direct ranking signal.

SSG (Static Site Generation)

SSG pre-builds every page at deploy time. The CDN serves static HTML instantly, TTFB drops to single-digit milliseconds, and Googlebot sees fully rendered content with no server-side delay.

When SSG wins for SEO:

• Marketing pages, landing pages, and documentation that change infrequently
• Blog content where a rebuild-on-publish workflow is acceptable
• High-traffic pages where CDN caching at the edge gives the best possible LCP

The staleness problem: Once deployed, SSG pages don't update until the next build. If your blog index shows 142 posts but you published three more this morning, Googlebot won't see them until the site rebuilds. For sites publishing dozens of articles daily, waiting on CI pipelines is a real operational cost.

SSG Performance Reality Check

These numbers aren't theoretical — they reflect what teams commonly report when migrating marketing sites from SSR to SSG, and the LCP improvement alone can move pages from "needs improvement" to "good" in Chrome's CrUX data, which feeds directly into Google's ranking signals.

ISR (Incremental Static Regeneration)

ISR is Next.js's attempt to split the difference. Pages are statically generated but revalidate in the background after a configurable interval — revalidate: 3600 means the page rebuilds at most once per hour.

How ISR affects SEO:

The first request after the revalidation window triggers a background rebuild. The visitor (and any crawler hitting at that moment) still gets the cached, potentially stale page. The next request gets the fresh one. This stale-while-revalidate pattern means Googlebot may crawl an outdated version even after new content exists.

For most editorial sites, this is an acceptable trade-off. A one-hour staleness window on a product page rarely causes ranking problems. But for news sites or time-sensitive content, ISR's lag can mean Google indexes the wrong price, the wrong date, or the wrong headline.

On-demand revalidation changes the calculus. Next.js 12.2+ added revalidatePath() and revalidateTag(), letting your CMS webhook trigger an immediate page rebuild on publish. This collapses ISR's main SEO weakness — you get static-file speed with near-real-time freshness.

// pages/api/revalidate.ts
export default async function handler(req, res) {
  if (req.query.secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: 'Invalid token' });
  }
  await res.revalidate(`/blog/${req.query.slug}`);
  return res.json({ revalidated: true });
}

Wire this endpoint into your CMS publish hook and you effectively get SSG performance with SSR freshness.

Crawlability: The Practical Decision Tree

Googlebot handles JavaScript better than it did in 2018, but it still processes JS-rendered content in a second wave that can lag days behind the initial crawl. Any rendering strategy that relies on client-side JavaScript to populate your <title>, <meta name="description">, or <h1> tags is a liability.

SSR, SSG, and ISR all produce HTML-first responses, so they're all preferable to a vanilla client-side React app. The differentiator is speed and freshness, not whether Googlebot can read the content.

Decision shortcuts:

• E-commerce product pages — ISR with on-demand revalidation. Static speed, inventory freshness on demand.
• Blog and editorial — SSG with on-demand revalidation via CMS webhook. Maximum CDN performance.
• Search results pages / faceted filters — SSR. Query parameters drive content; static generation can't enumerate every combination.
• User dashboards — SSR behind auth. Content is user-specific and must be server-rendered anyway.
• Marketing and landing pages — SSG, no exceptions. These pages need the best possible LCP and never change more than once a week.

Core Web Vitals: Rendering Mode's Direct Impact

Google's ranking algorithm incorporates CWV as a tiebreaker signal. The three metrics — LCP, INP (Interaction to Next Paint), and CLS — respond differently to rendering choice.

LCP is most directly tied to TTFB and resource loading order. Static pages served from a CDN edge node near the user have structurally lower LCP than server-rendered pages that travel to an origin server before returning HTML.

INP is primarily a JavaScript execution concern, not a rendering one. Whether you SSR or SSG, if your page hydrates a 500KB JS bundle, INP will suffer. Rendering strategy determines what the browser has to parse on load — SSG doesn't automatically mean less JS.

CLS is layout shift, which is an implementation concern independent of rendering mode. However, SSR pages that render skeleton states before hydration can introduce CLS if the skeleton dimensions don't match the final content.

What Next.js 13+ App Router Changes

The App Router introduced React Server Components (RSC), which blur the SSR/SSG line further. Components marked async fetch their data server-side; the result is streamed to the client. Route segments can be individually cached with export const revalidate.

From an SEO standpoint, RSC-first pages behave like SSR for crawlers but ship less JavaScript to the client — a genuine improvement for INP. The key shift: caching is now per-segment, not per-page, giving you more granular control over which parts of a page are static vs dynamic.

If you're starting a new Next.js project today, the App Router's per-segment caching model makes the old "pick one strategy per page" question less relevant. You can static-cache the shell, SSR the personalized section, and on-demand revalidate the product data — all in one route.

FAQ

Does Googlebot execute JavaScript in Next.js pages? Yes, but not immediately. Googlebot crawls in two waves: it first indexes the raw HTML response, then queues JS rendering for a second pass that may lag by hours or days. Pages where critical content appears only after client-side hydration risk being indexed without that content during the first-wave crawl. SSR, SSG, and ISR all put content in the initial HTML, which is why they're preferable to pure client-side rendering.

Is ISR bad for SEO because of stale content? Not categorically. The default stale-while-revalidate behavior means Googlebot might see content up to revalidate seconds old, which matters more for news sites than for evergreen product pages. The practical fix is on-demand revalidation triggered by your CMS — this eliminates staleness while keeping static-file delivery speeds. For most sites, ISR with on-demand revalidation is the best combined option.

Can I mix SSR and SSG in the same Next.js site? Yes, and you should. The Pages Router lets you use getServerSideProps (SSR) on some routes and getStaticProps (SSG or ISR) on others. The App Router makes this even more granular via per-segment caching. Apply SSR only where freshness or personalization genuinely requires it; everything else should be static.

Takeaway

Pick your rendering strategy based on data freshness requirements and traffic patterns, not developer familiarity. For most editorial and marketing content, SSG with on-demand revalidation gives you the best LCP, the lowest crawl budget overhead, and the simplest deployment story. Reserve SSR for routes where server-fresh data is non-negotiable. If you're writing content at scale, tools like FluxWriter can help you maintain a publishing cadence that makes ISR's revalidation windows and on-demand rebuild hooks genuinely worth configuring properly.

← All posts