Choosing Between CSR, SSR, SSG, and ISR

Picking the wrong rendering mode for a route is one of the most expensive SEO mistakes in a JavaScript app: a money page shipped as a client-rendered shell waits in Googlebot’s render queue and may be indexed empty, while a fully server-rendered dashboard wastes compute on a page no one searches for. This guide turns the rendering-mode decision matrix into a step-by-step choice you can apply route by route.

The decision, step by step

  1. Does the route need to rank? If no — authenticated app screens, internal tools — choose CSR. Content is built in the browser and never enters the render queue you care about.

    // ❌ Do NOT ship a public, rankable route as a bare CSR shell
// /products/:id renders only <div id="root"></div> to crawlers

  2. Does its data change between builds? If no — docs, marketing, legal — choose SSG. Build the HTML once and serve it from the CDN for the lowest TTFB and the strongest crawl guarantee.

    // ✅ Static generation: HTML exists before any request
export const dynamic = 'force-static'; // Next.js App Router

  3. Does it change periodically but not per visitor? Choose ISR. Serve static HTML and regenerate on an interval.

    // ✅ Incremental regeneration: static speed, near-fresh content
export const revalidate = 1800; // regenerate at most every 30 min

  4. Must it be correct on every request (price, stock, personalization-free freshness)? Choose SSR.

    // ✅ Server render per request: always fresh in the first response
export const revalidate = 0;

Each ✅ branch puts content in the first-wave HTML; only the CSR branch defers it. That single property is what your decision is protecting.

Per-route rendering decision tree Three yes/no questions route each page to CSR, SSG, ISR, or SSR based on whether it must rank and how often its data changes. Four modes, decided one route at a time Does the route need to rank? public and searchable? CSR built in the browser No Data changes between builds? or fixed until redeploy? SSG build once, serve from CDN No Periodic, not per visitor? same for all, on a timer ISR regenerate on an interval Yes SSR rendered every request Yes Yes No · per request
Walk the three questions top to bottom; the first "no" (or the per-request "no") drops the route into exactly one of CSR, SSG, ISR, or SSR.

Validation

  • curl the route. curl -sL <url> | grep '<h1' — content present means SSG/SSR/ISR is working; an empty shell means the route is still CSR.
  • GSC URL Inspection → View Crawled Page. Confirms the rendered HTML matches the live page.
  • Disable JavaScript in DevTools and reload — SSG/SSR/ISR routes still show content.
  • Search operator check. site:example.com/products/123 should return the page with the correct title within days of an SSR/SSG switch.
Reading the validation signals Each observation from curl, a JS-disabled reload, or a site: query maps to a verdict about whether the chosen rendering mode is actually applying. What each signal tells you What you observe What it proves curl shows the <h1> text SSG / SSR / ISR is live curl shows an empty shell route is still CSR content shows with JS disabled server-rendered, indexable site: lists it within days the mode switch took effect
Translate each check into a verdict: content in the raw response means a server mode is applying; an empty shell means the route never left CSR.

Configuration reference 

// nuxt.config.ts — one policy object, four modes, applied per route
export default defineNuxtConfig({
  routeRules: {
    '/':            { prerender: true },   // SSG  — stable marketing
    '/docs/**':     { prerender: true },   // SSG  — versioned docs
    '/blog/**':     { isr: 1800 },         // ISR  — periodic content
    '/products/**': { ssr: true },         // SSR  — live inventory
    '/account/**':  { ssr: false },        // CSR  — private, non-indexable
  },
});
When each mode produces the HTML SSG builds HTML once, ISR rebuilds it on a timer, SSR builds it per request, and CSR builds it in the browser — mapped along a timeline relative to the request. When the HTML actually exists Build time CDN edge Per request In browser SSG built once ISR rebuilt on a timer SSR built per request CSR built in the browser earlier — relative to the request — later; only CSR defers content past the first response
Reading left to right, SSG, ISR, and SSR all have HTML ready by the time the response is sent; only CSR waits until the browser to build it.

Frequently Asked Questions

Is SSR always better than CSR for SEO? For routes that must rank, SSR (or SSG/ISR) is safer because content is in the first response. For authenticated or non-indexable routes, CSR is fine and often simpler. The decision is per route, not per app.

When should I use ISR instead of SSR? Use ISR when content changes periodically but not per request — blog posts, category pages, documentation. ISR serves cached static HTML and regenerates on an interval, giving SSG-level performance with near-fresh content and far less server load than SSR.

← Back to CSR, SSG, SSR & ISR Rendering Strategies