Ein Kunde rief mich Anfang 2024 an, mittelgroße E-Commerce-Marke, React-Frontend, Next.js, auf dem Papier alles richtig gemacht. Ihre Kategorieseiten rankten nirgends. Nirgends. Die Website sah glänzend aus, das UX-Team war stolz darauf, und Googlebot sah im Grunde nur leere <div>Suppe. Drei Monate verlorener Umsatz, nur weil jemand einen Medium-Post aus 2021 gelesen und angenommen hatte, Googlebot verarbeitet JavaScript „wie Chrome das jetzt macht". Tut er nicht. Nicht zuverlässig. Nicht 2026.
Wichtigste Erkenntnis: Googlebot rendert JavaScript "irgendwie": Das Rendering ist verzögert und fehleranfällig, also server-seitig rendern Sie alles, das indexiert werden muss, und behandeln Sie reinen Client-seitigen Inhalt als unsichtbar.
Das ist das, was niemand klar ausspricht: Googlebot kann JavaScript rendern. Aber er läuft auf einem Crawl Budget, er rendert asynchron in einer zweiten Welle, und jedes JavaScript, das Inhalte nach dem initialen Paint abruft, ist ein Risiko, das du mit deinen Rankings eingehst. Ich habe gesehen, dass das Kunden zehntausende Pfund in verlorenem organischem Traffic gekostet hat. Lass uns also präzise sein, wann Server-Side Rendering dir tatsächlich hilft, und wann es stillschweigend deine Site langsamer und schwerer wartbar macht ohne jeden SEO-Gewinn.
Wie Googlebot JavaScript in 2026 tatsächlich verarbeitet
Googlebot nutzt eine Headless-Chromium-Instanz. Das ist wahr und ist es schon seit Jahren. Aber hier ist, was die Dokumentation stillschweigend übergeht: Das Rendering läuft in zwei Wellen ab. Die erste Welle crawlt dein HTML. Die zweite Welle, in der JavaScript ausgeführt wird, passiert später, manchmal Stunden später, manchmal Tage später. Googles eigene Dokumentation bestätigt diese Zwei-Wellen-Architektur, wirbt aber nicht gerade dafür.
Was das praktisch bedeutet: Wenn deine Produkttitel, Meta-Descriptions oder Body-Copy innerhalb eines useEffect leben, das nach dem Mount ausgelöst wird, besteht eine echte Chance, dass Googlebot eine leere oder unvollständige Version deiner Seite indexiert. Ich habe das dutzende Male mit Googles URL Inspection Tool in der Search Console verifiziert, der Tab „Rendered HTML" zeigt dir genau, was Googlebot sieht. Führe es jetzt auf deinen React-Seiten aus. Du könntest eine böse Überraschung bekommen.
Das Crawl-Budget-Problem, über das niemand spricht
Googlebot hat nicht unbegrenzte Rechenkapazität zum Rendern. Große JavaScript-Bundles verbrauchen das Crawl-Budget schneller. Eine Website mit 200KB blockierendem JS auf jeder Seite wird weniger häufig gecrawlt als eine schlankere. Bei kleinen Broschüren-Websites spielt das kaum eine Rolle. Bei einem E-Commerce-Katalog mit 40.000 SKUs? Das ist der Unterschied zwischen Googlebot, das deine Neuzugänge in zwei Tagen sieht, versus zwei Wochen.
Ich baute für einen Kunden in Manchester eine Großhandels-Fashion-Website mit etwa 22.000 Produktseiten, Shopify-basiert, aber mit einer stark angepassten React-Storefront-Schicht oben drauf. Ihre Crawl-Statistiken in Search Console zeigten, dass Googlebot fast 40% seines Crawl-Budgets nur auf JavaScript-Rendering ausgibt. Wir entfernten die Client-Side-Hydration auf Produktseiten, die sie nicht brauchten, wechselten zu statischem HTML für diese Templates, und die Crawl-Abdeckung verbesserte sich innerhalb von sechs Wochen um etwa 30%.
Wann SSR tatsächlich gewinnt
Richtig. Server-Side Rendering, wo der Server vollständiges HTML vor dem Versand an den Browser generiert, löst das Zwei-Wellen-Problem tatsächlich. Wenn dein Content in der initialen HTML-Response ist, muss Googlebot nicht auf das JavaScript-Rendering warten. Erste Welle fängt es auf. Fertig.
SSR ist die richtige Wahl in diesen spezifischen Situationen:
- Inhaltsreiche Seiten, bei denen Ranking das Hauptziel ist. Blog-Posts, Landing Pages, Produktdetail-Seiten mit erheblichem Text-Umfang, diese sollten vollständiges HTML im ersten Byte liefern.
- Seiten mit häufig wechselnden Daten, die aktuell sein müssen. Nachrichtenseiten, Live-Preise, Lagerbestand, SSR mit kurzen Cache-TTLs macht hier Sinn.
- Websites mit schmalem Crawl-Budget relativ zur Seitenzahl. Wenn du mehr Seiten hast, als Googlebot komfortabel in einer Woche crawlt, kaufst du dir mit SSR auf deinen hochpriorisierten Templates konsistente Indexation.
- Metadaten, die pro Seite variieren. Title-Tags, Canonical-URLs, Open Graph Tags, wenn diese von JavaScript geschrieben werden, hast du ein Problem, das SSR sofort behebt.
Next.js macht das relativ unkompliziert mit getServerSideProps (oder dem neueren App Router mit Server Components, die standardmäßig SSR sind). Nuxt macht dasselbe für Vue-Shops. Ich verlasse mich bei fast jedem ernstghaften SEO-Projekt bei Seahawk auf Next.js, wir haben interne Starter-Templates, die standardmäßig Server Components für alles nutzen, das Content berührt.
Aber SSR ist nicht kostenlos
Hier ist die Sache. SSR kostet dich Server-Ressourcen, erhöht die Latenz, wenn dein Server überfordert ist, und macht dein Deployment komplizierter. Time to First Byte zählt bei Core Web Vitals. Punkt. Eine dicke SSR-Response, die 800ms braucht, schneidet bei Interaction to Next Paint und Largest Contentful Paint schlechter ab als eine schlanke statische Seite mit etwas Client-seitigem Hydration.
Das habe ich selbst 2022 bei einem SaaS-Projekt gemacht. Wir haben alles SSR'd, jedes Dashboard-View, jeden Settings-Panel, sogar Seiten ohne SEO-Wert hinter einer Login-Wall. Die TTFB auf unterdimensioniertem Hosting lag bei etwa 900ms. Wir haben Core Web Vitals ruiniert und uns um SEO-Rankings gekümmert, die auf authentifizierten Seiten sowieso nicht zählen. Zwei Sprints brauchten wir dann, um das wieder auseinanderzunehmen.
Wo SSR dir schadet
Lass mich direkt sein: SSR ist falsch für einen erheblichen Teil dessen, was gebaut wird.
Authentifizierte Seiten hinter einem Login. Googlebot sieht sie nicht. SSR hier ist Verschwendung, reine Overhead ohne Ranking-Vorteil. Nutze Client-Side Rendering, cache was du kannst, und höre auf, für Server-Compute zu zahlen, um Seiten zu rendern, die nie indexiert werden.
Hochinteraktive UI-Komponenten. Dashboards, Datenvisualisierungen, Drag-and-Drop-Interfaces. SSR gibt dir die initiale Shell, aber du hydratisierst sowieso alles. Du zahlst die SSR-Kosten und die Hydration-Kosten. Denk hier über Islands Architecture nach, render die statische Shell, hydratisiere nur die interaktiven Teile. Astro macht das wunderbar. Ich nutze es seit Ende 2023 für content-heavy Sites und es hat wirklich verändert, wie ich darüber denke.
Kleine Sites ohne Ranking-Problem. Ein Fünf-Seiten-Portfolio, eine lokale Business-Brochure-Site, der Overhead einer SSR-Pipeline lohnt sich nicht. Statisches HTML in einem CDN, fertig.
Static Generation: Das unterschätzte Mittelfeld
Menschen springen von „Ich brauche SEO" direkt zu SSR und überspringen Static Site Generation (SSG) komplett. Das ist ein Fehler.
SSG, wo Seiten zum Deploy-Zeitpunkt gebaut und als statisches HTML serviert werden, gibt dir alle SEO-Vorteile von SSR (vollständiges HTML in der ersten Response, keine JavaScript-Rendering-Abhängigkeit) ohne die Server-Compute-Kosten. Es ist schneller. Es skaliert trivial. Und für die meisten Content-Sites, Blogs, Marketing-Seiten, Dokumentation, Portfolios ändern sich die Inhalte nicht oft genug für on-demand Rendering.
Bei Seahawk setzen wir standardmäßig auf SSG für alles, das keine Live-Daten braucht. Next.js's generateStaticParams im App Router, Gatsby für content-heavy Projekte (ja, immer noch, es ist fine), Astro für alles, wo Performance das primäre Anliegen ist. Das statische HTML wird über Cloudflare oder Vercel's CDN am Edge gecacht und die TTFB-Zahlen sind außergewöhnlich, durchgehend unter 100ms global.
Der Haken: SSG bricht zusammen, wenn du tausende Seiten hast, die häufig aktualisiert werden, oder wenn Content pro User personalisiert ist. Dann greifst du zu SSR oder ISR (Incremental Static Regeneration, Next.js's Hybrid-Ansatz, der statische Seiten nach Schedule revalidiert). Seahawk hatte ein Property-Portal-Projekt, wo ISR mit einem 60-Sekunden-Revalidation-Fenster perfekt passte. Listings blieben frisch genug, TTFB blieb niedrig, und Googlebot sah jedes Mal vollständiges HTML.
Diagnose deiner JavaScript-SEO-Probleme
Bevor du irgendetwas umschreibst, diagnostiziere. Hier ist der Prozess, den ich tatsächlich nutze:
- Google Search Console URL Inspection. Hole und rendere jede verdächtige URL. Vergleiche das „rendered HTML" mit deinem echten DOM. Wenn Inhalte aus der gerenderten Ansicht fehlen, sieht Googlebot es nicht.
- Screaming Frog im JavaScript-Rendering-Modus. Stelle es so ein, dass es JavaScript rendert, und starte einen Crawl. Vergleiche mit einem Non-Rendering-Crawl. Die Differenz zeigt dir, was JS-abhängig ist.
- Lighthouse in CI. Integriere Lighthouse CI in deine Deploy Pipeline. Du willst LCP unter 2,5 Sekunden und TTFB unter 600ms als Baseline-Ziele.
- Chrome DevTools > Network-Tab > Deaktiviere JavaScript. Brutal einfach. Wenn dein Seiten-Inhalt verschwindet, wenn du JS deaktivierst, sieht Googlebot's erste Welle nichts Nützliches.
- Search Console Coverage Report. „Crawled, currently not indexed" in großem Maßstab deutet oft auf Rendering-Probleme hin, nicht auf Content-Qualitätsprobleme. Nimm nicht an, dass Content-Qualität das erste Problem ist.
Ehrlich gesagt, Schritt vier behebt etwa 60 % der Probleme, die ich auf Client-Websites sehe. Es dauert dreißig Sekunden. Machen Sie es vor allem anderen.
Die Hydration-Steuer: Warum deine Core Web Vitals leiden
Vollständiger SSR mit vollständiger Client-Side Hydration ist das Worst of Both Worlds, wenn du nicht aufpasst. Du sendest ein komplettes HTML-Dokument, der Browser rendert es visuell, und dann springt React (oder Vue, oder was auch immer) ein und „übernimmt" das DOM. Während dieser Übernahme, der Hydration-Phase, ist die Seite visuell interaktiv, aber funktional eingefroren. Klicks werden nicht registriert. Formulare werden nicht abgesendet.
Das ist das, was Total Blocking Time und INP Scores killt. Ich sehe das ständig auf Next.js Sites, die SSR'd sind, aber massive Client-Side Bundles haben. Die React Teams eigene Dokumentation zu Server Components ist speziell dafür designt, dieses Problem zu reduzieren, indem mehr Logik auf dem Server gehalten wird und weniger JavaScript zum Browser geschickt wird.
Praktische Lösung: Überprüfen Sie Ihr JavaScript-Bundle mit der next build-Ausgabe oder Bundle Phobia. Finden Sie heraus, was groß ist, und fragen Sie sich, ob es überhaupt ins Client-Bundle gehört. Ich habe letztes Jahr 180KB aus einem Client-Bundle entfernt, indem ich drei Datenbeschaffungs-Bibliotheken nur auf den Server verschoben und Server-only-Package-Importe verwendet habe. Deren INP sank von 340ms auf 190ms. Das ist eine Verbesserung des Ranking-Signals, nicht nur eine UX-Verbesserung.
Rendering Mode Decision Framework
Hören Sie auf zu raten. So entscheide ich:
- Muss Googlebot diese Seite sehen? Wenn nein, nutze CSR, fertig.
- Ändert sich der Inhalt mehr als einmal pro Tag? Wenn nein, verwende SSG.
- Ändert sich der Inhalt häufig UND muss Googlebot ihn sehen? Nutze ISR, wenn eine gewisse Abgelauftheit akzeptabel ist, SSR, wenn nicht.
- Ist die Seite hochinteraktiv mit minimalem Inhalt? Nutze CSR mit SSG-Shell.
- Hast du ein knappes Server-Budget? Lehne dich zu SSG und Static Content hin, wo möglich.
Dieses Framework deckt etwa 90% der Fälle ab. Die restlichen 10% sind Sonderfälle, personalisierte Inhalte für eingeloggte Nutzer, die auch SEO brauchen (denk an E-Commerce-„Für dich empfohlen" auf öffentlichen Seiten). Das verlangt normalerweise einen hybriden Ansatz: Das Inhalts-Skelett mit SSR rendern und die Personalisierung nach dem Hydration client-seitig hinzufügen.
---
FAQ
Rendert Googlebot 2026 vollständig JavaScript?
Es rendert JavaScript, aber in einer zweiten Welle. Das kann die anfängliche Crawl um Stunden oder sogar Tage verzögern. Wichtige Inhalte wie Fließtext, Titel und Meta-Tags gehören in die initiale HTML-Response. Rechne nicht damit, dass Googlebot deine Rendering-Warteschlange abarbeitet.
Ist SSR beim SEO immer besser als Client-seitiges Rendering?
Nein. SSR ist beim SEO besser auf öffentlich indexierten Seiten, auf denen Inhalte von JavaScript generiert werden. Für authentifizierte Seiten, hochinteraktive Tools oder alles hinter einem Login bringt SSR Kosten ohne SEO-Vorteil. Nutze den richtigen Rendering-Modus für den Kontext.
Wie stelle ich am schnellsten fest, ob meine Website JavaScript-SEO-Probleme hat?
Öffne Chrome DevTools, gehe zu Einstellungen, aktiviere „JavaScript deaktivieren" unter Debugger und lade deine Seite neu. Wenn bedeutsamer Inhalt verschwindet, sieht Googlebots erste Crawl-Welle dieselbe leere Seite. Führe auch die URL-Prüfung in Google Search Console aus und vergleiche den Tab „gerendertes HTML" mit deinem Live-DOM.
Hilft mir Next.js App Router bei JavaScript SEO?
Ja, erheblich. Server Components im App Router rendern standardmäßig auf dem Server und geben vollständiges HTML aus. Du bekommst SSR praktisch umsonst für jede Komponente ohne Interaktivität. Der Haken ist nur: Server und Client Components richtig zu vermischen braucht Disziplin. Es ist leicht, versehentlich zu viel in Client Components zu packen und damit das alte CSR-Problem wieder zu haben.
Sollte ich React Server Components nutzen oder einfach statisch gehen?
Wenn dein Inhalt wirklich statisch ist, sich zwischen Deploys nicht ändert, gib ihn statisch aus. SSG ist einfacher, billiger zu hosten und genauso gut für SEO. React Server Components glänzen, wenn du dynamische Daten auf öffentlichen Seiten brauchst, ohne den vollständigen SSR-dann-Hydration-Overhead. Das sind nicht dasselbe, und die richtige Wahl hängt ganz davon ab, wie dynamisch dein Inhalt ist.
---
Die ehrliche Zusammenfassung: Googlebot ist intelligenter geworden seit 2019, aber es ist noch lange kein Chrome. Das Zwei-Wellen-Rendering-Modell, Crawl-Budget-Limits und Hydration-Kosten führen dazu, dass „wir nutzen SSR" keine vollständige JavaScript-SEO-Strategie darstellt. Es ist nur der Anfang. Kenne die Kosten für jeden Rendering-Modus. Prüfe vor dem Bauen. Höre auf, SSR standardmäßig für Seiten einzusetzen, die Googlebot ohnehin nie zu sehen bekommt. Die Websites, auf die ich bei Seahawk am stolzesten bin, haben nicht die ausgeklügeltste Rendering-Pipeline. Das Entscheidende: Jede Seite wurde genau so viel gerendert wie nötig. Nicht mehr.