Glossar Client-Side Rendering (CSR)
Beim Client-Side Rendering schickt der Server eine fast leere Seite, und der Browser baut den Inhalt mit JavaScript zusammen. Die Seite, die jemand sieht, hat auf dem Server nie als HTML existiert.
Google kann JavaScript rendern, aber in einem zweiten Schritt und ohne Zusage, wann. Was erst nach dem Ausführen von Code existiert, kommt später in den Index — oder gar nicht.
Der Server liefert ein Gerüst: ein leeres <div> und ein Skript-Verweis. Erst im Browser lädt das JavaScript, ruft Daten ab und schreibt den Inhalt in die Seite. Aus Sicht des Servers ist die Antwort fertig, bevor irgendein Text existiert.
Das ist die übliche Bauweise klassischer Single-Page-Anwendungen. Für eine App hinter dem Login ist sie unproblematisch — niemand muss sie finden. Für eine öffentliche Inhaltsseite ändert sich die Lage.
Google verarbeitet eine Seite in zwei Durchgängen. Zuerst wird das ausgelieferte HTML gelesen. Was dort nicht steht, kommt in eine Warteschlange fürs Rendern und wird später verarbeitet, wenn Rechenzeit frei ist.
Der zweite Durchgang findet statt — Google sagt das ausdrücklich —, aber nicht sofort und ohne Zusage über den Abstand. Für eine Nachricht, eine Preisänderung oder eine neue Kategorieseite ist dieser Abstand genau das Problem. Kommt beim Rendern ein Fehler dazu, ein blockiertes Skript, ein Zeitüberlauf, eine fehlgeschlagene Datenabfrage, bleibt der Inhalt ganz aus.
Die drei unterscheiden sich darin, wann das HTML entsteht.
Für Suchmaschinen sind SSR und SSG gleichwertig: Der Inhalt steht in der ersten Antwort. Der Unterschied zwischen ihnen ist betrieblicher Art — wie frisch die Daten sind und was ein Aufruf kostet.
Es ist keine Entweder-oder-Frage für die ganze Seite. Verbreitet ist die Mischung: der sichtbare Inhalt vom Server, die interaktiven Teile im Browser.
Die schnellste Probe: die Seite ohne JavaScript abrufen und ansehen, was übrig bleibt. Bleibt eine leere Fläche, ist der Inhalt CSR-abhängig.
Verlässlicher ist der Vergleich zweier Fassungen derselben Seite: das rohe HTML aus der Serverantwort gegen den gerenderten Text im Browser. Was nur in der zweiten Fassung vorkommt, existiert für den ersten Durchgang nicht. Dazu kommt die Prüfung in der Search Console, die zeigt, was Google tatsächlich gerendert hat.
Ein häufiger Fehler bei dieser Messung: Man prüft mit einem Werkzeug, das JavaScript ausführt, und sieht deshalb alles. Dann misst man den Browser, nicht den Crawler.
CSR ist keine Fehlentscheidung, sondern eine Wahl mit einem Preis. Sie ist in Ordnung, wo der Inhalt nicht gefunden werden muss: hinter einer Anmeldung, in einem Konfigurator, in einem Warenkorb, in einem Verwaltungsbereich.
Teuer wird sie dort, wo Auffindbarkeit die Aufgabe ist — Produkt-, Kategorie- und Inhaltsseiten. Für die gilt die einfache Regel: Was ranken soll, gehört in die erste Antwort.
Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.
Audit anfragenJa, Google führt JavaScript aus. Aber in einem zweiten Durchgang, ohne zugesagte Frist, und jeder Fehler beim Rendern lässt den Inhalt draußen. Die nützliche Frage ist nicht ob, sondern wann und wie verlässlich.
Die Seite ohne JavaScript abrufen und dieses HTML mit dem gerenderten Text vergleichen. Ein einfaches curl genügt. Wer mit einem Werkzeug prüft, das Skripte ausführt, misst den Browser und nicht den Crawler.
Fast nie. Üblich ist, nur das auf den Server zu holen, was gefunden werden muss: Texte, Überschriften, strukturierte Daten und interne Links. Die interaktiven Teile können im Browser bleiben.
Google beschreibt es als Behelfslösung und Übergang, nicht als Empfehlung auf Dauer. Zwei getrennte Fassungen auszuliefern bringt eine eigene Fehlerquelle mit: dass beide auseinanderlaufen, ohne dass es jemand merkt.
Meist auf LCP: Das Hauptelement kann erst gezeichnet werden, wenn das JavaScript geladen und ausgeführt ist. Das ist keine automatische Regel, aber der Weg bis zum ersten sichtbaren Inhalt ist bauartbedingt länger.