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, wurde bei GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Bytespider und Meta-ExternalAgent keine JavaScript-Ausführung gemessen (Vercel/MERJ, Dezember 2024). In dieser Messung bei keinem einzigen.

In meinen technischen Audits sehe ich regelmässig Single-Page-Apps, die für Google indexierbar sind, deren clientseitig erzeugte Inhalte im initialen HTML aber fehlen. Das kann die Auffindbarkeit in KI-Diensten einschränken. Beweisen lässt sich eine fehlende Sichtbarkeit allein aus dem Rendering-Verfahren nicht. 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, was die Messdaten zu KI-Crawlern und JavaScript zeigen und welche Rendering-Strategie 2026 die richtige ist.

Für das Rendering verwendet Google eine Headless-Chromium-Umgebung. Dieser Rendering-Schritt wird im SEO-Kontext häufig als Web Rendering Service beziehungsweise WRS bezeichnet. Seit 2019 basiert Googlebot auf einer Evergreen-Version von Chromium, die regelmässig aktualisiert wird. Das bedeutet: Moderne JavaScript-Syntax (ES6+, async/await, Promises, Fetch API) wird unterstützt.

Googles Suchprozess umfasst drei Hauptphasen: Crawling, Rendering und Indexierung. Für JavaScript-Seiten lässt sich der Ablauf vereinfacht als zwei aufeinanderfolgende Verarbeitungsschritte lesen, und genau so sind die folgenden Phasen 1 und 2 gemeint:

Phase 1 - HTTP-Crawl: Googlebot ruft die HTTP-Antwort ab und verarbeitet das darin enthaltene HTML. JavaScript wird hier noch nicht ausgeführt; das passiert erst in der nachgelagerten Rendering-Phase. Was zu diesem Zeitpunkt im initialen HTML steht, wird sofort ausgewertet und für das Indexing genutzt. Das initiale HTML liefert die wichtigen Signale: Links, Title-Tags, Meta-Descriptions, Canonical-URLs und robots-Meta-Tags. Sie sollten möglichst schon dort konsistent stehen; einen Teil davon kann Google auch noch nach dem Rendering verarbeiten. Die Geschwindigkeit spielt hier keine Rolle für die Vollständigkeit, das Abruflimit dagegen schon: Für jede einzelne abgerufene URL beziehungsweise Ressource gilt eine Grenze von 2 MB, und Bytes hinter dieser Grenze werden nicht abgerufen, nicht gerendert und nicht indexiert.

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 für das Rendering verarbeitet: CSS, JavaScript, XHR-Requests und API-Calls. Für Bild- und Videoinhalte gilt das nicht in derselben Form, und Googles JavaScript-Doku sagt dazu nichts Belastbares. Verlass dich bei kritischen Medien deshalb nicht auf nachgelagerte JavaScript-Ausführung, sondern prüfe sie im gerenderten HTML. Wenn API-Requests fehlschlagen, blockiert werden oder zu spät antworten, kann der benötigte Content im gerenderten HTML fehlen. Nachsehen lässt sich das im URL-Prüftool der Search Console und im Rich Results Test.

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 das nachgelagerte Rendering erfolgreich durchläuft, kann Google den dabei erzeugten DOM auswerten. Text, interne und externe Links und strukturierte Daten im JSON-LD-Format können aus dem gerenderten DOM verarbeitet werden, auch wenn das Script-Tag per JavaScript injiziert wurde. Bei Bildern und Videos müssen zusätzlich die URLs und die passenden HTML-Elemente im gerenderten HTML stehen. Verarbeitet werden heisst dabei nicht automatisch indexiert. Wie Google HTML grundsätzlich parst und verarbeitet - noch bevor Rendering ins Spiel kommt - erkläre ich in meinem Artikel über HTML-Parsing & SEO. Natives Lazy Loading über loading="lazy" ist grundsätzlich geeignet, gehört aber ins URL-Prüftool: Entscheidend ist, dass die Bild- und Video-URLs im gerenderten HTML stehen. Infinite Scroll wird dort zum Problem, wo einzelne Inhalte keine eigenständigen, crawlbaren URLs haben. Robuster ist eine zugängliche Paginierung mit normalen Links und konsistenten Canonicals — ein Canonical allein ersetzt keine Paginierung.

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: Canonical-Tags gehören möglichst ins initiale HTML. Google kann ein rel="canonical" zwar auch per JavaScript verarbeiten, schreibt dazu aber ausdrücklich „we don’t recommend using JavaScript for this“. Wird der Canonical erst nach dem Rendering gesetzt oder dabei verändert, darf er nicht von der im ursprünglichen HTML angegebenen kanonischen URL abweichen - sonst kann Google andere Signale heranziehen oder die URL nicht wie beabsichtigt kanonisieren. 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. Viele Crawler ausserhalb von Google arbeiten ohne nachgewiesene JavaScript-Ausführung.

Eine Übersicht der wichtigsten KI-Crawler und ihres Rendering-Stands - die Infrastruktur einzelner Plattformen kann sich ändern. Grundlage der Spalte „JavaScript-Rendering“ ist die Auswertung von Vercel und MERJ vom 17. Dezember 2024 („none of the major AI crawlers currently render JavaScript“, über 500 Millionen ausgewertete GPTBot-Abrufe). Eine Herstellerangabe zur JavaScript-Ausführung liegt für keinen dieser Bots vor; eine öffentliche Nachmessung für 2026 ebenfalls nicht. Stand des Abrufs: 16. August 2026.

* Auf Grundlage der Vercel/MERJ-Auswertung vom Dezember 2024. Es gibt dazu keine offizielle Herstellerangabe und keine von mir bestätigte öffentliche Nachmessung für 2026. Da sich Crawler-Infrastrukturen jederzeit ändern können, sollten Betreiber relevanter Seiten ihre Sichtbarkeit regelmässig selbst prüfen.
† Apple: Applebot kann Seiten im Browser rendern; dieselbe Auswertung nennt ihn „a browser-based crawler, similar to Googlebot“.
‡ Anthropic dokumentiert drei Crawler mit getrennten Zwecken: ClaudeBot (Training), Claude-User (Abruf auf eine Nutzerfrage) und Claude-SearchBot (Suchqualität in Claude). Nur ClaudeBot war Gegenstand der Auswertung von 2024; für die beiden anderen liegt mir keine Messung vor. Auch die Zweckangabe zu Bytespider (TikTok) konnte ich nicht an einer Herstellerquelle bestätigen.

Was bedeutet das praktisch? In der Vercel/MERJ-Auswertung luden die ChatGPT-Crawler in 11,50 % und die Claude-Crawler in 23,84 % der Requests JavaScript-Dateien herunter, führten sie aber nicht aus. Für die übrigen Bots sollte dieses Verhalten ohne eigene Messung nicht verallgemeinert werden. Content, der erst durch clientseitiges Rendering im Browser entsteht, bleibt für sie ungelesen. 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. In einem von mir geprüften E-Commerce-Projekt mit einer Vue.js-SPA ohne SSR fand ich im Server-Log über den ausgewerteten Zeitraum keinen verifizierten GPTBot-Abruf. Verifiziert heisst hier: abgeglichen gegen die von OpenAI veröffentlichten IP-Bereiche, weil ein User-Agent allein fälschbar ist. In den von mir geprüften Suchabfragen war für dieses Projekt keine Sichtbarkeit in ChatGPT Search feststellbar. Das ist eine Beobachtung aus einem Projekt und kein Beleg dafür, dass das Rendering die Ursache war.

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 möglicher Verzögerung und zusätzlichen Ressourcenabrufen, die auf das Crawl-Budget gehen können. Für Crawler ohne JavaScript-Ausführung bleibt der Inhalt in der Regel unerfasst.

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 erhält beim Abruf vollständiges HTML und ist nicht auf clientseitige JavaScript-Ausführung angewiesen.

Nachteil: Server-Load bei hohem Traffic. Vorteil: sehr gute Ausgangslage für Crawler, die HTML ohne JavaScript verarbeiten, und kein zusätzliches Warten auf clientseitiges Rendering.

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. Sehr gute Performance, sehr gute Ausgangslage für Crawler ohne JavaScript-Ausführung, 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 verlangen für SEO-relevante Projekte Zusatzarbeit, wenn der Content auch für KI-Crawler lesbar sein soll. Ohne SSR, SSG oder Prerendering steht er nicht im initialen HTML, und genau darauf sind diese Crawler nach der vorliegenden Messung angewiesen.

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 Googlebot-Abrufe und die zeitlichen Abstände dazwischen. Sie beweisen aber nicht, welcher Abruf zur Rendering-Phase gehört: Google dokumentiert keinen eigenen User-Agent für den Renderer, ein abweichender User-Agent taugt also nicht als alleiniger Nachweis. 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 lautet die Antwort auf die Rendering-Frage nach der letzten belastbaren Messung Nein, ohne dass ein Anbieter das offiziell bestätigt oder widerlegt. 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 für Google. Für GPTBot und PerplexityBot wurde in der herangezogenen Messung keine JavaScript-Ausführung festgestellt, und eine aktuelle offizielle Herstellerbestätigung dazu gibt es nicht. Traffic-relevant wird das zunehmend.

Der Handlungsrahmen für 2026 ist klar: SSG als bevorzugte Option für überwiegend statische, content-lastige Seiten, SSR für dynamische Inhalte, hybride Modelle wenn beides zusammenkommt, 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.