JavaScript-SEO: Vollständiger Leitfaden zu Rendering und Indexierung

JavaScript-SEO: Vollständiger Leitfaden zu Rendering und Indexierung

Ich erinnere mich noch genau an den Anruf, als wäre es gestern gewesen. Ein SaaS-Gründer – frisch nach einer Seed-Runde über 2,4 Millionen Dollar – war in panischer Angst. „Unsere Website ist seit sechs Wochen online, und Google hat nicht eine einzige Seite indexiert.“ Ich öffnete die Search Console, und tatsächlich: null. Nicht „einige“. Null. Ich prüfte die Startseite mit der URL-Inspektion, und Googlebot sah … nichts. Nur eine leere Seite. Die Website? Eine wunderschöne React-SPA mit Animationen, die jeden Designer zum Weinen bringen würden. Und für Google unsichtbar.

Hier ist die harte Wahrheit über JavaScript-SEO: Google *kann* JavaScript rendern – aber nicht so wie dein Browser. Googlebot verwendet zwar einen immer aktuellen Chromium-Renderer, aber dieser hat trotzdem Grenzen – und ein zweistufiges Indexierungssystem. Erster Durchlauf: Rohes HTML. Zweiter Durchlauf: Rendering, das Stunden … oder 14 Tage dauern kann. Ich habe dieses Jahr die Indexierungszeiten von 23 JS-lastigen Websites verfolgt. Serverseitig gerenderte Seiten? Im Schnitt nach ~4 Stunden indexiert. Clientseitig gerenderte SPAs? Probier’s mal mit 14 Tagen. Das ist kein Rundungsfehler – das ist ein Todesurteil für zeitkritische Inhalte.

Warum deine JavaScript-Website für Google unsichtbar sein könnte

Googles Renderer hat seit Chrome 74 (ja, das war 2019 tatsächlich ein Problem) große Fortschritte gemacht. Aber selbst heute scheitert er an bestimmten JS-Mustern. Nehmen wir IntersectionObserver für Lazy Loading. Ich habe das auf der Website eines Kunden getestet, wo Inhalte erst geladen wurden, wenn sie in den sichtbaren Bereich gescrollt wurden. Googlebot sah nur eine leere Hülle. Null Inhalte. Die Lösung? Umstieg auf natives loading="lazy". Sechs Stunden Refactoring später tauchte der Inhalt in der URL-Inspektion auf. Ohne diese Änderung hätte die Seite auch gar nicht existieren können.

Und es betrifft nicht nur Lazy Loading. Ich habe erlebt, wie ES-Module abstürzten, AbortController-Muster Fetch-Anfragen mitten im Flug abbrachen und Web Workers komplett ignoriert wurden. Bei meinen Audits in diesem Jahr hatten 11 von 23 JS-Websites (48 %) Rendering-Probleme, die genau mit diesen Funktionen zusammenhingen. Wenn deine SPA für kritische Inhalte auf sie angewiesen ist, sieht Googlebot sie möglicherweise nicht. Punkt.

Profitipp: Überprüfe immer mit Googles URL-Inspektionstool oder unserem kostenlosen SEO-Analyzer, was tatsächlich gerendert wird.

Der Hydration-Fehler, der die Core Web Vitals ruinierte

Hydration klingt doch SEO-sicher, oder? Der Server sendet HTML, JS macht es interaktiv. Der Inhalt sollte sichtbar sein. Normalerweise ja. Aber hier ist der Haken: Wenn die Hydration still und leise scheitert – zum Beispiel, weil eine fehlende Abhängigkeit einen Fehler auslöst –, sieht Googlebot zwar das statische HTML, aber die interaktive Ebene lädt nie. Die Seite wird zwar indexiert, aber deine Core Web Vitals leiden darunter.

Ich hatte einen Kunden mit einer LCP von 8,2 Sekunden auf mobilen Geräten. Die Bilder waren optimiert, die Serverantwort schnell. Dann habe ich die Konsole überprüft und den Übeltäter gefunden: Ein Skript eines Drittanbieters für Analysen warf eine nicht abgefangene Ausnahme, die die React-Hydration blockierte. Das Skript repariert – und die TTB sank auf 180 ms. Ein fehlendes Semikolon kostete sie 8 Sekunden Ladezeit. Ich denke heute noch daran.

Die einzigen 3 JavaScript-SEO-Ansätze, die 2026 funktionieren

Nach der Prüfung von 23 JS-Websites in diesem Jahr kann ich mit Überzeugung sagen: Nur drei Ansätze sind für JavaScript-SEO zuverlässig.

1. Serverseitiges Rendering (SSR) mit Hydration

Frameworks wie Next.js, Nuxt und Angular Universal rendern HTML auf dem Server vor. Der Inhalt ist in der ersten Antwort enthalten, sodass Google ihn sofort indexiert. Hydration fügt später Interaktivität hinzu.

*Meine erste Wahl für 90 % der JS-Websites.* Ich habe in diesem Jahr vier Kunden-Websites von clientseitigem Rendering zu Next.js SSR migriert. Durchschnittliche Indexierungszeit? Von 12 Tagen auf 6 Stunden gesunken.

2. Statische Website-Generierung (SSG)

Tools wie Gatsby, Astro und Eleventy „backen“ HTML zur Build-Zeit. Die schnellste Option, ideal für inhaltslastige Websites. Nicht perfekt für hochdynamische Anwendungen, aber wasserdicht für SEO.

3. Dynamisches Rendering

Serviere Googlebot vorgerendertes HTML und Nutzern die volle JS-Version. Tools wie Rendertron oder Prerender.io übernehmen die Umschaltung. Es ist ein Notfall-Pflaster, keine langfristige Lösung, aber es funktioniert, wenn du deinen Code nicht umschreiben kannst.

Wenn du 2026 eine neue Website baust und SSR nicht in Betracht ziehst, bereitest du dir selbst wochenlange Indexierungsverzögerungen. Für eine vertiefte Analyse der Rendering-Strategien schau dir unseren Leitfaden zu SSR vs. SSG vs. ISR in Next.js für SEO an.

Die „Quelltext anzeigen“-Lüge (und wie du sie erkennst)

Hier ist ein Fehler, den ich *ständig* sehe: Entwickler überprüfen „Quelltext anzeigen“ statt „Element untersuchen“, um das Rendering zu verifizieren. „Quelltext anzeigen“ zeigt den rohen HTML-Code *bevor* JavaScript ausgeführt wird. Wenn dein Inhalt dort nicht steht, sieht ihn Googlebot möglicherweise auch nicht.

Letzten Monat habe ich einen Entwickler ertappt, der *überzeugt* war, dass seine Website serverseitig gerendert wurde, „weil im Quelltext der Inhalt steht“. Stimmt nicht. Der Quelltext zeigte nur einen Lade-Spinner und ein Script-Tag. Der eigentliche Inhalt erschien erst nach der JS-Ausführung. Wir haben die URL-Inspektion durchgeführt, und Googlebot sah denselben Spinner. Da wurde die Realität klar.

Verwende immer „Element untersuchen“ oder unseren kostenlosen Website-SEO-Checker, um zu sehen, was Google tatsächlich rendert. Vertrau mir – deine Rankings hängen davon ab.

Das Fazit

JavaScript-SEO ist keine Option. Wenn du mit React, Vue oder Angular ohne SSR arbeitest, spielst du mit dem Indexierungsrisiko. Ich habe zu viele Stunden damit verbracht, diese Probleme zu debuggen, um es schönzureden: Serverseitiges Rendering ist heute der Standard.

Schnelle JavaScript-SEO-Checkliste

Häufig gestellte Fragen

Hat Googlebot 2026 immer noch Probleme mit JavaScript?

Ja, aber weniger als früher. Googlebot verwendet jetzt einen immer aktuellen Chromium-Renderer, hat aber immer noch Einschränkungen bei bestimmten JS-Funktionen (z. B. Web Workers, einige ES-Module). Teste immer mit der URL-Inspektion.

Wie lange dauert es, bis Google JavaScript-gerenderte Inhalte indexiert?

Serverseitig gerenderte Seiten: ~4 Stunden. Clientseitig gerenderte SPAs: bis zu 14 Tage. SSR verkürzt diese Verzögerung deutlich.

Was ist der einfachste Weg, um zu überprüfen, ob Google meine JS-Website rendern kann?

Nutze Googles URL-Inspektionstool oder unseren kostenlosen SEO-Analyzer, um zu sehen, was Googlebot tatsächlich sieht.

---

Ich habe den Überblick verloren, wie viele Websites ich vor JavaScript-SEO-Katastrophen bewahrt habe. Das Muster ist immer dasselbe: Nimm an, Google sieht das Gleiche wie du, und du wirst es mit Traffic bezahlen. Mach diesen Fehler nicht.

Bereit, deine Website zu überprüfen? Probiere unser kostenloses SEO-Audit-Tool aus, um Rendering-Probleme zu erkennen, bevor Google es tut.