Titelbild: KI-generiert
Das Wichtigste in Kürze |
|---|
✓ Google kann JavaScript verarbeiten, in drei Schritten: Crawlen, Rendern, Indexieren. Voraussetzung sind unter anderem echte Links, korrekte Statuscodes und kein noindex im ursprünglichen Code. |
✓ Der Googlebot liest je Datei nur die ersten 2 MB, gemessen unkomprimiert, und jede JavaScript-Datei zählt einzeln. Die oft zitierten 15 MB sind überholt. |
✓ Laut einer Auswertung von Vercel und MERJ, Stand Dezember 2024, führt keiner der großen KI-Crawler von OpenAI, Anthropic oder Perplexity JavaScript aus. Was erst per JavaScript entsteht, sehen sie demnach nicht. |
✓ Google empfiehlt serverseitiges oder statisches Rendern und nennt dynamisches Rendern eine Behelfslösung. Ob sich eine Umstellung lohnt, hängt davon ab, welche Inhalte gefunden werden sollen. |
Ihre neue Website ist eine moderne Web-App: Seiten wechseln ohne Neuladen, Inhalte erscheinen beim Scrollen, alles wirkt schnell. Der Quelltext, den der Server ausliefert, enthält dagegen fast nichts außer einem leeren Container und einer Reihe von Skripten. Den Rest baut erst der Browser. Genau hier setzt JavaScript SEO an: bei der Frage, ob das ein Problem ist.
Die Antwort hängt davon ab, wer liest. Google rendert JavaScript, allerdings unter Bedingungen. Die großen KI-Crawler tun es laut der einzigen Primärquelle, die wir dazu gefunden haben, nicht. Wir erklären, wie Google mit JavaScript umgeht, wo es trotzdem scheitert, was über KI-Crawler bekannt ist und woran Sie erkennen, ob Ihre Website handeln muss. Eine Entwickleranleitung ist das nicht. Stand: 4. Oktober 2026.
Kann Google JavaScript-Websites lesen?
Ja. Google verarbeitet JavaScript in drei Schritten: Crawlen, Rendern, Indexieren. Gerendert wird mit einer stets aktuellen Version von Chromium, dem technischen Unterbau von Chrome. Seiten warten dabei sowohl auf das Crawlen als auch auf das Rendern, und von außen ist nicht sofort erkennbar, auf welchen Schritt eine Seite gerade wartet (Quelle: Google Search Central, 2026).
Die Wartezeit kann kurz sein, muss es aber nicht. Alle Seiten mit dem Status 200 kommen laut Google zum Rendern in die Warteschlange, es sei denn, ein robots-Meta-Tag oder ein Header verbietet die Indexierung. Dort bleibt eine Seite „möglicherweise nur einige Sekunden“, es kann aber auch länger dauern. Bei Fehlerseiten mit Status 404 wird das Rendern womöglich übersprungen (Quelle: Google Search Central, 2026).
Eine Messung des Hosting-Anbieters Vercel mit der Beratung MERJ stützt das. Von über 100.000 Abrufen des Googlebots auf nextjs.org im April 2024 wurden alle HTML-Seiten vollständig gerendert, Fehlerseiten und nicht indexierbare Seiten ausgenommen. Zwischen Crawlen und Rendern lagen im Median 10 Sekunden, beim 90. Perzentil rund 3 Stunden und beim 99. Perzentil rund 18 Stunden (Quelle: Vercel, 2024).
Die Werte stammen im Wesentlichen von einer Website und von einem Anbieter, der das Framework Next.js betreibt. Als Beleg, dass Google JavaScript rendert, taugen sie. Als Richtwert für Ihre Website nicht.
Der Satz „Google kann kein JavaScript“ ist damit überholt. Offen ist nur, unter welchen Bedingungen es gelingt.
Wo scheitert JavaScript bei Google trotzdem?
Dort, wo eine Website mehr erwartet als einen einzelnen Seitenaufruf ohne Vorgeschichte. Der Googlebot speichert keinen Zustand zwischen Seitenaufrufen und lehnt Berechtigungsanfragen ab. Die wichtigsten Fallen laut Googles Dokumentation (Quellen: Google Search Central, 2026; Google Search Central, 2025; Google Search Central, 2026):
Falle | Was Google dazu sagt | Folge für Ihre Website |
|---|---|---|
Links ohne echtes Link-Element | Google findet Links nur, wenn sie a-Elemente mit href-Attribut sind | Unterseiten, die nur über eine Klick-Funktion erreichbar sind, bleiben unentdeckt |
Unterseiten hinter einem # | Das alte AJAX-Crawling-Schema ist seit 2015 eingestellt, auf URL-Fragmente ist kein Verlass | Unterseiten haben für Google keine eigene Adresse |
Inhalte hängen an Cookies oder lokalem Speicher | Cookies sowie Local und Session Storage werden zwischen Seitenaufrufen gelöscht | Google sieht die Seite wie ein Erstbesucher |
Echtzeitverbindungen und Berechtigungen | Keine WebSockets oder WebRTC, Berechtigungsanfragen lehnt der Googlebot ab | Was nur auf diesem Weg geladen wird, fehlt |
noindex im Ausgangscode, später per JavaScript entfernt | Google überspringt dann womöglich Rendern und JavaScript | Die Seite bleibt draußen, obwohl sie im Browser indexierbar wirkt |
Sehr große Dateien | Der Googlebot liest je Datei die ersten 2 MB | Was danach kommt, berücksichtigt Google nicht |
Die 2-MB-Grenze gilt für jede Datei einzeln. Beim Crawling für die Google-Suche liest der Googlebot die ersten 2 MB eines unterstützten Dateityps, bei PDF-Dateien 64 MB. Jede im HTML eingebundene JavaScript- oder CSS-Datei wird separat abgerufen und unterliegt derselben Grenze. Gemessen wird unkomprimiert. Ist die Grenze erreicht, bricht der Googlebot den Abruf ab und gibt nur den bereits geladenen Teil weiter (Quelle: Google Search Central, 2026). Die in älteren Ratgebern genannten 15 MB sind überholt.
Auch Weiterleitungen per JavaScript sind riskant. Google rät, sie nur zu nutzen, wenn serverseitige Weiterleitungen oder meta refresh nicht möglich sind. Scheitert das Rendern, sieht Google die Weiterleitung womöglich nie (Quelle: Google Search Central, 2026).
Fehlerseiten sind ein eigener Fall. Single-Page-Apps, die Fehler im Browser behandeln, melden laut Google oft den Status 200 statt eines passenden Fehlercodes. Fehlerseiten können so in den Index geraten oder als Soft 404 gewertet werden (Quelle: Google Search Central, 2025).
Was hinter dieser Meldung steckt, beschreibt unser Beitrag Soft 404.
Lesen ChatGPT, Perplexity und andere KI-Crawler JavaScript?
Nach der einzigen Primärquelle, die wir dazu gefunden haben, nicht. Stand ist Dezember 2024. Vercel und MERJ haben die Crawler auf nextjs.org und im Netzwerk von Vercel beobachtet. Keiner der großen KI-Crawler führte JavaScript aus. Genannt werden die Crawler von OpenAI (OAI-SearchBot, ChatGPT-User, GPTBot), Anthropic (ClaudeBot), Meta (Meta-ExternalAgent), ByteDance (Bytespider) und Perplexity (PerplexityBot) (Quelle: Vercel, 2024).
Laden heißt nicht ausführen. Die Crawler von ChatGPT und Claude rufen JavaScript-Dateien durchaus ab, bei ChatGPT 11,50 % und bei Claude 23,84 % der Abrufe. Ausgeführt werden sie laut der Auswertung nicht. Inhalte, die schon im ersten HTML stehen, etwa als JSON-Daten, können trotzdem erfasst werden (Quelle: Vercel, 2024).
Ausnahmen sind Gemini und der AppleBot. Gemini nutzt laut Vercel die Infrastruktur des Googlebots und rendert JavaScript vollständig, der AppleBot rendert ebenfalls. Klein sind die Mengen nicht: Im Netzwerk von Vercel kamen GPTBot und Claude in einem Monat auf 569 und 370 Millionen Abrufe, zusammen rund 20 % der 4,5 Milliarden Abrufe des Googlebots (Quelle: Vercel, 2024). Das gilt für dieses Netzwerk, nicht für das ganze Web.
Die Einschränkungen gehören dazu. Vercel ist ein Hosting-Anbieter und betreibt das Framework Next.js, hat also ein eigenes Interesse am Thema. Eine Stichprobengröße für die Aussage zum Rendern nennt die Auswertung nicht, und alle gemessenen KI-Crawler kamen aus Rechenzentren in den USA. Eine neuere Primärquelle haben wir nicht gefunden, Angaben von OpenAI, Anthropic oder Perplexity selbst ebenfalls nicht. Google schreibt allerdings selbst, dass nicht alle Bots JavaScript ausführen können (Quelle: Google Search Central, 2026).
Welche KI-Crawler es gibt, wofür sie zuständig sind und wie die robots.txt sie steuert, zeigt unsere Übersicht der KI-Crawler. Für Googles eigene KI-Übersichten gilt wie für die normale Suche: Als Quelle kommt nur infrage, was indexiert ist (Quelle: Google Search Central, 2025). Was Google rendern kann, erreicht ChatGPT oder Perplexity womöglich nicht. SEO bleibt die Basis, und diese Basis sollte im ausgelieferten HTML stehen.
Welche Rendering-Lösung empfiehlt Google?
Serverseitiges Rendern, statisches Rendern oder Hydration. Dynamisches Rendern, bei dem Crawler eine vorgerenderte Fassung bekommen, nennt Google dagegen eine Behelfslösung: „Dynamisches Rendering war eine Behelfslösung und keine langfristige Lösung für Probleme mit von JavaScript generierten Inhalten in Suchmaschinen.“ Andere Suchmaschinen ignorieren JavaScript laut Google womöglich ganz (Quelle: Google Search Central, 2025).
Selbst für Websites, die es problemlos rendert, empfiehlt Google fertiges HTML: „Serverseitiges oder Pre-Rendering ist trotzdem eine sehr gute Option, da deine Website dadurch für Nutzer und Crawler schneller wird und nicht alle Bots JavaScript ausführen können.“ (Quelle: Google Search Central, 2026) Die Ansätze im Vergleich:
Ansatz | Was passiert | Einordnung |
|---|---|---|
Clientseitiges Rendern | Der Server schickt ein fast leeres Gerüst, der Browser baut die Seite | Google rendert unter Bedingungen, KI-Crawler sehen laut Vercel und MERJ wenig |
Serverseitiges Rendern | Der Server liefert bei jedem Aufruf fertiges HTML | Von Google empfohlen |
Statisches Rendern | Fertige HTML-Seiten werden vorab erzeugt | Von Google empfohlen |
Hydration | Fertiges HTML kommt vom Server, JavaScript macht es danach interaktiv | Von Google empfohlen |
Dynamisches Rendern | Crawler bekommen eine vorgerenderte Fassung, Menschen die JavaScript-Version | Laut Google eine Behelfslösung, nicht empfohlen |
Die Wahl ist eine Architekturentscheidung. Verbreitete Frameworks bieten mehrere dieser Ansätze an, manche sogar je Seitentyp. Welcher zu Ihrer Website passt, sollten Entwicklung und SEO gemeinsam festlegen, am besten bevor gebaut wird. Bei einem Relaunch gehört die Frage deshalb in die Planung. Was dort sonst vor dem Umschalten geklärt sein muss, steht in unserem Beitrag zum SEO Relaunch.
Woran erkennen Sie, ob Ihre Website betroffen ist?
Am Unterschied zwischen dem HTML, das der Server ausliefert, und der fertig gerenderten Seite. Fehlen wichtige Inhalte im ausgelieferten HTML, ist Ihre Website bei Google auf das Rendern angewiesen, und den KI-Crawlern aus der Vercel-Auswertung fehlen diese Inhalte ganz. Wie Google eine Seite gerendert hat, zeigt der Live-Test der URL-Prüfung in der Search Console unter „Getestete Seite anzeigen“ (Quelle: Google Search-Console-Hilfe, 2026).
Für eine erste Einordnung reichen sechs Fragen:
Steht der Hauptinhalt im ausgelieferten HTML? Überschriften, Texte und Leistungsbeschreibungen sollten dort stehen, nicht erst nach dem Rendern.
Sind interne Links echte Links? Jede Unterseite braucht eine eigene Adresse und ein Link-Element, das auf sie zeigt.
Melden Fehlerseiten echte Fehlercodes? Eine nicht vorhandene Seite sollte mit 404 antworten, nicht mit 200 und einer Fehlermeldung.
Steht im Ausgangscode ein noindex? Wird es erst per JavaScript entfernt, verlässt sich die Website auf einen Schritt, den Google womöglich überspringt. Wie noindex sonst auf wichtige Seiten gerät, beschreibt unser Beitrag Durch noindex ausgeschlossen.
Wie groß sind HTML- und Skriptdateien? Was jenseits der ersten 2 MB einer Datei steht, berücksichtigt Google nicht.
Sind Skripte oder Schnittstellen per robots.txt gesperrt? Gesperrte Ressourcen kann Google laut eigener Dokumentation nicht laden (Quelle: Google Search Central, 2025).
Für KI-Crawler gibt es kein vergleichbares Prüfwerkzeug. Aus unserer Sicht gilt deshalb: Was nicht im ausgelieferten HTML steht, sollten Sie bei diesen Crawlern nicht voraussetzen. Daraus ergeben sich typische Befunde und unsere Einschätzung dazu:
Befund | Unsere Einschätzung |
|---|---|
Inhalte stehen im ausgelieferten HTML, JavaScript steuert nur Menüs, Formulare oder Animationen | Aus Sicht von JavaScript SEO kein Handlungsbedarf |
Inhalte entstehen erst im Browser, Googles gerenderte Ansicht zeigt sie vollständig | Für Google tragfähig, für KI-Crawler außerhalb von Google ein Risiko. Abwägen |
Inhalte fehlen auch in Googles gerenderter Ansicht | Dringend, die Seiten sind für Google unvollständig |
Neue Website oder Relaunch in Planung | Serverseitiges oder statisches Rendern von Anfang an einplanen |
Anwendung liegt hinter einer Anmeldung | Für Suchmaschinen ohne Belang, solange die öffentlichen Seiten davor lesbar sind |
Wann lohnt sich eine Umstellung, und wann nicht?
Wenn Seiten, mit denen Sie Anfragen gewinnen wollen, ihre Inhalte erst im Browser erzeugen. Dann stehen die Sichtbarkeit bei Google und in KI-Antworten auf dem Spiel, und der Aufwand für serverseitiges oder statisches Rendern ist gut begründet.
Bei Anwendungen hinter einer Anmeldung lohnt sie sich meist nicht. Google indexiert nur öffentlich zugängliche Seiten und crawlt Seiten nicht, für die eine Anmeldung nötig ist (Quelle: Google Search Central, 2025). Für Kundenportale, interne Werkzeuge oder die eigentliche Software hinter dem Login zählt deshalb Bedienbarkeit, nicht Sichtbarkeit. Wichtig sind die öffentlichen Seiten davor: Startseite, Leistungen, Preise, Ratgeber.
Bei Baukästen entscheidet der Anbieter mit. Ob ein Website-Baukasten Inhalte im ausgelieferten HTML bereitstellt, legt in erster Linie seine Technik fest, nicht Ihre Redaktion. Prüfen lässt es sich trotzdem, mit denselben Fragen wie oben. Fällt das Ergebnis schlecht aus, spricht das für eine andere Einstellung, im Zweifel für ein anderes System.
In unserem SEO-Audit prüfen wir, welche Seiten betroffen sind, was Google rendert, was im ausgelieferten HTML für andere Crawler übrig bleibt und welche Lösung zum vorhandenen System passt. Der Bericht ist so geschrieben, dass Ihre Entwicklung oder Webagentur damit arbeiten kann. Für die Diagnose genügt uns Lesezugriff auf die Search Console.
FAQ: JavaScript SEO
Kann Google Inhalte indexieren, die per JavaScript entstehen? Ja. Google crawlt, rendert und indexiert JavaScript-Seiten mit einer aktuellen Chromium-Version. Voraussetzung sind unter anderem echte Links, korrekte Statuscodes und kein noindex im ursprünglichen Code.
Wie lange dauert das Rendern bei Google? Google spricht von möglicherweise nur einigen Sekunden in der Warteschlange, es kann aber länger dauern. In der Messung von Vercel und MERJ auf nextjs.org lag der Median 2024 bei 10 Sekunden, beim 99. Perzentil bei rund 18 Stunden. Für andere Websites sind das keine Richtwerte.
Lesen ChatGPT und Perplexity JavaScript? Laut Vercel und MERJ, Stand Dezember 2024, führen ihre Crawler JavaScript nicht aus. Inhalte im ersten HTML können sie trotzdem erfassen. Eine neuere Primärquelle oder eine Aussage der Anbieter selbst haben wir nicht gefunden.
Ist dynamisches Rendern noch eine gute Lösung? Google nennt es eine Behelfslösung und empfiehlt stattdessen serverseitiges Rendern, statisches Rendern oder Hydration. Als Cloaking wertet Google dynamisches Rendern laut Dokumentation in der Regel nicht, solange die Inhalte ähnlich sind. Für eine neue Website ist es trotzdem nicht der empfohlene Weg.
Gilt für den Googlebot noch die Grenze von 15 MB? Nein. Laut aktueller Dokumentation liest der Googlebot je Datei die ersten 2 MB, gemessen unkomprimiert, bei PDF-Dateien 64 MB. Jede JavaScript- und CSS-Datei wird einzeln abgerufen und unterliegt derselben Grenze.
Braucht eine Web-App hinter einem Login JavaScript SEO? Nein, denn Google crawlt Seiten hinter einer Anmeldung nicht. Wichtig sind die öffentlichen Seiten, über die Interessenten Sie finden. Für diese gelten alle Fragen aus diesem Beitrag.
Bei JavaScript SEO geht es nicht darum, ob Google JavaScript kann, sondern welche Inhalte erst im Browser entstehen und wer sie dort noch sieht. Für Google lässt sich das prüfen, für KI-Crawler ist das ausgelieferte HTML der sichere Weg. Wenn Sie wissen möchten, wie Ihre Website dasteht, sprechen Sie mit uns.
