The Ultimate Guide to Incremental Static Regeneration (ISR) in Next.js – Complete Guide

Most teams running large content sites face the same trade-off: full static generation gives you the fastest possible page loads, but rebuilding thousands of pages every time a single post changes becomes slow and expensive. Pure server-side rendering solves the freshness problem but adds latency to every single request. Incremental Static Regeneration (ISR) was built specifically to remove that trade-off, and it’s one of the most practical features in the Next.js rendering toolkit.

This guide covers what ISR actually does, how the caching model works under the hood, how to implement it in both the Pages Router and the App Router, and the pitfalls that trip up most teams the first time they use it.

What Is ISR?

ISR is a hybrid rendering strategy that sits between Static Site Generation (SSG) and Server-Side Rendering (SSR). Pages are generated as static HTML at build time, just like SSG, but instead of staying frozen until the next full deployment, individual pages can be regenerated in the background after a set time interval or on demand, without rebuilding the rest of the site.

In practice, this means a 10,000-page blog or e-commerce catalog can ship in seconds, while individual pages quietly refresh themselves as their content changes.

How ISR Works: Stale-While-Revalidate

ISR follows a stale-while-revalidate model:

1. The first request for a page is served from the static cache, generated either at build time or on first visit.
2. Once the page’s revalidate window has passed, the next visitor still receives the cached (now “stale”) version instantly — there’s no waiting on a rebuild.
3. In the background, Next.js regenerates that page using fresh data.
4. Once regeneration finishes, the cache is updated, and all subsequent requests receive the new version.

The key benefit: no visitor ever waits on a regeneration. They either get a fully fresh page or a slightly stale one, never a loading spinner.

Implementing ISR

ISR is configured slightly differently depending on which router your project uses.

Pages Router

If you’re on the older Pages Router, ISR is configured with the revalidate property inside getStaticProps:

export async function getStaticProps() {
  const res = await fetch('https://your-api.com/posts');
  const posts = await res.json();

  return {
    props: { posts },
    revalidate: 60, // regenerate at most once every 60 seconds
  };
}

revalidate: 60 doesn’t mean the page rebuilds every 60 seconds on a timer — it means the page becomes eligible for regeneration on the next request that arrives after that window closes.

App Router

The App Router (the current standard since Next.js 13+) handles this in one of two ways.

Route segment config, applied to an entire route:

// app/blog/[slug]/page.tsx
export const revalidate = 60;

export default async function Post({ params }) {
  const res = await fetch(`https://your-api.com/posts/${params.slug}`);
  const post = await res.json();
  return <Article post={post} />;
}

Per-fetch revalidation, applied to a specific data request:

const res = await fetch('https://your-api.com/posts', {
  next: { revalidate: 60 },
});

One detail worth knowing: in recent Next.js versions, fetch calls are uncached by default unless you explicitly opt in with next: { revalidate } or cache: 'force-cache'. If your pages aren’t caching the way you expect, this is usually why.

On-Demand Revalidation

Time-based revalidation works well for content that changes on a predictable schedule, but it’s not ideal when you need a page to update the instant content changes — for example, the moment an editor publishes a post in a headless WordPress backend. For that, Next.js supports on-demand revalidation via revalidatePath and revalidateTag, typically called from a Route Handler triggered by a CMS webhook:

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';

export async function POST(request) {
  const { path } = await request.json();
  revalidatePath(path);
  return Response.json({ revalidated: true });
}

For a headless WordPress + Next.js stack — the kind of setup used for fast content management paired with a high-performance frontend — wiring a publish webhook to this endpoint means content goes live within seconds, with none of the staleness window that pure time-based ISR introduces.

ISR vs. SSG vs. SSR vs. CSR

Strategy	Build cost	Freshness	First-byte speed	Best for
SSG	Full rebuild per change	Stale until rebuild	Fastest	Pages that rarely change
ISR	One-time build, incremental updates	Near-fresh, configurable	Fastest (cached)	Large sites with periodic content changes
SSR	None (runs per request)	Always fresh	Slower (server work per request)	Highly dynamic, user-specific content
CSR	None	Fresh after JS loads	Slow initial render	Authenticated dashboards, apps

Common Pitfalls

A few mistakes account for most ISR problems in production.

Setting revalidate too low (a few seconds) on high-traffic pages can effectively turn ISR into SSR, since pages regenerate almost continuously and lose most of the performance benefit.

ISR requires a Node.js server runtime (such as next start, or hosting on a platform that supports it) — it does not work with a fully static export (output: 'export'), since there’s no server present to handle regeneration requests.

For dynamic routes generated after build time, the fallback behavior in generateStaticParams (App Router) or getStaticPaths (Pages Router) determines whether new pages are blocked-and-rendered on first request or shown as a loading state — getting this wrong is a common source of confusing first-visit behavior on new content.

Why This Matters For Your Business

This isn’t just a detail for developers — it affects how much your website costs to run, how fast it loads for customers, and whether it shows up properly in Google and AI search results.

Online stores and product catalogs

Prices, stock levels, and seasonal listings change constantly. With the old approach, updating even one product often meant rebuilding the entire site — slow and expensive once you have thousands of products. This approach updates each product page on its own, so a single price change doesn’t touch anything else. Connected to your inventory system, a stock update can show up on the live site within seconds instead of waiting for the next full site update.

Blogs, news sites, and content-heavy businesses

New articles go live instantly without taking the whole site down to rebuild it, while older pages that rarely change keep loading instantly at almost no extra cost. There’s also something many business owners don’t realize: if a site relies too heavily on behind-the-scenes code to display its content, search engines and AI tools like ChatGPT or Google’s AI search may not actually see that content at all. Set up correctly, every visitor — human or search engine — sees the full page right away.

Marketing pages and lead generation

Pages built to convert visitors into customers — pricing pages, landing pages, sign-up forms — need to load instantly. Even a one-second delay can measurably hurt how many visitors turn into leads or customers. This approach gives those pages instant load speed, while still letting your marketing team update pricing, offers, or testimonials without waiting on a developer to push a full site update.

If you’re not sure whether your website is actually set up to support your search rankings and sales goals — rather than just being convenient to build — that’s worth a second look.

Frequently Asked Questions

What’s the actual difference between ISR and SSR?

SSR renders a page from scratch on every single request. ISR serves a cached static page and only regenerates in the background, after a set interval has passed — most visitors never trigger a server render at all.

Does ISR work with a fully static export?

No. output: 'export' produces a static site with no server, so there’s nothing to handle background regeneration. ISR needs a running Node.js server or a hosting platform built to support it.

How do I update a page immediately instead of waiting for the revalidate timer?

Use on-demand revalidation with revalidatePath or revalidateTag, typically triggered by a webhook from your CMS the moment content is published or edited.

Can a visitor ever see a broken or half-rendered page during regeneration?

No. The stale-while-revalidate model always serves either the previous complete version or the new complete version — regeneration happens entirely in the background.

Does serving a stale page temporarily hurt SEO?

Not meaningfully. Crawlers see the same fully-rendered static HTML a user would, and the staleness window is typically measured in seconds to minutes, not something that affects indexing or ranking.

Key Takeaways

ISR gives you the page-load speed of static generation without forcing a full rebuild every time content changes. Time-based revalidation works well for predictable content; on-demand revalidation is the right call when freshness needs to be near-instant, such as a CMS publish event. The tradeoffs to watch are runtime requirements (no static export), fallback behavior on new dynamic routes, and avoiding revalidate windows so short they erase the performance benefit entirely.

Need Help Making Sure Your Website Works For Your Business, Not Just Your Developers?

Every website is different, and the right setup depends on how big your site is, how often things change, and where your traffic comes from. If you’re not sure whether your current website is helping or hurting your search rankings and sales, get in touch through ahsanweb.com for a straightforward review.

Related Reading

• SSR: The Non-Negotiable Standard for SEO Performance
• Stop Hydration Mismatches in Next.js: A Practical Guide to SSR Stability
• SEO for Software Engineers: Moving from Crawlers to Generative AI

Conclusion

ISR isn’t a niche optimization — it’s the practical default for any content site large enough that full rebuilds are a real cost. Used well, paired with on-demand revalidation for time-sensitive content, it closes the gap between static performance and dynamic freshness almost entirely.