JavaScript SEO & Rendering: Wie Googlebot und KI-Crawler mit JS-Seiten umgehen

Am 4. März 2026 hat Google eine Warnung aus seiner offiziellen JavaScript-SEO-Dokumentation entfernt. Die Sektion „Design for accessibility“ – die empfahl, Seiten auch ohne JavaScript funktionsfähig zu halten – wurde kommentiert mit: Die Information sei „veraltet und nicht mehr so hilfreich wie früher.“ Google rendere JavaScript seit Jahren, daher mache JS das Indexing nicht schwerer.

Das klingt nach Entwarnung. Ist es aber nicht. Die Frage „Kann Google JavaScript rendern?“ war schon seit 2019 weitgehend beantwortet. Die relevante Frage 2026 lautet: Welche Crawler erreichen deinen JavaScript-generierten Content überhaupt? Und da wird es unangenehm. Denn während Google seinen Web Rendering Service (WRS) seit Jahren verbessert, rendern die meisten KI-Crawler – GPTBot, ClaudeBot, PerplexityBot, Bytespider, Meta-ExternalAgent – kein JavaScript. Keiner.

In meinen technischen Audits sehe ich regelmässig Single-Page-Apps, die für Google weitgehend korrekt indexiert werden, aber in ChatGPT Search oder Perplexity praktisch unsichtbar sind. Das ist das eigentliche JavaScript-SEO-Problem in 2026 – nicht ob Google es kann, sondern wer ausser Google überhaupt mitkommt.

In diesem Artikel: Wie Googles WRS technisch funktioniert, was im Zwei-Wellen-Crawling schiefgehen kann, warum KI-Crawler kein JS rendern und welche Rendering-Strategie 2026 die richtige ist.

Googles Rendering-Infrastruktur besteht aus dem Web Rendering Service (WRS). Der WRS führt einen Headless-Chromium-Browser aus, um JavaScript zu verarbeiten – denselben Chromium-Build, der auch hinter Google Chrome steckt. Seit 2019 ist dieser Chromium-Build „evergreen“, wird also automatisch auf aktuelle Versionen gehalten. Das bedeutet: Moderne JavaScript-Syntax (ES6+, async/await, Promises, Fetch API) wird unterstützt.

Der Crawling-Prozess läuft in zwei klar getrennten Phasen ab:

Phase 1 – HTTP-Crawl: Googlebot fetcht das rohe HTML vom Server. Kein JavaScript, kein CSS. Was zu diesem Zeitpunkt im initialen HTML steht, wird sofort ausgewertet und für das Indexing genutzt. Title-Tags, Meta-Descriptions, Canonical-URLs, robots-Meta-Tags – alles wird aus diesem HTML gelesen. Die Geschwindigkeit spielt hier keine Rolle für die Vollständigkeit, aber das 2-MB-Limit gilt: Bytes jenseits von 2 MB werden komplett ignoriert.

Phase 2 – Rendering Queue: Seiten mit JavaScript werden von Googlebot in eine Rendering-Queue eingereiht. Sobald Googles Ressourcen es erlauben, wird die Seite mit dem WRS gerendert. Erst jetzt sieht Google den durch JavaScript erzeugten Content. Wie lange das dauert? Google nennt keine konkreten Zahlen. In der Praxis reicht die Spanne von wenigen Stunden bis zu mehreren Wochen – abhängig von der Crawl-Frequenz der Domain, der Server-Performance und der verfügbaren WRS-Kapazität.

Was der WRS verarbeitet: CSS, JavaScript, XHR-Requests und API-Calls. Was er nicht verarbeitet: Bilder und Videos werden nicht heruntergeladen. Das heisst, bei APIs mit langen Response-Zeiten kann der WRS das Rendering abbrechen, bevor der Content geladen ist.

Einen detaillierten Blick auf Googles Crawling-Mechanismus insgesamt – Crawl-Budget, Prioritäten, Frequenz – findest du in meinem Artikel über Crawling und Indexierung bei Google.

Wenn Phase 2 erfolgreich durchläuft, sieht Google den vollständig gerenderten Zustand der Seite. Text, interne und externe Links, strukturierte Daten im JSON-LD-Format (auch wenn das Script-Tag via JS injiziert wurde), Bilder mit korrekten Alt-Tags – das alles ist indexierbar. Wie Google HTML grundsätzlich parst und verarbeitet – noch bevor Rendering ins Spiel kommt – erkläre ich in meinem Artikel über HTML-Parsing & SEO. Lazy Loading, das natives HTML-Attribut loading="lazy" nutzt, ist kein Problem. Infinite Scroll ist schwieriger, aber über eine Paginierung mit korrekten Canonical-URLs lösbar.

Die klassischen JS-SEO-Fails – 2026 noch genauso relevant

Aus meiner Arbeit in technischen SEO-Audits sehe ich bestimmte Muster immer wieder. Die häufigsten Fehler:

Canonical-URLs via JavaScript setzen: Googles Dokumentation ist eindeutig – Canonical-Tags müssen im initialen HTML stehen, nicht via JavaScript gesetzt werden. Wenn der Canonical erst nach dem Rendering gesetzt wird, kann es passieren, dass Google die falsche URL als kanonisch behandelt – oder gar keine. Das ist besonders kritisch bei E-Commerce-Sites mit dynamisch generierten URL-Parametern.

Fragment-basiertes Routing (#): Wenn deine SPA Fragment-URLs nutzt (z. B. example.com/#/produkt/123), sieht Googlebot diese URLs als eine einzige Seite mit Fragments – nicht als separate Seiten. Die korrekte Lösung ist die History API des Browsers, die saubere URLs ohne Fragment erzeugt.

HTTP-Status-Codes via JavaScript: 404-Seiten, die nur clientseitig als „nicht gefunden“ markiert werden, aber den HTTP-Status 200 zurückgeben – das ist ein Klassiker in SPAs. Google sieht eine 200-Seite und indexiert sie als leeren oder fehlleitenden Content.

Für eine detaillierte Übersicht der gängigen technischen Fehler bei structured Data empfehle ich meinen Artikel zu FAQ Rich Results und Schema-Markup – viele der dort beschriebenen Schema-Grundlagen gelten auch für JavaScript-generierte Markup-Daten. Wer wissen will, ob strukturierte Daten speziell für AI Overviews einen Vorteil bringen, findet eine Einschätzung in meinem Artikel zu strukturierten Daten und AI Overviews.

Das ist der Teil, den viele JS-SEO-Artikel von 2026 noch immer ausblenden: Googles Fähigkeit, JavaScript zu rendern, ist die Ausnahme – nicht die Regel. Die grosse Masse der Crawler, die deinen Content aufnehmen, arbeitet ohne JavaScript-Rendering.

Eine Übersicht der wichtigsten KI-Crawler und ihres Rendering-Stands zum Stand Mitte 2026 – die Infrastruktur einzelner Plattformen kann sich ändern:

* Beobachtung, Stand Mai 2026, keine offizielle Herstelleraussage. Da sich Crawler-Infrastrukturen jederzeit ändern können, sollten Betreiber relevanter Seiten ihre Sichtbarkeit regelmässig prüfen.

Was bedeutet das praktisch? ChatGPT und Claude laden JavaScript-Dateien teilweise herunter, führen sie aber nicht aus. Sie können in der Regel keinen Content lesen, der durch clientseitiges Rendering erst im Browser erzeugt wird. Wenn dein Produkttext, deine Preise oder dein Hauptinhalt nur via JavaScript in den DOM gerendert werden, sehen diese Crawler eine leere Seite – oder bestenfalls den HTML-Skeleton.

In meiner Praxis ist das kein abstraktes Problem mehr. Bei einem Client im E-Commerce-Bereich mit einer Vue.js-SPA ohne SSR war der GPTBot-Traffic schlicht null. Nicht weil die Inhalte schlecht waren, sondern weil GPTBot nichts sehen konnte. Die Indexierung in ChatGPT Search war faktisch nicht vorhanden.

Wie sich KI-Crawler insgesamt auf Traffic und Sichtbarkeit auswirken, ist ein Thema, das den Rahmen dieses Artikels sprengt. Relevant in diesem Kontext: Google hat für KI-Agenten einen eigenen User Agent eingeführt – was das bedeutet, erkläre ich im Artikel zum Google-Agent und dem neuen User Agent für KI-Agenten. Wer seinen Content gezielt für KI-Suchen sichtbar machen will, findet Ansätze im llms.txt Guide. Und wie Google seinen Algorithmus für KI-gestützte Suche gewichtet, erkläre ich im Artikel über den Google Algorithmus: Crawling, Indexierung und Ranking.

Die vier verbreiteten Rendering-Ansätze unterscheiden sich grundlegend darin, wo und wann HTML generiert wird (technischer Hintergrund: web.dev: Rendering on the Web):

Client-Side Rendering (CSR)

Der Browser erhält eine minimale HTML-Seite mit einem leeren <div id="app"></div>. JavaScript lädt, führt sich aus und erzeugt erst dann den sichtbaren Content. Das ist der klassische SPA-Ansatz mit React, Vue oder Angular ohne serverseitiges Rendering.

Für Google: Funktioniert nach Phase 2 – aber mit Verzögerung und Crawl-Budget-Kosten. Für alle anderen Crawler: Meistens unsichtbar.

Server-Side Rendering (SSR)

Der Server rendert die Seite bei jedem Request vollständig und liefert fertiges HTML. Next.js, Nuxt.js und Remix unterstützen SSR nativ. Jeder Crawler – Google, GPTBot, ClaudeBot – erhält sofort vollständiges HTML.

Nachteil: Server-Load bei hohem Traffic. Vorteil: Beste Crawlbarkeit für alle Bots, kein Rendering-Queue-Problem.

Static Site Generation (SSG)

HTML wird einmalig zur Build-Zeit generiert und als statische Datei ausgeliefert. Astro, Next.js (getStaticProps), Nuxt.js (nuxt generate) oder 11ty sind typische SSG-Tools. Maximale Performance, perfekte Crawlbarkeit für alle Bots, kein serverseitiger Rendering-Overhead.

Einschränkung: Dynamischer Content (User-spezifisch, Echtzeit-Daten) benötigt clientseitiges Nachladen oder ISR.

Dynamic Rendering

Eine Middleware erkennt Crawler via User-Agent und liefert statisch vorgerendertes HTML nur für Bots aus. Normale User erhalten die SPA. Seit Google SSR-Frameworks empfiehlt, gilt Dynamic Rendering offiziell als Übergangslösung – nicht als bevorzugter Ansatz für neue Projekte.

Das Problem mit Dynamic Rendering für KI-Crawler: Viele KI-Bots sind in der Bot-Detection-Liste nicht aufgeführt. Du müsstest GPTBot, ClaudeBot, PerplexityBot etc. alle explizit als Bots eintragen und regelmässig aktualisieren, wenn neue Crawler dazukommen. Das ist wartungsintensiv und fehleranfällig.

Das Framework entscheidet nicht über SEO-Erfolg oder -Misserfolg. Die Konfiguration des Renderings entscheidet das. Trotzdem gibt es klare Unterschiede, wie leicht oder schwer ein Framework gutes Rendering ermöglicht:

Next.js ist der Platzhirsch für React-basierte SSR- und SSG-Projekte. App Router, Server Components, getStaticProps und ISR (Incremental Static Regeneration) bieten granulare Kontrolle darüber, was server- und was clientseitig gerendert wird. SEO-technisch sehr stark, wenn man die Rendering-Modes bewusst einsetzt – nicht als Autopilot.

Nuxt.js ist das Vue.js-Äquivalent zu Next.js und ebenbürtig in der Rendering-Flexibilität. SSR, SSG und hybride Modes werden nativ unterstützt. Für Teams mit Vue-Hintergrund die natürliche Wahl.

Astro verfolgt einen anderen Ansatz: „Islands Architecture“ oder „Partial Hydration“. Standardmässig werden statische HTML-Seiten ohne clientseitiges JavaScript ausgeliefert. JavaScript wird nur dort hinzugeladen, wo interaktive Komponenten es tatsächlich brauchen. Das ist aus SEO-Sicht – und besonders aus KI-Crawler-Sicht – der cleanste Ansatz. Nachteil: Sehr dynamische Applikationen sind mit Astro umständlicher zu bauen.

Remix orientiert sich stark an Web-Standards und nativen Browser-APIs. Serverseitiges Rendering ist der Default. Für content-getriebene Seiten eine sehr solide Wahl.

Angular (ohne Universal) und reines React/Vue ohne SSR sind für SEO-relevante Projekte 2026 keine Option mehr, wenn der Content für KI-Crawler sichtbar sein soll.

Ein technischer Aspekt, der oft unterschätzt wird: Zu grosse JavaScript-Bundles können beim WRS-Rendering zu Timeouts führen. Das Googlebot 2-MB-Crawl-Limit gilt auch für externe Ressourcen. Bundle-Splitting und Code-Splitting sind deshalb nicht nur Performance-Optimierungen, sondern direkt SEO-relevant.

Google hat einen veralteten Hinweis aus der Dokumentation entfernt: den Browser-Quick-Check, bei dem JavaScript im Browser deaktiviert wurde, um zu sehen, was Googlebot sieht. Das war lange eine verbreitete Methode – sie ist veraltet. Der korrekte Workflow:

URL Inspection Tool in der Search Console: Gibt dir das gerenderte HTML zurück, das Googlebot zuletzt gesehen hat, inkl. Screenshot. Zeige „Getestete Seite anzeigen“ – dort siehst du genau, welche Ressourcen geladen wurden, welche Fehler aufgetreten sind und wie die Seite gerendert aussieht. Das ist das direkteste Signal, das Google dir anbietet.

Rich Results Test: Für JSON-LD-Validierung und Structured-Data-Überprüfung. Zeigt, ob Google deine Markup-Daten lesen kann – egal ob sie direkt im HTML stehen oder via JavaScript injiziert werden.

Lighthouse im Chrome DevTools: Gibt Performance-Metriken (LCP, CLS, INP) und zeigt, wie das JavaScript-Rendering die Core Web Vitals beeinflusst. Hohe JavaScript-Ausführungszeiten schlagen sich direkt in schlechten INP-Werten nieder. Einen vollständigen Optimierungs-Guide zu allen drei Metriken habe ich in meinem Artikel zu Core Web Vitals: LCP, INP & CLS optimieren aufbereitet.

Log-File-Analyse: Server-Logs zeigen dir, wann Googlebot deine Seiten crawlt (Phase 1) und wann der WRS zum Rendering zurückkehrt (Phase 2 – erkennbar am anderen User-Agent-String des Googlebot-Renderers). Sehr grosse Abstände zwischen Phase 1 und Phase 2 sind ein Signal, dass deine Seiten in der Rendering-Queue niedrig priorisiert werden.

Zum umfassenderen technischen SEO-Monitoring – inklusive Core Web Vitals, Crawl-Budget-Verwaltung und Indexierungs-Status – verweise ich auf meine Artikel zum Google-Crawling und Indexierungsprozess.

Googles Entscheidung, die „JavaScript deaktivieren“-Empfehlung aus der Doku zu streichen, ist ein Signal: Das War „Kann Google JS rendern?“ ist gewonnen. Wer seinen Stack in den letzten Jahren auf SSR oder SSG umgestellt hat, ist gut aufgestellt.

Die neue Front ist die KI-Suche. Und da ist die Antwort auf die Rendering-Frage noch immer ein klares Nein für die meisten Bots. Aus meiner Arbeit mit Clients weiss ich, wie unterschätzt dieser Punkt ist – gerade in Teams mit starkem Entwickler-Hintergrund, die argumentieren „Google rendert das doch.“ Stimmt. Aber GPTBot nicht. Und Perplexity nicht. Und das wird zunehmend traffic-relevant.

Der Handlungsrahmen für 2026 ist klar: SSG als Default für content-lastige Seiten, SSR wo dynamischer Content nötig ist, clientseitiges JavaScript nur für interaktive Elemente – niemals für inhaltlich relevanten Content. Dynamic Rendering nur als Übergangslösung für Legacy-SPAs, nicht als Neubau-Ansatz.

Stand dieser Einschätzung: Mitte 2026. Insbesondere die Angaben zum JavaScript-Rendering-Verhalten von KI-Crawlern basieren auf Beobachtungen und können sich mit technologischen Änderungen in der Crawler-Infrastruktur der jeweiligen Anbieter ändern. Empfehlung: Sichtbarkeit in KI-Suchen regelmässig per Log-Analyse oder Crawler-Audit prüfen.