JavaScript-SEO: Rendering, Hydration und Indexierung

Januar 2025: Ein Mode-E-Commerce meldete sich in Panik. 18.000 PDP-URLs waren als 'soft 404' indexiert. Das ausgelieferte HTML enthielt drei Zeilen im , der eigentliche Inhalt erschien erst, nachdem React clientseitig gemountet war. Der Googlebot fuhrte das JS zwar aus, aber mit durchschnittlich neun Tagen Verzogerung in der Render-Queue. Ergebnis: ein nach jedem Deploy fast zwei Wochen unsichtbarer Katalog. Diese Art von Problem taucht in keinem Copy- oder Backlink-Audit auf. Bevor man irgendetwas anderes anfasst, lohnt sich ein Blick auf On-Page-SEO ohne Vermutungen pruefen: ein datenbasiertes Audit, um zu sehen, wo JS-Rendering in die Diagnose einzuordnen ist.

Die Verwirrung beginnt bei der Terminologie. CSR (Client-Side Rendering) liefert ein nahezu leeres HTML und delegiert alles an den Browser. SSR (Server-Side Rendering) erzeugt HTML pro Request, fur jeden Nutzer. SSG (Static Site Generation) baut alles im Build und liefert fertige Dateien. ISR (Incremental Static Regeneration), durch Next.js popular geworden, ist ein Hybrid: statisch, aber on demand revalidiert. Jede Variante hat eigene Trade-offs bei TTFB, Cache-Komplexitat und Serverkosten. Fur SEO lautet die richtige Frage nicht 'welche ist besser', sondern 'in welchem meiner Templates muss der kritische Inhalt im initialen HTML stehen'.

An der Hydration scheitern die meisten Teams. Sie liefern perfektes SSR-HTML, Google indexiert es, doch das JavaScript, das die Seite hydratisiert, wiegt 800 KB und blockiert die Interaktivitat 4 Sekunden lang im 4G-Netz. Der Inhalt rankt zunachst, dann zerstort der LCP das Ranking. Astro, Qwik und React Server Components zielen genau darauf ab, mit partial hydration und resumability. Vor einem Stack-Wechsel sollten Sie messen: Wie viel des aktuellen JS ist above the fold tatsachlich notig? Die meisten Teams stellen fest, dass 70% statisches HTML sein konnen. Das bringt einen doppelten Gewinn bei Core Web Vitals: jenseits des LCP, was wirklich den Hebel bewegt und bei der Indexierung.

Der Mythos 'Google fuhrt doch JavaScript aus' muss differenziert sterben. Ja, der Web Rendering Service nutzt ein aktuelles headless Chromium. Aber es gibt zwei Queues: Crawl (rohes HTML) und Render (mit JS). Auf grossen Seiten kann die Render-Queue tagelang hinterherhinken. Schlimmer: Links, die nur im Post-JS-DOM auftauchen, landen erst nach dem Rendern in der Crawl-Queue. Eine reine SPA-Architektur bestraft also die Entdeckung neuer URLs. Kombiniert mit Problemen aus Crawl Budget: wann es kritisch wird und wie man es misst entstehen Kataloge, in denen 30% der Seiten nie indexiert werden, obwohl sie im Sitemap stehen.

Wie entscheiden in der Praxis? Mit einer einfachen Matrix pro Template. Institutionelle Landingpages mit seltenen Anderungen: SSG, ohne Diskussion. PLPs im E-Commerce mit Filtern: SSR mit Edge-Cache (Vercel Edge, Cloudflare Workers), geschlusselt nach den meistgenutzten Filtern, Fallback auf reines SSR. PDPs: SSG mit ISR von einer Stunde lost 90% der Falle. Eingelogger Bereich (Dashboards, Checkout): CSR ist perfekt, Sie wollen das ohnehin nicht indexiert haben. Der Klassiker-Fehler: die gleiche Strategie auf die gesamte Site anzuwenden, weil das Framework es 'empfiehlt'. Diese Zuordnung greift direkt in die Entscheidungen aus On-Page fur E-Commerce: PLP vs PDP ohne Kannibalisierung.

Tools zur Validierung vor dem Deployment: URL Inspection in der Search Console zeigt das gerenderte HTML, das Google tatsachlich gesehen hat, mit Timestamp. Der Rich Results Test verwendet denselben Renderer. Fur skalierbare Audits vergleicht Screaming Frog im 'JavaScript rendering'-Modus rohes HTML mit gerendertem und legt Inhalte offen, die nur post-JS existieren. Server-Logs sind die einzige harte Wahrheit: nach Googlebot-User-Agent filtern und das tatsachliche Verhaltnis zwischen Googlebot Smartphone und Googlebot beobachten. Wer noch nie Logs angefasst hat, erlebt im ersten Monat von Log file analysis: Was Googlebot wirklich tut meist einen Schock.

Drei Fallen, die ich 2026 immer noch sehe: Lazy-Load mit IntersectionObserver am Hauptinhalt (der Googlebot scrollt nicht, also wird nichts geladen), Client-seitiges Routing ohne korrekte History API (Hash-#-URLs werden nicht indexiert), und per JS nach dem Load injizierte Meta-Tags (im DOM ausgetauschte Titles und Canonicals werden je nach Timing respektiert oder nicht). Fur den dritten Fall lohnt ein Blick auf Canonical Tags: haeufige Fehler, die organischen Traffic ausbluten, denn das Problem ist selten das Canonical selbst, sondern der Zeitpunkt, zu dem es im Dokument erscheint.

Praktischer Takeaway: Fuhren Sie heute ein Audit uber 10 strategische URLs durch. Vergleichen Sie 'view-source' mit 'Inspect Element' in Chrome. Wenn kritische Inhalte, Navigationslinks und Meta-Tags nicht in view-source stehen, haben Sie ein Rendering-Problem, kein Content-Problem. Dokumentieren Sie die Lucken pro Template, priorisieren Sie SSR oder SSG bei Templates, die organischen Umsatz erzeugen, und belassen Sie CSR dort, wo es egal ist. Ein moderner Stack ist keine Ausrede fur leeres HTML auf einer Seite, die ranken muss.