Incremental Static Regeneration (ISR) ist ein Verfahren aus dem Framework Next.js, bei dem statische Seiten zur Laufzeit erzeugt oder aktualisiert werden, ohne die gesamte Website neu zu bauen. Das Kürzel ISR hat auch andere Bedeutungen, hier geht es um die Rendering-Technik.
Wie funktioniert ISR?
Beim Build werden Seiten vorgerendert und zwischengespeichert. Läuft die eingestellte Revalidierungszeit ab, liefert die nächste Anfrage noch die gecachte, nun veraltete Seite aus. Im Hintergrund entsteht eine neue Version, die danach die bisherige ersetzt. Alternativ lässt sich der Cache gezielt per revalidatePath oder revalidateTag ungültig machen. Schlägt die Neuerzeugung fehl, bleibt die zuletzt erfolgreiche Version erhalten. Die Next.js-Dokumentation empfiehlt eine eher hohe Revalidierungszeit, zum Beispiel eine Stunde statt einer Sekunde.
Ein Statusheader x-nextjs-cache zeigt, ob eine Antwort aus dem Cache kam (HIT), veraltet war (STALE), frisch gerendert wurde (MISS) oder per On-Demand-Revalidierung neu entstand (REVALIDATED). ISR läuft nicht bei einem statischen Export. Die Beschreibung gilt für ISR ohne Cache Components, für die Next.js eine eigene Anleitung führt (Doku-Stand Oktober 2026).
| Art | Wo und wann entsteht das HTML? | Inhalt schon im ausgelieferten HTML? | Einordnung durch Google |
|---|---|---|---|
| Client-Side Rendering (CSR) | im Browser per JavaScript; Daten, Templates und Routing laufen auf dem Client | nein, erst nach Ausführen von JavaScript | Google rendert Seiten mit Status 200 in einem eigenen Schritt nach dem Crawlen und empfiehlt Server-Side- oder Pre-Rendering, weil nicht alle Bots JavaScript ausführen |
| Server-Side Rendering (SSR) | auf dem Server, bei jeder Anfrage | ja | von Google als Lösung empfohlen (statt Dynamic Rendering) |
| Static Site Generation (SSG, statisches Rendering) | beim Build; meist vorab eine HTML-Datei je URL | ja | von Google als Lösung empfohlen (statt Dynamic Rendering) |
| Incremental Static Regeneration (ISR) (dieser Begriff) | beim Build vorgerendert; nach Ablauf der Revalidierungszeit erzeugt der Server die Seite im Hintergrund neu (Framework-Funktion, z. B. Next.js) | ja, aus dem Cache; bis zur Neuerzeugung wird die ältere Version ausgeliefert | keine eigene Angabe von Google |
| Prerendering | beim Build; die clientseitige App wird ausgeführt und ihr Startzustand als statisches HTML gespeichert | ja (Startzustand) | Google nennt Server-Side- oder Pre-Rendering weiterhin „eine gute Idee“, weil es Seiten für Nutzer und Crawler schneller macht |
| Dynamic Rendering | ein Rendering-Server erzeugt HTML nur für erkannte Crawler; Nutzer erhalten die clientseitig gerenderte Version | nur in der Version für Crawler | laut Google ein Workaround und keine dauerhafte Lösung; gilt nicht als Cloaking, solange Nutzer und Crawler ähnliche Inhalte sehen |
Als Ersatz für Dynamic Rendering nennt Google Server-Side Rendering, statisches Rendering und Hydration. Der ältere web.dev-Artikel „Rendering on the Web“ bezeichnet Dynamic Rendering noch als erwägenswerte Option; die Tabelle folgt der aktuellen Google-Search-Central-Doku. ISR ist kein Webstandard, die Beschreibung stammt aus der Next.js-Dokumentation. Prerendering hat im Sprachgebrauch weitere Bedeutungen; hier ist die Definition von web.dev gemeint. Quellen: 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). Stand: .
Bedeutung für SEO
Crawler erhalten fertiges HTML, sofern die Seite im Cache liegt (Einschätzung). Inhalte können nach einer Änderung bis zur nächsten Regeneration veraltet bleiben, auch für Googlebot.
Beispiel
export const revalidate = 3600;
Next.js regeneriert die Seite frühestens eine Stunde nach der letzten Erzeugung, ausgelöst durch die nächste Anfrage.
Quellen
Stand: