Nuxt 3 SSR vs SSG: How to Decide for Your Site

Nuxt 3 lets you choose between server rendering (SSR), static generation (SSG), client-only rendering, and a hybrid where each route picks its own. The flexibility is great. It also means you have to decide. Here is how I think about it.

SSG when content does not change per request

Marketing pages, blog posts, documentation, and most landing pages are best served as static HTML. Run nuxt generate at build time, deploy to a CDN, and every request is fast and cheap. SEO is excellent because the HTML is fully populated before the browser asks.

Even when content updates regularly, SSG with on-demand revalidation (Incremental Static Regeneration via the Nitro layer) covers most blog and news patterns. New post? Trigger a rebuild for that route only.

SSR when the response depends on the user

Authenticated dashboards, personalized feeds, and any page that reads the request to decide what to render need SSR. The first response includes the user's data, so the page is fast and SEO-friendly (where applicable). The trade-off is that every request hits a server, so you need real infrastructure (or a serverless function) and you pay for compute.

Hybrid: route rules

Nuxt's route rules let you mix modes per route. Marketing pages get SSG, the dashboard gets SSR, the admin panel goes client-only because SEO does not matter. This is the configuration most production Nuxt apps end up with.

ts// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/blog/**': { prerender: true },
    '/dashboard/**': { ssr: true },
    '/admin/**': { ssr: false },
    '/api/**': { cors: true },
  },
})

Default to static

If you are not sure, start with SSG. It is the fastest, cheapest, and most cacheable option. Reach for SSR only when you genuinely cannot serve a fully baked HTML response — usually because the page depends on who the user is.