Incremental static regeneration (ISR) is a caching strategy that serves pre-rendered static pages and regenerates them in the background after a set time or on demand, without rebuilding the whole site. The abbreviation ISR has other meanings. This entry covers the rendering technique. It originated with Next.js (Vercel’s docs list further frameworks).
How does ISR work?
Pages are pre-rendered at build time and cached. After the revalidation time has passed, the next request still receives the cached, now stale page. At the same time, a new version is generated in the background, and once that succeeds it replaces the cached one. A page that was not pre-rendered can be generated on first request. If regeneration fails, the last successfully generated version keeps being served.
The cache can also be invalidated directly, for example with revalidatePath or revalidateTag in Next.js. The Next.js documentation recommends a high revalidation time, one hour rather than one second. ISR is not supported for static exports. This describes ISR without Cache Components, which Next.js documents separately (docs as of October 2026).
| Approach | Where and when is the HTML built? | Content in the delivered HTML? | Google's position |
|---|---|---|---|
| Client-side rendering (CSR) | in the browser with JavaScript; data fetching, templating and routing run on the client | no, only after JavaScript has run | Google renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript |
| Server-side rendering (SSR) | on the server, for each request | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Static site generation (SSG, static rendering) | at build time; usually one HTML file per URL ahead of time | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Incremental static regeneration (ISR) (this term) | prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js) | yes, from the cache; the older version is served until regeneration finishes | no specific statement from Google |
| Prerendering | at build time; the client-side app is run and its initial state saved as static HTML | yes (initial state) | Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers |
| Dynamic rendering | a rendering server builds HTML only for detected crawlers; users get the client-side rendered version | only in the version served to crawlers | Google calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content |
Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .
What does it mean for SEO?
Visitors and crawlers receive finished HTML from the cache (assessment). After a content change, the old version can be served until regeneration has finished, also to Googlebot (assessment).
Example
export const revalidate = 3600;
At the earliest one hour after the last generation, the next request triggers a new generation of the page.
Sources
Last updated: