Nuxt Route Rules: Pick Rendering per Route, Not per Project

The global mode trap

The moment you deploy a Nuxt 3 application, you inherit a rendering decision that applies to every route. Set ssr: true globally and your server re-renders each page on request, keeping content fresh but adding server work and latency. Set ssr: false and you ship a client-rendered single-page app, which can hurt first paint and crawlability. Most teams accept this tradeoff because the alternative—maintaining separate apps—feels heavier than the problem.

Nuxt 3 removes that constraint through routeRules in nuxt.config.ts. These rules are passed to Nitro, the server engine that powers Nuxt's build and deployment output. Instead of one global mode, you map path patterns to specific behaviors: prerender at build time, render on demand, cache with revalidation, or disable SSR entirely for certain routes.

What route rules actually control

A routeRules entry accepts a path pattern and an object describing how that route should behave. The most common keys are:

• prerender: true — emit static HTML during nuxt build.
• ssr: false — skip server rendering and serve a client-rendered shell.
• swr: true — enable stale-while-revalidate caching.
• isr: 60 — enable incremental static regeneration with a revalidation window in seconds.

You can also attach response headers or redirects to the same pattern. Because these rules feed into Nitro, the exact behavior depends on your deployment preset and hosting provider.

A worked split for a typical site

Consider a site with a marketing homepage, a blog, and an authenticated dashboard. These have different freshness and performance requirements, so a single mode is wrong for at least two of them.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/pricing': { prerender: true },
    '/blog/**': { isr: 60 },
    '/dashboard': { ssr: false }
  }
})

Here, / and /pricing are prerendered: their HTML is generated at build time and served as static files, which is ideal for content that changes rarely. The /blog/** pattern uses ISR with a 60-second window. The first request after the window expires triggers a background rebuild, so the CDN can serve stale HTML while fresh HTML is generated. The /dashboard route disables SSR because it sits behind authentication and does not need SEO; it ships as a client-rendered app.

The trade-off: cache semantics are not universal

The biggest limitation is that SWR and ISR intentionally serve stale HTML while regenerating. That is a feature for uptime, but it means a content correction may not appear immediately. Worse, support for revalidation, TTL semantics, and on-demand purging varies by hosting adapter and Nitro preset. A behavior that works on one provider may behave differently on another, or may require additional platform configuration.

Using ssr: false also shifts rendering to the client. The initial HTML payload is smaller, but the browser must execute JavaScript before meaningful content appears. For routes that must be crawlable or fast on first paint, this is a poor fit regardless of how clean the client code is.

Route rules are therefore an operational decision, not just a config trick. They change what your build emits, what your CDN caches, and how quickly corrections propagate. Treat them like cache policy with explicit ownership and invalidation expectations.

Verify the behavior on your target host

Do not assume the config produces the behavior you expect. After changing routeRules, run nuxt build in your project root. This requires write access to the output directory. If you prerender a large or unbounded dynamic route list, the build can slow significantly or hit platform limits, so bound the path set explicitly.

After building, inspect the generated output directory. Confirm which paths were emitted as static files versus configured for on-demand rendering. Then deploy or preview on your target host and request each route pattern.

For ISR or SWR routes, change source content, wait past the revalidation window, and request the route again to see whether the HTML updates without a full rebuild. For ssr: false routes, compare the first-load HTML against the client-hydrated version to confirm the server is not rendering markup.

Check response headers for cache directives. During testing, use a cache bypass or a fresh deploy so stale HTML does not mask a bug. Read the current Nuxt and Nitro documentation for your installed version and deployment preset before enabling SWR or ISR in production.

Make the call per route, not per project

Rendering strategy is not a one-time project setting. It is a per-route decision driven by freshness requirements, crawlability, and operational cost. Start by listing your route patterns and asking which ones must be fresh, which can tolerate a revalidation window, and which are irrelevant to search engines. Then encode that answer in routeRules, and verify the result on your actual host before trusting it in production.