Rendering Modes for SEO in Nuxt

Rendering mode decides whether a crawler's first HTTP response already contains your content, or an empty <div id="__nuxt"></div> that only fills in after JavaScript runs. Nuxt lets you set that per route instead of picking one mode for the whole app.

Rendering Modes at a Glance

Server-Side Rendering (SSR)

Nuxt renders SSR by default: ssr: true in nuxt.config.ts is the implicit setting.

export default defineNuxtConfig({
  ssr: true // the default, shown for clarity
})

SSR supports personalized or frequently changing content. Rendering, caching, and backend latency affect TTFB. An edge runtime can reduce some network distance, but distant data sources or cache misses can offset that benefit.

Static Site Generation (SSG)

Nuxt renders routes once at build time and serves the resulting HTML from a CDN. Use nitro.prerender.routes for an explicit list:

export default defineNuxtConfig({
  nitro: {
    prerender: {
      routes: ['/blog', '/docs', '/about']
    }
  }
})

Use routeRules to configure discovered paths. A pattern does not enumerate unlinked dynamic URLs; provide an explicit list or crawlable discovery paths:

export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { prerender: true },
    '/docs/**': { prerender: true }
  }
})

Good for docs, marketing pages, and anything that changes at deploy time rather than per request. Each prerendered route adds build work. Measure build duration and content-update needs before choosing cached SSR or host-supported ISR.

With @nuxt/content, let Nitro's crawler discover routes instead of listing every URL by hand:

export default defineNuxtConfig({
  nitro: {
    prerender: {
      crawlLinks: true,
      routes: ['/']
    }
  }
})

Nitro starts at / and follows eligible rendered anchor hrefs. Check the build output; unlinked dynamic URLs require explicit discovery.

Incremental Static Regeneration (ISR)

SWR serves cached content and lets an eligible request trigger background revalidation after expiry. ISR uses supported hosting infrastructure. These options have different deployment boundaries:

export default defineNuxtConfig({
  routeRules: {
    '/products/**': { swr: 600 } // cached content becomes stale after 600 seconds; requests trigger revalidation
  }
})

Good for product catalogs and news, where a full rebuild per change is wasteful but content can't go stale indefinitely. isr support depends on your deployment target: check your host's Nitro preset docs before relying on it in production.

Client-Side Rendering (CSR)

ssr: false disables server rendering, globally or per route:

export default defineNuxtConfig({
  routeRules: {
    '/admin/**': { ssr: false }
  }
})

Google queues successful 200 responses for rendering, including server-rendered pages. CSR depends on that rendering to expose its content. Google states the page "may stay on this queue for a few seconds, but it can take longer than that", with no fixed timeframe published. Clients that only read the initial response cannot see content rendered later. Check each provider’s current crawler documentation instead of assuming a shared rendering capability.

Choose CSR based on reader tasks and rendering requirements. Google can index rendered CSR content. Set noindex only when the route should stay out of search, regardless of its rendering mode. See Meta Tags and Indexing Issues.

Reported internal observations show rendering itself taking seconds, with hours in its queue. Slow cases reached days or weeks. Initial HTML can expose content without client rendering, but SSR does not bypass every Google rendering process. See Google Search timelines for the stages and their limits.

Server Components (Islands)

Server components can reduce client-side JavaScript for eligible content. This experimental feature has version and deployment limits.

Follow the current Nuxt server component documentation before using islands. A server-rendered component does not itself guarantee better INP.

Mixing Modes with routeRules

routeRules is what makes per-route rendering practical: static pages get prerendered, catalogs get ISR, dashboards stay client-only, all from one config block.

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/blog/**': { prerender: true },
    '/products/**': { swr: 600 },
    '/account/**': { ssr: true },
    '/admin/**': { ssr: false }
  }
})

Test overlapping route rules against your deployment target. Do not rely on object insertion order as a universal first-match rule.

Full reference: Nuxt rendering docs.

Verifying What Google Sees

Compare direct response HTML with Google’s reported rendered HTML:

1. View Page Source (not "Inspect Element"). If your content is missing from the raw HTML, you're relying on client-side rendering
2. URL Inspection in Search Console. "Test Live URL" and compare the crawled HTML against the rendered HTML tab
3. Inspect a response using a Googlebot user-agent string. This does not authenticate Googlebot or reproduce its rendering:

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://yoursite.com

4. Check the build output for routes you expected to prerender:

ℹ Prerendering 42 initial routes with crawler
  ├── /
  ├── /blog/post-1
  └── ...

If a route is missing, check its explicit discovery source, rendered links, fetch failures, and applicable route rules.

Checklist