Configuring Per‑Route Rendering Strategies in Nuxt 3 with Route Rules

Problem: One rendering mode does not fit all pages

Most Nuxt applications contain a mix of content types: marketing pages that benefit from instant HTML for SEO, dashboards that rely on client‑side interactivity, and blogs that update infrequently but still need to be crawlable. Forcing a single mode (SSR or SPA) across the whole app either wastes server resources or harms search visibility.

Useful takeaway: By defining route rules in nuxt.config.ts you can assign a rendering strategy—SSR, static (SSG), stale‑while‑revalidate (SWR), incremental static regeneration (ISR), or SPA—to each URL pattern, letting you optimise performance and SEO on a per‑route basis.

Prerequisites

• Nuxt 3.8 or higher (route rules are stable from this version).
• Node.js 18+.
• A Nitro preset that matches your deployment target (e.g., vercel, netlify, cloudflare-pages, node-server). Note that ISR and SWR rely on the platform’s ability to run edge functions or background revalidation; on the node-server preset they fall back to SSR unless you provide a custom Nitro storage driver.

Focused procedure

1. Edit the configuration Open nuxt.config.ts and add a routeRules object. Each key is a URL pattern (path‑to‑regexp syntax) and the value is an object that selects a strategy.

   // nuxt.config.ts
   export default defineNuxtConfig({
     routeRules: {
       // Static generation at build time
       '/about': { static: true },
       
       // SWR: cache HTML for 60 seconds, revalidate in background
       '/blog/**': { swr: 60 },
       
       // SPA: render only on the client
       '/dashboard/**': { spa: true },
       
       // Explicit SSR (default, shown for clarity)
       '/search': { ssr: true },
       
       // Example of a redirect handled at the rule level
       '/legacy': { redirect: '/modern' }
     }
   })

   More specific patterns win; for example /blog/2026/10/post matches /blog/** before a broader /** rule.

2. Build the application Run the build command for your chosen preset.

   # Build using the default preset (or specify with --preset if needed)
   npx nuxi build

   Nitro generates server‑less or node‑server output according to the preset. For static routes you will see prerendered files in .output/public (or the equivalent folder for your preset).

3. Deploy Use the preset’s CLI to publish the build output.

   # Example for Vercel
   vercel deploy --prod
   # Example for Netlify
   netlify deploy --dir=.output --prod

Expected checks

• Inspect build artefacts: After nuxi build, look at .output/server/routes.json (when using the node-server preset) to confirm that Nitro has mapped each pattern to the chosen strategy. The exact file location varies with the preset; consult the Nitro output directory.
• Check response headers: Deploy to a staging environment and run curl -I <URL> or use the browser’s Network tab. Look for headers that Nitro adds to indicate caching behavior (commonly x-nitro-cache with values like HIT, MISS, or STALE). Verify that the header matches the expectation for the route’s strategy.
• Validate revalidation (SWR/ISR): For a route with swr: 60, update the underlying data source, then request the page twice within a minute. The first response should show the previously cached (stale) content, and the second (after the TTL) should reflect the update. This confirms that background revalidation is occurring.
• Lighthouse or manual SEO check: Run Lighthouse on static and SWR routes to ensure they serve full HTML with meta tags; SPA routes will show a lower SEO score unless you add prerendering or server‑side fallback.

Recovery options

• Temporary fallback to SSR: If a route serves stale or incorrect content, change its rule to { ssr: true }, rebuild, and redeploy. This bypasses any caching layer and guarantees fresh rendering.
• Clear edge cache: On platforms that support it, purge the cache for the affected path (e.g., vercel purge --scope=my‑team --path=/blog/* or trigger a new deploy on Netlify).
• Force static generation for dynamic routes: If a dynamic route like /blog/[slug] is not being picked up as static, add the discovered paths to nitro.prerender.routes in nuxt.config.ts.
• Rollback: Because route rules are baked into the build, the only way to revert a strategy change is to redeploy a previous build artifact (using your platform’s rollback or redeploy‑previous‑version feature).

Limitations and practical notes

• Route rules are static after build; you cannot alter a rendering strategy at runtime without a new build and deploy.
• ISR and SWR require the target platform to support edge functions or background workers. On the node-server preset they default to SSR unless you configure a custom Nitro storage driver.
• Standard Nuxt middleware runs on SSR and client‑side navigation, but not on every request for static or cached ISR/SWR responses. Use the appMiddleware key inside a route rule if you need edge‑level middleware (verify its availability in your Nuxt version).
• Header names used by Nitro for cache status may change between releases; consult the Nitro documentation for the exact header to inspect.
• The .output/server/routes.json file is present when using the node-server preset; other presets may store route information differently.

By following the steps above you can tailor the rendering mode to each part of your Nuxt application, balancing server load, update frequency, and search‑engine visibility.