Server-Side-Rendering (SSR) bezeichnet eine Rendering-Strategie, bei der ein Webserver das vollständige HTML einer Seite erzeugt, bevor er es an den Browser ausliefert. Der Server führt den nötigen Code aus, holt Daten aus Datenbank oder API und schickt dem Client eine fertig befüllte Seite. Das ist der entscheidende Unterschied zu Ansätzen, die den Inhalt erst im Browser per JavaScript zusammensetzen. Gerade für Suchmaschinen-Crawler und KI-Bots, die HTML lesen, aber kein oder nur eingeschränkt JavaScript ausführen, ist SSR häufig die Voraussetzung dafür, dass der Inhalt überhaupt erfasst wird. Damit ist SSR heute weniger eine reine Entwickler-Frage als eine Entscheidung mit direkten Folgen für Sichtbarkeit und Umsatz.
Wie Server-Side-Rendering funktioniert
Bei einer SSR-Seite läuft die Anfrage so ab: Der Browser fordert eine URL an. Der Server nimmt die Anfrage entgegen, führt die Anwendungslogik aus, lädt die benötigten Daten und rendert daraus ein vollständiges HTML-Dokument. Dieses Dokument geht zurück an den Browser, der es sofort anzeigen kann — der sichtbare Inhalt steht also bereits, bevor irgendein clientseitiges Skript geladen wurde. In modernen Frameworks folgt danach meist ein zweiter Schritt namens Hydration: Das mitgelieferte JavaScript „belebt" die bereits gerenderte Seite, hängt Event-Handler an und macht sie interaktiv. Der Nutzer sieht den Inhalt also früh, die volle Interaktivität kommt kurz darauf.
Dem gegenüber steht das Client-Side-Rendering (CSR), das den umgekehrten Weg geht. Hier schickt der Server zunächst nur ein nahezu leeres HTML-Gerüst mit Verweisen auf JavaScript-Dateien. Erst im Browser wird der Code ausgeführt, Daten werden nachgeladen und der eigentliche Inhalt entsteht. Für einen menschlichen Nutzer mit modernem Browser funktioniert das oft tadellos. Für einen Crawler, der das initiale HTML liest und kein JavaScript rendert, bleibt die Seite jedoch praktisch leer. Genau dieser Unterschied entscheidet darüber, ob eine Seite für Maschinen sichtbar ist oder nicht.
Was bei der Hydration passieren kann
Die Hydration ist die elegante Idee hinter modernem SSR, aber auch ihre häufigste Fehlerquelle. Stimmt das serverseitig erzeugte HTML nicht exakt mit dem überein, was das clientseitige JavaScript erwartet, kommt es zu einem sogenannten Hydration-Mismatch: Die Seite „flackert", Interaktionen funktionieren erst verspätet, oder es erscheinen Konsolenfehler. Solche Mismatches entstehen typischerweise durch Inhalte, die auf Server und Client unterschiedlich gerendert werden — etwa Zeitstempel, Zufallswerte oder browserspezifische Logik. Wer SSR sauber aufsetzt, achtet darauf, dass beide Seiten denselben Ausgangszustand erzeugen.
Abgrenzung: SSR, CSR und SSG
Neben SSR und CSR gibt es eine dritte verbreitete Variante: das Static Site Generation (SSG). Dabei wird das HTML nicht bei jeder Anfrage, sondern einmalig zum Build-Zeitpunkt erzeugt und dann als statische Datei ausgeliefert. SSG ist extrem schnell und crawlerfreundlich, eignet sich aber nur für Inhalte, die sich nicht ständig ändern. SSR rendert dagegen pro Anfrage frisch und passt damit für dynamische, personalisierte oder häufig aktualisierte Seiten. In der Praxis mischen viele moderne Anwendungen diese Strategien — statische Seiten per SSG, dynamische per SSR, hochinteraktive Teilbereiche per CSR. Eine vierte Variante, das Incremental Static Regeneration, kombiniert die Geschwindigkeit von SSG mit der Frische von SSR, indem statische Seiten im Hintergrund in Intervallen neu erzeugt werden.
| Strategie | HTML entsteht | Crawler-Freundlichkeit | Typischer Einsatz |
|---|---|---|---|
| SSR | pro Anfrage auf dem Server | hoch | dynamische, aktuelle Inhalte |
| SSG | einmalig zum Build-Zeitpunkt | sehr hoch | selten geänderte Inhalte (Blog, Doku) |
| CSR | im Browser per JavaScript | niedrig | hochinteraktive Web-Apps hinter Login |
Warum SSR für SEO und KI-Sichtbarkeit zählt
Der größte praktische Hebel von SSR liegt in der Auffindbarkeit. Weil das vollständige HTML sofort vorliegt, können Suchmaschinen-Bots den Inhalt direkt erfassen, ohne auf Skript-Ausführung, Datenabrufe oder Rendering-Verzögerungen warten zu müssen. Das erhöht die Wahrscheinlichkeit, dass Seiten vollständig gecrawlt und korrekt indexiert werden. Googlebot kann zwar JavaScript rendern, tut dies aber in einem nachgelagerten, ressourcenintensiveren Schritt — was bei reinem CSR zu Verzögerungen und unvollständiger Indexierung führen kann. Bei großen Seiten mit knappem Crawl-Budget kann dieser Unterschied darüber entscheiden, ob neue Inhalte zeitnah oder erst Wochen später im Index landen.
Bei KI-Crawlern ist die Lage noch schärfer. Bots wie GPTBot, ClaudeBot und PerplexityBot rendern in der Regel kein JavaScript. Sie lesen das initiale HTML — und sonst nichts. Eine reine Client-Side-SPA, die ihren Inhalt erst per JavaScript nachlädt, erscheint diesen Bots als leere Seite. Wer also in KI-Antworten zitiert werden will, kommt um serverseitig gerenderten oder statisch generierten Inhalt kaum herum. Das ist einer der Gründe, warum die Rendering-Strategie heute nicht nur eine Performance-, sondern eine Sichtbarkeitsfrage ist. Die KI-Sichtbarkeit beginnt im wahrsten Sinne beim ersten Byte HTML.
Vor- und Nachteile im Überblick
- Vorteil — Auffindbarkeit: Crawler und KI-Bots sehen den vollständigen Inhalt sofort.
- Vorteil — wahrgenommene Ladezeit: Der Nutzer sieht früh echten Inhalt statt eines leeren Gerüsts.
- Vorteil — schwache Endgeräte: Das Rendern passiert auf dem Server, nicht auf einem alten Smartphone.
- Vorteil — Social-Sharing: Vorschau-Karten in sozialen Netzwerken und Messengern brauchen Meta-Tags im initialen HTML.
- Nachteil — Serverlast: Jede Anfrage erzeugt Rechenaufwand auf dem Server statt beim Client.
- Nachteil — Komplexität: Hydration, Caching und State-Handling sind anspruchsvoller als bei reinem CSR.
- Nachteil — Time to First Byte: Weil der Server erst rendert, kann die erste Antwort minimal später kommen als bei einer statischen Datei.
SSR in der Praxis: Frameworks und Shopware
Im JavaScript-Ökosystem haben sich Frameworks etabliert, die SSR und SSG aus einer Hand anbieten. Next.js (auf Basis von React) und Nuxt (auf Basis von Vue) sind die bekanntesten Vertreter; beide erlauben, pro Seite zu entscheiden, ob serverseitig gerendert, statisch generiert oder clientseitig gearbeitet wird. Auch Angular bringt mit Angular Universal eine SSR-Lösung mit, und SvelteKit verfolgt denselben Ansatz. Im E-Commerce ist die Frage besonders relevant: Shopware liefert seine Storefront standardmäßig serverseitig gerendert aus — ein struktureller Vorteil für SEO und KI-Sichtbarkeit, den man nicht leichtfertig verschenken sollte. Wer auf einen Headless-Ansatz mit eigenem Frontend umbaut, muss SSR oder SSG bewusst wieder einplanen, sonst fällt die Storefront für nicht-JavaScript-rendernde Crawler aus.
Ein konkretes Beispiel: Ein Händler ersetzt seine serverseitig gerenderte Shopware-Storefront durch eine selbst gebaute React-SPA ohne SSR. Im Browser sieht alles perfekt aus, die Conversion-Tests laufen gut. Wochen später fällt auf, dass organischer Traffic einbricht und die Marke in KI-Antworten verschwindet — weil die Crawler nur noch ein leeres HTML-Gerüst sehen. Erst die Nachrüstung von Server-Side-Rendering stellt die Sichtbarkeit wieder her. Solche Fälle sind der Grund, warum die Rendering-Entscheidung früh und bewusst getroffen werden sollte und nicht als reine Frontend-Geschmacksfrage behandelt gehört.
Wann sich der Aufwand nicht lohnt
SSR ist kein Selbstzweck. Für eine reine Web-Anwendung hinter einem Login — ein Dashboard, ein internes Tool, ein Konfigurator — spielt die Crawler-Sichtbarkeit keine Rolle, weil diese Seiten ohnehin nicht indexiert werden sollen. Hier ist CSR oft die einfachere und günstigere Wahl, weil die Komplexität von Hydration und serverseitigem State entfällt. Die Faustregel lautet: Öffentliche, auffindbare Inhalte profitieren von SSR oder SSG, geschlossene Anwendungsbereiche selten. Wer beides in einem Projekt hat, kann pro Route entscheiden — genau das ist die Stärke moderner Meta-Frameworks.
Häufige Fragen zu Server-Side-Rendering
Was ist der Unterschied zwischen SSR und CSR?
Bei SSR erzeugt der Server das fertige HTML, bevor er es ausliefert. Bei CSR schickt der Server nur ein leeres Gerüst, und der Inhalt entsteht erst im Browser per JavaScript. Für Crawler ist SSR deutlich freundlicher.
Brauche ich SSR zwingend für gutes SEO?
Nicht zwingend — auch SSG erfüllt den Zweck, und Googlebot kann JavaScript rendern. Aber bei dynamischen Inhalten und besonders für KI-Crawler, die kein JavaScript ausführen, ist serverseitig oder statisch geliefertes HTML der sicherste Weg.
Was ist Hydration?
Hydration ist der Schritt, bei dem das clientseitige JavaScript die bereits serverseitig gerenderte Seite übernimmt, Event-Handler anhängt und sie interaktiv macht — ohne den sichtbaren Inhalt neu aufzubauen.
Ist Shopware serverseitig gerendert?
Ja. Die Shopware-Storefront wird standardmäßig serverseitig gerendert ausgeliefert, was ihr einen Vorteil bei SEO und KI-Sichtbarkeit verschafft.
Was kostet SSR im Vergleich zu CSR?
SSR erzeugt höhere Serverlast, weil jede Anfrage gerendert wird. Das erfordert oft Caching-Strategien und mehr Infrastruktur. Dafür entlastet es schwache Endgeräte und verbessert die Auffindbarkeit.
Sehen KI-Crawler eine CSR-Seite überhaupt?
In der Regel nicht vollständig. Bots wie GPTBot rendern kein JavaScript und sehen bei reinem CSR nur das leere HTML-Gerüst. Für KI-Sichtbarkeit ist serverseitig oder statisch geliefertes HTML daher praktisch Pflicht.
Weiterführend: die Wikipedia-Übersicht zu Server-side Rendering sowie die Next.js-Dokumentation zum serverseitigen Rendern.