Server-side Rendering (SSR)

Was SSR wirklich ist, jenseits der Definition

Drei Regime teilen sich das Feld. Beim Client-side Rendering schickt der Server ein nahezu leeres Dokument plus ein JavaScript-Bundle, das den Inhalt im Browser zusammenbaut. Beim Server-side Rendering erzeugt der Server das fertige HTML pro Anfrage. Bei Static Site Generation passiert dasselbe, nur einmal zum Build-Zeitpunkt und danach vom CDN ausgeliefert. Viele Teams verbrennen Wochen in der Debatte SSR gegen SSG. Für einen Crawler ist diese Debatte fast bedeutungslos.

Die Trennlinie, die zählt, verläuft woanders: Steht der Inhalt im ersten HTTP-Response, oder entsteht er erst nach der JavaScript-Ausführung? SSR und SSG liegen beide auf der richtigen Seite dieser Linie, CSR auf der falschen. Wer diese Frage sauber beantwortet hat, hat die eigentliche Architekturentscheidung getroffen. Ob das HTML pro Request oder pro Deployment entsteht, ist danach eine Frage von Caching, Redaktionsworkflow und Infrastrukturkosten, nicht von Sichtbarkeit.

Hydration ist der Preis, den SSR zahlt. Der Server liefert HTML, der Browser lädt anschließend dasselbe Komponentenmodell erneut und heftet Event-Handler an das bestehende DOM. Zwischen ausgeliefertem Markup und hydriertem Zustand kann eine Lücke entstehen, und genau in dieser Lücke sitzen die meisten SSR-Fehler, die in Audits auffallen: sichtbarer Text ja, aber Canonical, hreflang oder die interne Navigation kommen erst nach der Hydration. Ein Team, das SSR aktiviert und die Sache damit für erledigt hält, hat oft nur den bequemsten Teil des Problems gelöst.

Es lohnt außerdem, das Vokabular sauber zu halten. Partielles Hydrieren, Streaming-SSR, Server Components und Insel-Architekturen sind Varianten derselben Grundidee mit unterschiedlichen Kompromissen bei Bundle-Größe und Interaktivität. Für die Indexierung sind sie alle gleichwertig, solange der ausgelieferte erste Response vollständig ist. Wer eine Migration mit Framework-Argumenten begründet statt mit einem gemessenen Unterschied zwischen rohem und gerendertem HTML, verkauft eine Refaktorierung als SEO-Projekt.

Wie Googles Rendering 2026 tatsächlich abläuft

Googlebot arbeitet in zwei Wellen. Zuerst wird das initiale HTML geholt und verarbeitet, was darin steht. Was JavaScript erfordert, landet in der Warteschlange des Web Rendering Service und wird später abgearbeitet. Google formuliert das in der eigenen Dokumentation zurückhaltend: JavaScript werde verarbeitet, solange es nicht blockiert ist, JavaScript-basierte Seiten seien aber komplexer zu optimieren und erforderten die üblichen JavaScript-SEO-Praktiken. Das ist keine Entwarnung, das ist eine Warnung in Beamtendeutsch.

Wichtig für die Diagnose: In den letzten zwölf Monaten gab es kein bestätigtes Google-Update, das SSR, CSR oder JavaScript-Frameworks gezielt betrifft. Das May 2026 core update lief laut Google Search Status Dashboard vom 21. Mai bis 2. Juni 2026, das June 2026 spam update vom 24. bis 26. Juni 2026. Beides sind Ranking- beziehungsweise Spam-Systeme, keine Rendering-Änderungen. Wer nach einem Core Update Sichtbarkeit verliert und reflexhaft die Rendering-Architektur beschuldigt, spart sich die Arbeit der Segmentierung und findet die echte Ursache nicht.

Der Zustand lässt sich in zehn Minuten messen. Ein roher Abruf ohne JavaScript-Ausführung zeigt, was ein einfacher Crawler bekommt. Der Vergleich mit dem gerenderten HTML aus der URL-Prüfung in der Search Console zeigt die Differenz. Ein Crawl mit und einer ohne JavaScript-Rendering, gegeneinandergestellt, liefert die Liste der URLs, deren Titel, Canonical, interne Links oder JSON-LD nur in der gerenderten Fassung existieren. Diese Liste ist die eigentliche Arbeitsgrundlage, und der Schwellenwert ist hart: alles darauf ist ein Risiko, unabhängig davon, ob Google es aktuell trotzdem einsammelt.

SSR verschiebt zudem die Lastverteilung. Die Serverantwort dauert länger, weil gerendert wird, während die Arbeit im Browser entfällt. In der Praxis steigt TTFB, LCP sinkt meist deutlich, und die Hydration bringt ein eigenes Risiko für Layout-Verschiebungen nach dem ersten Paint mit sich. Wer SSR einführt und danach die Kennzahlen zur Ladeperformance nicht neu erhebt, tauscht schlicht ein Problem gegen ein anderes.

Der eigentliche Grund für SSR im Jahr 2026

Bis vor Kurzem war SSR ein Argument über Googles Renderer. Das ist es heute nicht mehr. Die Crawler der Antwortmaschinen verhalten sich anders als Googlebot: GPTBot, ClaudeBot und PerplexityBot stützen sich nach übereinstimmenden technischen Audits deutlich stärker auf das initiale HTML. Eine CSR-Seite kann bei Google sauber indexiert sein und in genau den Systemen unsichtbar bleiben, die sich zunehmend zwischen Nutzer und Website schieben.

Das Volumen dieser Oberflächen ist belegt. Semrush hat 2025 über 10 Millionen Keywords ausgewertet: 6,49 % lösten im Januar 2025 eine AI Overview aus, im Juli 2025 waren es 24,61 %, im November 2025 noch 15,69 %. Google hat den AI Mode am 7. Oktober 2025 auf über 40 weitere Länder und mehr als 35 Sprachen ausgeweitet. Die Klickfolgen sind ebenfalls dokumentiert: Eine Ahrefs-Studie vom Februar 2026 verglich 300.000 Keywords, je zur Hälfte mit und ohne AI Overview, und berichtete eine um 58 % niedrigere CTR für das erstplatzierte Ergebnis, gegenüber 34,5 % in der vorangegangenen Analyse vom April 2025. Das Pew Research Center veröffentlichte im Juli 2025 die Auswertung von 68.879 realen Google-Suchen von 900 US-Erwachsenen: Bei eingeblendeter KI-Zusammenfassung klickten Nutzer in 8 % der Fälle auf ein klassisches Ergebnis, ohne Zusammenfassung in 15 %.

Die operative Folge ist unbequem, aber eindeutig. Sichtbarkeit verlagert sich in Richtung generativer Antwortflächen, und wer dort zitiert werden will, muss seinen Inhalt in dem Format anbieten, das diese Systeme tatsächlich lesen. Ein Absatz, der erst nach der Hydration im DOM erscheint, ist für einen Crawler ohne JavaScript-Ausführung nicht vorhanden. Er wird nicht schlechter bewertet, er wird nie eingesammelt, und was nie eingesammelt wurde, kann auch nicht zitiert werden.

Wo SSR in einer Netlinking-Operation zählt

Der Punkt, den Linkbuilder regelmäßig übersehen: Ein Link zählt nur, wenn er in dem HTML steht, das eingesammelt wird. Für einen eingekauften Backlink ist das meist unkritisch, weil der Link auf der Seite des Publishers steht und dessen Rendering darüber entscheidet. Kritisch wird es auf der Empfängerseite. Wenn Navigation, verwandte Artikel und Breadcrumbs client-seitig erzeugt werden, existiert der interne Linkgraph für einen Teil der Crawler schlicht nicht. Die Autorität, die über den externen Link hereinkommt, bleibt auf der Landingpage liegen, statt in die Tiefe des Silos zu fließen.

Aus eigener Audit-Erfahrung ist das der teuerste stille Defekt in Kampagnen mit React- oder Vue-Frontends: extern sauber verlinkte Kategorieseiten, deren Verteilung der Linkkraft nach innen nur im Browser stattfindet. Das Budget für die externen Platzierungen ist ausgegeben, die Wirkung endet nach einem Hop, und im Reporting sieht man davon nichts, weil die Links in jedem Browser-basierten Prüfwerkzeug brav auftauchen.

Auf der Publisher-Seite ist derselbe Mechanismus ein Auswahlkriterium. Bevor ein Medium in einen Plan aufgenommen wird, lohnt der rohe Abruf einer Beispielseite ohne JavaScript: Steht der Artikeltext mitsamt Links im ersten Response? Bei Nautilinks ist das kein Prüfschritt, sondern eine Eigenschaft der Infrastruktur, weil die französischen Redaktionsmedien, die wir im Eigenbetrieb führen, als vorgerendertes HTML ausgeliefert werden. Wer die Medien vor einer Buchung selbst prüfen will, findet den öffentlich einsehbaren Medienkatalog ohne Anmeldung und kann jede URL vorab durch den eigenen Crawler schicken.

Was in Audits regelmäßig schiefgeht

Der häufigste Fehler ist halbherziges SSR. Der Fließtext wird serverseitig gerendert, aber Canonical-Tag, hreflang-Auszeichnung oder das JSON-LD schreibt eine Client-Komponente nachträglich in den Head. Für Google geht das meistens gut, für alles andere nicht, und für Google auch nur so lange, wie die Renderwarteschlange mitspielt.

Der zweite Fehler ist Prerendering nach User-Agent. Ein Dienst liefert Bots eine vorgerenderte Fassung, Nutzern das CSR-Bundle. Dynamisches Rendering ist bestenfalls eine Übergangslösung. Praktisch veralten diese Caches, und dann verteilt man monatelang eine Version, die mit der Live-Seite nichts mehr zu tun hat. Der Abstand zwischen zulässiger Auslieferungsoptimierung und Cloaking wird an dieser Stelle sehr schmal.

Der dritte Fehler ist SSR ohne Caching-Schicht. Jede Anfrage rendert neu, TTFB steigt, und bei großen Seitenbeständen frisst das Crawl-Budget. SSR ist keine Entschuldigung dafür, das Ergebnis nicht zu cachen. Bei Inhalten, die sich selten ändern, ist Prerendering zum Build-Zeitpunkt ohnehin die ehrlichere Antwort.

Der vierte Fehler ist das Sperren von JavaScript- und CSS-Ressourcen in der robots.txt. Wer serverseitig rendert und trotzdem die Assets blockiert, sabotiert die zweite Welle und bekommt eine Bewertung auf Basis eines halb gebauten Dokuments.

Der fünfte Fehler ist diagnostischer Natur. Nach jedem größeren Update tauchen Threads auf, in denen Rankingverluste einer Framework-Migration zugeschrieben werden, die zufällig im selben Quartal stattfand. Die Reihenfolge der Prüfung ist umgekehrt: erst Search-Console-Daten entlang der offiziellen Rollout-Daten segmentieren, dann HTTP-Status, Canonicals, interne Links und Indexierungsstatus einzeln testen, und erst danach über Rendering reden.

Was ein Praktiker konkret tut

Der Einstieg ist ein Diff, kein Projekt. Zwei Crawls derselben 500 URLs, einer ohne JavaScript-Rendering, einer mit, und die Differenzliste nach Feldern sortiert: Titel, Meta-Description, Canonical, hreflang, H1, Anzahl interner Links, Vorhandensein strukturierter Daten. Was nur in der gerenderten Spalte auftaucht, ist die Migrationsliste, priorisiert nach Traffic und nach Anzahl eingehender externer Links. Diese Priorisierung ist der Unterschied zwischen einem Ticket, das in zwei Wochen erledigt ist, und einem Refactoring-Vorhaben, das nie beginnt.

Danach hilft ein zweiter Blick aus der Perspektive der Antwortmaschinen. Ein einfacher Abruf mit dem User-Agent eines KI-Crawlers und ohne JavaScript zeigt, welcher Anteil des Artikels für diese Systeme tatsächlich existiert. Parallel gehört in die robots.txt eine bewusste Entscheidung darüber, welche dieser Crawler willkommen sind, statt einer geerbten Default-Konfiguration, die niemand je gelesen hat.

Für neue Projekte ist die Empfehlung unspektakulär: statisch generieren, wo es geht, serverseitig rendern, wo Personalisierung oder Aktualität es erzwingen, und Client-Rendering auf die Teile beschränken, die niemand indexiert sehen muss, etwa Filter, Warenkorb oder Dashboards. Wer ein Redaktionsnetz betreibt, wählt ohnehin den statischen Weg. Wie das im Betrieb aussieht, zeigt der Aufbau des im Eigenbetrieb geführten Mediennetzes, in dem jede Publikation als fertiges HTML vom CDN kommt.

Eine Erwartung sollte man dabei fallen lassen: SSR ist kein Rankingfaktor. Es gibt keinen Bonus für serverseitiges Rendering, und keine Google-Kommunikation der letzten zwölf Monate deutet auf einen hin. Es gibt nur das Verschwinden einer ganzen Klasse von Abhängigkeiten, und in einem Suchumfeld mit mehreren konkurrierenden Crawlern ist das mehr wert als ein Faktor, den man ohnehin nicht direkt steuern könnte.