Three rendering strategies, three sets of trade-offs, three sets of SEO implications. Most posts on this topic are written by people optimizing for one extreme and pretending the others don't exist. Here's the honest version, calibrated for 2026 — what each does, what Googlebot actually sees, and when to pick which.
The three strategies in one paragraph each
SSG — Static Site Generation
Pages are built at build time. HTML files are uploaded to a CDN. Every request returns the same HTML. To update, you rebuild and redeploy.
Fastest possible delivery. Zero compute per request. The catch: stale content until the next deploy.
ISR — Incremental Static Regeneration
SSG plus a TTL. Pages are built at build time, then regenerated on demand when they're older than the TTL. First request after TTL expires triggers the regeneration in the background; the user gets the stale version, the next user gets the fresh one. Best of both worlds, with some staleness window.
SSR — Server-Side Rendering
Pages are built on every request. Always fresh. Slowest delivery. Most compute per request.
CDN caching is possible but ad-hoc.
What Googlebot sees
Identical HTML in all three cases. This is the most important point of the post. SEO purists who claim "SSR is required for SEO" are 5 years out of date — Googlebot doesn't care how the HTML was generated, only that it exists and renders consistently.
The actual SEO trade-offs are about:
- Time to First Byte (TTFB) — affects CWV indirectly
- Content freshness signals (
dateModifiedupdates) - Cache headers and how they interact with Googlebot's crawl behavior
- JavaScript-rendered content (a problem orthogonal to SSR/SSG/ISR — see below)
SSG and SEO
SSG produces the fastest possible TTFB. CDN serves a pre-built HTML file. The TTFB is whatever your CDN's edge latency is — usually 50–150ms.
Where SSG wins for SEO:
- Marketing pages, landing pages, documentation
- Anything with a stable URL and stable content
- Pages where the content doesn't depend on the requester
Where SSG loses for SEO:
- Content that changes frequently — your
dateModifiedonly updates when you redeploy - Sites with hundreds of pages — build time scales linearly
- Personalized content (not SEO content usually, but worth noting)
SEO verdict: Excellent for stable content. The TTFB advantage shows up in CWV scores. The only catch is content freshness — Google rewards updated content, and SSG only updates on deploy.
ISR and SEO
ISR is what Booplex uses for almost every page. revalidate = 3600 means "regenerate hourly if requested." New posts appear within an hour of being published, without a deploy.
Where ISR wins for SEO:
- Blog index pages where new posts should appear
- Listing pages that occasionally reorder or add items
- Pages where 1-hour staleness is fine
- Sites with too many pages for SSG at deploy time
Where ISR loses for SEO:
- The first request after TTL expires gets the stale version. If that request happens to be Googlebot's, Google sees old content. (Negligible at scale, but possible.)
- Cache invalidation is your problem. If a post is edited mid-TTL, the change isn't visible until either the TTL expires or you trigger revalidation manually.
SEO verdict: The sweet spot for content sites. TTFB is SSG-equivalent (CDN edge). Freshness is much better than SSG. Used correctly, ISR is the default choice for blogs in 2026.
SSR and SEO
SSR runs the page render on every request. Always fresh. Slowest TTFB.
Where SSR wins for SEO:
- Pages that genuinely change per request — pricing pages with geo-aware pricing, search result pages, dashboards
- Pages that need request-time auth signals (private pages with public previews)
- Content that depends on real-time data — stock tickers, leaderboards
Where SSR loses for SEO:
- TTFB is much worse than SSG/ISR — 200–800ms is typical
- Server load scales with traffic — your AWS bill scales with traffic
- Cache headers become finicky — too aggressive and you've reinvented ISR; too loose and the SSR advantage is theoretical
SEO verdict: Only when you actually need per-request rendering. The CWV cost is real. Most pages billed as needing SSR don't actually need it.
The pattern that works for most content sites
For a typical content/portfolio site in 2026:
| Page type | Strategy | Why |
|---|---|---|
| Homepage | ISR (1h) | Mostly stable, but you want recent posts visible |
| About / Now / Contact | SSG | Stable. No reason to regenerate. |
| Blog index | ISR (1h) | New posts should appear |
| Blog post page | ISR (1h) | Post might be edited; updates should propagate |
| Pillar hub pages | ISR (1h) | New posts in the cluster should appear |
| Tool pages | SSG | Static UI + client-side interactivity |
| Search results page | SSR | Truly per-request |
| Admin pages | SSR | Always per-request, never indexed anyway |
The pattern: SSG for stable pages, ISR for content that updates, SSR only when you genuinely need per-request rendering.
The JavaScript rendering trap
Independent of SSR/SSG/ISR: if your content is rendered client-side (React hydration that fetches data after page load), Googlebot will see an empty page during initial crawl. This is a separate problem from your rendering strategy.
Three ways to avoid it:
- Render the content server-side (any of the three strategies above)
- Use streaming SSR with React Server Components to ship content in the initial HTML
- Use a pre-rendering service (Prerender.io, Rendertron) — least preferred, adds latency
If your data fetching happens in useEffect on the client, you have a problem. Move it to a server component, or fetch at build/request time.
What changed in 2026
Three things worth noting since 2023-2024:
1. React Server Components are stable in Next.js. RSC blurs the line between SSG and SSR — you can stream pre-rendered content with dynamic parts. The clean SSG/ISR/SSR categories are less clean than they used to be. For most pages, you're picking a TTL value, not a strategy.
2. Googlebot's JS rendering improved. Google now renders JavaScript on most crawls. But "renders" doesn't mean "renders quickly" — if your client-side fetch takes 2s, Google will likely have left before it completes. The advice "render server-side" still applies.
3. AI engine crawlers are stricter. ChatGPT's browsing tool, Perplexity's crawler, Claude's web search — none of them execute JavaScript reliably. If you care about AI citations, server-render your content.
The honest summary
SSR-for-SEO advice was right in 2018 when client-side React was the default and Googlebot's JS rendering was unreliable. It's wrong in 2026.
The 2026 default is ISR for content that updates, SSG for content that doesn't. SSR for the few cases where per-request rendering is genuinely required. Picking a single strategy site-wide is rarely the right call — pick per route.
FAQ
Is SSR better for SEO than SSG?
No. Googlebot doesn't care which generates the HTML — it cares that the HTML exists. SSG usually wins on TTFB (better CWV). SSR is only needed when you have per-request data.
Does ISR hurt SEO?
No. ISR produces the same HTML as SSG, with periodic regeneration. Googlebot sees fresh content shortly after each update. The TTFB matches CDN-served static — fast.
What TTL should I use for ISR?
For blog post pages: 1 hour (3600 seconds). For blog index pages: 1 hour. For homepages: 30 minutes if it changes often, 1 hour otherwise. For evergreen pages: 24 hours or longer.
Does Google render JavaScript reliably?
Usually, but with delay. Server-render anything important. JS-only content has higher risk of being missed during a crawl pass.
How does AI search (ChatGPT, Perplexity) handle JS-rendered content?
Mostly badly. AI search crawlers don't execute JavaScript reliably. Server-render anything you want cited.
When should I use SSR over ISR?
When the content is genuinely different per request — geo-aware pricing, search results, authenticated previews. Otherwise, ISR with a short TTL accomplishes the same thing with better caching.