Nuxt routeRules: Prerender the Blog, Keep the Dashboard Dynamic

A typical Nuxt site is not one kind of site. The marketing pages barely change, the blog changes daily, and the account dashboard must render fresh on every request. Running the whole thing as SSR wastes server time on pages that could be static; prerendering everything makes the dashboard stale or broken. Nuxt 3's answer is routeRules: per-URL rendering modes declared in one place, nuxt.config.ts.

The useful takeaway: you can ship one Nuxt app where /blog/** is built as static HTML, the homepage is cached with stale-while-revalidate, and /account/** stays fully server-rendered — without splitting the project or writing middleware.

What routeRules actually does

Nuxt 3 runs on Nitro, the server engine that handles requests and builds. routeRules is a Nitro feature exposed in your Nuxt config. Each key is a URL pattern, and the value describes how that route should be rendered, cached, redirected, or proxied.

Patterns support wildcards, and more specific rules win over broader ones. That lets you prerender /blog/** while carving out /blog/admin as SSR. The matching is prefix-based, so /blog/** covers nested paths like /blog/2026/my-post.

A worked example: mixed-content site

Say you run a marketing site with a CMS-driven blog and a logged-in account area. A reasonable config looks like this:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    // Static at build time — no server work per request
    '/blog/**': { prerender: true },
    // Except the editor, which must be live
    '/blog/admin': { ssr: true },
    // Homepage: cached for an hour, revalidated in the background
    '/': { swr: 3600 },
    // Account pages: always fresh, never cached
    '/account/**': { ssr: true },
    // Old URL, no middleware needed
    '/pricing-v1': { redirect: '/pricing' }
  }
})

Three distinct strategies in one deployment:

• Prerender (prerender: true): the page is rendered to HTML at build time. Great for content that changes on deploy cadence, not request cadence.
• Stale-while-revalidate (swr: 3600): the first request renders and caches the page; later requests get the cached copy instantly while Nitro re-renders in the background after the TTL expires.
• SSR (ssr: true): rendered per request. Use this for anything personalized or auth-gated.

Verifying it works

Don't assume the config took effect — check it. After adding prerender: true for a route, run npx nuxi build locally and inspect the build output: prerendered routes are listed during the build and emitted as static files under .output/public. If your route isn't there, the pattern didn't match or the route wasn't crawled — you may need to add it to nitro.prerender.routes explicitly if no link points to it.

For swr, start the production server (node .output/server/index.mjs), request the route twice, and compare response headers or a rendered timestamp on the page. The second response should arrive without re-rendering. This assumes the Node preset; behavior differs elsewhere, which brings us to the catch.

The trade-offs you need to know

Cache semantics depend on your deployment preset. swr and isr are honored by Nitro, but how the cache persists across instances or deploys is platform-specific. A rule that works beautifully on one hosting platform may be ignored or behave differently on a self-hosted Node server behind your own proxy. Verify on your actual target, not just locally.

Prerendering moves failures to build time. If your blog pages fetch from a CMS during prerender, a CMS outage during the build fails the build or produces stale/empty pages. Add retries or fallbacks in your data fetching, and treat build-time API dependencies as a real operational concern.

Caching and personalization don't mix. If a page under an swr rule accidentally renders user-specific data (a greeting, an avatar), that personalized HTML gets served to everyone. Keep cached pages anonymous; load user data client-side after hydration.

Where to start

Pick your single slowest, most cache-friendly route — usually the homepage or a top landing page — and give it swr: 3600. Deploy, hit it twice, confirm the cache behavior on your real hosting preset. Then work through the rest of the route table: prerender what changes on deploy, cache what changes hourly, and leave everything personalized on plain SSR. One config key, three rendering strategies, no middleware.