Server-Side Rendering und SEO

Ihre Inhalte können noch so brillant sein – wenn ein Such-Crawler nur eine leere HTML-Hülle und ein JavaScript-Bundle erhält, zählt nichts davon. Die Rendering-Strategie, also wo und wann Ihr HTML aufgebaut wird, entscheidet im Stillen darüber, ob Google eine fertige Seite sieht oder eine leere Bühne. Für alles, was auf organischen Traffic angewiesen ist, ist dies die SEO-Entscheidung, die vor Keywords, Links oder Inhalten getroffen werden muss. Sie können alles andere richtig machen und dennoch unsichtbar bleiben, wenn der Crawler Ihre Texte nie zu Gesicht bekommt.

Die drei Rendering-Strategien

• CSR (Client-Side Rendering): Der Server liefert eine nahezu leere HTML-Datei plus ein JavaScript-Bundle. Der Browser lädt dieses JavaScript herunter, parst und führt es aus – und baut daraus erst die Seite auf. Schnell zu entwickeln und günstig zu hosten, aber das initiale HTML, also das, was ein Crawler als Erstes liest, ist im Wesentlichen leer.
• SSR (Server-Side Rendering): Der Server führt Ihren Anwendungscode aus und baut für jede Anfrage vollständiges HTML auf, das direkt angezeigt werden kann. Der Browser rendert es sofort und „hydriert" es anschließend, indem JavaScript angebunden wird, um die Seite interaktiv zu machen.
• SSG (Static Site Generation): Seiten werden einmalig zur Build-Zeit als HTML gerendert und als statische Dateien von einem CDN ausgeliefert. Am schnellsten von allen und nahezu ausfallsicher, aber der Inhalt ist bis zum nächsten Build und Redeploy eingefroren.

Die für SEO entscheidende Unterscheidung ist einfach: SSR und SSG liefern Crawlern beim ersten Request vollständiges HTML. CSR nicht. Bei CSR existieren die eigentlichen Inhalte erst, nachdem JavaScript ausgeführt wurde – und ob das zuverlässig, für jeden Crawler, auf jeder Seite, geschieht, liegt nicht in Ihrer Hand. Dieser eine Umstand ist die Wurzel aller nachfolgenden Probleme. Alles Weitere in diesem Artikel ist eine Konsequenz daraus.

Warum CSR SEO in der Praxis schadet

Google kann JavaScript ausführen, weshalb viele annehmen, CSR sei kein Problem. In der Praxis ist es jedoch fehleranfällig – und genau diese Fehleranfälligkeit ist das eigentliche Problem. Googles Indexierung läuft in zwei Wellen ab: Zunächst crawlt Google das rohe HTML, dann stellt die Seite eine zweite, verzögerte Rendering-Runde in die Warteschlange, bei der JavaScript tatsächlich ausgeführt wird. Diese zweite Runde kann bei knappem Crawl-Budget um Tage verzögert werden. Wenn Ihre Inhalte nur nach der JS-Ausführung existieren, werden sie erst dann indexiert, wenn – und falls – dieser Durchlauf abgeschlossen ist.

Und Google ist der beste Fall unter den Crawlern. Das breitere Ökosystem sieht schlechter aus: Viele Social-Preview-Bots (die eine Vorschaukarte erzeugen, wenn jemand Ihren Link teilt), zahlreiche AI-Crawler und Bing in verschiedenen Konfigurationen verarbeiten JavaScript schlecht oder gar nicht. Sie sehen die leere Hülle und ziehen weiter.

Diese Fehleranfälligkeit zeigt sich in konkreten, umsatzrelevanten Symptomen:

• Verzögerte oder inkonsistente Indexierung neuer Seiten – Sie veröffentlichen, und wochenlang erscheint nichts in den Suchergebnissen
• Fehlende oder fehlerhafte Social-Previews beim Teilen von Links, was die Click-Through-Rate senkt
• Meta-Tags, kanonische URLs und strukturierte Daten, die nie gelesen werden, weil sie per JavaScript injiziert werden
• Inhalte, die still und leise schlechter ranken als server-gerenderte Konkurrenten, die dem Crawler die Arbeit erleichtern

Wenn Ihr Ranking – und der Traffic, der Ihre Rechnungen bezahlt – davon abhängt, ist „funktioniert meistens" keine Strategie. Genau deshalb setzen wir auf Frameworks mit erstklassigem Server-Rendering; das fließt in die Abwägung bei Next.js vs React und bei der Wahl des Tech-Stacks ein.

SSR oder SSG: Die richtige Wahl treffen

Beide sind SEO-freundlich – der Crawler erhält in beiden Fällen echtes HTML. Welche Strategie passt, hängt davon ab, wie häufig sich Inhalte ändern und ob sie personalisiert sind:

1. SSG für Inhalte, die zwischen Deploys stabil bleiben: Marketing-Seiten, Landing Pages, Dokumentation, die meisten Blog-Beiträge (wie dieser hier). Am schnellsten und günstigsten in der Auslieferung, skaliert unbegrenzt vom CDN und hat kaum eine Angriffsfläche.
2. SSR für personalisierte oder sich laufend ändernde Inhalte: Produktseiten mit aktuellem Lagerbestand und Preisen, Such- und Filterergebnisse, alles Nutzerspezifische mit öffentlicher URL. Sie zahlen für ein Server-Rendering bei jeder Anfrage, dafür sind die Inhalte stets aktuell.
3. ISR (Incremental Static Regeneration), angeboten von Frameworks wie Next.js, kombiniert beides: Auslieferung von schnellem statischen HTML, aber Neugenerierung einzelner Seiten im Hintergrund nach einem Zeitplan oder bei Bedarf, wenn sich Daten ändern. Das ist der Sweet Spot für große Content-Seiten und E-Commerce-Kataloge – Tausende von Seiten, die regelmäßig aktualisiert werden, aber kein Request-by-Request-Rendering benötigen.

Sie müssen sich nicht für eine Strategie für die gesamte Website entscheiden. Die beste Lösung mischt in der Regel alle drei, je nach Route: statische Marketing-Seiten, ISR für den Produktkatalog, SSR für die Suche.

Es geht um mehr als nur Crawler

Server-Rendering verbessert auch die Metriken, die echte Nutzer spüren – und die Google inzwischen direkt misst. HTML, das bereits fertig zum Anzeigen ankommt, erzeugt einen schnelleren Largest Contentful Paint und weit weniger Layout-Shift als eine Seite, die im Browser nach einem JavaScript-Download von Grund auf zusammengesetzt wird. Nutzer mit langsamen Smartphones und instabilen Verbindungen – ein großer Teil des Webs – merken das am stärksten, und genau sie sind am ehesten geneigt, bei einem leeren Bildschirm abzuspringen.

Da Core Web Vitals ein Ranking-Signal sind, helfen SSR und SSG gleich doppelt: Crawler sehen Ihre Inhalte, und Nutzer erhalten eine messbar schnellere Seite – was sowohl Rankings als auch Conversions verbessert. Beide Ziele zeigen in dieselbe Richtung. Unser Core Web Vitals-Leitfaden zeigt, wie man die Schwellenwerte misst und erreicht; wenn das Payload selbst der Engpass ist, ist Caching-Strategien der nächste Hebel.

Was ist mit AI-Suche und Social Sharing?

SEO bedeutete früher: Google – und Google allein konnte irgendwann Ihr JavaScript ausführen. Das ist nicht mehr das ganze Spiel. Ein wachsender Anteil der Inhalte-Entdeckung findet über AI-Assistenten und Answer Engines statt, die das Web crawlen, um ihre Antworten zu untermauern, über Social-Plattformen, die Link-Previews generieren, und über Bing, das mehr Oberflächen betreibt, als sein reiner Marktanteil vermuten lässt. Viele dieser Crawler sind in Bezug auf JavaScript weniger leistungsfähig als Googlebot, nicht mehr – sie lesen das rohe HTML und hören dort auf.

Das verlagert die Abwägung noch weiter in Richtung Server-Rendering. Wenn Sie möchten, dass Ihre Inhalte von einem AI-Assistenten zitiert werden, beim Teilen korrekt angezeigt werden und von jeder Suchmaschine indexiert werden – nicht nur von der ausgefeiltesten –, ist der sichere Weg: Stellen Sie sicher, dass die eigentlichen Inhalte, Text, Metadaten, strukturierte Daten, in dem HTML stehen, das der Server ausliefert, jedes Mal. Rendering-Strategie ist heute die Grundvoraussetzung, um überhaupt gefunden zu werden – nicht nur, um bei Google zu ranken.

Häufige Fehler auch bei server-gerenderten Seiten

Server-seitiges Rendering ist notwendig, aber nicht hinreichend. Wir auditieren regelmäßig „SSR"-Seiten, die SEO-Lücken aufweisen:

• Hydration-Mismatches, die den client-seitig gerenderten Output aus dem Takt mit dem Server-HTML bringen und manchmal Inhalte nach dem Laden ausblenden.
• Meta-Tags und strukturierte Daten, die client-seitig gesetzt werden – das untergräbt den Zweck; setzen Sie sie in der Server-Antwort.
• Trotzdem ein riesiges JS-Bundle ausliefern, sodass die Hydration langsam ist und die Seite lange nach dem visuellen Erscheinen noch nicht interaktiv ist.
• Crawler in robots.txt blockieren oder durch aggressive Bot-Protection, die auch Googlebot abweist.
• Soft-404s und client-seitige Redirects, die Crawler als defekte oder fehlende Seiten interpretieren.

So sehen Sie, was der Crawler tatsächlich sieht

Sie müssen nicht raten. Prüfen Sie es direkt, nach aufsteigendem Aufwand:

1. Quelltext anzeigen – nicht den DevTools-Inspector. Das Elements-Panel zeigt das hydrierte DOM nach der JavaScript-Ausführung, das immer in Ordnung aussieht. Rechtsklick und „Seitenquelltext anzeigen" (oder curl auf die URL) zeigt das rohe HTML, das der Server tatsächlich gesendet hat. Wenn Ihre Überschrift und Ihr Fließtext nicht darin enthalten sind, sieht sie weder Googlebots erster Durchlauf noch ein Social-Bot.
2. Verwenden Sie das URL-Inspektionstool in der Google Search Console. Es zeigt das gerenderte HTML und den Screenshot, den Google erstellt hat, sowie etwaige Indexierungsprobleme. Das ist die verlässliche Quelle dafür, was Google konkret erhalten hat.
3. Testen Sie die Social-Preview, indem Sie Ihre URL in einen Debugger einfügen (LinkedIn, Facebook und Slack stellen je einen bereit). Eine fehlerhafte Karte ist ein unmittelbares Zeichen dafür, dass Ihre Meta-Tags client-seitig gerendert werden.
4. Deaktivieren Sie JavaScript im Browser und laden Sie die Seite neu. Wenn die Seite leer wird, gilt das auch für jeden Crawler, der kein JS ausführt.

Führen Sie diese Checks vor dem Launch und nach jeder Framework- oder Rendering-Änderung durch – Regressionen hier sind lautlos, und man entdeckt sie oft erst Wochen später, wenn der Traffic still ausbleibt.

Die pragmatische Regel

Wenn eine Seite durch Suche gefunden oder in sozialen Netzwerken geteilt werden soll, rendern Sie sie auf dem Server oder zur Build-Zeit – Punkt. Wenn eine Seite hinter einem Login liegt und kein Crawler sie je sehen wird, ist CSR absolut in Ordnung und oft einfacher; es gibt kein SEO zu verlieren. Die meisten echten Produkte sind eine bewusste Mischung: eine server-gerenderte öffentliche Hülle – Marketing, Inhalte, Produktseiten – die eine client-gerenderte, authentifizierte App umschließt, bei der SEO keine Rolle spielt.

Wenn organischer Traffic für Ihr Produkt wichtig ist und Sie nicht sicher sind, ob Ihr aktueller Stack für Crawler korrekt rendert, sprechen Sie uns an – zu prüfen, was Googlebot tatsächlich erhält, gehört zu den ersten Dingen, die wir auditieren, und es ist oft der günstigste SEO-Gewinn, den eine Website erzielen kann.