Wenn ich mich mit Technischer SEO beschäftige, stoße ich immer wieder auf Fragen, die weit über klassische Optimierungsmaßnahmen hinausgehen. Dazu gehört auch die Frage, wie eine Website ihre Inhalte eigentlich erzeugt. Denn was für den Nutzer im Browser wie eine gewöhnliche Webseite aussieht, kann technisch auf vollkommen unterschiedliche Weise entstanden sein.
Drei Begriffe sind dabei besonders wichtig: Client-Side Rendering (CSR), Server-Side Rendering (SSR) und Static Site Generation (SSG). Alle drei Modelle verfolgen letztlich dasselbe Ziel, nämlich Inhalte im Browser darzustellen. Sie unterscheiden sich jedoch darin, wo und wann das dafür benötigte HTML erzeugt wird. Diese recht technische Unterscheidung kann erhebliche Auswirkungen auf die Performance einer Website, die Aktualität ihrer Inhalte sowie deren Verarbeitung und Darstellung durch Suchmaschinen haben.
Doch welches Modell ist aus SEO-Sicht tatsächlich sinnvoll? Ich halte es für wenig hilfreich, eine der drei Technologien grundsätzlich zu bevorzugen. Vielmehr müssen wir verstehen, welche Aufgaben sie erfüllen, wo ihre Grenzen liegen und unter welchen Voraussetzungen sich welches Modell eignet.
Drei unterschiedliche Wege zur fertigen Website
Beim Client-Side Rendering (CSR) übernimmt der Browser einen wesentlichen Teil der Arbeit. Der Server liefert zunächst ein HTML-Grundgerüst und die notwendigen JavaScript-Dateien aus. Erst durch die Ausführung von JavaScript im Browser werden die eigentlichen Inhalte erzeugt oder nachgeladen. Ich denke dabei beispielsweise an eine Projektmanagement-Anwendung, in der Aufgaben, Kalender, Auswertungen und persönliche Einstellungen immer wieder aktualisiert werden.
Eine solche Oberfläche soll schnell auf Benutzerinteraktionen reagieren, ohne dass ständig vollständige Seiten neu geladen werden müssen. Für solche Anwendungen kann CSR ausgesprochen sinnvoll sein. Aus Sicht der Suchmaschinenoptimierung entsteht allerdings eine zusätzliche Abhängigkeit.
Wenn wesentliche Inhalte erst durch JavaScript erzeugt werden, sind sie möglicherweise nicht Bestandteil des ursprünglich ausgelieferten HTML. Suchmaschinen wie Google müssen die Seite dann unter Umständen zusätzlich rendern, um diese Informationen vollständig verarbeiten zu können.
Das ist grundsätzlich möglich, wie Google in seiner Dokumentation zu den Grundlagen von JavaScript-SEO erläutert. Dennoch muss sichergestellt sein, dass die notwendigen Ressourcen erreichbar sind und wichtige Inhalte sowie interne Links tatsächlich im gerenderten HTML erscheinen. Das Problem liegt also nicht zwangsläufig im Client-Side Rendering selbst, sondern in der Art und Weise, wie es umgesetzt wird.
Einen anderen Ansatz verfolgt das Server-Side Rendering (SSR). Hier übernimmt der Server die Erzeugung des HTML, bevor die fertige Antwort an den Browser übermittelt wird.
Stellen wir uns ein Reiseportal vor, auf dem Unterkünfte mit aktuellen Preisen, Verfügbarkeiten und Beschreibungen angeboten werden. Ruft ein Nutzer eine Hotelseite auf, kann der Server die notwendigen Informationen aus unterschiedlichen Datenquellen abrufen und daraus die HTML-Seite erzeugen.
Für Google liegt der Vorteil darin, dass die wesentlichen Inhalte bereits in der ursprünglichen Serverantwort enthalten sein können. Eine zusätzliche Ausführung von JavaScript ist dann für die Erfassung dieser Informationen nicht notwendig. Allerdings wäre es falsch, daraus abzuleiten, dass SSR grundsätzlich schneller oder besser ist. Die dynamische Erzeugung von HTML benötigt ebenfalls Ressourcen. Umfangreiche Datenbankabfragen, eine hohe Serverauslastung oder unzureichende Cache-Mechanismen können die Antwortzeiten erheblich beeinträchtigen.
SSR verlagert also zunächst einen Teil der Arbeit vom Browser auf den Server. Ob daraus tatsächlich Vorteile entstehen, hängt von der technischen Umsetzung ab. Hinzu kommt, dass serverseitig erzeugte Inhalte keineswegs auf Interaktivität verzichten müssen. JavaScript kann anschließend zusätzliche Funktionen übernehmen, etwa für Filter, Buchungssysteme oder Warenkörbe.
Noch einen anderen Weg geht die Static Site Generation (SSG). Bei diesem Modell werden die HTML-Seiten bereits im Voraus erzeugt, etwa während eines Build-Prozesses oder bei der Veröffentlichung neuer Inhalte. Wenn ein Nutzer die Seite aufruft, muss der Server das HTML nicht erst zusammenstellen, sondern kann eine bereits fertige Datei ausliefern.
Ein Wissensportal mit mehreren Tausend Fachartikeln wäre dafür ein anschauliches Beispiel. Wenn sich die Inhalte nur gelegentlich verändern, erscheint es wenig sinnvoll, bei jedem Seitenaufruf dieselben Informationen erneut dynamisch erzeugen zu müssen. Statisch generierte Seiten lassen sich häufig sehr effizient über ein Content Delivery Network (CDN) bereitstellen, während die wichtigen Texte und Links bereits im HTML vorhanden sind.
Die Herausforderung liegt allerdings in der Aktualität. Sobald sich Inhalte regelmäßig verändern, muss gewährleistet sein, dass auch die zuvor erzeugten Seiten entsprechend aktualisiert werden. Was bei einem Fachartikel relativ unkompliziert erscheint, kann bei einem großen Onlineshop mit häufig wechselnden Preisen und Lagerbeständen schnell aufwendig werden. Auch hier zeigt sich also, dass technische Vorteile immer im Kontext des konkreten Anwendungsfalls betrachtet werden müssen.
Warum eine Kombination sinnvoller sein kann
Besonders interessant wird die Unterscheidung zwischen CSR, SSR und SSG, wenn wir sie auf eine größere Website übertragen. Nehmen wir einen Onlineshop mit 100.000 Produkten. Die Produktbeschreibungen verändern sich vergleichsweise selten, während Preise und Verfügbarkeiten regelmäßig aktualisiert werden. Gleichzeitig erwarten die Nutzer eine moderne Oberfläche mit Filtern, Warenkorb, Merklisten und weiteren interaktiven Funktionen. Welches Modell wäre dafür geeignet?
Eine vollständig clientseitige Umsetzung könnte funktionieren, würde aber möglicherweise wichtige Inhalte vom JavaScript-Rendering abhängig machen. Eine ausschließlich serverseitige Erzeugung aller Informationen bei jeder Anfrage könnte unnötige Ressourcen beanspruchen. Eine rein statische Umsetzung müsste dagegen besonders sorgfältig mit der Aktualisierung veränderlicher Daten umgehen.
Genau deshalb würde ich zunächst hinterfragen, ob überhaupt sämtliche Bestandteile einer Website auf dieselbe Weise erzeugt werden müssen. Vielleicht ist es sinnvoller, stabile Produktinformationen bereits als HTML bereitzustellen, während Preise und Verfügbarkeiten über geeignete Aktualisierungs- und Cache-Mechanismen eingebunden werden. Interaktive Funktionen könnten weiterhin im Browser ausgeführt werden, ohne dass die grundlegenden Inhalte davon abhängig sein müssen.
Eine solche hybride Architektur verbindet die Vorteile unterschiedlicher Ansätze, statt sich auf ein einziges Modell festzulegen. Moderne Frameworks bieten dafür verschiedene Möglichkeiten. Mit der sogenannten Incremental Static Regeneration (ISR) lassen sich etwa statisch erzeugte Seiten aktualisieren, ohne bei jeder Änderung zwangsläufig die gesamte Website neu erstellen zu müssen.
Natürlich ist auch dieses Verfahren keine Universallösung. Bei Informationen, deren Aktualität besonders wichtig ist, müssen die entsprechenden Aktualisierungsprozesse zuverlässig funktionieren. Entscheidend bleibt deshalb, dass sich die Architektur an den tatsächlichen Anforderungen orientiert. Nicht jede Information muss in Echtzeit erzeugt werden, und nicht jede Benutzerinteraktion benötigt eine vollständig dynamische Website. Gerade bei größeren Projekten kann diese Unterscheidung einen erheblichen Unterschied machen.
Was bedeutet das für die Technische SEO?
Bei der Bewertung solcher Architekturen besteht die Gefahr, aus technischen Eigenschaften unmittelbar SEO-Vorteile abzuleiten. SSR ist jedoch nicht automatisch besser für das Ranking als CSR. Ebenso wenig sorgt SSG allein deshalb für bessere Suchergebnisse, weil die HTML-Seiten bereits im Voraus erzeugt werden. Die Rendering-Strategie selbst ist kein eigenständiger Rankingfaktor.
Viel wichtiger ist das Ergebnis der jeweiligen Umsetzung. Kann Google die relevanten Inhalte zuverlässig erfassen? Sind interne Links erreichbar? Werden aktuelle Informationen ausgeliefert? Und wie verhält sich die Website hinsichtlich Ladezeiten und Serverantwortzeiten? Mich interessieren diese Fragen wesentlich mehr als die Entscheidung für ein bestimmtes Framework.
Dabei sehe ich auch eine direkte Verbindung zu meiner bisherigen Beschäftigung mit der internen Verlinkung und Websitearchitektur. Eine moderne Rendering-Technologie hilft wenig, wenn wichtige Seiten innerhalb einer Website kaum erreichbar sind. Umgekehrt wäre es wenig sinnvoll, eine funktionierende Architektur allein deshalb zu verändern, weil eine andere Technologie theoretisch SEO-Vorteile bieten könnte.
Gerade bei größeren Websites können solche Entscheidungen weitreichende Folgen haben. Eine Umstellung der Rendering-Architektur beansprucht Entwicklungsressourcen, verursacht Kosten und kann neue technische Probleme schaffen. Deshalb würde ich zunächst untersuchen, welche Inhalte bereits im ursprünglichen HTML vorhanden sind, was Google tatsächlich rendern kann und ob überhaupt Schwierigkeiten bei der Auffindbarkeit oder Indexierung bestehen. Auch die Logfile-Analyse kann dabei helfen, das tatsächliche Crawling-Verhalten besser zu verstehen.
Erst wenn sich aus diesen Prüfungen konkrete Probleme ergeben, würde ich über eine Veränderung der Architektur nachdenken. Eine technische Migration sollte schließlich eine nachvollziehbare Verbesserung ermöglichen und nicht bloß dem Wunsch folgen, eine vermeintlich modernere Technologie einzusetzen.
Mein Fazit
CSR, SSR und SSG beschreiben unterschiedliche Wege, Inhalte für den Browser bereitzustellen. Beim Client-Side Rendering übernimmt JavaScript im Browser einen wesentlichen Teil der Arbeit, beim Server-Side Rendering entsteht das HTML während der Anfrage auf dem Server und bei der Static Site Generation werden die Seiten bereits im Voraus erzeugt. Alle drei Modelle besitzen ihre Stärken und Grenzen.
In der Praxis kann es deshalb sinnvoll sein, verschiedene Ansätze miteinander zu vergleichen oder sogar zu kombinieren. Für mich beginnt die Entscheidung jedoch nicht bei der Frage, welche Technologie gerade besonders modern erscheint, sondern bei den Inhalten und den Anforderungen der Website.
Wie häufig ändern sich die Informationen? Welche Funktionen benötigen die Nutzer? Wie zuverlässig können Suchmaschinen die Inhalte erfassen? Und welchen Aufwand rechtfertigen die erwarteten Verbesserungen? Gerade die Technische SEO sollte solche Fragen differenziert beantworten können, statt eine bestimmte Architektur grundsätzlich zu bevorzugen.
Die beste Rendering-Architektur ist nicht zwangsläufig die modernste, sondern diejenige, die zu den tatsächlichen Anforderungen einer Website passt.