Static vs Dynamic Rendering in Next.js: A Decision Guide for Marketing Pages

For a Next.js marketing page, default to static rendering (SSG) — pages built once at deploy time and served as plain HTML. Use ISR when content changes on a known cadence, so pages refresh without a full rebuild. Reach for dynamic rendering (SSR) only when the page genuinely depends on the request — cookies, headers, or per-user data. For SEO, static and ISR win on speed and crawlability; dynamic is the exception.

What is the difference between static, dynamic, and ISR in Next.js?

The three strategies differ on when the HTML is generated. Static rendering (SSG) builds the page once, at deploy time, and serves the same prebuilt HTML to everyone. Dynamic rendering (SSR) generates the HTML on the server for each request, so it can read the incoming request. Incremental Static Regeneration (ISR) is the middle path: it serves prebuilt HTML like static, but quietly regenerates the page in the background on a schedule you set.

In the Next.js App Router, you rarely pick these by name. A route is static by default, and it becomes dynamic only when you use a request-time API — cookies(), headers(), searchParams, or an uncached fetch. ISR is opt-in with one line: export const revalidate = 3600. So the practical question is not "which function do I call," it is "does this page need the request, and how fresh does it need to be." For background on the underlying mechanics, see our explainers on static site generation, server-side rendering, and incremental static regeneration.

Why static rendering is the right default for marketing pages

Most marketing pages — your home page, about, features, a service page, a glossary term — show the same content to every visitor. There is no per-user state to compute. That makes them a textbook fit for static rendering: build once, cache at the edge, serve instant HTML from a location near the user.

The SEO payoff is direct. A static page has the lowest possible Time to First Byte because no server work happens at request time, which feeds straight into Core Web Vitals and the load-speed signals search and AI crawlers care about. The full HTML exists before any crawler arrives, so there is no risk of a bot timing out on server rendering or missing content behind client-side fetches. Static pages are also cheap and resilient — a CDN can absorb a traffic spike that would strain an SSR server.

In our experience building B2B and SaaS sites, the large majority of pages should be static, and treating static as the default — then justifying any exception — keeps a site fast and easy to reason about. This is a core reason we lean on Next.js for marketing sites in the first place. The same instinct shapes how we ship a complete schema graph on a Next.js B2B site — prebuilt, predictable, crawler-friendly.

When should a Next.js page use ISR instead of full static?

Use ISR when the content is the same for everyone but changes after deploy and you do not want to rebuild the whole site to publish it. A blog, a news section, a pricing page pulling from a CMS, or a directory that updates a few times a day are the classic cases. You get static-grade speed for the visitor while keeping content reasonably fresh.

The mechanism is one route segment export: export const revalidate = 60. Next.js serves the cached page, and at most once per interval it regenerates that page in the background when a request comes in. You can pair it with generateStaticParams to prebuild your known URLs at deploy and let new ones generate on demand:

export const revalidate = 60

export async function generateStaticParams() {
  const posts = await fetch('https://api.example.com/posts').then((r) => r.json())
  return posts.map((post) => ({ slug: post.slug }))
}

For SEO this is usually the sweet spot for content-driven pages: crawlers still hit fast, cached HTML, and your published edits appear within the revalidation window without a deploy. The thing to watch is staleness — set the interval to match how time-sensitive the page really is. A legal-disclaimer page can revalidate daily; a "latest funding round" banner cannot.

When do you actually need dynamic (SSR) rendering?

You need dynamic rendering when the correct HTML cannot be known until the request arrives. The honest list for a marketing site is short: pages that read cookies() or headers() (auth-gated previews, geolocation by IP), pages that act on searchParams to render different primary content (a search results page), or anything personalized per visitor. If the page is identical for every anonymous visitor, you almost certainly do not need SSR.

In the App Router you usually do not flip a switch — touching a request-time API makes the route dynamic automatically. You can force it with export const dynamic = 'force-dynamic', but reaching for that on a marketing page is usually a smell worth questioning. SSR costs you the TTFB advantage (the server renders on every hit) and adds a runtime that can fail or slow under load, which is why it should be the exception. A common middle ground is keeping the page static or ISR and hydrating the small dynamic bit on the client, or — on newer Next.js — using Partial Prerendering to serve a static shell instantly while the dynamic slice streams in.

Static vs dynamic vs ISR: the decision table

Here is the quick decision matrix we use when planning a build. Map each page to its row, not the other way around.

The pattern is clear: static for stable pages, ISR for content that updates, dynamic only when the page truly reads the request. For a deeper architectural view of how these choices interact with caching and the rest of a stack, see our guide on Next.js for marketing sites.

How rendering choice affects SEO and AI search

Rendering choice is mostly an SEO choice through one lever: speed and reliability of the HTML a crawler receives. Static and ISR both serve prebuilt HTML from cache, so a crawler — Googlebot or an AI crawler like GPTBot — gets complete content fast, with no dependence on a live server rendering correctly under load. That consistency is what protects your crawl experience.

Dynamic rendering is not anti-SEO by itself; Google renders server-rendered pages fine. The risk is operational: every request does work, so a slow database or a traffic spike can push TTFB up or cause timeouts exactly when a crawler visits. For answer engine optimization, where you want content lifted cleanly into an AI answer, the same logic holds — fast, complete, static-served HTML is the safest substrate. None of this changes the content rules from our AEO playbook for B2B websites; it just removes a class of delivery risk. When we migrate sites — see the WordPress to Next.js migration guide — moving stable pages to static is one of the most reliable speed wins on the table, and a natural pairing with ranking in ChatGPT and Perplexity.

FAQ

Is static or dynamic rendering better for SEO in Next.js?

Static is better for SEO in most cases. It serves prebuilt HTML from a cache, giving crawlers complete content with the lowest Time to First Byte and no dependence on a live server rendering under load. Dynamic rendering is fine when a page genuinely needs the request, but it adds runtime work that can slow or fail at the worst moment.

What is the default rendering mode in the Next.js App Router?

Static. In the App Router a route is statically rendered by default and is only switched to dynamic when you use a request-time API — cookies(), headers(), searchParams, or an uncached fetch. You opt into ISR explicitly with export const revalidate, and you can force dynamic with export const dynamic = 'force-dynamic'.

When should I use ISR instead of static generation?

Use ISR when content is the same for all visitors but changes after deploy and you do not want to rebuild the site to publish — blogs, CMS pricing pages, directories. Add export const revalidate = <seconds> to a route segment, optionally with generateStaticParams, and Next.js regenerates the cached page in the background on that interval.

Does server-side rendering hurt page speed?

It can. SSR renders the HTML on every request, so Time to First Byte depends on your server and data sources, and it degrades under traffic spikes or slow queries — whereas static and ISR serve cached HTML almost instantly. Use SSR only when a page truly depends on the request; otherwise prefer static or ISR for speed.

How do I make a Next.js page dynamic on purpose?

Either use a request-time API in the component — reading cookies(), headers(), or searchParams automatically opts the route into dynamic rendering — or add export const dynamic = 'force-dynamic' to the route segment. On a marketing page, prefer the first approach and only force dynamic when the page genuinely cannot be prerendered.