# Incremental static regeneration

Category: [Rendering & JavaScript](https://seo-geo-glossary.com/en/glossary/category/rendering-javascript/) › [Rendering methods](https://seo-geo-glossary.com/en/glossary/category/rendering-javascript/rendering-methods/)

**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).

## 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
```javascript
export const revalidate = 3600;
```

At the earliest one hour after the last generation, the next request triggers a new generation of the page.

## Rendering approaches compared

| 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) | 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 |

Sources: [web.dev: Rendering on the Web](https://web.dev/articles/rendering-on-the-web); [Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04)](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics); [Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10)](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering); [Next.js Docs: How to implement Incremental Static Regeneration (ISR)](https://nextjs.org/docs/app/guides/incremental-static-regeneration). Last checked: October 8, 2026

*Diagram: Where the HTML is created: CSR, SSR, SSG.* ISR is not drawn in the diagram. The highlight shows static generation at build time, which ISR builds on (assessment).

## Related terms

- [Static site generation](https://seo-geo-glossary.com/en/glossary/static-site-generation/index.md)
- [Static URL](https://seo-geo-glossary.com/en/glossary/static-url/index.md)
- [Server-side rendering](https://seo-geo-glossary.com/en/glossary/server-side-rendering/index.md)
- [Rendering](https://seo-geo-glossary.com/en/glossary/rendering/index.md)
- [CDN (content delivery network)](https://seo-geo-glossary.com/en/glossary/cdn/index.md)
- [Cache-Control](https://seo-geo-glossary.com/en/glossary/cache-control/index.md)

## Sources

- [Incremental Static Regeneration (ISR) – Next.js Docs](https://nextjs.org/docs/app/guides/incremental-static-regeneration)
- [Incremental Static Regeneration – Vercel Docs](https://vercel.com/docs/incremental-static-regeneration)

---

Last updated: October 8, 2026
URL: https://seo-geo-glossary.com/en/glossary/incremental-static-regeneration/
