Static Site Generation (SSG) bedeutet, dass die HTML-Dateien einer Website schon beim Build erzeugt werden, nicht erst beim Aufruf. Der Server liefert fertige, statische Dateien aus, häufig über ein CDN. Das gängige Werkzeug dafür ist ein Static Site Generator wie Next.js im Export-Modus, Astro, Hugo oder Eleventy.
Wie funktioniert SSG?
Beim Build läuft der Code einmal pro Seite und schreibt das Ergebnis als HTML-Datei. Next.js beschreibt das so: next build erzeugt eine HTML-Datei je Route, die auf jedem Webserver ausgeliefert werden kann, der statische Dateien bereitstellt. web.dev nennt als Vorteil eine schnelle erste Darstellung (FCP) und eine durchgehend niedrige TTFB, da der Server nichts berechnen muss.
Grenzen
- Änderungen brauchen einen neuen Build. Ändert sich ein Inhalt, muss die Seite neu erzeugt und veröffentlicht werden. Verfahren wie Incremental Static Regeneration (ISR) erneuern einzelne Seiten ohne vollständigen Build, in Next.js allerdings nicht im reinen statischen Export.
- Viele dynamische Seiten. web.dev nennt es anspruchsvoll bis undurchführbar, wenn sich die URLs nicht vorab bestimmen lassen oder die Website sehr viele einzigartige Seiten hat.
- Keine Logik pro Anfrage. Cookies, Redirects und Header-Regeln der Next.js-Konfiguration gehören laut Doku zu den Funktionen, die im statischen Export nicht unterstützt werden.
SSG und SEO
Das fertige HTML enthält den Inhalt bereits. Crawler müssen kein JavaScript ausführen, um Text und Links zu sehen. Google empfiehlt statt Dynamic Rendering, das es als Workaround und nicht als empfohlene Lösung bezeichnet, Server-Side Rendering, Static Rendering oder Hydration.
| 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) (dieser Begriff) | beim Build; meist vorab eine HTML-Datei je URL | ja | von Google als Lösung empfohlen (statt Dynamic Rendering) |
| Incremental Static Regeneration (ISR) | 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: .
Beispiel
npm run build
# erzeugt z. B. out/index.html, out/blog/post-1.html
Die Dateien aus out/ liegen anschließend auf einem Webserver oder CDN. Jede URL entspricht einer fertigen HTML-Datei.
Häufige Fehler
- Dynamische Routen ohne bekannte Parameter. In einem statischen Next.js-Export sind dynamische Routen ohne
generateStaticParams()nicht unterstützt. Das Framework meldet das schon in der Entwicklung als Fehler. - Serverkonfiguration für 404 vergessen. Die Next.js-Doku zeigt für einen statischen Host wie Nginx eine Konfiguration mit
try_files $uri $uri.html $uri/ =404underror_page 404 /404.html, damit unbekannte URLs mit dem Status 404 antworten. - Static Rendering mit Prerendering gleichsetzen. Laut web.dev sind statisch gerenderte Seiten auch ohne viel JavaScript bedienbar. Prerendering verbessert dagegen nur die erste Darstellung einer Single-Page-Application, die im Browser noch starten muss. Ein Test mit abgeschaltetem JavaScript zeigt den Unterschied.
Quellen
Stand: