Ein Klient rief mich Anfang 2024 an -- mittleres E-Commerce-Unternehmen, React Frontend, Next.js, alles auf dem Papier richtig gemacht. Ihre Kategorieseiten rankten nirgendwo. Nirgendwo. Die Website sah brillant aus, das UX-Team war stolz drauf, und Googlebot sah im Grunde nur leere <div>-Suppe. Drei Monate verlorene Einnahmen, nur weil jemand einen Medium-Artikel von 2021 gelesen hatte und annahm, Googlebot würde JavaScript "wie Chrome jetzt handhaben". Tut er nicht. Nicht zuverlässig. Nicht 2026.Next.js, did everything right on paper. Their category pages were ranking nowhere. Nowhere. The site looked brilliant, the UX team was proud of it, and Googlebot was essentially seeing empty<div>soup. Three months of missed revenue, all because someone had read a Medium post from 2021 and assumed Googlebot handles JavaScript "like Chrome does now." It doesn't. Not reliably. Not in 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.Googlebot renders JavaScript "sort of": rendering is delayed and fallible, so server-side render anything you need indexed and treat client-only content as invisible.
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.can render JavaScript. But it runs on a crawl budget, it renders asynchronously in a secondary wave, and any JavaScript that fetches content after the initial paint is a gamble you're taking with your rankings. I've seen this cost clients tens of thousands of pounds in lost organic traffic. So let's be precise about when server-side rendering actually helps you, and when it quietly makes your site slower and harder to maintain for no SEO gain whatsoever.
Wie Googlebot JavaScript in 2026 tatsächlich verarbeitet
Googlebot verwendet eine headless Chromium-Instanz. Das stimmt und ist seit Jahren so. Aber hier ist, was die Dokumentation diskret übersieht: Das Rendering läuft in zwei Wellen ab. Die erste Welle crawlt Ihr HTML. Die zweite Welle -- wo 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 wirklich dafür.Google's own documentation confirms this two-wave architecture, though it doesn't exactly advertise the delay.
Was das praktisch bedeutet: Wenn Ihre Produkttitel, Meta-Beschreibungen oder Body Copy in einem useEffect leben, das nach dem Mount feuert, gibt es eine echte Chance, dass Googlebot eine leere oder teilweise Version Ihrer Seite indexiert. Ich habe das dutzende Male mit dem URL-Inspektions-Tool von Google Search Console überprüft -- der Tab "Gerendertes HTML" zeigt Ihnen genau, was Googlebot sieht. Führen Sie es jetzt auf Ihren React-Seiten aus. Sie könnten eine unangenehme Überraschung bekommen.useEffect that fires after mount, there's a real chance Googlebot indexes a blank or partial version of your page. I've verified this dozens of times using Google Search Console's URL Inspection tool -- the rendered HTML tab shows you exactly what Googlebot sees. Run it on your React pages right now. You might get a nasty surprise.
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 eine Großhandelsfashion-Website für einen Kunden in Manchester -- 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 für JavaScript-Rendering aufwendete. Wir strippten die Client-seitige Hydration auf Produktseiten, die sie nicht brauchten, schalteten auf statisches HTML für diese Templates um, und die Crawl-Abdeckung verbesserte sich innerhalb von sechs Wochen um ungefähr 30%.
Wann SSR tatsächlich gewinnt
Richtig. Also Server-seitiges Rendering -- wo der Server vollständiges HTML generiert, bevor es zum Browser geht -- löst das Zwei-Wellen-Problem wirklich. Wenn Ihr Inhalt in der initialen HTML-Response ist, muss Googlebot nicht auf das JavaScript-Rendering warten. Erste Welle schnappst es sich. Fertig.
SSR ist die richtige Wahl in diesen spezifischen Situationen:
- Inhaltsreiche Seiten, bei denen Ranking das primäre Ziel ist. Blog-Beiträge, Landing Pages, Produktdetail-Seiten mit umfangreicher Copy -- diese sollten vollständiges HTML beim ersten Byte liefern.Blog posts, landing pages, product detail pages with substantial copy -- these should be delivering full HTML on the first byte.
- Seiten mit häufig wechselnden Daten, die aktuell sein müssen. Nachrichtenseiten, Live-Preisgestaltung, Verfügbarkeit von Beständen -- SSR mit kurzen Cache-TTLs macht hier Sinn.News sites, live pricing, stock availability -- SSR with short cache TTLs makes sense here.
- 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.If you've got more pages than Googlebot comfortably crawls in a week, SSR on your high-priority templates buys you consistent indexation.
- Metadaten, die pro Seite unterschiedlich sind. Title Tags, Canonical URLs, Open Graph Tags -- wenn diese von JavaScript geschrieben werden, haben Sie ein Problem, das SSR sofort behebt.Title tags, canonical URLs, Open Graph tags -- if these are being written by JavaScript, you've got a problem SSR fixes instantly.
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. Bei Seahawk setze ich für fast jedes ernsthafte SEO-Projekt auf Next.js -- wir haben interne Starter-Templates, die standardmäßig Server Components für alles verwenden, das mit Content arbeitet.getServerSideProps(or the newer App Router's Server Components, which are SSR by default). Nuxt does the same for Vue shops. I lean on Next.js for almost every serious SEO project at Seahawk -- we've got internal starter templates that default to server components for anything that touches content.
Aber SSR ist nicht kostenlos
Hier ist die Sache. SSR addiert Server-Last, es addiert Latenz, wenn dein Server langsam oder unterdimensioniert ist, und es addiert Komplexität zu deiner Deployment Pipeline. Time to First Byte (TTFB) zählt für Core Web Vitals. Eine aufgeblähte SSR-Response, die 800ms zum Ankommen braucht, ist schlechter für Interaction to Next Paint und Largest Contentful Paint als eine schnelle statische Seite mit ein wenig Client-Side Hydration.Interaction to Next Paint and Largest Contentful Paint than a fast static page with a bit of client-side hydration.
Ich habe diesen Fehler selbst 2022 in einem SaaS-Projekt gemacht. Wir haben alles SSR'd -- jede Dashboard-View, jedes Settings-Panel, Pages ohne SEO-Wert hinter einer Login-Wall. Die TTFB auf unterdimensioniertem Hosting lag bei etwa 900ms. Wir haben Core Web Vitals verschlechtert, um einen SEO-Gewinn zu erzielen, der auf authentifizierte Pages gar nicht anwendbar war. Es hat uns zwei Sprints gekostet, das wieder rückgängig zu machen.
Wo SSR dir schadet
Lass mich direkt sein: SSR ist falsch für einen erheblichen Teil dessen, was gebaut wird.wrong for a significant chunk of what gets built.
Authentifizierte Pages hinter einem Login. Googlebot kann sie nicht sehen. SSR ist hier Verschwendung -- reiner Overhead ohne Ranking-Nutzen. Nutze Client-Side Rendering, cache was du kannst, und höre auf, Server-Rechenleistung dafür auszugeben, um Pages zu rendern, die nie indexiert werden.Googlebot can't see them. SSR here is waste -- pure overhead with no ranking benefit. Use client-side rendering, cache what you can, and stop paying for server compute to render pages that will never be indexed.
Hochinteraktive UI-Komponenten. Dashboards, Datenvisualisierungen, Drag-and-Drop-Interfaces. SSR gibt dir die initiale Shell, aber du hydratisierst ohnehin alles. Du zahlst die SSR-Kosten und die Hydrations-Kosten. Erwäge hier eine Islands-Architektur -- rendere die statische Shell, hydratisiere nur die interaktiven Teile. Astro macht das hervorragend. Ich nutze es seit Ende 2023 für Content-Heavy Sites und es hat wirklich verändert, wie ich über das nachdenke.Dashboards, data visualisations, drag-and-drop interfaces. SSR gives you the initial shell but you're hydrating everything anyway. You're paying the SSR cost and the hydration cost. Consider islands architecture here -- render the static shell, hydrate only the interactive bits. Astro does this beautifully. I've been using it for content-heavy sites since late 2023 and it's genuinely changed how I think about this.
Kleine Sites ohne Ranking-Problem. Ein Portfolio mit fünf Pages, eine lokale Business-Brochure-Site -- der Overhead einer SSR-Pipeline lohnt sich nicht. Statisches HTML in einem CDN, Punkt.A five-page portfolio, a local business brochure site -- the overhead of an SSR pipeline isn't worth it. Static HTML in a CDN, full stop.
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 -- bei dem Pages zur Deploy-Zeit gebaut und als statisches HTML ausgeliefert werden -- gibt dir alle SEO-Vorteile von SSR (vollständiges HTML in der ersten Response, keine JavaScript-Rendering-Abhängigkeit) ohne die Server-Rechenleistungs-Kosten. Es ist schneller. Es skaliert trivial. Und für die Mehrheit von Content-Sites -- Blogs, Marketing Pages, Dokumentationen, Portfolios -- ändert sich der Content nicht oft genug, um On-Demand Rendering zu brauchen.
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 in Ordnung), Astro für alles, bei dem Performance die primäre Sorge ist. Das statische HTML wird am Edge via Cloudflare oder Vercel's CDN gecacht und die TTFB-Zahlen sind außergewöhnlich -- durchgehend unter 100ms weltweit.generateStaticParams in the App Router, Gatsby for content-heavy projects (yes, still, it's fine), Astro for anything where performance is the primary concern. The static HTML gets cached at the edge via Cloudflare or Vercel's CDN and the TTFB numbers are extraordinary -- consistently under 100ms globally.
Der Haken: SSG funktioniert nicht, wenn du tausende Pages hast, die häufig aktualisiert werden, oder wenn Content pro Nutzer personalisiert ist. Dann greifst du zu SSR oder ISR (Incremental Static Regeneration -- Next.js's Hybrid-Ansatz, der statische Pages nach Plan neu validiert). Seahawk hatte ein Property-Portal-Projekt, bei dem ISR mit einem 60-Sekunden-Revalidierungs-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.Fetch and render any suspect URL. Compare the "rendered HTML" against your actual DOM. If content is missing from the rendered view, Googlebot isn't seeing it.
- 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.Set it to render JavaScript and run a crawl. Compare with a non-rendering crawl. The delta shows you what's JS-dependent.
- Lighthouse in CI. Integriere Lighthouse CI in deine Deploy Pipeline. Du willst LCP unter 2,5 Sekunden und TTFB unter 600ms als Baseline-Ziele.Integrate Lighthouse CI into your deploy pipeline. You want LCP under 2.5 seconds and TTFB under 600ms as baseline targets.
- 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.Brutally simple. If your page content disappears when you disable JS, Googlebot's first wave sees nothing useful.
- Search Console Coverage-Report. "Crawled -- currently not indexed" im großen Stil deutet oft auf Rendering-Probleme hin, nicht auf Content-Quality-Probleme. Gehe nicht davon aus, dass erst Content-Quality das Problem ist."Crawled -- currently not indexed" at scale often points to rendering issues, not content quality issues. Don't assume content quality first.
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.
The Hydration Tax: Why Your Core Web Vitals Are Suffering
Vollständiges SSR mit vollständiger Client-Side Hydration ist das Schlechteste aus beiden Welten, wenn du nicht aufpasst. Du sendest ein vollständiges HTML-Dokument, der Browser rendert es visuell, und dann startet React (oder Vue, oder was auch immer) und "übernimmt" das DOM. Während dieser Übernahme -- der Hydrations-Phase -- ist die Page 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.React team's own documentation on Server Components is specifically designed to reduce this problem by keeping more logic on the server and shipping less JavaScript to the browser.
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.next build output or Bundle Phobia. Find what's large and ask whether it needs to be in the client bundle at all. I cut 180KB from a client's bundle last year just by moving three data-fetching libraries to server-only and using server-only package imports. Their INP went from 340ms to 190ms. That's a ranking signal improvement, not just a UX improvement.
Rendering Mode Decision Framework
Hören Sie auf zu raten. So entscheide ich:
- Muss Googlebot diese Seite sehen? Wenn nein -- verwende 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 Spezialfälle -- personalisierter Inhalt für angemeldete Benutzer, der auch SEO benötigt (denk an E-Commerce "empfohlen für dich" auf öffentlichen Seiten), was üblicherweise ein Hybrid erfordert: SSR für das Inhalts-Skelett mit Personalisierung, die nach dem Hydration client-seitig hinzugefügt wird.
---
FAQ
Rendert Googlebot 2026 vollständig JavaScript?
Es rendert JavaScript, aber in einer zweiten Welle, die dem ursprünglichen Crawl um Stunden oder Tage hinterherhinken kann. Inhalte, die für die Indexierung kritisch sind -- Body-Text, Titel, Meta-Tags -- sollten in der ursprünglichen HTML-Response sein. Verlasse dich nicht auf Googlebots Rendering-Queue für deine Rankings.
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 werden standardmäßig auf dem Server gerendert, was bedeutet, dass ihre Ausgabe vollständiges HTML ist. Du bekommst praktisch SSR kostenlos für jede Komponente, die keine Interaktivität benötigt. Der Haken ist, dass das korrekte Mischen von Server und Client Components Disziplin erfordert -- es ist leicht, versehentlich zu viel in Client Components zu schieben und das alte CSR-Problem nachzubilden.
Sollte ich React Server Components nutzen oder einfach statisch gehen?
Wenn dein Inhalt wirklich statisch ist -- ändert sich nicht zwischen Deployments -- mache ihn statisch. SSG ist einfacher, günstiger zu hosten und genauso gut für SEO. React Server Components glänzen, wenn du dynamische Daten auf öffentlichen Seiten brauchst, ohne den ganzen Server-rendered-HTML-dann-hydrate-Overhead. Sie sind nicht dasselbe, und die richtige Wahl hängt ganz davon ab, wie dynamisch dein Inhalt ist.
---
Die ehrliche Zusammenfassung: Googlebot ist intelligenter als 2019, aber es ist immer noch nicht Chrome. Das Two-Wave-Rendering-Modell, Crawl-Budget-Beschränkungen und Hydration-Kosten bedeuten, dass "wir verwenden SSR" keine vollständige JavaScript-SEO-Strategie ist -- es ist ein Ausgangspunkt. Kenne die Kosten jedes Rendering-Modus, prüfe vor dem Bau, und höre auf, SSR standardmäßig für Seiten zu verwenden, die Googlebot ohnehin nie sehen wird. Die Seiten, auf die ich bei Seahawk am stolzesten bin, sind nicht diejenigen, die die anspruchsvollste Rendering-Pipeline verwenden. Es sind diejenigen, bei denen jede Seite genau so viel gerendert wurde, wie sie brauchte, und nicht mehr.exactly as much as it needed to be, and no more.