Nuxt routeRules: Per-Route Rendering Control Without Touching Page Components

The problem: rendering strategy locked into page components

In a typical Nuxt application, rendering behavior is decided inside each page. You add ssr: false to definePageMeta for a dashboard, set up prerendering for marketing pages, and hope the data-fetching logic matches. As the app grows, this scatters infrastructure concerns across dozens of files and makes it hard to answer a simple question: which routes are static, which are server-rendered, and which are client-only?

The useful takeaway: Nuxt’s routeRules in nuxt.config let you declare rendering and caching behavior per path pattern in one place, compiled into the server layer at build time.

What route rules actually do

Route rules are a map of glob patterns to rendering directives. Nuxt passes them to Nitro, the server engine that powers Nuxt deployments. At build time, Nitro compiles these rules into route handlers and cache configuration. When a request arrives, Nitro matches the URL against your patterns and applies the corresponding strategy before any page component logic runs.

Because the rules live in the server layer, they work the same way whether you deploy to Node, a serverless platform, or an edge runtime—though exact cache semantics can vary by preset.

Common directives include:

• ssr: false — skip server rendering; return a client-side shell.
• prerender: true — generate static HTML at build time.
• swr: <seconds> — serve cached HTML and revalidate in the background after the given time.
• isr: true or isr: <seconds> — incremental static regeneration (behavior depends on deployment target).

A worked configuration

Consider an application with a public blog and a private admin area. You want blog posts to be fast and cacheable, but the admin dashboard should never render sensitive data on the server.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { swr: 600 },
    '/admin/**': { ssr: false }
  }
})

A request to /blog/my-first-post matches the first pattern. Nitro serves the cached HTML response. If the cached entry is older than 600 seconds (ten minutes), Nitro triggers a background revalidation: the next visitor still receives the stale page immediately, while a fresh copy is generated for subsequent requests.

A request to /admin/settings matches the second pattern. Nitro returns a minimal HTML shell without executing server-side page logic. The dashboard hydrates in the browser and fetches data client-side.

Limits you need to know

Route rules are powerful, but they do not override everything.

• Page-level ssr: false wins. If a page component sets ssr: false in definePageMeta, a route rule cannot force that page back into server rendering. The page-level opt-out is final.
• Server-side data fetching still happens for server-rendered strategies. If you use swr, isr, or prerender, any useAsyncData call in the page still executes on the server when HTML is generated or revalidated. To prevent that, the page itself must opt out of SSR.
• Prerender ignores query strings. A rule like '/products/**': { prerender: true } treats /products/shoe and /products/shoe?color=red as the same route. Query-string variants are not discovered automatically.
• Dynamic routes need explicit discovery. Route rules alone do not crawl your API to find unknown slugs. You must supply prerenderRoutes or use a crawler so Nitro knows which dynamic paths to generate.

Common mistakes

Overly broad globs. A pattern like '/**': { prerender: true } will attempt to statically generate every matching route, including authenticated pages. This can leak private data into build artifacts or cause extremely long build times. Scope patterns tightly.

Assuming SWR invalidates on content change. swr: 600 is a time-based cache. If you publish a blog post and need it live immediately, the rule alone will not purge the old HTML. You need a webhook, a manual cache purge, or a shorter TTL.

Forgetting deployment differences. ISR and SWR behavior is not identical across Node, Vercel, Netlify, and Cloudflare presets. Cache headers, background revalidation triggers, and purge mechanisms can differ. Verify against your target platform.

How to verify the behavior

After changing routeRules, rebuild the application. In your project root, run:

nuxt build

Then inspect the generated server output (typically under .output/server or your configured dist directory) to confirm that Nitro created handlers matching your patterns.

To check live response headers, run from any terminal with network access:

curl -I https://your-site.com/blog/my-first-post

Look for cache-related headers such as Cache-Control, x-nitro-prerendered, or SWR indicators. The exact header names depend on your Nuxt version and deployment preset, so compare against the official documentation for your installed release.

For a quick local check, create two routes—one with swr and one with ssr: false—and compare the raw HTML from View Source against what you see after client-side navigation. The SWR route should contain fully rendered markup; the ssr: false route should contain an empty shell that fills in after hydration.

Because route rule syntax and cache primitives have evolved across Nuxt 3 minor releases, always confirm the supported keys and defaults in the documentation for your exact version before relying on them in production.