Glossar Static Site Generation (SSG)
Bei der statischen Generierung entsteht das HTML jeder Seite ein einziges Mal, beim Bauen des Projekts, und wird als Datei abgelegt. Ruft jemand sie auf, liefert der Server nur diese Datei aus — im Moment des Abrufs wird nichts mehr berechnet.
Das Schnellste und Robusteste, was man ausliefern kann — mit einer Bedingung: Der Inhalt ändert sich erst, wenn etwas neu baut.
Beim Bauen läuft ein Programm über die Inhalte — Dateien, ein CMS, eine Datenbank — und schreibt für jede Adresse eine fertige HTML-Datei. Danach ist das Ergebnis ein Ordner voller Dateien.
Diese Dateien brauchen keinen Anwendungsserver. Sie können auf einem einfachen Webserver oder direkt in einem CDN liegen, geografisch verteilt, nahe an den Besuchern.
Der Crawler bekommt den vollständigen Inhalt in der ersten Antwort. Es gibt keine Warteschlange fürs Rendern, kein JavaScript, das fehlschlagen kann, und keine Datenabfrage, die im falschen Moment ins Leere läuft.
Dazu kommt die Antwortzeit. Eine fertige Datei aus einem CDN ist in wenigen Millisekunden da — das hilft dem LCP und macht das Crawling billiger, weil jeder Abruf weniger kostet.
Was gebaut ist, bleibt so, bis neu gebaut wird. Ändert sich ein Preis, ein Lagerbestand oder eine Öffnungszeit, sieht die Seite das nicht — bis ein Bauvorgang läuft.
Bei wenigen hundert Seiten ist das gleichgültig, ein Bau dauert Sekunden. Bei Zehntausenden wird es zur Rechenaufgabe: Ein vollständiger Bau kann Minuten bis Stunden brauchen, und das für eine Änderung an einer einzigen Seite.
Dagegen gibt es zwei Antworten. Inkrementelles Bauen erneuert nur, was sich geändert hat. Nachträgliche Erneuerung liefert die alte Fassung aus und baut die betroffene Seite im Hintergrund neu — der nächste Aufruf bekommt die frische.
Für Suchmaschinen sind beide gleichwertig — der Inhalt steht in der ersten Antwort. Die Wahl entscheidet sich an zwei anderen Fragen.
Wie oft ändert sich der Inhalt? Ein Glossareintrag ändert sich selten, ein Lagerbestand ständig. Hängt die Seite vom Betrachter ab? Preise je Land, ein Warenkorb, ein angemeldeter Zustand — das kann eine Datei nicht abbilden.
Ein Nachschlagewerk, ein Blog, eine Dokumentation sind die klaren SSG-Fälle. Ein Warenkorb ist der klare SSR-Fall. Dazwischen wird gemischt, Seite für Seite.
Drei Lagen sprechen dagegen. Sehr viele Seiten mit häufigen Änderungen — dort wird die Bauzeit zum Engpass, und ohne inkrementelles Bauen wartet jede Korrektur auf den nächsten vollständigen Lauf.
Inhalt, der pro Person verschieden ist — er lässt sich nicht vorproduzieren. Sehr kurze Aktualisierungszyklen, etwa Live-Preise, brauchen einen anderen Weg.
Auch hier gilt: keine Entscheidung fürs ganze Projekt. Der Katalog kann statisch sein und der Warenkorb serverseitig, in derselben Anwendung.
Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.
Audit anfragenFür den Crawler sind beide gleichwertig: In beiden Fällen steht der Inhalt in der ersten Antwort. Der Vorteil von SSG liegt bei Geschwindigkeit und Robustheit, nicht bei der Indexierung. Wer zwischen beiden wählt, entscheidet über Aktualität und Kosten, nicht über SEO.
Für einen Teil davon, ja. Produktseiten, Kategorien und redaktionelle Inhalte eignen sich gut, Warenkorb, Live-Preis und angemeldeter Zustand nicht. Üblich ist eine gemischte Seite, und diese Mischung ist der Normalfall.
Die praktische Grenze ist nicht die Seitenzahl, sondern die Bauzeit. Tausende sind unproblematisch; ab Zehntausenden lohnt der Blick, ob das Werkzeug inkrementell baut — sonst zieht jede kleine Änderung einen vollständigen Lauf nach sich.
Im Ergebnis wenig: In beiden Fällen liegt fertiges HTML vor der Anfrage bereit. Der Unterschied liegt im Zweck. SSG ist die Bauweise der ganzen Seite; Prerendering ist meist ein Zusatz zu einer Anwendung, die sonst im Browser rendert.
Ja. Das HTML kommt fertig an, und JavaScript ergänzt danach, was nötig ist — eine Suche, ein Filter, ein Formular. Wichtig für den Crawler ist nur, dass der Inhalt nicht davon abhängt, dass dieser Code läuft.