JavaScript-SEO für KI-Crawler: Was GPTBot nie zu sehen bekommt

Von Manfred Mayer Rieger · Veröffentlicht 22. Oktober 2026

Eine Produktseite, als Single-Page-App gebaut, liefert auf eine Anfrage ohne Skriptausführung oft fast nichts zurück: ein Title-Tag, ein Stylesheet-Link, ein leerer Container — sonst nichts. Dieselbe Adresse im Browser geöffnet, füllt sich: Fotos, Preis, drei Kundenbewertungen, ein Warenkorb-Button, alles von einem Skript eingefügt, das erst nach dem Laden der Seite läuft. Beide Versionen dieser Seite sind völlig unterschiedliche Dokumente, und welche davon jemand zu sehen bekommt, hängt allein davon ab, ob dazwischen etwas das Skript ausgeführt hat.

Der Googlebot gehört zu den wenigen, die das tun. Die meisten Crawler, die heute darüber entscheiden, ob eine Marke in einer KI-Antwort überhaupt auftaucht, tun es nicht.

Warum war JavaScript für Google kein Thema mehr – und warum ist es jetzt wieder eins?

Jahrelang hatte die Frage, ob Google JavaScript rendert, eine klare Antwort: ja. Google kündigte im Mai 2019 an, dass der Googlebot von einer Rendering-Engine auf Basis des veralteten Chrome 41 auf eine “evergreen” Version von Chromium umgestiegen war, die von da an laufend aktuell gehalten wird. Diese eine Änderung hat den größten Teil des JavaScript-SEO-Problems für die Suchmaschine gelöst, die Website-Betreibern am meisten Sorgen machte: Eine Single-Page-App, die früher einen eigenen Server-Rendering-Workaround brauchte, um bei Google zu ranken, funktioniert seitdem meistens einfach.

Diese Lehre hat sich für ein Publikum, das es damals noch nicht gab, als überholt erwiesen. Die Analyse von Vercel und MERJ zu über 500 Millionen GPTBot-Anfragen fand keinen einzigen Hinweis darauf, dass der Bot jemals JavaScript ausführt, und neuere Tests zeigen dasselbe Verhalten bei ClaudeBot und PerplexityBot: Alle drei rufen gelegentlich die Skript-Dateien einer Seite ab, aber nichts spricht dafür, dass einer von ihnen tatsächlich ausführt, was darin steht. Ein im Oktober 2026 veröffentlichter Überblick liefert eine Komplikation, die sich nicht einfach auflösen lässt: Ein Entwickler berichtete, OpenAIs Crawler hätten Ende September begonnen, Seiten zu rendern — ohne dass OpenAI das selbst bestätigt oder dementiert hätte. Selbst der aktuellste Stand trägt hier ein Fragezeichen.

Was verbirgt clientseitiges Rendering vor einem Crawler, der kein Skript ausführt?

Eine Seite lässt sich auf drei verschiedene Arten bauen, und der Unterschied ist für jemanden, der sie im Browser betrachtet, unsichtbar. Serverseitiges Rendering und statische Seitengenerierung liefern beide ein fertiges HTML-Dokument gleich bei der ersten Antwort — ein Browser ergänzt danach die Interaktivität, aber die Wörter stehen schon da. Reines clientseitiges Rendering liefert eine fast leere Hülle plus ein Skript, und die Wörter existieren erst, sobald dieses Skript fertig gelaufen ist. Ob eine Seite in einer KI-Antwort überhaupt auftaucht, hängt davon ab, dass ein Crawler sie zuerst erreicht, dann lesen kann und ihr danach vertraut — und ein Crawler, der das Skript nicht ausführt, kommt nie über das Lesen hinaus, egal wie gut der Rest der Seite sonst ist.

Ein aus Entwicklerbequemlichkeit gewähltes Framework, der Wechsel zu einer schwereren Komponentenbibliothek oder auch nur ein Produktlisten-Template, das still zu einem clientseitig gerenderten Widget umgebaut wird, kann einen Teil einer Website von der ersten in die zweite Kategorie verschieben — ohne dass im Browser irgendetwas davon zu sehen wäre.

Wie viel Inhalt kann tatsächlich verschwinden, und wie würde das jemand merken?

Das lässt sich nur beantworten, indem dieselbe Adresse zweimal gerendert wird — einmal ohne jede Skriptausführung, einmal in einem vollständigen Browser — und der überlebende Text verglichen wird. Das eigene Audit dieses Produkts führt genau diesen Vergleich in der kostenpflichtigen Stufe durch und behandelt die Lücke nicht als einzelnes Urteil, sondern als Skala: Bleiben unter rund 30 % des gerenderten Textes im rohen HTML übrig, gilt das als kritisch; liegt die Lücke zwischen 30 % und 70 %, gilt sie als kleiner, aber real.

Die kostenlose Stufe desselben Audits kann diese Prüfung gar nicht ausführen, weil der Vergleich ein echtes Browser-Rendering braucht, und dieser Schritt existiert nur in der kostenpflichtigen Stufe. Das ist kein milderes Ergebnis — es ist gar kein Ergebnis, was für eine Website, die das nie gemessen hat, eine eigene Art von Warnung ist. Eine veröffentlichte Zahl dazu, wie oft die kritische Schwelle über alle gescannten Websites hinweg tatsächlich auslöst, gibt es bislang nicht; das ist eine echte Lücke im bekannten Wissen, keine zurückgehaltene Statistik.

Welche Rendering-Ansätze halten Inhalte sichtbar, ohne ein Skript auszuführen?

Serverseitig rendernde Frameworks — Next.js, Nuxt, SvelteKit und die Standardeinstellung von Astro selbst — erzeugen bei jeder Anfrage fertiges HTML auf dem Server, sodass ein nicht ausführender Crawler nichts verpasst. Statische Seitengeneratoren gehen noch weiter und bauen dieses HTML einmal im Voraus, weshalb ein so gebauter Blog oder eine Marketingseite dieses Problem kaum je hat. Eine rein clientseitig gebaute Single-Page-App ist die eine Architektur, bei der die Lösung keine Einstellung ist: Nötig ist entweder eine vorgeschaltete Rendering-Schicht (manchmal dynamisches oder hybrides Rendering genannt) oder ein Umbau genau des Teils, den Such- und KI-Traffic tatsächlich betrifft — meist die Marketing- und Inhaltsseiten, nicht das eingeloggte Produkt dahinter.

Beweist ein gutes Google-Ranking etwas über die Erfahrung eines KI-Crawlers?

Nein, und genau das übersehen viele Migrations-Checklisten. Eine Website, die gut rankt, ihre Core Web Vitals besteht und in Googles eigenen Testwerkzeugen perfekt aussieht, hat damit nur bewiesen, dass eine einzelne Software — Googles evergreen Renderer — an der leeren Hülle vorbeikommt. OAI-SearchBot, GPTBot und ClaudeBot sind drei getrennte Crawler von drei getrennten Unternehmen, und keines davon hat eine Rendering-Garantie veröffentlicht, wie Google sie 2019 gegeben hat. Eine Seite kann jede Prüfung bestehen, die ein Entwickler normalerweise ausführt, und trotzdem für die Systeme, die über eine Markenerwähnung in einer KI-Antwort entscheiden, praktisch leer bleiben — eine Lücke, die außerhalb eines direkten Rendering-Vergleichs keine Spur hinterlässt, die ein Browser je zeigen würde.

Diese Lücke schließt sich in dem Moment, in dem irgendein Crawler anfängt zu rendern, und laut dem unbestätigten Bericht von September könnte sie sich bei mindestens einem von ihnen bereits schließen. Bis ein Unternehmen das selbst bestätigt, bleibt die vorsichtigere Annahme für alles, was eine Maschine lesen soll, die ältere: die Wörter ins HTML schreiben und das Skript als Dekoration behandeln.