SSR vs. SSG: Welche Architektur besser für SEO ist

Die Frage „SSR oder SSG?” ist eine der wichtigsten Architekturentscheidungen für SEO-Verantwortliche. Beide Ansätze haben ihre Stärken – aber für unterschiedliche Anwendungsfälle. Wer die falsche Architektur wählt, kämpft danach ständig gegen strukturelle SEO-Probleme. Wer die richtige Wahl trifft, hat die technische Grundlage für gute Rankings fast automatisch.

Was ist SSR, was ist SSG?

Server-Side Rendering (SSR): HTML wird bei jeder Anfrage dynamisch auf dem Server generiert. Der Nutzer und Googlebot erhalten frisch gerenderte HTML-Seiten. Frameworks: Next.js (mit getServerSideProps), Nuxt.js, SvelteKit.

Static Site Generation (SSG): HTML wird beim Build-Prozess einmalig generiert. Alle Seiten existieren als fertige HTML-Dateien auf dem Server oder CDN. Frameworks: Next.js (mit getStaticProps), Astro, Gatsby, Hugo, Eleventy.

Incremental Static Regeneration (ISR): Hybridansatz von Next.js. Seiten werden statisch generiert, aber mit definierten Revalidierungsintervallen automatisch aktualisiert. Beste von beiden Welten für viele Anwendungsfälle.

Client-Side Rendering (CSR): HTML wird im Browser via JavaScript generiert. SEO-problematisch – Googlebot muss JavaScript rendern, was Verzögerungen erzeugt. Nur für nicht-öffentliche Bereiche (Dashboards, Apps nach Login) geeignet.

Statisch generierte Seiten haben im Median einen 0,8 Sekunden schnelleren LCP als Server-Side Rendered Seiten – weil kein Datenbankaufruf und keine Serververarbeitungszeit anfällt.

SSG: Stärken und Schwächen für SEO

Stärken von SSG

Maximale Performance: Statische HTML-Dateien werden direkt vom CDN ausgeliefert. TTFB liegt typischerweise bei 20–80 ms. Das ist die beste mögliche Ausgangsbasis für LCP.

Hohe Verfügbarkeit: Kein dynamischer Server kann ausfallen. CDN-Netzwerke haben Verfügbarkeit von 99,99 %. Downtime = keine Crawling-Fehler für Googlebot.

Sicherheit: Keine Datenbank, kein Anwendungsserver – die Angriffsfläche ist minimal.

Günstig: CDN-Hosting für statische Sites ist kostenlos (Netlify, Vercel, Cloudflare Pages) oder sehr günstig. Kein teurer Application-Server nötig.

Schwächen von SSG

Kein Echtzeit-Inhalt: Wenn Preise, Lagerbestände oder News-Artikel sich häufig ändern, muss die Site neu gebaut werden. Bei großen Sites (10.000+ Seiten) kann das Build-Prozesse dauern.

Build-Zeiten: Jedes Deployment baut alle Seiten neu. Bei 50.000 Seiten kann das 30–60 Minuten dauern – was Content-Updates verlangsamt.

Personalisierung nicht nativ: Nutzerabhängige Inhalte (eingeloggte Zustände, personalisierte Empfehlungen) müssen via Client-Side JavaScript nachgeladen werden.

Ideal für SSG: Unternehmenswebsites, Blogs, Dokumentationen, Marketing-Sites, Landing Pages – alles wo Inhalte sich selten ändern.

SSR: Stärken und Schwächen für SEO

Stärken von SSR

Echte Aktualität: Jeder Pageload zeigt den aktuellen Zustand der Datenbank. Ideal für E-Commerce (aktuelle Preise, Lagerbestände), News (aktuelle Artikel) und dynamische Inhalte.

Personalisierung: Nutzerabhängige Inhalte (angemeldete Nutzer, Geo-Targeting, A/B-Tests) sind nativ möglich.

Kein Build-Prozess für Content-Updates: Neue Inhalte sind sofort live ohne Re-Build.

Schwächen von SSR

Höhere TTFB: Jede Anfrage löst Datenbankabfragen, Business-Logik und Template-Rendering aus. TTFB von 200–800 ms ist typisch – deutlich langsamer als statisch.

Serverabhängigkeit: Hoher Traffic kann Server überlasten. Scaling kostet Geld.

Caching-Komplexität: Um Performance zu verbessern, muss serverseitiges Caching (Redis, Varnish, CDN-Caching) konfiguriert werden – das erhöht Komplexität.

Ideal für SSR: E-Commerce mit dynamischen Preisen, News-Sites, Social Platforms, alles mit personalisierten Inhalten.

Hybrider Ansatz: Das Beste aus beiden Welten

Moderne Frameworks ermöglichen, SSG und SSR auf Seiten-Ebene zu mischen:

Next.js App Router – jede Seite kann individuell als statisch oder dynamisch konfiguriert werden:

// Statische Seite (SSG)
export const dynamic = 'force-static'

// Dynamische Seite (SSR)
export const dynamic = 'force-dynamic'

// ISR mit 60 Sekunden Revalidierung
export const revalidate = 60

Astro mit Server-Islands: Astro 4+ unterstützt Server-Islands, bei denen der Seitenrahmen statisch ist, aber bestimmte Komponenten serverseitig gerendert werden. Ideal für Seiten mit 95 % statischem Inhalt und 5 % dynamischen Elementen.

Typische Hybrid-Architektur:

• Startseite, Über uns, Kontakt → SSG (kein Datenbankaufruf)
• Blog, Dokumentation → SSG mit ISR (1-Stunden-Revalidierung)
• Produktseiten → ISR mit 5-Minuten-Revalidierung (Preise)
• Warenkorb, Checkout → SSR (personalisiert, sicherheitsrelevant)

Konkrete SEO-Auswirkungen der Architekturwahl

LCP: SSG auf CDN → 50–150 ms TTFB → LCP oft < 1,5s. SSR ohne Caching → 200–800 ms TTFB → LCP potenziell > 2,5s. Mit gutem SSR-Caching → ähnlich wie SSG.

CLS: Unabhängig von SSR/SSG – hängt von Bildoptimierung und Layout-Stabilität ab.

INP: Unabhängig von SSR/SSG – hängt von JavaScript-Menge und Event-Handler-Effizienz ab.

Indexierung: SSG und SSR sind für Googlebot gleich gut crawlbar, da vollständiges HTML ausgeliefert wird. CSR hingegen erfordert JavaScript-Rendering.

Websites mit SSG/ISR-Architektur haben im Durchschnitt eine 95th-Percentile TTFB von 180 ms vs. 620 ms bei ungecachtem SSR – ein entscheidender Unterschied für LCP.

Empfehlung nach Website-Typ