Server-Side Rendering
Server-Side Rendering (SSR) ist die Rendering-Strategie, bei der das HTML einer Seite vollständig auf dem Server zum Zeitpunkt der Anfrage zusammengesetzt und als komplettes Dokument an den Browser gesendet wird. Die erste Antwort enthält bereits Text, Links und Meta-Tags, sodass die Seite aussagekräftig ist, bevor überhaupt JavaScript ausgeführt wird.
Server-Side Rendering (SSR) ist die Rendering-Strategie, bei der das HTML einer Seite vollständig auf dem Server zum Zeitpunkt der Anfrage zusammengesetzt und als komplettes Dokument an den Browser gesendet wird. Die erste Antwort enthält bereits Text, Links und Meta-Tags, sodass die Seite aussagekräftig ist, bevor überhaupt JavaScript ausgeführt wird.
Warum es wichtig ist
Suchmaschinen und KI-Crawler verbrauchen echtes Budget für die JavaScript-Ausführung. Googlebot verwendet ein Zwei-Pass-Modell, eine erste HTML-Analyse und anschließend einen verzögerten JS-Rendering-Durchlauf, und das Ausliefern einer leeren, clientseitig gerenderten Hülle kann die Indexierung verzögern oder ganz verhindern. KI-Crawler wie GPTBot, PerplexityBot und ClaudeBot führen JS meist überhaupt nicht aus, was bedeutet, dass CSR für Answer-Engines praktisch unsichtbar ist. SSR löst dies in einem einzigen Schritt und verbessert zugleich die Core Web Vitals. Es ist eine der wirkungsvollsten technischen Entscheidungen für SEO und GEO.
CSR vs. SSR vs. SSG vs. ISR
| Strategie | Rendering-Ort | Erstes HTML | SEO-Eignung | Anwendungsfall |
|---|---|---|---|---|
| CSR (Client-Side Rendering) | Browser | Leere Hülle | Schwach | Eingeloggte Dashboards |
| SSR (Server-Side Rendering) | Server, bei jeder Anfrage | Vollständig | Stark | Dynamische, personalisierte Inhalte |
| SSG (Static Site Generation) | Build-Zeit | Vollständig | Am stärksten | Blogs, Dokumentationen, Marketing |
| ISR (Incremental Static Regeneration) | Build + periodische Regeneration | Vollständig | Am stärksten | Häufig aktualisierte statische Seiten |
Die SEO-Priorität lautet ungefähr SSG ≈ ISR > SSR > CSR. Frameworks wie Next.js, Nuxt, Remix und SvelteKit erlauben es Ihnen, diese Modi in einer einzigen Codebasis zu kombinieren.
Auswirkungen auf SEO und GEO
Sofortige Indexierung: Inhalte sind bereits beim ersten Durchlauf des Googlebot sichtbar, ohne auf den verzögerten Rendering-Durchlauf zu warten. Die Indexierung neuer Seiten sinkt von Tagen auf Stunden.
Kompatibilität mit KI-Crawlern: GPTBot und Co. führen kein JS aus. Ohne SSR existieren Ihre Inhalte für das LLM-Training und die Suche praktisch nicht.
Verbesserung der Core Web Vitals: LCP wird ausgelöst, sobald das erste HTML eintrifft, nicht erst nachdem ein JS-Bundle heruntergeladen und ausgeführt wurde. FCP, LCP und TTI verbessern sich allesamt.
Zuverlässige Meta-Tags: Open Graph, Such-Snippets und strukturierte Daten müssen in der ersten Antwort enthalten sein, damit sie als vertrauenswürdig gelten. CSR sendet leere Meta-Tags an Twitter, Facebook und andere Social-Bots.
Progressive Enhancement: Inhalte sind auch bei deaktiviertem JS, in langsamen Netzwerken oder auf älteren Geräten zugänglich.
Kompromisse bei SSR
Höhere Serverkosten: Die HTML-Generierung pro Anfrage kostet CPU, Arbeitsspeicher und Infrastruktur. CDN-Caching und ISR mildern dies ab.
Mögliche Erhöhung der TTFB: Aufwändige Serverlogik verzögert die Time-to-First-Byte. DB-Abfragen und externe APIs werden zu Engpässen.
Komplexität: Hydration-Mismatches, Unterschiede zwischen Server- und Client-Umgebung sowie Cache-Invalidierung erhöhen allesamt den Aufwand für die Fehlersuche.
Grenzen der Personalisierung: Benutzerbezogenes SSR lässt sich schwer cachen. Das Muster lautet: gemeinsame Hülle + clientseitige Personalisierung.
Hydration und ihre Fallstricke
Nachdem SSR das HTML ausgeliefert hat, "hydratisiert" der Client es, indem er JavaScript erneut anbindet, um es interaktiv zu machen. Was dabei schiefgehen kann:
Hydration-Mismatch: Wenn das serverseitig gerenderte HTML und das erste Rendering des Clients voneinander abweichen, gibt React/Vue Warnungen aus, oft als sichtbares Flackern oder fehlerhaftes Verhalten.
Hydration-Kosten: Das Hydratisieren einer großen Seite blockiert den Haupt-Thread und beeinträchtigt INP. Partielle Hydration, React Server Components und Astro Islands sind Alternativen.
SSR ≠ kleinere Bundles: SSR verkleinert das Client-Bundle nicht. Beide müssen weiterhin optimiert werden.
Wann SSR verwenden
- Inhalte hängen von SEO-/GEO-Traffic ab (Blogs, Nachrichten, E-Commerce, Dokumentationen)
- Benutzerspezifische Daten müssen im ersten Paint enthalten sein (personalisierte Dashboards)
- Dynamische OG-Tags sind für das Teilen in sozialen Medien wichtig
- Sie streben KI-Such-Zitate an
Wann SSR überdimensioniert ist
- Authentifizierte Dashboards (kein SEO-Anliegen)
- Statische Inhalte, SSG ist schneller und günstiger
- Winzige Websites, eine einzelne statische HTML-Datei genügt
Häufige Fehler
Alles per SSR rendern: Statische Inhalte sind als SSG/ISR schneller und günstiger. Wählen Sie pro Route den richtigen Modus.
APIs ohne Caching ansprechen: Datenabrufe pro Anfrage ohne Caching lassen die TTFB explodieren. Verwenden Sie SWR oder Cache-Header.
Hydration-Mismatches ignorieren: Konsolenwarnungen zeigen an, dass sich das HTML, das Google gesehen hat, vom HTML des Benutzers unterscheidet, ein SEO-Risiko.
Meta-Tags nur auf dem Client setzen: Meta-Tags müssen im Head der SSR-Antwort vorhanden sein, damit Bots sie lesen können.
Auf Framework-Standardeinstellungen vertrauen: Next.js und Nuxt wählen nicht immer automatisch den richtigen Modus. Legen Sie ihn pro Route explizit fest.
Sources: