Nuxt 3 routeRules: Mix SSR, static, ISR, and SWR in one app

One rendering mode for every page is the wrong trade-off

In a typical Nuxt 3 application, you might want marketing pages pre-rendered as static files, a dashboard rendered on the server for every request because it shows private data, and blog posts regenerated hourly without rebuilding the whole site. Before route rules, choosing one rendering mode forced every route into the same bucket. Nuxt 3 solves this with routeRules in nuxt.config.ts, letting you assign SSR, static, ISR, or SWR per route pattern in a single deployment.

How routeRules assign rendering strategies

routeRules maps URL patterns to rendering modes. Nitro, Nuxt's server engine, evaluates the rules in the order you define them, and the first match wins.

• ssr — server-side rendered on each request (default).
• static or prerender — pre-rendered at build time.
• swr — stale-while-revalidate; serves cached HTML while refreshing in the background after the TTL.
• isr — incremental static regeneration on platforms that support it, such as Vercel, Netlify, Cloudflare Pages, or AWS Lambda@Edge.

Patterns can be exact paths (/about), wildcards (/blog/**), or custom match functions. The rules also apply to API routes, so you can cache /api/search differently from /api/user.

Worked example: mixed rendering in one config

This nuxt.config.ts configures a content site with a personalized dashboard and a search API:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { static: true },
    '/features': { static: true },
    '/pricing': { static: true },
    '/dashboard/**': { ssr: true },
    '/blog/**': { isr: 3600 },
    '/api/search': { swr: 60 },
    '/**': { ssr: true }
  }
})

Place specific rules before the catch-all /** rule. If the catch-all comes first, it matches every route and the specific rules never run.

Cache headers Nitro sets automatically

Mode	Typical Cache-Control header
static / prerender	public, max-age=31536000, immutable
swr / isr	public, max-age=0, must-revalidate, stale-while-revalidate=<ttl>
ssr	No immutable cache header; typically no-store or framework default

TTL stands for time-to-live. On static hosts, Nitro's output adapter translates these rules into platform primitives such as edge functions or ISR manifests.

Limitations to check before you deploy

• ISR is platform-dependent. On hosts without ISR support, the adapter may fall back to SSR or static. Confirm your target platform honors ISR before relying on it.
• TTL is advisory. Edge cache behavior and traffic patterns can mean stale content is served beyond the configured TTL, especially after a cold start.
• Dynamic routes are not discovered automatically. For /blog/[slug], you still need generate.routes or a crawler so Nuxt knows which slugs to pre-render.
• Middleware still runs on every request. If middleware should skip static or ISR routes, inspect the route rule inside the middleware handler.

Verify locally before deploying

1. Create a project: npx nuxi init route-rule-demo (run in your terminal; no special permissions required).
2. Add the config above to nuxt.config.ts.
3. Build the app: npx nuxi build.
4. Inspect the compiled route map: cat .output/server/routes.json. Look for your patterns and assigned modes.
5. Start the production preview: npx nuxi preview, then open your browser's Network tab and check the Cache-Control header for /, /blog/some-post, and /api/search.

If a header is missing or a route has the wrong mode, check rule order in nuxt.config.ts. Reverting the config file and redeploying is the rollback path.

Closing: classify routes, deploy once

Group your routes by caching and personalization needs: SEO-critical public pages to static, personalized pages to SSR, frequently updated content to ISR or SWR. Encode that classification in nuxt.config.ts, verify the headers locally, and deploy to a platform that supports your chosen ISR or SWR behavior.