SSG, SSR und CSR verständlich erklärt: Rendering, ISR, SEO und Crawling für moderne Websites

Die wichtigsten Konzepte auf einen Blick

Was ist Static Site Generation (SSG)?

Static Site Generation bezeichnet ein Renderingverfahren, bei dem Webseiten bereits während des Build-Prozesses als fertige HTML-Dateien erzeugt werden. Beim späteren Seitenaufruf liefert der Server oder ein CDN diese vorbereiteten Dateien direkt aus. Dadurch entstehen häufig sehr schnelle Ladezeiten und eine stabile Grundlage für das Suchmaschinen-Crawling.

Unterschied zwischen SSG, SSR und CSR

Der zentrale Unterschied zwischen diesen drei Renderingmethoden liegt im Zeitpunkt und Ort der HTML-Erzeugung. Die folgende Tabelle zeigt die wichtigsten Unterschiede:

Für SEO und maschinelle Inhaltsanalyse ist es meist vorteilhaft, wenn der Hauptinhalt bereits im initial ausgelieferten HTML enthalten ist. Das ermöglicht es Suchmaschinen und KI-Systemen, die Inhalte direkt zu erfassen, ohne auf zusätzliche Rendering-Schritte angewiesen zu sein.

Was ist Incremental Static Regeneration (ISR)?

Incremental Static Regeneration erlaubt es, statische Seiten nach dem ursprünglichen Build gezielt zu aktualisieren, ohne die gesamte Website neu zu erzeugen. Einzelne Seiten werden dabei im Hintergrund neu generiert, während die vorhandene Version weiterhin ausgeliefert wird. Das ermöglicht es, die Vorteile statischer Websites mit der Flexibilität häufiger Inhalts-Updates zu kombinieren.

Warum Renderingstrategien für SEO, Crawling und moderne Systeme entscheidend sind

Moderne Websites bestehen häufig aus komplexen JavaScript-Architekturen. Für Suchmaschinen und KI-Systeme wie generative Sprachmodelle ist jedoch entscheidend, ob Inhalte bereits im HTML vorhanden sind oder erst durch Client-Skripte erzeugt werden.

Das praktische Problem ist folgendes: Wenn der Hauptinhalt erst im Browser generiert wird, müssen Suchsysteme zusätzliche Rendering-Schritte durchführen. Das kostet Rechenressourcen, kann die Indexierung verlangsamen und dazu führen, dass Inhalte teilweise unzugänglich bleiben. Statische oder serverseitig gerenderte Inhalte sind deshalb meist robuster für Crawling und maschinelle Analyse. Auch generative KI-Systeme können Inhalte besser verarbeiten und zitieren, wenn diese bereits im HTML vorhanden sind, statt erst nach der JavaScript-Ausführung sichtbar zu werden.

Für Publisher und Content-Plattformen sind dabei drei zentrale Fragen entscheidend:

1. Wo wird das HTML erzeugt – lokal, auf dem Server oder im Browser?
2. Wann wird eine Seite aktualisiert – einmalig beim Build oder regelmäßig?
3. Ist der Hauptinhalt im initialen HTML vorhanden oder erst nach der JavaScript-Ausführung?

Diese Fragen bestimmen maßgeblich die Sichtbarkeit in Suchmaschinen und die Zitierfähigkeit für generative Systeme.

Was ist Static Site Generation (SSG) im Detail?

Static Site Generation ist eine Methode zur Erstellung von Websites, bei der HTML-Dateien bereits während eines Build-Prozesses erzeugt werden. Der Build kann lokal auf dem Rechner eines Entwicklers stattfinden, in einer Continuous-Integration-Pipeline oder direkt auf einer Hosting-Plattform. Der typische Ablauf ist dabei standardisiert: Zunächst werden Inhalte aus verschiedenen Datenquellen geladen, etwa aus einem CMS, Markdown-Dateien oder APIs. Diese Inhalte werden dann mit Templates oder Komponenten kombiniert, um fertige HTML-Seiten zu erzeugen. Die resultierenden Dateien können anschließend direkt über einen Webserver oder ein CDN ausgeliefert werden. Da keine dynamische Berechnung beim Seitenaufruf notwendig ist, entstehen häufig sehr kurze Antwortzeiten. Ein CDN kann die statischen Dateien weltweit verteilen und dabei Latenzen stark reduzieren.

Static Site Generation eignet sich besonders gut für Seitentypen, die sich nicht bei jeder einzelnen Nutzeranfrage ändern. Dazu gehören Blogartikel und News-Archive, Dokumentationsseiten, Wissensdatenbanken und FAQs, Landingpages sowie Marketingseiten und Produktkataloge. Diese Inhalte ändern sich zwar gelegentlich, aber nicht kontinuierlich bei jedem Seitenaufruf. Das macht sie ideal für die statische Generierung. Im Gegensatz dazu sind Websites mit täglich oder stündlich wechselnden Inhalten weniger gut für SSG geeignet.

SSG, SSR und CSR: Wo wird das HTML erzeugt?

Der zentrale Unterschied zwischen Renderingstrategien liegt im Zeitpunkt und Ort der HTML-Erzeugung. Damit verbunden sind unterschiedliche Vor- und Nachteile, die je nach Anwendungsfall mehr oder weniger relevant sind.

SSG: Rendering beim Build

Bei Static Site Generation wird das HTML bereits vor dem eigentlichen Besuch erzeugt. Die fertigen Seiten liegen anschließend als statische Dateien vor und können direkt ausgeliefert werden. Die Inhalte sind bereits vorhanden, bevor der erste Nutzer oder Crawler die Seite aufruft. Dieser Ansatz bietet mehrere Vorteile:

• Schnelle Ladezeiten durch direkte Datei-Auslieferung und globales CDN-Caching
• Einfache und kostengünstige CDN-Konfiguration
• Stabile HTML-Grundlage für das Suchmaschinen-Crawling, da Inhalte direkt sichtbar sind
• Niedrige Serverkosten, da keine Berechnung auf dem Server stattfinden muss
• Hohe Verfügbarkeit, da statische Dateien einfach repliziert werden können

Ein praktisches Beispiel veranschaulicht dies: Ein Blog mit 500 Artikeln wird beim Build einmalig erzeugt. Alle Seiten liegen danach als fertige HTML-Dateien vor und können über ein CDN weltweit in unter 100 Millisekunden ausgeliefert werden. Der Server muss die Dateien nur bereitstellen, nicht berechnen. Ein Nutzer in Berlin kann Dateien von einem CDN-Server in Europa laden statt vom Origin-Server in den USA. Das führt zu sehr schnellen Ladezeiten und besseren Rankings.

SSR: Rendering bei jeder Anfrage

Beim Server-Side-Rendering wird das HTML jedes Mal neu erzeugt, wenn eine Seite aufgerufen wird. Der Server ruft Daten ab, rendert die Seite und sendet das fertige HTML an den Browser. Dieser Ansatz ermöglicht es, bei jeder Anfrage aktuelle Inhalte auszuliefern und Inhalte basierend auf Nutzer-Präferenzen zu personalisieren. Die Inhalte sind immer aktuell, da bei jedem Request neue Daten geladen werden. Suchmaschinen erhalten das vollständige HTML direkt vom Server, und personalisierte Inhalte sind basierend auf Nutzerverhalten oder Präferenzen möglich.

Der Nachteil ist jedoch erheblich: Der Server muss bei jeder Anfrage Arbeit verrichten, was zu höherer Serverbelastung führt. Dadurch entstehen längere Antwortzeiten, da der Server erst Daten laden und dann rendern muss. Das führt zu höheren Hosting-Kosten aufgrund der größeren Serverauslastung, und Caching-Strategien werden komplexer. Ein praktisches Beispiel: Eine Nachrichten-Website nutzt SSR, um bei jedem Aufruf die aktuellsten Artikel zu laden und personalisierte Inhalte basierend auf Nutzer-Präferenzen und Leseverlauf zu zeigen. Dieser Ansatz ist notwendig, weil sich die Inhalte ständig ändern.

CSR: Rendering im Browser

Beim Client-Side-Rendering wird zunächst ein minimales HTML-Grundgerüst ausgeliefert. Der eigentliche Inhalt entsteht anschließend im Browser durch JavaScript. Der Browser lädt einen JavaScript-Bundle herunter, führt es aus und rendert die Inhalte anschließend. Dieser Ansatz eignet sich gut für interaktive Anwendungen: Die Benutzerinteraktion ist sehr responsiv, und der Server wird entlastet, da die Rendering-Arbeit im Browser stattfindet. Auch Rich-Media-Anwendungen mit vielen Animationen sind damit gut umsetzbar.

Die Nachteile für SEO und Performance sind aber erheblich. Inhalte sind nicht sofort im HTML vorhanden, sondern entstehen erst nach der JavaScript-Ausführung. Das bedeutet, dass Suchmaschinen zusätzliche Rendering-Schritte durchführen müssen, was Zeit und Ressourcen kostet. Auch die Time-to-Content ist länger, da der Browser zunächst JavaScript herunterladen, analysieren und ausführen muss. Nutzer mit langsamen Verbindungen erleben dadurch lange Wartezeiten. Dieser Ansatz eignet sich gut für interaktive Web-Anwendungen wie Dashboards oder Collaboration-Tools, für Content-Websites ist CSR jedoch nicht optimal und führt oft zu schlechteren Rankings.

Warum SSG für SEO und Zitierfähigkeit häufig vorteilhaft ist

SSG bietet mehrere Eigenschaften, die für Suchmaschinen und KI-Systeme hilfreich sind und damit zu besseren Rankings und besserer Auffindbarkeit führen. Die Kombination dieser Eigenschaften macht SSG zu einer robusten Strategie für Content-Websites.

Inhalte sind direkt im HTML vorhanden

Wenn Überschriften, Haupttexte und interne Links bereits im ausgelieferten HTML enthalten sind, können Suchmaschinen diese Inhalte unmittelbar erfassen. Das reduziert die Abhängigkeit vom JavaScript-Rendering, das zusätzliche Ressourcen kostet und nicht immer zuverlässig funktioniert. Auch generative Sprachmodelle können Inhalte besser verarbeiten und zitieren, wenn diese bereits im HTML vorhanden sind, statt erst nach der JavaScript-Ausführung sichtbar zu werden. Das ist besonders wichtig, da immer mehr Nutzer KI-Systeme zur Informationsbeschaffung nutzen.

Ein praktisches Beispiel: Ein Artikel über „Beste Praktiken für Web Performance“ wird von Google vollständig indexiert und ist für generative KI-Systeme direkt zitierbar, weil der Text im HTML vorliegt. Wenn derselbe Inhalt erst nach der JavaScript-Ausführung sichtbar wäre, könnte es zu Problemen bei der Indexierung kommen. Google müsste zusätzliche Ressourcen aufwenden, um den Inhalt zu rendern, und KI-Systeme könnten ihn möglicherweise übersehen.

Hohe Ladegeschwindigkeit

Da statische Dateien direkt ausgeliefert werden können, sind SSG-Websites oft sehr schnell. Ein CDN kann die Dateien weltweit verteilen und Latenzen dadurch erheblich reduzieren. Schnelle Seiten ranken in Google besser, da Geschwindigkeit ein etablierter Ranking-Faktor ist. Außerdem konvertieren schnelle Seiten Besucher besser, da Nutzer bei langsam ladenden Seiten schnell abspringen. Studien zeigen, dass jede Sekunde Verzögerung zu einem signifikanten Rückgang der Nutzerzahlen führt.

Stabilere Inhaltsstruktur

SSG-Projekte basieren häufig auf klar strukturierten Templates. Diese Struktur erleichtert es Suchmaschinen und automatisierten Systemen, Inhalte zu analysieren und zu extrahieren. Auch interne Tools und Skripte können leichter mit dem HTML arbeiten, da die Struktur vorhersehbar ist. Das führt zu konsistenten Seiten mit klarer Hierarchie und verlässlichen Datenstrukturen, die ein Crawler zuverlässiger auslesen kann.

Risiken von SSG für SEO und Crawling

Trotz vieler Vorteile gibt es einige technische Risiken bei SSG, die bei der Planung berücksichtigt werden sollten. Mit der richtigen Strategie lassen sich diese jedoch gut in den Griff bekommen.

Veraltete Inhalte

Da Seiten beim Build erzeugt werden, können Inhalte veralten, wenn sich Datenquellen ändern. Das ist besonders problematisch bei Inhalten, die sich häufig ändern, etwa Preisangaben und Angebote, Produktdaten und Verfügbarkeitsstatus, News-Inhalte und aktuelle Events, dynamische Statistiken und Rankings sowie Lagerbestände und Reservierungen. Wenn sich beispielsweise ein Produktpreis ändert, bleibt die alte Version auf der Website sichtbar, bis die Seite neu generiert wird. Das kann zu Verwirrung bei Kunden führen und das Vertrauen in die Website beschädigen.

Die Lösung besteht darin, ISR zu nutzen oder regelmäßige Rebuilds zu planen, wenn sich Inhalte häufig ändern. Mit ISR können einzelne Seiten gezielt aktualisiert werden, ohne die gesamte Website neu zu generieren. Alternativ können häufig geänderte Inhalte über JavaScript nachgeladen werden, statt sie ins SSG-HTML zu integrieren. Dabei ist jedoch wichtig, dass der Hauptinhalt im HTML vorhanden ist und nur ergänzende Daten nachgeladen werden.

Clientseitig geladene Inhalte

Viele moderne Projekte kombinieren SSG mit clientseitigem JavaScript. Das kann zu Problemen führen, wenn zentrale Inhalte erst im Browser geladen werden. Dann entsteht ein hybrides Modell, bei dem wichtige Informationen möglicherweise nicht sofort im HTML stehen. Ein Beispiel: Ein Artikel wird mit SSG generiert, aber die Kommentare werden erst via JavaScript geladen. Suchmaschinen sehen dann keinen Kommentarbereich, und Nutzer müssen auf das Laden warten. Für Crawling und Zitierfähigkeit ist es entscheidend, dass der Hauptinhalt direkt im Dokument enthalten ist.

Die Lösung besteht darin, Hauptinhalte ins SSG-HTML zu integrieren und nur optionale Komponenten über JavaScript nachzuladen. Kommentare können nachladen, aber der Artikeltext muss im HTML vorhanden sein. Dieses Konzept nennt sich Progressive Enhancement und ist ein bewährtes Architekturmuster. Dadurch bleibt die Seite auch lesbar, wenn JavaScript fehlschlägt oder nicht unterstützt wird.

Schwache interne Verlinkung

Crawler entdecken neue Seiten vor allem über HTML-Links im <a>-Tag-Format. Wenn wichtige Seiten nur über JavaScript-Navigation oder dynamische Filter erreichbar sind, kann ihre Auffindbarkeit eingeschränkt sein, weil der Crawler die Links nicht im HTML findet. Das kann dazu führen, dass tiefer verschachtelte Seiten gar nicht indexiert werden, was zu erheblichen Sichtbarkeitsproblemen führt.

Die Lösung besteht darin, eine klare HTML-Navigation zu nutzen und eine Sitemap zu erstellen. Interne Links sollten als echte <a>-Tags mit href-Attribut implementiert sein, nicht als Buttons mit onClick-Handlern. Eine Sitemap-XML sollte alle wichtigen Seiten enthalten, damit der Crawler diese auch findet, falls die HTML-Navigation unvollständig ist.

Incremental Static Regeneration (ISR) im Detail

Incremental Static Regeneration ist ein Mechanismus, der die klassische statische Generierung erweitert. Das Ziel besteht darin, die Vorteile statischer Websites zu erhalten und gleichzeitig eine bessere Aktualisierung von Inhalten zu ermöglichen. ISR löst das Problem veralteter Inhalte bei reinem SSG und ist damit der Sweetspot zwischen Geschwindigkeit und Aktualität.

Grundprinzip von ISR

ISR ermöglicht es, einzelne Seiten nach dem ursprünglichen Build neu zu generieren, ohne die gesamte Website regenerieren zu müssen. Der Ablauf ist folgendermaßen: Eine Seite wird beim Build erzeugt, beispielsweise eine Produktseite. Nach einer bestimmten Zeit oder einem definierten Event wird sie als veraltet markiert. Beim nächsten Seitenaufruf wird im Hintergrund eine neue Version erzeugt, die die alte Version ersetzt, sobald sie fertig ist.

Ein wichtiger Aspekt dabei ist, dass die bisherige Version während der Aktualisierung weiterhin erreichbar bleibt. Nutzer erleben keine Downtime und erhalten sofort eine Antwort. Das ist ein erheblicher Vorteil gegenüber einem vollständigen Rebuild, bei dem alle Seiten neu generiert werden müssen.

Zeitbasierte Revalidierung

Bei zeitbasierter ISR wird eine Seite nach einem definierten Zeitraum aktualisiert. Der Administrator legt beispielsweise fest, dass eine Seite alle 60 Sekunden neu generiert wird. Dieser Ansatz eignet sich für Inhalte mit regelmäßigen, aber nicht kontinuierlichen Änderungen. Ein praktisches Beispiel: Produktpreise ändern sich täglich einmal am Morgen. Mit zeitbasierter ISR kann man konfigurieren, dass die Preisseiten alle 24 Stunden neu generiert werden. Diese Art der Revalidierung ist einfach zu implementieren, aber weniger präzise als die On-Demand-Revalidierung.

On-Demand-Revalidierung

Eine präzisere Variante ist die On-Demand-Revalidierung. Dabei wird die Aktualisierung gezielt ausgelöst, etwa durch eine CMS-Änderung oder Publishing-Aktion, einen Webhook von einer externen API, ein Publishing-Event oder Statusupdate oder einen manuellen Admin-Trigger. Dieser Ansatz sorgt dafür, dass Inhalte unmittelbar nach einer Änderung aktualisiert werden können. Ein praktisches Beispiel: Ein Artikel wird im CMS aktualisiert, das CMS sendet einen Webhook an die Website, die daraufhin ISR für diese spezifische Seite auslöst. Die Seite wird sofort neu generiert, der Cache wird aktualisiert, und die neue Version ist im CDN sofort verfügbar. Das ist deutlich präziser als zeitbasierte Revalidierung und stellt sicher, dass Inhalte immer aktuell sind.

Vorteile von ISR

ISR verbindet zwei wichtige Eigenschaften: hohe Geschwindigkeit durch statische Auslieferung und bessere Aktualität der Inhalte. Die resultierenden Websites sind so schnell wie SSG, liefern aber aktuelle Inhalte wie SSR. Gleichzeitig ist ISR ressourceneffizient, da nicht die gesamte Website regeneriert wird. Gerade große Content-Plattformen mit Tausenden oder Hunderttausenden von Seiten profitieren davon erheblich, weil nur die geänderten Seiten neu generiert werden. Das spart Rechenressourcen und führt zu kürzeren Build-Zeiten.

Crawling-Probleme früh vermeiden: Praktische Tipps

Viele SEO-Probleme entstehen bereits bei der technischen Architektur einer Website. Mit einer bewussten Planung lassen sich diese Probleme jedoch vermeiden. Die folgenden Maßnahmen sind dabei besonders wichtig.

Hauptinhalt im initialen HTML ausgeben

Die wichtigsten Informationen sollten im ersten HTML-Dokument enthalten sein. Dazu gehören die H1-Überschrift, die Einleitung mit den ersten zwei bis drei Sätzen, der Haupttext oder die Kernaussage, interne Links zu verwandten Seiten, strukturierte Daten wie Schema-Markup und die Meta-Description. Wenn diese Elemente im HTML vorhanden sind, können Suchmaschinen und KI-Systeme sie direkt erfassen. Ein einfacher Test: Öffne die Seite im Browser, deaktiviere JavaScript in den DevTools und lade neu. Sind alle wichtigen Inhalte noch sichtbar? Falls nicht, liegt ein Renderingproblem vor, das behoben werden sollte.

HTML-Links statt reinem JavaScript-Routing

Crawler folgen klassischen <a>-Links zuverlässig. Navigationen, die ausschließlich über JavaScript-Events funktionieren, können die Entdeckung von Seiten erschweren. Richtig ist: <a href=“/blog/artikel-1″>Artikel 1</a>. Problematisch ist: <button onClick={() => navigate(‚/blog/artikel-1‘)}>Artikel 1</button>. Da Crawler den onClick-Handler nicht erkennen, können sie den Links nicht folgen, was dazu führt, dass manche Seiten nicht entdeckt werden. Besser ist es, echte HTML-Links zu nutzen und diese optional mit JavaScript zu ergänzen, um die Nutzererfahrung zu verbessern. Dieses Konzept nennt sich Progressive Enhancement.

Rendering frühzeitig testen

Eine praktische Methode zur Überprüfung besteht darin, eine Seite ohne JavaScript zu betrachten. Öffne dazu die Website in Chrome, öffne die DevTools mit F12, gehe zu „More tools“ und wähle „Rendering“. Dort lässt sich JavaScript deaktivieren. Lade die Seite neu und prüfe, ob wichtiger Inhalt fehlt. Diese einfache Methode zeigt schnell, ob kritische Inhalte von JavaScript abhängig sind, und sollte bei jeder neuen Seite oder größeren Änderung durchgeführt werden.

Sitemap und robots.txt richtig konfigurieren

Eine Sitemap-XML sollte alle wichtigen Seiten enthalten und regelmäßig aktualisiert werden. Die robots.txt-Datei sollte dem Crawler das Crawling der Website ermöglichen und keine unbeabsichtigten Blockierungen enthalten. Bei Duplicate Content sollten Canonical-Tags gesetzt sein. Das Crawl-Budget sollte nicht durch Fehlerseiten oder unnötige Parameter verschwendet werden, da Suchmaschinen nur eine begrenzte Anzahl von Seiten pro Tag crawlen.

Häufig verwendete JavaScript-Frameworks für SSG

Mehrere moderne Frameworks unterstützen statische Generierung nativ und erleichtern den Aufbau von SSG-Websites. Die Wahl des Frameworks hängt von den Anforderungen und der vorhandenen Expertise im Team ab.

Next.js (React)

Next.js ist ein React-Framework, das SSG, SSR und hybride Renderingmodelle kombiniert. Es ist besonders verbreitet bei Content-Websites und Marketingplattformen, weil es alle Rendering-Strategien in einem Framework bietet. Next.js eignet sich ideal für Blogs, Landingpages und E-Commerce-Websites. Das Framework hat integrierte ISR-Unterstützung, was die Implementierung von Incremental Static Regeneration vereinfacht. Die Lernkurve ist mittel, da React-Kenntnisse erforderlich sind. Die Community ist sehr aktiv und bietet viele Ressourcen und Tutorials.

Nuxt (Vue)

Nuxt ist ein Vue-Framework mit integrierter Unterstützung für statische Generierung und serverseitiges Rendering. Es eignet sich gut für content-getriebene Projekte, die auf dem Vue-Framework basieren. Auch Nuxt bietet ISR-Support über Hybrid-Rendering. Die Lernkurve ist mittel, da Vue-Kenntnisse erforderlich sind. Nuxt ist besonders beliebt in der europäischen Developer-Community und verfügt über eine ausführliche Dokumentation.

Astro

Astro ist ein modernes Framework mit einer sogenannten Islands-Architektur. Dabei wird der Großteil der Seite als statisches HTML erzeugt, während interaktive Elemente separat geladen werden. Das ermöglicht schnelle Seiten mit minimalem JavaScript. Astro eignet sich besonders für inhaltsreiche Websites mit wenig Interaktionsbedarf. Eine besondere Eigenschaft ist das Zero-JavaScript-by-default-Prinzip: Standardmäßig werden keine JavaScript-Dateien an den Browser gesendet, es sei denn, es ist explizit notwendig. Die Lernkurve ist niedrig, sodass auch Einsteiger ohne tiefe Framework-Kenntnisse gut damit arbeiten können.

SvelteKit

SvelteKit ist ein modernes Framework mit Unterstützung für statische und serverseitige Renderingstrategien sowie hybride Ansätze. Es eignet sich gut für interaktive Websites, die gleichzeitig gutes SEO erfordern. SvelteKit hat ISR-Support, und die Lernkurve ist mittel. Das Framework zeichnet sich durch gute Performance und eine intuitive Developer-Experience aus. Svelte als Sprache ist sehr lesbar und kompakt.

Gatsby (React)

Gatsby ist ein React-Framework mit Fokus auf statische Websites und content-getriebene Projekte. Es eignet sich ideal für Blogs und Wikis mit vielen Inhalten. Gatsby hat ISR-Support über Gatsby Cloud, und die Lernkurve ist mittel. Das Framework hat eine starke Plugin-Architektur, die es einfach macht, verschiedene Datenquellen anzubinden. Gatsby war ein Pionier bei SSG und hat viele etablierte Best Practices in diesem Bereich geprägt.

Best Practices: Suchmaschinenoptimierte SSG-Websites umsetzen

Eine technisch saubere Umsetzung erhöht die Chancen auf stabile Indexierung und gute Rankings erheblich. Die folgenden Prinzipien sollten von Anfang an in die Architektur integriert werden, nicht erst nachträglich als Korrekturmaßnahmen.

Inhalte und Struktur

Alle wichtigen Inhalte sollten im initialen HTML vorhanden sein. Das ist das Fundament für gutes SEO. Zusätzlich sollte eine klare Überschriftenhierarchie verwendet werden, die mit H1 beginnt und dann H2 und H3 folgt. Interne Links sollten strukturiert aufgebaut sein, etwa über Breadcrumbs oder verwandte Artikel, um Crawlern die Seitenstruktur zu verdeutlichen. Duplicate Content sollte vermieden oder mit Canonical-Tags gekennzeichnet werden. Eine logische URL-Struktur ohne unnötige Parameter verbessert die Crawlbarkeit zusätzlich.

Performance und Crawling

Die Seitenladezeit sollte unter drei Sekunden liegen, gemessen über eine 3G-Verbindung. Das ist besonders wichtig für mobile Nutzer. Es sollte keine JavaScript-only-Navigation geben, da Crawler dieser nicht zuverlässig folgen können. Eine Sitemap-XML sollte aktuell und vollständig sein. Die robots.txt sollte korrekt konfiguriert sein und dem Crawler nicht versehentlich Seiten blockieren. Das Crawl-Budget sollte nicht durch Fehlerseiten oder unnötige URL-Parameter verschwendet werden, da Suchmaschinen nur eine begrenzte Anzahl von Seiten pro Tag crawlen.

Inhalts-Updates und Aktualisierungslogik

Die Aktualisierungslogik sollte von Anfang an geplant werden. Das bedeutet, festzulegen, wie häufig sich Inhalte ändern, und die passende Strategie zu wählen – ob ISR, regelmäßige Rebuilds oder SSR. On-Demand-Revalidierung über Webhooks ermöglicht eine enge CMS-Integration und sofortige Updates. Es ist wichtig, zu überwachen, ob veraltete Inhalte im HTML erscheinen, und entsprechende Alerts einzurichten, damit Probleme schnell erkannt und behoben werden können.

Dynamische Inhalte gezielt einsetzen

Nur optionale Komponenten sollten nach dem SSG-Build nachgeladen werden, etwa Kommentare oder Live-Statistiken. Der Hauptinhalt bleibt im HTML. Kritisches CSS und wichtiges JavaScript sollten inline eingebunden sein, um die First Contentful Paint zu optimieren. Das bedeutet, dass das für das erste Rendering notwendige CSS und JavaScript direkt im HTML stehen sollte, statt in separaten Dateien geladen zu werden.

Mit diesen Best Practices verbindet SSG hohe Performance mit guter Crawlbarkeit und stabiler maschineller Analyse. Die konsequente Umsetzung führt zu Websites, die nicht nur schnell sind, sondern auch zuverlässig in Suchmaschinen und KI-Systemen sichtbar sind.

FAQ