SSG erklärt — Static Site Generation für Webseiten

Direkte Antwort

SSG: Static Site Generation bedeutet, dass das komplette HTML einer Seite einmal beim Veröffentlichen erzeugt wird und danach als fertige Datei bereitliegt. Besucher, Suchmaschinen und KI-Assistenten bekommen dieselbe, sofort lesbare Seite — ohne dass bei jedem Aufruf Code läuft. Praktisch heißt das: Für Leistungs-, Themen- und Regionsseiten ist SSG meist der schnellste und robusteste Weg.

Wichtigste Punkte

SSG erzeugt das HTML beim Build; jeder Besucher erhält dieselbe vorgebaute Datei.
Ideal für Seiten, die sich nach Redaktionsplan ändern: Leistungen, Themen, Regionen, Glossar.
Vollständiges HTML hilft Crawlern und der Extraktion durch KI und liefert starke LCP-Werte.
Personalisierte oder sekündlich wechselnde Teile brauchen SSR, API-Aufrufe oder ISR.

— Steve Baka

Aktualisiert: 6. Oktober 2026 · Autor: Steve Baka

Was ist SSG?

Static Site Generation ist ein Rendering-Modell, bei dem die Seiten nicht erst im Moment des Aufrufs, sondern vorab erzeugt werden. Beim Build ruft das Framework für jede Route die nötigen Daten ab, rendert die Komponenten zu HTML und speichert das Ergebnis als Datei. Beim Aufruf liefert der Server — oder besser ein CDN — nur noch diese Datei aus. Es gibt keine Datenbankabfrage, keinen PHP-Prozess und keine Wartezeit auf eine Template-Engine.

Der Gegenentwurf ist Server-Side Rendering, bei dem das HTML pro Anfrage frisch entsteht, und das reine Client-Side Rendering, bei dem der Browser erst JavaScript lädt und die Seite selbst zusammenbaut. Frameworks wie Next.js erlauben es, diese Modelle pro Seite zu mischen: Die Leistungsseite ist statisch, ein Kundenbereich serverseitig, ein kleines Widget clientseitig.

Der Begriff „statisch“ führt oft in die Irre. Eine statisch generierte Seite ist nicht unbedingt „unbeweglich“: Sie kann Formulare, Animationen, Suchfelder und Live-Daten enthalten. Statisch ist nur, wann das Grund-HTML entsteht.

Wie funktioniert SSG im Ablauf?

Inhalte liegen als Dateien, in einem CMS oder einer Datenbank vor.
Der Build ermittelt alle Routen, lädt die Daten und rendert HTML.
Die Ausgabe — HTML, CSS, JavaScript, Bilder — wird auf eine Hosting-Plattform wie Vercel hochgeladen.
Das CDN verteilt die Dateien an viele Standorte; Anfragen werden aus dem Cache beantwortet.
Bei neuem Inhalt läuft ein neuer Build, oder ISR erneuert einzelne Seiten im Hintergrund.

Der Preis ist Aktualitätslatenz: Zwischen Redaktionsänderung und Sichtbarkeit liegt ein Build. Bei Marketingseiten ist das unkritisch. Bei Preislisten, Lagerbeständen oder Newsfeeds nutzt man ISR oder holt die Daten live nach.

Warum ist SSG für Core Web Vitals und KI relevant?

Weil das HTML schon fertig ist, sind Antwortzeit und Time to First Byte minimal — das schafft die Grundlage für gute Core Web Vitals. Der größte sichtbare Inhaltsblock steht ohne Umwege im Dokument; Layout-Sprünge entstehen seltener, weil keine Skripte den Aufbau verzögern.

Für Crawler und KI-Systeme ist die Wirkung noch größer. Viele KI-Crawler führen kein oder nur begrenzt JavaScript aus. Eine statisch generierte Seite zeigt Texte, Überschriften, FAQ und strukturierte Daten direkt im ersten Response. Das ist die Voraussetzung für Extrahierbarkeit und damit dafür, dass du in Antworten zitiert werden kannst. Pagebuilder-Seiten, die Inhalte erst per Skript aufbauen, scheitern genau hier.

Wann passt SSG — und wann nicht?

Gut geeignet: Unternehmens- und Leistungsseiten, Blog und Fachartikel, Themen- und Regionshubs, Glossare, Landingpages, Dokumentation.

Nur mit Ergänzung: Seiten mit Nutzer-Login, Warenkorb, individuellen Preisen oder Echtzeitdaten. Hier kombinierst du eine statische Hülle mit serverseitigen oder clientseitigen Datenabrufen.

Ungeeignet allein: Millionen von Seiten, die sich stündlich ändern — dort wären Builds zu lang. Genau dafür gibt es ISR und SSR.

Wie setzt Modern Stack SSG ein?

Die meisten öffentlichen Seiten von Modern Stack — Startseite, Leistungsseiten, Themen, Regionen, Glossar — sind statisch generiert und liegen am Edge von Vercel. Inhalte stammen aus gepflegten Katalogdateien; bei jedem Content-Update läuft ein neuer Deploy. Für Bereiche mit Daten, etwa Anfragen oder individuelle Berichte, nutzen wir serverseitiges Rendering. Diese Mischung beschreiben wir ausführlich im Thema SSR/SSG-Stack. Nach einer WordPress-Migration ist der Unterschied messbar: weniger Server-Last, kürzere Ladezeiten und HTML, das Maschinen ohne Umwege lesen.

Quellen

web.dev — Rendering on the Web — Google web.dev
Vergleicht statisches Rendering, SSR und Client-Rendering mit Auswirkungen auf Performance und SEO.
Next.js — Static Exports — Next.js
Herstellerdokumentation zur statischen Erzeugung von Seiten.
Next.js — Incremental Static Regeneration — Next.js
Beschreibt, wie statische Seiten ohne vollständigen Rebuild aktualisiert werden.
SSR/SSG-Stack — Modern Stack
Praxis, wie wir Rendering-Modelle für Marketing-Webseiten kombinieren.

Häufige Fragen

Wie werden Änderungen bei SSG sichtbar?

Durch einen neuen Build und Deploy oder durch Incremental Static Regeneration (ISR), die einzelne Seiten im Hintergrund neu erzeugt. Für Redaktions- und Marketingseiten ist der Content-Deploy der Normalfall.

Geht SSG mit Formularen und dynamischen Funktionen?

Ja. Die Seite ist statisch, das Formular sendet seine Daten an eine Server-Funktion oder API. Auch kleine interaktive Bausteine laufen als Client-Komponenten, ohne dass die ganze Seite dynamisch werden muss.

Ist SSG besser als SSR?

Nicht grundsätzlich, aber für Inhalte, die für alle gleich sind, meist einfacher, schneller und günstiger. SSR lohnt sich bei Personalisierung oder Daten, die sich ständig ändern.

Weiterlesen

SSR
SSR (Server-Side Rendering) erzeugt das HTML einer Seite auf dem Server pro Anfrage, statt es dem Browser per JavaScript zusammenbauen zu lassen. Crawler, Assistenten und Nutzer erhalten den Inhalt sofort im ersten Response.
SSR/SSG-Stack
Warum servergerendertes und statisch generiertes HTML die Basis für Performance, Crawlability und KI-Extraktion ist — und warum eine reine React-SPA für Marketingseiten meist nicht reicht.
ISR
ISR (Incremental Static Regeneration) erneuert statisch erzeugte Seiten nach einem Zeitintervall oder auf Abruf im Hintergrund — ohne die gesamte Webseite neu zu bauen. Besucher bekommen schnelle statische Antworten, Inhalte bleiben trotzdem aktuell.
Next.js
Next.js ist ein React-Framework von Vercel für Webanwendungen und Unternehmensseiten. Es rendert Seiten auf dem Server oder vorab (SSR, SSG, ISR) und liefert fertiges HTML — gut für Geschwindigkeit, Suche und KI.
Crawlability
Crawlability beschreibt, ob Suchmaschinen-Crawler und KI-Assistenten deine Inhalte erreichen und lesen dürfen und können. Gesperrte Bots, fehlerhafte Statuscodes, Soft-404 und leere JavaScript-Hüllen verhindern sie.
Core Web Vitals
Core Web Vitals sind Googles drei Nutzererlebnis-Kennzahlen: LCP (Ladezeit des größten Elements), INP (Reaktionszeit auf Eingaben) und CLS (visuelle Stabilität). Sie fließen in die Suche ein und zeigen Timeout- und Abbruchrisiken auch für KI-Crawler.
CDN
Ein CDN (Content Delivery Network) ist ein verteiltes Netz aus Cache-Servern (PoPs), das statische und oft auch gerenderte Dateien geografisch nah am Nutzer ausliefert — statt alles vom Origin-Server zu ziehen.