Warum KI-Crawler Seiten mit JavaScript oft nicht lesen

„Warum wird unsere Seite in ChatGPT nie erwähnt, obwohl wir bei Google auf Platz zwei stehen?“ Diese Frage kommt in fast jedem Erstgespräch. In etwa jedem dritten Fall ist die Antwort banal: Der Text, um den es geht, steht nicht im HTML-Dokument, sondern entsteht erst im Browser des Nutzers – und KI-Crawler haben keinen Browser.

KI-Crawler holen ein Dokument, kein fertiges Bild der Seite

Googles Suchcrawler hat sich über Jahre einen Rendering-Apparat aufgebaut. Er lädt die Seite, führt JavaScript aus, wartet, baut das DOM zusammen und indexiert das Ergebnis. Das ist teuer, deshalb passiert es bei Google oft verzögert, aber es passiert.

Die Crawler der KI-Anbieter tun das nach unserer Beobachtung nicht. GPTBot und OAI-SearchBot von OpenAI, ClaudeBot und Claude-SearchBot von Anthropic, PerplexityBot – sie fordern eine URL an, nehmen die Antwort entgegen und verarbeiten den Text darin. Was danach im Browser passieren würde, findet nicht statt.

Der Grund ist keine Nachlässigkeit, sondern Ökonomie. Diese Systeme crawlen im großen Stil, teilweise zur Anreicherung von Trainingsdaten, teilweise live während einer Nutzeranfrage. Bei einer Live-Anfrage in Perplexity oder ChatGPT hat der Abruf ein Zeitbudget von wenigen Sekunden, weil der Nutzer auf eine Antwort wartet. In dieses Budget passt kein Headless-Browser, der 40 JavaScript-Bundles auswertet.

Für Sie heißt das: Es gibt eine harte Grenze zwischen dem, was Ihre Besucher sehen, und dem, was ein Sprachmodell über Sie erfährt.

Der Test dauert zwei Minuten

Öffnen Sie ein Terminal und rufen Sie eine Ihrer wichtigen Seiten mit dem User-Agent eines KI-Crawlers ab:

curl -A "GPTBot" -s https://ihre-domain.de/leistungen/beratung

Was jetzt durchläuft, ist ungefähr das, was der Bot bekommt. Suchen Sie darin nach einem Satz, den Sie auf der Seite sehen. Etwa nach Ihrem Preis:

curl -A "GPTBot" -s https://ihre-domain.de/preise | grep -i "euro"

Kommt nichts zurück, sieht kein KI-System Ihre Preise. Wer kein Terminal öffnen will: Im Browser Strg+U drücken, dann erscheint der ausgelieferte Quelltext. Nicht die Entwicklerkonsole mit dem Element-Inspektor – der zeigt das gerenderte DOM und damit genau das, was der Bot eben nicht hat. Dieser Unterschied ist die häufigste Fehlerquelle bei der Selbstprüfung.

Ein zweiter Wert ist aufschlussreich:

curl -A "GPTBot" -s https://ihre-domain.de/ | wc -c

Liegt das Ergebnis unter 15.000 Zeichen, während die Seite im Browser gefüllt aussieht, ist der Fall klar. Bei einer typischen Single-Page-Anwendung sehen wir Werte um 2.000 bis 4.000 Zeichen – ein leeres <div id="root"> plus Skript-Verweise.

Wo die Inhalte typischerweise verschwinden

In der Projektarbeit tauchen immer wieder dieselben Muster auf. Sie sind selten dramatisch, aber sie treffen ausgerechnet die Passagen, die für eine KI-Antwort zählen.

Akkordeons und Tabs, die ihren Inhalt per Klick nachladen. Der FAQ-Bereich sieht vollständig aus, im HTML stehen aber nur die Fragen, nicht die Antworten. Genau die Antworten wären das zitierfähige Material.

Bewertungen und Referenzen als eingebundenes Fremd-Widget. Trustpilot, ProvenExpert, Google-Rezensionen – alles nachgeladen, alles unsichtbar für den Bot. Wenn Ihre Reputation in einer KI-Antwort auftauchen soll, muss sie im Dokument stehen, mindestens als strukturierte Daten.

Preise und Verfügbarkeiten aus einer API. Im Shop üblich, technisch nachvollziehbar. Für ein Modell, das gerade eine Kaufempfehlung formuliert, ist die Seite dann eine Produktseite ohne Preis.

Cookie-Banner, die den Inhalt erst nach Zustimmung ausliefern. Wenn Ihr Consent-Werkzeug den Hauptinhalt bis zur Einwilligung zurückhält – nicht nur überlagert, sondern serverseitig zurückhält –, dann ist die Seite für jeden Bot leer. Das ist selten, aber wir haben es gesehen, meist bei Nachrichtenseiten und bei Konfiguratoren.

Und schließlich: Inhalte hinter Infinite Scroll. Was erst beim vierten Nachladen erscheint, existiert für den Crawler nicht. Paginierung mit echten URLs löst das.

Ladezeit ist für Bots ein anderes Problem als für Menschen

Bei Nutzern geht es um wahrgenommene Geschwindigkeit, um Largest Contentful Paint und den Moment, in dem die Seite bedienbar wirkt. Bei Crawlern zählt etwas anderes: die Zeit bis zum ersten Byte und die Frage, ob der Server überhaupt sauber antwortet.

Belastbare Timeout-Werte veröffentlichen die Anbieter nicht. Was wir aus Serverlogs von Kundenprojekten sehen: URLs mit sehr langer Serverantwort – Größenordnung mehrere Sekunden bis zum ersten Byte – werden im Zeitverlauf spürbar seltener erneut abgefragt als schnelle URLs derselben Domain. Das ist eine Beobachtung an einer überschaubaren Zahl von Projekten, keine Statistik. Die Richtung ist aber plausibel, weil jeder Crawler ein Budget verteilen muss.

Deutlich kritischer als Langsamkeit sind Fehler unter Last. KI-Crawler kommen nicht höflich verteilt, sondern manchmal in Schüben. Wenn Ihr Server dann 429 oder 503 zurückgibt, wertet der Bot das als Signal, die Frequenz zu senken. Bei einem Kunden mit einem knapp dimensionierten Shared Hosting hat ein einzelner ClaudeBot-Schub über zwei Tage dazu geführt, dass die Fehlerquote bei über 60 Prozent der Anfragen lag. Danach dauerte es Wochen, bis das Abrufvolumen wieder anzog.

Schauen Sie deshalb nicht nur auf PageSpeed-Werte, sondern in Ihr Zugriffsprotokoll. Filtern Sie nach den Bot-Namen und zählen Sie die Statuscodes der letzten 30 Tage. Ein hoher Anteil an 4xx und 5xx ist ein Befund, den kein Content-Konzept ausgleicht.

Server-Rendering, Prerendering, statische Auslieferung

Die Lösung ist technisch unspektakulär. Der Text muss im HTML stehen, das der Server ausliefert. Welcher Weg dorthin führt, hängt von der Seite ab.

Zum Prerendering für Bots eine Einordnung: Technisch liefern Sie hier je nach User-Agent eine vorgerenderte Fassung aus. Das ist kein Cloaking, solange der Inhalt identisch ist – Google beschreibt dynamisches Rendering seit Jahren als zulässige Übergangslösung, hält es aber für einen Notbehelf. Wir sehen es genauso. Der Wartungsaufwand ist unterschätzt, weil neue User-Agents laufend hinzukommen und die vorgerenderte Fassung veraltet, sobald jemand vergisst, den Cache zu leeren.

Wer heute neu baut, nimmt Next.js, Nuxt, Astro oder ein klassisches CMS und rendert serverseitig. Der Punkt ist nicht das Werkzeug, sondern die Regel: Jeder Satz, der in einer KI-Antwort auftauchen soll, steht im Quelltext.

Die zweite Ursache sitzt in der Firewall

Nicht jede unsichtbare Seite ist ein Rendering-Problem. Genauso oft blockiert eine Schutzschicht den Zugriff, ohne dass es jemand entschieden hat.

Cloudflare hat im Sommer 2024 eine Ein-Klick-Option eingeführt, mit der Betreiber KI-Crawler pauschal aussperren können, und behandelt Blockieren inzwischen als Standardfall für neue Domains. Viele Betreiber wissen nicht, dass die Option aktiv ist. Dazu kommen Bot-Fight-Modi, Rate Limits und WAF-Regeln, die auf ungewöhnliche Abrufmuster reagieren.

Der Test ist derselbe wie oben. Wenn curl -A "GPTBot" einen 403 oder eine Challenge-Seite zurückgibt, während derselbe Aufruf ohne User-Agent-Angabe funktioniert, haben Sie den Grund gefunden. Prüfen Sie danach die robots.txt, aber verlassen Sie sich nicht darauf – die Sperre sitzt oft eine Ebene darüber. Zur richtigen Konfiguration von robots.txt und llms.txt haben wir an anderer Stelle geschrieben; hier geht es um die Schicht davor.

Und ja, es gibt gute Gründe, KI-Crawler auszusperren. Wer Inhalte verkauft, will sie nicht kostenlos ins Training geben. Nur sollte das eine Entscheidung sein und kein Nebeneffekt einer Voreinstellung.

Wo diese Disziplin an ihre Grenze stößt

Ein sauberes HTML-Dokument garantiert gar nichts. Es ist die Eintrittskarte, nicht der Platz auf der Bühne.

Zwei Mechanismen sind zu unterscheiden. Bei Live-Abrufen – ChatGPT mit Websuche, Perplexity, Claude mit Websuche – wirkt eine technische Korrektur relativ schnell. Wir sehen Veränderungen in der Zitierhäufigkeit typischerweise nach zwei bis sechs Wochen, sobald die Suchindexe dahinter die Seite neu erfasst haben. Bei Wissen, das fest im Modell steckt, wirkt gar nichts kurzfristig. Diese Gewichte ändern sich erst mit einem neuen Trainingslauf, und darauf haben Sie keinen Einfluss.

Ebenfalls offen: Wie stark die Anbieter ihre Crawler künftig um Rendering erweitern. Es wäre technisch machbar und für die Trainingsdatenerhebung, wo Zeit weniger drückt, sogar wahrscheinlich. Wer heute auf diese Entwicklung wartet, statt sein HTML in Ordnung zu bringen, wettet allerdings auf einen Zeitpunkt, den niemand kennt.

Was das für Sie bedeutet

Nehmen Sie sich einen Vormittag und arbeiten Sie diese fünf Schritte ab:

1. Wählen Sie Ihre zehn wichtigsten URLs aus – die Seiten, die in einer KI-Antwort zu Ihrem Thema auftauchen sollen. Rufen Sie jede per curl -A "GPTBot" -s URL ab und suchen Sie darin nach drei Kernaussagen der Seite. Notieren Sie, was fehlt.
2. Prüfen Sie im Zugriffsprotokoll die Statuscodes für GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot und PerplexityBot über die letzten 30 Tage. Alles jenseits von 200 und 304 ist ein Befund.
3. Wenn Sie Cloudflare oder einen ähnlichen Dienst einsetzen: Sehen Sie in den Bot-Einstellungen nach, ob KI-Crawler blockiert werden, und entscheiden Sie bewusst.
4. Verschieben Sie FAQ-Antworten, Preise und Referenzen aus Akkordeons und Widgets ins ausgelieferte HTML. Das ist meist eine Aufgabe von wenigen Stunden und bringt mehr als jede weitere Textoptimierung.
5. Wiederholen Sie den curl-Test nach dem Umbau und legen Sie sich eine Erinnerung auf vier Wochen später, um zu prüfen, ob die Seite in Perplexity oder ChatGPT mit Websuche als Quelle auftaucht.

Wenn Sie ein Relaunch-Projekt vor sich haben, schreiben Sie eine Zeile ins Lastenheft: Der gesamte Hauptinhalt jeder Seite muss ohne JavaScript-Ausführung im HTML lesbar sein. Diese eine Zeile spart Ihnen später den halben Aufwand, über den dieser Text handelt.