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.

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.

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
  },
});

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