Incremental Static Regeneration (ISR)

Incremental Static Regeneration lets a Next.js site serve pre-built static pages and quietly refresh a single page in the background — on a schedule or triggered by an event — instead of rebuilding the whole site. Visitors keep getting the cached, fast version while the new one is generated, then later requests get the updated page. It's the middle ground between fully static and fully dynamic.

How ISR works in Next.js

ISR builds on static site generation: pages are rendered to HTML at build time and cached at the edge. The difference is that each page can carry a revalidation rule. With time-based revalidation, you set a revalidate value (say, 3600 seconds); after that window passes, the next visitor still gets the cached page instantly, and Next.js regenerates a fresh copy in the background for everyone after them. This is "stale-while-revalidate" applied to whole pages.

On-demand revalidation skips the timer entirely. When content changes in your CMS or database, a webhook calls Next.js to invalidate one specific path or tag, and only that page rebuilds. Nothing else is touched. This avoids the all-or-nothing cost of a full deploy when you've edited a single blog post, and it keeps the rest of the cache warm. Compared with server-side rendering, ISR does the work once and reuses it, rather than rendering on every request.

Why ISR matters for B2B sites

Most marketing and B2B content is static for hours or days at a time, so it should be served from cache — fast, cheap, and reliable. But some surfaces change often: a pricing page, a customer logo wall, a blog index, a changelog. ISR lets those pages refresh on their own cadence without forcing a rebuild of the whole site or pushing every page onto a slow dynamic path. You get static performance where it counts and freshness where it counts.

For SEO and AI search, speed and stable HTML help: crawlers and answer engines get fully rendered pages quickly, and Core Web Vitals stay strong. The trade-off is cache nuance — you have to decide each page's revalidation window deliberately, which is the same judgment call covered in static vs dynamic rendering. In our experience, mapping each page type to the right strategy is the core decision when building a Next.js marketing site.

FAQ

Is ISR the same as static site generation?

No, but it extends it. Static site generation renders every page once at build time and leaves it frozen until the next full deploy. ISR starts from those same static pages but adds a revalidation rule per page, so individual pages can rebuild in the background — on a timer or on demand — without redeploying the whole site. Think of ISR as static generation that's allowed to update itself.

When should I use ISR instead of server-side rendering?

Use ISR when content changes occasionally and can be the same for everyone for a while — pricing, blog posts, marketing pages. You pay the rendering cost once and serve from cache. Choose server-side rendering when a page must be fresh or personalized on every request, such as a logged-in dashboard. The decision tree for each page type is laid out in static vs dynamic rendering.

Does ISR hurt SEO or confuse crawlers?

Not when it's set up well. ISR serves fully rendered static HTML, which crawlers and AI answer engines read easily and quickly, so it tends to help Core Web Vitals rather than hurt them. The risk is stale content: if a page's revalidation window is too long, search engines may index an out-of-date version. Pairing a sensible revalidate value with on-demand revalidation for important edits keeps the indexed page current.