SSR (Server-Side Rendering)

SSR (Server-Side Rendering), auf Deutsch serverseitiges Rendering, ist eine Antwort auf eine einfache Frage: Wird der Inhalt einer Webseite auf dem Server zusammengesetzt oder erst im Browser? Bei SSR übernimmt das der Server. Rendern heißt hier, aus Vorlagen, Daten und Programmcode das HTML zu erzeugen, also den Text mit Überschriften, Absätzen und Links, den Browser und andere Programme lesen. Das HTML, das der Server ausliefert, enthält dann schon die Hauptüberschrift, etwa „Wartung für Wärmepumpen“ (im Code als h1 gekennzeichnet), darunter die Beschreibung, die Preise und die Links zu weiteren Seiten.

JavaScript ist die Programmiersprache, mit der Websites im Browser Inhalte nachladen und Funktionen wie Filter, Formulare oder Warenkörbe steuern. Das Gegenstück zum serverseitigen ist das clientseitige Rendering (Client-Side Rendering), bei dem erst der Browser Texte, Bilder und Links per JavaScript aufbaut. Programme, die kein JavaScript ausführen, sehen dann kaum Inhalt; welche das sind und wie das Problem entsteht, erklärt der Begriff JavaScript-Rendering.

Serverseitig, statisch, vorgerendert

Beim klassischen serverseitigen Rendering erzeugt der Server das HTML bei jeder Anfrage neu, etwa mit aktuellen Daten aus einem Shop- oder Content-Management-System. Weitere Wege führen zum selben Ergebnis, nämlich dass der Inhalt im ausgelieferten HTML steht:

• Statische Generierung: Das HTML aller Seiten entsteht vorab, wenn die Website erstellt wird (beim sogenannten Build), und liegt dann als fertige Datei bereit. Google nennt diese Variante statisches Rendering.
• Prerendering: Eine Anwendung, die eigentlich im Browser rendert, wird schon beim Build einmal ausgeführt, und ihr Anfangszustand wird als fertiges HTML gespeichert.
• Progressive Enhancement: Ein Gestaltungsprinzip, das mit HTML beginnt. Inhalte, Links und Formulare funktionieren schon ohne JavaScript, und JavaScript ergänzt Komfortfunktionen in Browsern, die es ausführen.

Etwas anderes ist das dynamische Rendering: Der Server erkennt Bots an der Kennung, die sie bei jeder Anfrage mitschicken (dem User-Agent), und liefert nur ihnen eine vorgerenderte Fassung, während Menschen die im Browser aufgebaute Seite erhalten. Google bezeichnet dynamisches Rendering als Behelfslösung, nicht als langfristige Lösung, und empfiehlt stattdessen Alternativen wie serverseitiges oder statisches Rendering.

Warum SSR für GEO zählt

Laut Google können nicht alle Bots JavaScript ausführen. Serverseitiges Rendering oder Prerendering nennt Google deshalb „eine sehr gute Option“, zumal die Website dadurch für Nutzer und Crawler schneller wird. Für die Sichtbarkeit in KI-Antworten heißt das: Inhalte im ausgelieferten HTML erreichen jedes Programm, das eine Seite abruft, ob es JavaScript ausführt oder nicht. Dazu gehören KI-Crawler, die Seiten als mögliche Quellen erfassen, User-triggered Fetcher, die eine Seite im Auftrag einer Person abrufen, und KI-Agenten, die auf Websites Aufgaben erledigen. Auch strukturierte Daten lassen sich so ausliefern: Wer serverseitig rendert, kann sie laut Google direkt in das ausgelieferte HTML aufnehmen.

Serverseitiges Rendering sorgt dafür, dass Inhalte lesbar ankommen, und gehört so zu den technischen Grundlagen der Crawlbarkeit und der Onpage-GEO. Ob ein KI-System eine Seite dann als Quelle auswählt, entscheidet jeder Anbieter selbst, und keiner beziffert einen Effekt von SSR auf KI-Zitate.

Serverseitiges Rendering in der Praxis

Ob eine Website auf dem Server rendert, hängt von der Technik ab, mit der sie gebaut ist. Content-Management-Systeme wie WordPress erzeugen ihre Seiten in der Regel auf dem Server. Auch dann lohnt sich ein Blick auf einzelne Bestandteile, die erst nachträglich per JavaScript geladen werden, etwa eingebundene Kundenbewertungen, Preistabellen oder Produktlisten. Bei Websites, die mit einem JavaScript-Framework gebaut sind, also einem Baukasten für Webanwendungen, unterscheidet sich die Voreinstellung: Next.js und Nuxt rendern Seiten standardmäßig auf dem Server, Angular dagegen im Browser. In Angular lässt sich serverseitiges Rendering oder Prerendering zuschalten, bei bestehenden Projekten mit einem Erweiterungspaket; in Nuxt lässt es sich umgekehrt auch abschalten. Entscheidend ist also, wie das konkrete Projekt eingestellt ist.

Für das Gespräch mit deinen Entwicklern oder deiner Agentur genügen meist zwei Fragen: Werden unsere Seiten auf dem Server erzeugt, vorab statisch generiert oder erst im Browser aufgebaut? Und stehen Texte, Preise, Kontaktdaten, Links und strukturierte Daten schon im HTML, das der Server ausliefert? Lautet die Antwort „erst im Browser“, ist der Umstieg auf serverseitiges Rendering oder statische Generierung der robuste Weg. Ob ein Inhalt im ausgelieferten HTML steht, lässt sich im Seitenquelltext nachsehen.