Static Site Generation (SSG)

Was ist Static Site Generation (SSG)?

Static Site Generation (SSG) bezeichnet ein Verfahren, bei dem vollständige HTML-Seiten bereits während eines Build-Prozesses erzeugt werden. Der Webserver liefert diese vorbereiteten Dateien direkt aus, statt Inhalte bei jedem Aufruf neu zu berechnen. Das kann Ladezeiten, Crawling und Stabilität verbessern, erfordert aber einen geregelten Prozess für Aktualisierungen.

Wie Static Site Generation funktioniert

Static Site Generation (SSG), deutsch: statische Seitengenerierung, verarbeitet Inhalte, Templates und Daten vor der Veröffentlichung. Ein Generator erstellt daraus für jede vorgesehene URL eine fertige HTML-Datei. Beim späteren Seitenaufruf muss der Server keine Datenbank abfragen und kein Template zusammensetzen, sondern liefert die bereits erzeugte Datei aus.

Der Build-Prozess kann beispielsweise Inhalte aus Markdown-Dateien, einem Headless-CMS, einer Programmierschnittstelle oder einem Produktdatenbestand beziehen. Ändert sich eine Quelle, startet ein neuer Build. Die aktualisierten HTML-, CSS- und JavaScript-Dateien werden anschließend auf dem Hosting oder in einem Content Delivery Network, kurz CDN, bereitgestellt.

Quelldaten: Texte, Bilder, Produktinformationen und Metadaten werden aus Dateien oder externen Systemen geladen.
Build: Templates und Quelldaten werden zu vollständigen Seiten zusammengeführt.
Deployment: Die erzeugten Dateien werden auf den Webserver oder ein CDN übertragen.
Auslieferung: Browser und Crawler erhalten das vorbereitete HTML ohne erneute serverseitige Berechnung.

Static Site Generation bedeutet nicht, dass eine Website ohne JavaScript auskommen muss. Navigation, Formulare, Suche, Filter oder personalisierte Bereiche können weiterhin im Browser ausgeführt oder über APIs angebunden werden. Statisch ist zunächst die Erzeugung des HTML-Dokuments, nicht zwangsläufig jede Funktion der Website.

Vorteile von Static Site Generation

Static Site Generation reduziert die Arbeit, die bei einem einzelnen Seitenaufruf auf dem Server anfällt. Da das HTML bereits vorhanden ist, entfallen für öffentliche Inhalte häufig Datenbankabfragen und die serverseitige Erzeugung des Dokuments. Das erleichtert Caching und erlaubt die Auslieferung über geografisch verteilte CDN-Server.

Die mögliche Geschwindigkeitsverbesserung ist jedoch kein Automatismus. Große Bilder, blockierende Skripte, umfangreiche Schriftdateien oder nachgeladene Komponenten können auch eine statisch generierte Seite verlangsamen. Static Site Generation optimiert vor allem die Bereitstellung des Ausgangsdokuments. Für gute Core Web Vitals müssen alle weiteren Ressourcen ebenfalls geprüft werden.

Ein vereinfachtes Beispiel: Ein Projekt enthält 500 veröffentlichte URLs. Der Build-Prozess erzeugt 500 HTML-Dateien, bevor die Website online geht. Ruft ein Nutzer eine dieser URLs auf, wird die vorhandene Datei ausgeliefert. Ändert sich ein Text, muss je nach System die betroffene Seite oder das gesamte Projekt neu erzeugt und veröffentlicht werden.

Static Site Generation im SEO

Static Site Generation kann technisches SEO erleichtern, weil Titel, Meta-Description, Überschriften, interne Links, strukturierte Daten und Hauptinhalte bereits im initialen HTML stehen können. Suchmaschinen müssen dann nicht erst JavaScript ausführen, um den wesentlichen Seiteninhalt zu erkennen. Das vereinfacht auch die Prüfung durch SEO-Crawler.

Ein verbreiteter Denkfehler besteht darin, statisch generiertes HTML automatisch mit guter Indexierbarkeit gleichzusetzen. Eine fertige HTML-Datei wird nur indexiert, wenn die URL erreichbar ist, einen geeigneten HTTP-Statuscode liefert, nicht durch Robots-Anweisungen ausgeschlossen wird und über interne Links oder eine Sitemap auffindbar ist. Prüfe deshalb nicht nur den Quelltext, sondern auch Statuscodes, Canonicals, Indexierungsregeln und interne Verlinkung.

Messbar ist die technische Qualität zum Beispiel so: Vergleiche den an den Browser ausgelieferten HTML-Quelltext mit dem gerenderten Dokument und prüfe, ob Hauptinhalt, Canonical Tag, Meta-Robots-Angabe und interne Links bereits vor der JavaScript-Ausführung vorhanden sind. Ein Technik-Crawler für automatisierte Website-Checks kann zusätzlich Statuscodes, Weiterleitungsketten, fehlende Metadaten und fehlerhafte interne Links erfassen.

Für die Ladezeit solltest du Feld- und Labordaten getrennt betrachten. Labortests simulieren einen einzelnen Abruf unter festgelegten Bedingungen. Felddaten bilden reale Besuche über einen längeren Zeitraum ab. Ein schneller Serverabruf allein belegt daher noch keine gute Nutzererfahrung. Der kostenlose Ladezeiten-Check liefert einen ersten Überblick über mobile und stationäre PageSpeed-Werte.

Prüfe die Ladeleistung deiner statisch generierten Seiten direkt im Artikel:

Mit Nutzung dieses PageSpeed-Checks erklären Sie, dass Sie die Datenschutzerklärung zur Kenntnis genommen haben und damit einverstanden sind, dass die von Ihnen angegebenen Daten elektronisch erhoben und gespeichert werden. Ihre Daten werden dabei nur streng zweckgebunden zur Bearbeitung des PageSpeed-Checks benutzt. Mit der Nutzung dieses PageSpeed-Checks erklären Sie sich mit der Verarbeitung einverstanden.

Ladezeiten-Score: N/A von 100

i Ladezeiten (Desktop):	N/A
i Ladezeiten (Mobile):	N/A
i PageSpeed (Desktop):	N/A
i PageSpeed (Mobile):	N/A
i CMS:
i Gehosted bei:
i WordPress Theme:

Ladezeiten (Desktop)

Ladezeiten (Mobile)

SSG, SSR und CSR im Vergleich

Der Unterschied zwischen Static Site Generation, Server-Side Rendering und Client-Side Rendering liegt im Zeitpunkt und Ort der HTML-Erzeugung. SSG erzeugt das HTML vor einem Seitenaufruf. Server-Side Rendering, kurz SSR, erzeugt das HTML auf dem Server für eine konkrete Anfrage. Client-Side Rendering, kurz CSR, baut wesentliche Teile der Seite erst im Browser mit JavaScript auf.

Verfahren	Zeitpunkt der Erzeugung	Typischer Vorteil	Typische Grenze
SSG	Vor der Veröffentlichung	Direkt auslieferbares HTML und gutes Caching	Änderungen können einen neuen Build erfordern
SSR	Bei der Serveranfrage	Aktuelle und anfrageabhängige Inhalte	Mehr Rechenarbeit während des Abrufs
CSR	Im Browser	Interaktive Anwendungen und dynamische Ansichten	Hauptinhalte können von JavaScript abhängig sein

Incremental Static Regeneration, kurz ISR, ergänzt das SSG-Prinzip um eine gezielte Neuerzeugung. Statt bei jeder Änderung alle URLs neu zu bauen, kann ein System einzelne Seiten nach einer festgelegten Zeit oder nach einem Ereignis aktualisieren. Die konkrete Umsetzung hängt vom eingesetzten Framework und der Hosting-Infrastruktur ab.

Wann eignet sich SSG?

Static Site Generation eignet sich besonders für Inhalte, die sich seltener ändern und für viele Besucher identisch sind. Dazu gehören Unternehmensseiten, Ratgeber, Glossare, Dokumentationen, Landingpages und redaktionelle Themenbereiche. Auch größere Projekte können SSG verwenden, wenn Builds, Datenquellen und Veröffentlichungen zuverlässig automatisiert sind.

Der Hauptinhalt ist öffentlich und muss nicht pro Nutzer berechnet werden.
Änderungen können über einen geregelten Build- und Deployment-Prozess veröffentlicht werden.
Die Anzahl der Seiten lässt sich innerhalb akzeptabler Build-Zeiten verarbeiten.
Interaktive Funktionen können getrennt über JavaScript oder APIs eingebunden werden.

Für stark personalisierte Kontobereiche, Live-Bestände, Warenkörbe oder Inhalte mit sekündlichen Änderungen ist eine ausschließlich statische Architektur häufig unpassend. Solche Projekte kombinieren SSG oft mit SSR, APIs oder clientseitigen Komponenten. Die passende Architektur richtet sich deshalb nach der Aktualität jeder Inhaltsart und nicht nur nach der Gesamtgröße der Website.

Der häufigste SEO-Fehler bei Static Site Generation ist ein unvollständiger Veröffentlichungsprozess. Wenn eine Seite im CMS existiert, aber der Build nicht ausgelöst wurde, bleibt online eine veraltete Version stehen oder die neue URL fehlt vollständig. Kontrolliere nach jedem Deployment stichprobenartig Inhalte, Statuscodes, Canonicals, Sitemap-Einträge und interne Links.

Technische Prüfung vor dem Start

Eine SSG-Website sollte vor der Veröffentlichung wie ein Relaunch geprüft werden. Wichtig sind erreichbare Ziel-URLs, konsistente Canonical Tags, eine aktuelle XML-Sitemap, korrekte Weiterleitungen und interne Links auf die endgültigen Adressen. Auch eine statische Website kann durch fehlerhafte Templates denselben Fehler auf Tausenden Seiten ausrollen.

Eine sinnvolle Qualitätssicherung umfasst mindestens einen vollständigen Crawl der Testumgebung, einen Vergleich alter und neuer URLs sowie eine Prüfung des ausgelieferten HTML. Der Leitfaden zum Management technischer SEO-Fehler zeigt, welche Kontrollen dauerhaft in den Betrieb gehören. Bei einer neuen Architektur sollte außerdem die Website-Entwicklung mit SEO-Fokus bereits Templates, Metadaten und Indexierungsregeln berücksichtigen.

Häufige Fragen zu Static Site Generation

Kann Google statisch generierte Seiten indexieren?

Ja. Google kann statisch generierte Seiten indexieren, wenn die URLs erreichbar, crawlbar und für die Indexierung freigegeben sind. Interne Links, eine XML-Sitemap und korrekte Canonical Tags helfen dabei, die vorgesehenen URLs eindeutig zuzuordnen.

Ist SSG automatisch schneller als eine dynamische Website?

SSG verkürzt häufig die serverseitige Verarbeitung, garantiert aber keine schnelle Seite. Bilder, JavaScript, CSS, Schriftdateien und externe Dienste beeinflussen weiterhin die Ladeleistung und die Core Web Vitals.

Wie werden Inhalte auf einer SSG-Website aktualisiert?

Eine Inhaltsänderung löst normalerweise einen neuen Build und ein anschließendes Deployment aus. Je nach System kann das gesamte Projekt oder nur eine betroffene Auswahl von Seiten neu erzeugt werden.

Kann eine SSG-Website Formulare und Suche enthalten?

Ja. Formulare, Suchfunktionen und andere interaktive Elemente können über JavaScript, APIs oder externe Dienste eingebunden werden. Das grundlegende HTML der Seite bleibt dabei statisch generiert.

Eignet sich SSG für Onlineshops?

SSG kann für Kategorieseiten, Ratgeber und andere überwiegend stabile Shop-Inhalte geeignet sein. Preise, Verfügbarkeit, Warenkorb und Kundenkonto benötigen häufig zusätzliche dynamische Komponenten oder eine hybride Rendering-Architektur.

Warum erscheint eine neue SSG-Seite nicht bei Google?

Eine neue SSG-Seite kann fehlen, wenn der Build oder das Deployment nicht ausgeführt wurde, die URL intern unverlinkt ist oder Indexierungsregeln den Zugriff verhindern. Prüfe außerdem den HTTP-Statuscode, das Canonical Tag und den Eintrag in der XML-Sitemap.

Wenn du eine neue Website planst oder eine bestehende Architektur auf SSG umstellen möchtest, sollte die technische SEO-Prüfung bereits vor dem ersten Deployment beginnen.

Kostenlosen Potenzialcheck anfragen

Sie haben noch Fragen?

Kontaktieren Sie uns