Prerendering vs SSR vs SSG: 2026 Decision Guide

The rendering decision used to be binary, server-rendered or client-rendered. In 2026 it is at least four-way: static generation, server-side rendering, prerendering on top of a JavaScript app, and React Server Components with streaming. Each one wins for specific route shapes, and each one has a failure mode teams underestimate when they pick on intuition.

Updated for April 2026, this guide walks through the rendering models that matter for technical SEO, when each one is the right answer, and what they cost the team to operate. We avoid framework politics, every modern frontend supports all four approaches, and focus on the practical question of which path delivers reliable crawler-facing HTML for the specific shape of site you actually run. The framing pairs with the broader JavaScript SEO work and the prerendering for technical SEO discussion.

What each rendering model actually does

Before the comparison, a tight definition of each model. Most arguments about which is "best" come from people meaning slightly different things by the same words.

Static Site Generation (SSG)

The frontend generates every page as static HTML at build time. The HTML is deployed as files. There is no per-request server rendering, the CDN serves the pre-built HTML directly. Examples: Astro by default, Next.js with generateStaticParams, Hugo, Eleventy, Gatsby.

The crawler-visible HTML is exactly what was built. Cache invalidation is "rebuild and redeploy." TTFB is the time it takes the CDN to respond, which is usually 30 to 100ms anywhere in the world.

Server-Side Rendering (SSR)

The server renders HTML on every request. The framework runs on each incoming request, fetches data, generates HTML, and sends it back. Examples: Remix everywhere, Next.js with force-dynamic, Express + EJS, classic PHP/Rails apps.

The crawler-visible HTML is generated fresh per request. Cache invalidation is whatever the team builds into the rendering pipeline. TTFB depends on origin response time and any data dependencies, typically 200ms to 1.5s.

Incremental Static Regeneration (ISR)

A hybrid. Pages are static-served from cache, but regenerated on demand or on a TTL. The first request after a cache expiry triggers a regeneration; subsequent requests hit the fresh cache. Examples: Next.js ISR, Vercel's caching layer.

The crawler-visible HTML is whatever is in the cache, which can be stale by up to the TTL. Background regeneration keeps it close to fresh without per-request rendering cost.

Prerendering on top of a JavaScript app

A JavaScript SPA or hybrid app delivers normal HTML to humans. A separate prerendering layer (managed service or self-hosted cluster) intercepts crawler traffic, runs the app in headless Chrome, and returns deterministic HTML. The two paths are decoupled.

The crawler-visible HTML comes from the prerendering layer. The human-visible UI comes from the regular SPA delivery. Cache lifetime, bot detection, and regeneration are managed independently of the application code. We covered the integration in redirect bot traffic to prerendering.

Decision criteria, the things that actually decide

Not every rendering decision is about Core Web Vitals. The criteria that matter:

• Content freshness, how quickly does a publish need to reach search engines and AI crawlers?
• Personalization boundaries, is the page identical for every user, or does it depend on session/locale/cookies?
• Build time tolerance, how long can the deploy take?
• Engineering capacity, who maintains the rendering layer when things break?
• Origin load, can the backend handle full SSR traffic, or do most pages need to be cached?
• Crawler-side reliability, does the framework's default ship complete HTML to bots, or does something extra need to happen?

Pick the rendering model that fits these constraints, not the one that has the most discourse on Twitter.

When SSG is the right answer

SSG wins for content sites where:

• The set of URLs is bounded and known at build time (a few thousand pages, not millions)
• Content updates are batched (daily, weekly), not instant
• Personalization is handled client-side or not at all
• The team values operational simplicity over rendering flexibility

SSG produces the fastest possible TTFB because there is no rendering work per request, just a CDN file lookup. Core Web Vitals tend to land in the green by default. Cache invalidation is "rebuild," which is a real constraint for sites with breaking news or rapid editorial cycles, but a non-issue for marketing sites and documentation.

The failure mode: build times. A 50,000-page SSG build takes 20 to 40 minutes on most infrastructure. A 500,000-page build is impractical. Past about 10,000 pages, ISR starts looking better.

When SSR is the right answer

SSR wins when:

• Content changes per request (personalization, A/B tests, real-time data)
• The URL set is unbounded or generated from user inputs (search results, filters, dynamic content)
• The team has disciplined edge caching to keep TTFB under 500ms
• Origin capacity can handle the full request volume

SSR gives the most flexibility, every page is fresh, every request can be customized. The cost is operational. Without aggressive caching, SSR sites tend to ship 800ms to 1.5s TTFB, which eats most of the LCP budget and fails Core Web Vitals at p75.

The framework patterns that make SSR work well: strong edge caching with stale-while-revalidate, route-level cache headers, and a separation between SSR routes (data-driven, personalized) and static routes (content, marketing). Most production-grade SSR sites in 2026 are actually hybrids.

The failure mode: TTFB regressions that ship invisibly. A new database query in a route handler can add 200ms without anyone noticing until field metrics catch it weeks later.

When ISR is the right answer

ISR is the answer when:

• Page count is too large for full SSG (above ~10,000 routes)
• Content updates need to reach users within minutes, not hours
• Personalization is bounded, the page is the same for most users, with optional client-side personalization layered on top
• The framework supports it (Next.js is the dominant ISR implementation)

ISR splits the difference between SSG and SSR. The first request after a TTL expires triggers a background regeneration; subsequent requests hit the fresh cache. TTFB is CDN-fast for cached responses (30 to 100ms) and SSR-shaped for cache-miss responses (300 to 800ms).

The pattern that works: short TTL (60 seconds for fast-changing content, 5 to 15 minutes for editorial), combined with on-demand revalidation triggered from CMS webhooks. We covered the headless integration in technical SEO for headless CMS.

The failure mode: stale content windows during incidents. If the regeneration logic breaks, the cache keeps serving old content silently for hours. Monitoring matters here.

When prerendering on top of a JavaScript app is the right answer

Prerendering wins when:

• The app is fundamentally a SPA or hybrid that cannot be quickly migrated to SSR or SSG
• Crawler-facing HTML is broken or unreliable in the current stack
• The team needs to ship a fix fast, weeks, not months
• The rendering model and the application code can be decoupled cleanly

This is the model that gets cynical reactions from "frameworks should solve this" purists. The honest position: many real production codebases are not architected to be migrated easily. A SPA built three years ago with a React Router setup, dozens of useEffect data fetches, and a build pipeline that doesn't support SSR is not going to become an SSR app over a weekend. Prerendering bridges the gap.

The pattern: detect crawler traffic at the edge, route it to a prerendering layer, return the deterministic HTML the crawler can index. Human users get the regular SPA delivery. The application code stays the same. We covered the architectural decision in which pages should use prerendering and the cost tradeoffs in build vs buy prerendering.

The failure mode: rendering parity drift. The prerendered HTML and the human-visible UI can drift over time, especially after design system or content schema changes. Validation matters, patterns in SSR cloaking risks and semantic parity.

A decision matrix you can actually use

This is not exhaustive. The right model often combines two or three, most production sites we audit have a mix of SSG marketing pages, ISR catalog pages, SSR personalized routes, and selective prerendering for hard-to-migrate sections.

What stays the same regardless of model

The technical SEO discipline that decides whether a site ranks does not change with the rendering model:

• Canonical logic at the template level, covered in canonical issues on JavaScript websites
• Structured data in the first response, covered in structured data for AI visibility
• Sitemap accuracy and freshness, covered in XML sitemap guide for technical SEO
• Image discipline, covered in image SEO at scale
• CI gates that catch regressions, covered in Lighthouse CI for technical SEO validation

The rendering model decides who serves the HTML. The technical SEO work above decides whether that HTML actually ranks.

What rendering choice does not solve

A few problems no rendering model fixes:

• A weak content strategy doesn't get fixed by faster rendering
• Bad URL architecture doesn't get fixed by SSR
• Missing or wrong structured data doesn't appear because you switched to ISR
• Crawler discovery problems persist regardless of how the page renders

Pick the right rendering model, then do the rest of the technical SEO work. Both halves are required.

Common engineering mistakes

Patterns we see when teams pick rendering models on intuition:

• Migrating to SSR because "SSR is good for SEO" without checking whether the framework's defaults already produced complete HTML
• Sticking with SSG on a 100,000-page site because the team likes the simplicity, then accepting 30-minute deploys
• Using ISR with a 24-hour TTL on a news site (publishing latency is unacceptable)
• Using SSR on a marketing site (origin cost without benefit)
• Adding prerendering to a site that already ships complete server HTML (extra layer with no payoff)
• Treating "the framework supports SSR" as "the site is SSR" when the actual defaults push toward client-side rendering

The right rendering model is the one that fits the route shape. Audit the routes, check the defaults, and pick deliberately. The diagnostic side is in how to test if your site needs prerendering.

Conclusion

SSG, SSR, ISR, and prerendering are not interchangeable. Each one wins for specific route shapes, content sites for SSG, large editorial for ISR, dynamic apps for SSR, hard-to-migrate SPAs for prerendering. Most production sites combine two or three. Pick the model that fits the route, not the one with the most discourse, and make sure the technical SEO discipline that surrounds rendering is doing its job regardless of which model you picked.

The rendering decision is the chassis. The work that decides whether the site actually ranks happens above it.

Frequently Asked Questions