JavaScript-Rendering prüfen: Was Google und KI-Crawler wirklich sehen

Der Zwei-Minuten-Test: Was steht im ausgelieferten HTML?

Der Test braucht kein Tool, nur Chrome. Er zeigt das HTML, das der Server ausliefert, bevor JavaScript irgendetwas verändert. Genau diese Fassung bekommt jeder Crawler zuerst zu sehen, und viele bekommen nie eine andere.

1. Die Seite in Chrome öffnen.

2. Rechtsklick auf die Seite, Untersuchen wählen, in den Tab Network (Netzwerk) wechseln und den Filter Doc anklicken.

3. Die Seite neu laden, links auf den Seitennamen klicken und rechts den Tab Response (Antwort) öffnen.

4. Mit STRG+F (Mac: CMD+F) nach etwas Wichtigem suchen: der Hauptüberschrift, einer Leistungsbeschreibung, einem Preis, einer FAQ-Antwort.

Taucht der gesuchte Text auf, steht er im ausgelieferten HTML. Fehlt er, obwohl er im Browser sichtbar ist, wurde er erst nachträglich per JavaScript eingefügt.

Wer es noch schneller mag: STRG+U öffnet den Seitenquelltext und zeigt dasselbe rohe HTML.

Der Haken: Der Elements-Tab zeigt etwas anderes

Ein häufiger Denkfehler passiert direkt nach dem Klick auf „Untersuchen“. Der Tab Elements zeigt nicht das ausgelieferte HTML, sondern das fertige DOM, nachdem JavaScript gelaufen ist. Dort ist immer alles vorhanden. Für die Prüfung zählt deshalb nur die Response im Network-Tab oder der Seitenquelltext.

Noch ein Hinweis zur Einordnung: Der Test zeigt, was der Server dem eigenen Browser schickt. Liefert eine Website Bots andere Inhalte aus oder blockt eine Firewall bestimmte Crawler, fällt das hier nicht auf. Dazu weiter unten mehr.

Was JavaScript-Rendering bedeutet

Rendering ist der Schritt, in dem aus Code eine fertige Seite wird. Der Browser lädt HTML, CSS und JavaScript, führt die Skripte aus und baut daraus das DOM, also die Struktur, die am Ende auf dem Bildschirm steht.

Bei einer klassischen Website ist dieser Schritt unspektakulär. Das HTML vom Server enthält bereits Überschriften, Texte und Links. JavaScript ergänzt höchstens ein Menü oder einen Slider.

Bei vielen modernen Websites ist es umgekehrt. Der Server schickt ein fast leeres Gerüst mit einem Verweis auf ein JavaScript-Bundle. Erst das Skript holt die Inhalte über eine API und schreibt sie in die Seite. Im Quelltext sieht das dann ungefähr so aus:

<body> <div id="root"></div> <script src="/assets/app.4f2a.js"></script> </body>

Es gibt also zwei Fassungen jeder Seite:

• Rohes HTML: das, was der Server als Antwort ausliefert.

• Gerendertes HTML: das, was nach dem Ausführen von JavaScript im Browser steht.

Menschen sehen immer die zweite Fassung. Ein Crawler sieht sie nur, wenn er selbst einen Browser mitbringt und JavaScript ausführt. Das kostet Rechenzeit, und genau deshalb sparen sich viele Bots diesen Schritt.

CSR, SSR, SSG: Wo die Inhalte entstehen

Ob eine Seite im rohen HTML Inhalte mitbringt, hängt davon ab, wo sie zusammengebaut wird. Das beschreibt das Rendering-Modell.

Client-Side Rendering (CSR) heißt: Die Seite entsteht im Browser des Besuchers, also auf dem Client. Der Server liefert nur die leere Hülle und das Skript. Das ist die Standardbetriebsart klassischer Single-Page-Applications mit React, Vue oder Angular. CSR ist damit die Ursache für genau das Problem, das der Test oben sichtbar macht.

Frameworks wie Next.js, Nuxt oder SvelteKit beherrschen SSR und SSG von Haus aus. Wichtig: Ein modernes Framework allein ist keine Garantie. Auch in einer servergerenderten Seite fehlen alle Inhalte im HTML, die eine Komponente erst nach dem Laden per Fetch aus einer API holt.

CSR ist deshalb nicht grundsätzlich falsch. Für alles hinter einem Login spielt Sichtbarkeit keine Rolle. Kritisch wird es bei Seiten, die gefunden und zitiert werden sollen.

Wie Google mit JavaScript umgeht

Google verarbeitet JavaScript-Seiten laut eigener Dokumentation in drei Phasen:

1. Crawling: Googlebot ruft die URL ab, liest das rohe HTML und sammelt die Links aus den href-Attributen ein.

2. Rendering: Seiten mit Statuscode 200 landen in einer Render-Warteschlange. Sobald Ressourcen frei sind, führt ein Headless-Chromium das JavaScript aus.

3. Indexierung: Google indexiert das gerenderte HTML und schickt die dort gefundenen Links erneut in die Crawl-Warteschlange.

Das funktioniert in den meisten Fällen zuverlässig. Trotzdem hat der Umweg über das Rendering Schwachstellen, die SEOs kennen sollten:

• Zeitverzug: Laut Google bleibt eine Seite oft nur Sekunden in der Warteschlange, es kann aber auch länger dauern. Inhalte und Links, die erst nach dem Rendering existieren, werden entsprechend später entdeckt.

• Keine Interaktion: Google scrollt nicht und klickt nicht. Inhalte, die erst nach einer Nutzeraktion geladen werden, sieht Google nicht.

• Fehlerseiten: Bei Statuscodes ungleich 200 kann Google das Rendering überspringen.

• noindex im Ausgangs-HTML: Stößt Google dort auf noindex, kann das Rendering ebenfalls entfallen. Ein Skript, das den Tag nachträglich entfernt, kommt dann nie zum Zug.

• Blockierte Ressourcen: JavaScript-Dateien, die per robots.txt gesperrt sind, führt Google nicht aus.

Hinzu kommt die schlichte Fehleranfälligkeit. Bricht ein Skript ab oder antwortet eine API zu langsam, bleibt die Seite für Google leer, während im eigenen Browser alles gut aussieht.

Google selbst zieht daraus einen klaren Schluss. Server-Side Rendering oder Prerendering bleibe eine gute Idee, heißt es in der Dokumentation: Es mache Websites für Nutzer und Crawler schneller, und nicht alle Bots könnten JavaScript ausführen.

Immerhin lässt sich bei Google nachsehen, was angekommen ist. Die URL-Prüfung in der Search Console zeigt unter Gecrawlte Seite anzeigen das gerenderte HTML samt Screenshot. Dasselbe leistet der Test für Rich-Suchergebnisse für beliebige URLs.

KI-Crawler: kein JavaScript, kein zweiter Durchlauf

Bei den meisten KI-Crawlern fehlt die Render-Stufe nach aktuellem Stand komplett. Sie holen das rohe HTML ab und arbeiten mit dem, was darin steht. Eine Warteschlange für einen späteren zweiten Durchlauf gibt es nicht.

Die wichtigste Datengrundlage ist eine Analyse von Vercel und MERJ vom Dezember 2024. Ausgewertet wurden die Zugriffe im Vercel-Netzwerk, darunter in einem Monat 569 Millionen Abrufe durch GPTBot und 370 Millionen durch Claude. Das Ergebnis: Keiner der großen KI-Crawler rendert JavaScript. ChatGPT und Claude laden zwar JavaScript-Dateien herunter (11,5 bzw. 23,84 Prozent ihrer Abrufe), führen sie aber nicht aus.

Geändert hat sich daran seither wenig. Das Search Engine Journal führt GPTBot, ClaudeBot, PerplexityBot und CCBot auch im April 2026 als Crawler ohne JavaScript-Rendering. Glenn Gabe hat im August 2025 in einer Fallstudie gezeigt, was das praktisch heißt: ChatGPT, Perplexity und Claude konnten clientseitig gerenderte Inhalte einer Website schlicht nicht finden.

Auch der direkte Seitenabruf liest nur rohes HTML

Interessant ist ein Test von Andre Alpar vom Juni 2026. Er hat zwölf KI-Assistenten jeweils eine URL in den Chat gegeben. Im rohen HTML stand ein falscher Wert, der richtige wurde erst per JavaScript eingesetzt.

ChatGPT, Claude, Gemini, Perplexity, Meta AI und Microsoft Copilot nannten den Wert aus dem rohen HTML. Den richtigen Wert lieferten nur DeepSeek, ERNIE, Qwen, Kimi und Mistral. Überraschend war vor allem Gemini, das trotz Googles Rendering-Infrastruktur nur das rohe HTML las.

Der Test ist eine Momentaufnahme mit einer Website und einem Prompt pro Assistent. Er passt aber ins Bild.

Warum pauschale Aussagen trotzdem zu kurz greifen

„KI ignoriert JavaScript komplett“ liest man oft. Ganz so einfach ist es nicht:

• Googles KI-Antworten in der Suche bauen auf dem Suchindex auf, und der kennt gerenderte Inhalte. Der Live-Abruf im Gemini-Chat verhielt sich im Test dagegen anders.

• Agentische Browser wie ChatGPT Atlas oder Perplexity Comet sind echte Browser und sehen die fertige Seite. Sie arbeiten aber für einen einzelnen Nutzer und bauen keinen Index auf.

• Daten im HTML können ankommen, auch wenn sie nicht sichtbar gerendert sind. Vercel weist darauf hin, dass Sprachmodelle etwa eingebettetes JSON aus der ersten Server-Antwort lesen können.

• Die Anbieter ändern ihre Systeme, ohne es anzukündigen. Was heute gilt, kann in einem halben Jahr überholt sein.

Für die Praxis heißt das: KI-Crawler haben mit JavaScript-Inhalten sehr wahrscheinlich Probleme, im Einzelfall weiß man es aber nicht sicher. Wer vom ungünstigsten Fall ausgeht, liegt bei allen Systemen richtig.

Das eigentliche Problem: keine Search Console für KI-Crawler

Bei Google gibt es ein Kontrollinstrument. Die URL-Prüfung zeigt schwarz auf weiß, welches HTML Google nach dem Rendering vorliegt. Für ChatGPT, Claude oder Perplexity gibt es bislang nichts Vergleichbares. Kein Anbieter zeigt Website-Betreibern, was sein Crawler auf einer URL tatsächlich gesehen hat. Glenn Gabe hat genau das schon 2025 unter dem Stichwort „AI Search Console“ gefordert.

Den Chatbot einfach zu fragen, hilft nur bedingt. In Alpars Test behauptete Perplexity im Chat, die Seite nicht erreichen zu können. Laut Server-Log hatte der eigene Crawler sie zu diesem Zeitpunkt längst mit Statuscode 200 abgerufen. Selbstauskünfte der Assistenten sind keine Messung.

Es bleiben Prüfungen, die das Verhalten der Crawler nachstellen:

• Rohes HTML prüfen: Der Zwei-Minuten-Test von oben ist die wichtigste Kontrolle. Was dort fehlt, fehlt sehr wahrscheinlich auch für KI-Crawler.

• JavaScript im Browser abschalten: In den Chrome DevTools mit STRG+SHIFT+P das Befehlsmenü öffnen, „Disable JavaScript“ eingeben und die Seite neu laden. Was jetzt noch zu sehen ist, kommt ohne JavaScript aus.

• Abruf per curl: Der Befehl holt die Seite ohne Browser und mit dem User-Agent eines Bots. So fällt auch auf, wenn eine Firewall oder ein CDN Bots anders behandelt als Besucher.

• Crawl ohne Rendering: SEO-Crawler wie Screaming Frog können eine Website einmal ohne und einmal mit JavaScript-Rendering crawlen. Der Vergleich zeigt für die gesamte Website, welche Inhalte und Links nur gerendert existieren.

• Server-Logs auswerten: Die Logs zeigen, welche KI-Bots welche URLs abrufen und welche Statuscodes sie erhalten. Es ist der einzige Ort, an dem das tatsächliche Verhalten der Bots sichtbar wird.

curl -s -A "GPTBot" https://www.example.com/seite | grep -i "gesuchter text"

Liefert der Befehl keine Zeile zurück, steht der gesuchte Text nicht im ausgelieferten HTML. Eine Einschränkung bleibt: Sperren auf IP-Ebene deckt curl nicht auf, weil die Anfrage vom eigenen Rechner kommt.

Typische Stolperfallen

Nicht nur reine Single-Page-Applications sind betroffen. Auch auf klassisch gebauten Websites verschwinden einzelne Inhalte unbemerkt aus dem HTML. Die häufigsten Fälle:

• Inhalte hinter Klicks: Tabs, Akkordeons oder „Mehr anzeigen“-Buttons, die ihren Text erst beim Klick vom Server holen. Unkritisch sind dagegen Inhalte, die im HTML stehen und nur per CSS eingeklappt sind.

• Nachladen beim Scrollen: Infinite Scroll und Textblöcke, die erst beim Scrollen geladen werden.

• Strukturierte Daten per Tag Manager: Google kann per JavaScript eingefügtes JSON-LD verarbeiten. Crawler ohne Rendering sehen es nie.

• Title, Description und Canonical per JavaScript: Google übernimmt die gerenderten Werte. Alle anderen sehen die Platzhalter aus der Hülle, oft denselben Title für jede URL.

• Interne Links ohne href: Navigationen, die nur über Klick-Events funktionieren. Google folgt ausschließlich echten Links mit href-Attribut.

• Eingebundene Widgets: Bewertungen, Preise, Verfügbarkeiten oder Stellenanzeigen von Drittanbietern, die per Skript geladen werden.

• Fehlerseiten in SPAs: Der Router zeigt „Seite nicht gefunden“, der Server antwortet aber mit Statuscode 200. Das Ergebnis sind Soft-404-Fehler.

Tückisch sind vor allem strukturierte Daten und Meta-Angaben per JavaScript. Google verarbeitet sie meist korrekt, in der Search Console fällt also nichts auf. Sichtbar wird das Problem erst, wenn Inhalte in KI-Antworten fehlen.

Was jetzt zu tun ist

Für SEOs ergibt sich daraus eine überschaubare Liste:

1. Seitentypen testen: Pro Template eine URL prüfen, also Startseite, Kategorie, Produkt- oder Leistungsseite und Ratgeber. Gesucht wird jeweils nach H1, zentralem Text, Preis, FAQ, internen Links und JSON-LD.

2. Kritische Inhalte ins HTML bringen: Hauptinhalt, Title, Description, Canonical, Navigation, interne Links und strukturierte Daten gehören in die Server-Antwort.

3. JavaScript für die Kür nutzen: Zähler, Chat-Widgets, Personalisierung und interaktive Elemente dürfen weiterhin im Browser entstehen. Das empfiehlt auch Vercel.

4. Rendering-Modell mit der Entwicklung klären: Für alle indexierbaren Seitentypen SSR oder SSG einplanen. Bei bestehenden SPAs kann Prerendering die Zeit bis zum Umbau überbrücken.

5. Regelmäßig nachprüfen: Nach jedem Relaunch, jeder Template-Änderung und jedem neuen Tracking- oder Consent-Setup erneut testen.

Der letzte Punkt geht in der Praxis am häufigsten unter. Rendering-Probleme entstehen selten beim Launch, sondern Monate später durch eine unscheinbare Änderung im Frontend. Die Prüfung gehört deshalb als feste Aufgabe mit Verantwortlichem in jeden technischen Audit.

Fazit

Der Blick ins rohe HTML dauert zwei Minuten und beantwortet eine Frage, die lange nur für Google relevant war: Kommen die Inhalte auch ohne JavaScript an?

Für Google ist JavaScript ein Umweg mit Risiken. Für die meisten KI-Crawler ist es nach aktuellem Stand eine Sackgasse. Und anders als bei Google gibt es dort kein Werkzeug, das Probleme meldet.

Die Konsequenz ist dieselbe, die Google seit Jahren empfiehlt: Alles, was gefunden und zitiert werden soll, gehört in das HTML, das der Server ausliefert. Wer das sicherstellt, muss nicht darauf wetten, welcher Crawler wann welche Fähigkeiten bekommt.

Quellen

• Understand the JavaScript SEO basics, Google Search Central, Stand 4. März 2026

• Fix lazy-loaded content, Google Search Central, Stand 10. Dezember 2025

• The rise of the AI crawler, Vercel und MERJ, 17. Dezember 2024

• AI Search and JavaScript Rendering, Glenn Gabe, 11. August 2025

• The Technical SEO Audit Needs A New Layer, Slobodan Manic im Search Engine Journal, 27. April 2026

• Do AI Assistants Actually Render Your JavaScript when Grounding?, Andre Alpar bei Search Engine World, 9. Juni 2026