Was ist Server-Side Rendering?
Stell dir zwei Bäcker vor. Der eine reicht dir die fertige Torte über die Theke. Der andere gibt dir Zutaten und Rezept, backen musst du selbst. Server-Side Rendering (SSR) ist der erste Bäcker.
Technisch heißt das: Der Server erzeugt die Seite und schickt fertiges HTML an den Browser. So beschreibt es auch Googles Entwickler-Plattform web.dev: Die Anwendung wird auf dem Server gerendert, beim Client kommt HTML statt JavaScript an. Rendern heißt hier schlicht: aus Daten und Vorlagen die sichtbare Seite bauen.
Der Gegenbegriff ist Client-Side Rendering (CSR). Dort bekommt der Browser ein fast leeres Gerüst und viel JavaScript. Die Seite entsteht erst auf dem Gerät des Besuchers.
So unterscheiden sich die Rendering-Arten
Es gibt nicht nur schwarz und weiß. Vier Varianten begegnen dir immer wieder:
Art
Wo die Seite entsteht
SSR
Auf dem Server, bei jeder Anfrage neu
Static Rendering
Einmal beim Bauen, danach als fertige Datei
CSR
Im Browser, per JavaScript
Hydration
Erst Server-HTML, dann macht JavaScript es interaktiv
Static Rendering ist am schnellsten, geht aber nur, wenn die Adressen vorab feststehen. SSR passt, wenn Inhalte tagesaktuell oder personalisiert sind. Hydration ist der übliche Mittelweg bei Frameworks wie Next.js oder Nuxt.
Warum SSR für SEO und KI-Suche zählt
Google kann JavaScript ausführen, aber zeitversetzt. Erst wird die Seite gecrawlt, dann landet sie in einer Warteschlange. Sobald Ressourcen frei sind, rendert ein Chromium-Browser sie. Eine Wartezeit nennt Google nicht.
Trotzdem schreibt Google in seiner JavaScript-Doku: Serverseitiges Rendern oder Prerendering bleibt eine gute Idee. Die Seite wird schneller, und nicht alle Bots können JavaScript ausführen.
Das betrifft vor allem KI-Crawler. Vercel maß in seinem Netzwerk: Keiner der großen KI-Crawler rendert JavaScript, genannt werden GPTBot, ClaudeBot und PerplexityBot. Ausnahmen sind Gemini, das Googles Infrastruktur nutzt, und AppleBot. Die Crawler laden JS-Dateien zwar, führen sie aber nicht aus.
Dazu zählen Haupttext, Überschriften, Preise, interne Links und strukturierte Daten. Zähler, Chat-Widgets oder Social-Feeds dürfen ruhig per Skript nachkommen.
Häufige Fehler
Fehler 1 · „Google kann JavaScript, also egal“
Google kann es, die Warteschlange bleibt aber. Andere Bots rendern womöglich gar nicht. Für die ist deine App dann eine leere Seite.
Fehler 2 · SSR für automatisch schnell halten
Das Erzeugen auf dem Server kostet Zeit und kann die Time to First Byte erhöhen. Hydration verdoppelt zudem Arbeit, weil der Browser die Oberfläche noch einmal aufbaut. Das kann Interaktivität kosten, selbst wenn der erste sichtbare Inhalt schneller kommt. Web.dev rät deshalb: Erst die eigenen Engpässe messen.
Fehler 3 · Dynamic Rendering als Dauerlösung
Dabei bekommen Bots eine vorgerenderte Fassung, Menschen die JavaScript-Version. Google nennt das ausdrücklich einen Workaround und keine Lösung für die Dauer. Empfohlen werden SSR, Static Rendering oder Hydration.
Fehler 4 · Nur im Browser prüfen
Dein Browser zeigt immer die fertige Seite. Das sagt nichts darüber, was im rohen HTML steht. Wer nur dort schaut, merkt nicht, dass Preise oder Texte erst per Skript kommen.
So prüfst du deine Seite
Dafür brauchst du zwei Minuten und keine Spezialtools:
- Seitenquelltext ansehen (Rechtsklick im Browser) und nach einem Satz aus deinem Haupttext suchen. Fehlt er, kommt er per JavaScript.
- URL-Prüfung in der Google Search Console: Sie zeigt, was Google nach dem Rendern sieht.
- PageSpeed Insights oder Lighthouse: LCP, INP und CLS messen. Als gut gelten laut Google LCP bis 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1.
Häufige Fragen
Was ist der Unterschied zwischen Server-Side und Client-Side Rendering?
Beim Server-Side Rendering erzeugt der Server fertiges HTML. Beim Client-Side Rendering baut der Browser die Seite per JavaScript selbst zusammen. Für Besucher sieht das Ergebnis oft gleich aus, für Crawler nicht.
Ist SSR ein Rankingfaktor?
Nein, das sagt Google nirgends. Die Doku empfiehlt SSR, weil Seiten schneller werden und mehr Bots den Inhalt lesen können. Der Nutzen ist indirekt: Was Google nicht sieht, kann nicht ranken.
Können ChatGPT und andere KI-Crawler JavaScript ausführen?
Laut einer Messung von Vercel vom Dezember 2024 nicht: GPTBot, ClaudeBot und PerplexityBot laden JS-Dateien höchstens, führen sie aber nicht aus. Das kann sich ändern. Sicher bist du, wenn der Inhalt im HTML steht.
Brauche ich SSR bei einer WordPress-Website?
Meist hast du es schon, denn WordPress liefert seine Seiten serverseitig aus. Prüfen solltest du nur Inhalte, die Plugins oder Widgets erst per Skript nachladen. Anders sieht es aus, wenn dein Frontend headless läuft.
