Lesen KI-Assistenten meine Website, und was bremst sie dabei?
Ja, und in großer Zahl. Der Hoster Vercel zählte im Dezember 2024 in seinem Netz 569 Millionen Abrufe von OpenAIs GPTBot und 370 Millionen von Anthropics Crawler innerhalb eines Monats. Keiner der großen KI-Crawler führte dabei JavaScript aus; sie lesen das HTML, das Ihr Server ausliefert, und nichts, was erst im Browser entsteht. Was KI-Assistenten bremst, ist deshalb vor allem Text, der nicht im HTML steht, und ein Server, der unter vielen Abrufen langsam antwortet.
Drei Arten von Abrufen: für das Training, für die Suche und im Auftrag eines Nutzers

OpenAI beschreibt in seiner Dokumentation drei eigene Abrufer. GPTBot sammelt Inhalte, die für das Training der Sprachmodelle verwendet werden können. OAI-SearchBot holt Seiten, um sie in den Suchfunktionen von ChatGPT anzuzeigen; wer ihn aussperrt, erscheint dort nicht in den Suchantworten. ChatGPT-User ruft eine Seite ab, wenn ein Nutzer im Gespräch danach fragt; OpenAI schreibt dazu, dass die Regeln der robots.txt für solche von Nutzern ausgelösten Abrufe möglicherweise nicht gelten. Google sagt für seine KI-Antworten, dass eine Seite dafür im Suchindex stehen muss und es keine weiteren Anforderungen gibt; der Schalter Google-Extended steuert nur, ob Inhalte für das Training der Gemini-Modelle und das Grounding verwendet werden, und hat nach Googles Aussage weder auf die Aufnahme in die Suche noch auf das Ranking Einfluss. Nach einer Auswertung von Cloudflare vom August 2025 entfielen fast 80 Prozent der Aktivität von KI-Bots auf das Training, ein Jahr zuvor 72 Prozent. Die robots.txt dazu behandelt der Prüfbereich GEO in einem eigenen Artikel.
Die KI-Crawler führen kein JavaScript aus, Google tut es mit Verzögerung
Vercel hat im Dezember 2024 das Verhalten der Crawler in seinem Netz untersucht und festgestellt, dass keiner der großen KI-Crawler JavaScript ausführt, genannt sind die Crawler von OpenAI, Anthropic, Meta, ByteDance und Perplexity; Inhalte, die erst im Browser durch ein Skript entstehen, können sie nicht lesen. Das betrifft Systeme, die ihre Seiten als leeres Gerüst ausliefern und den Text nachladen. Google geht anders vor: Es verarbeitet JavaScript in drei Phasen, Crawlen, Rendern und Indexieren, und stellt Seiten für das Rendern in eine Warteschlange. Google schreibt dazu, dass eine Seite dort einige Sekunden bleiben kann, aber auch länger, und dass ein Chromium ohne Oberfläche die Seite erst darstellt, wenn die Ressourcen es zulassen. Für Sie heißt das: Was im HTML steht, ist für Google sofort und für KI-Crawler überhaupt da. Was ein Skript aufbaut, ist für Google später da und für die KI-Crawler nach dem Stand von Dezember 2024 gar nicht.
Viel Abruf, wenig Rückfluss: das Verhältnis, das Cloudflare misst
Der Netzbetreiber Cloudflare veröffentlichte im August 2025 das Verhältnis von Seitenabrufen eines Dienstes zu den Besuchern, die er zurückschickt. Für Juli 2025 lag es bei Google bei 5,4 Abrufen je weitergeleitetem Besucher, bei OpenAI bei 1.091, bei Perplexity bei 195 und bei Anthropic bei 38.065. Googlebot machte dabei 39 Prozent des gesamten Verkehrs von Such- und KI-Crawlern aus. Diese Verhältnisse gelten für das Netz von Cloudflare insgesamt; Cloudflare schreibt in einem Beitrag vom Juli 2025 dazu, dass native Apps keinen Referer senden und die Verhältnisse deshalb überzeichnet sein können, ohne zu wissen, um wie viel. Sie zeigen aber die Mechanik: KI-Dienste holen Ihre Seiten hundert- bis zehntausendfach häufiger, als sie Ihnen Besucher bringen. Jeder dieser Abrufe kostet Ihren Server Rechenzeit wie der Abruf durch einen Menschen. Ob das Ihren Server bremst, hängt von seiner Reserve ab; ein geteiltes Hosting-Paket mit wenig Rechenleistung spürt Hunderte zusätzliche Abrufe am Tag eher als ein eigener Server. Das ist eine Einschätzung aus der Mechanik, keine Messung.
Ein Server, der schnell antwortet, bekommt mehr Abrufe von Google und bleibt für KI-Crawler lesbar
Google beschreibt in seiner Dokumentation zum Crawl-Budget, dass die Zahl gleichzeitiger Verbindungen zu einer Website steigt, wenn der Server eine Zeit lang zügig antwortet, und sinkt, wenn Antwortzeiten länger werden; Google crawlt dann weniger. Dieselbe Serverantwortzeit misst der Wert TTFB, die Zeit bis zum ersten Byte, für den Google 0,8 Sekunden als gut und mehr als 1,8 Sekunden als schlecht nennt; TTFB ist selbst kein Core Web Vital. Für KI-Crawler gibt es keine veröffentlichte Grenze, ab der sie einen Abruf aufgeben. Was sich belegen lässt, ist das Zusammenspiel: Ein Server, der unter Last langsam wird, antwortet Google, den KI-Crawlern und Ihren Kunden gleichzeitig langsam, weil alle über dieselbe Leitung kommen. Ein Zwischenspeicher, der fertige Seiten ausliefert, statt jede Anfrage neu zu berechnen, hilft allen dreien zugleich; der Artikel zur Serverantwortzeit in diesem Prüfbereich beschreibt die Hebel.
Was Sie für lesbare Seiten tun: Text im HTML, wenige Skripte, schnelle Antwort
Der wirksamste Schritt ist, dass Ihr Haupttext, Ihre Preise und Ihre Kontaktdaten im ausgelieferten HTML stehen. Viele Systeme bieten dafür eine Darstellung auf dem Server (Server-Side Rendering); fragen Sie Ihre Agentur, ob Ihres dazugehört. Der zweite Schritt sind die Skripte von Dritten: Das HTTP Archive führt 2024 schlechte Reaktionszeiten auf dem Telefon vor allem auf Skripte von Dritten zurück, genannt sind Verhaltensmessung, Consent-Dienste und CDN-Skripte; für KI-Crawler sind sie ohne Belang, weil sie nicht ausgeführt werden, für Google und Ihre Besucher kosten sie Zeit. Der dritte Schritt ist die Serverantwort: ein Zwischenspeicher und ein Hosting-Paket mit Reserve. Alle drei Schritte verbessern zugleich die Werte, die Google als Core Web Vitals misst.
Was im November 2026 offen ist
Die Zahlen oben stammen aus zwei Veröffentlichungen von Netzbetreibern, Vercel vom Dezember 2024 und Cloudflare vom August 2025, zuletzt geändert im Juli 2026. Beide beschreiben ihr eigenes Netz; Ihre Website kann anders liegen. Ob die KI-Crawler inzwischen JavaScript ausführen, hat keiner der Anbieter öffentlich erklärt; OpenAIs Dokumentation der Bots sagt dazu nichts. Was sich prüfen lässt, ist Ihr eigener Bestand: welche Crawler kommen, wie oft, und was sie bekommen.
So gehen Sie es an
- Öffnen Sie den Quelltext Ihrer Startseite im Browser (Tastenkombination Strg+U oder Cmd+U) und suchen Sie mit Strg+F einen Satz aus Ihrem Haupttext und Ihre Telefonnummer. Finden Sie beides, steht es im HTML.
- Schalten Sie JavaScript im Browser ab (in Chrome unter Einstellungen, Datenschutz und Sicherheit, Website-Einstellungen, JavaScript) und laden Sie Startseite, Leistungsseite und Kontaktseite neu. Was dann fehlt, fehlt auch für KI-Crawler.
- Lassen Sie sich von Ihrem Hoster oder Ihrer Agentur die Zugriffsprotokolle des letzten Monats nach den Kennungen GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot und Googlebot filtern und zählen Sie die Abrufe je Kennung.
- Prüfen Sie in PageSpeed Insights die Serverantwortzeit (TTFB) in den Felddaten und vergleichen Sie sie mit der Grenze von 0,8 Sekunden; liegt sie darüber, beginnt die Arbeit beim Hosting und beim Zwischenspeicher.
- Entscheiden Sie mit dem Artikel des Prüfbereichs GEO zur robots.txt, welche Crawler Sie zulassen, und halten Sie die Entscheidung in der robots.txt fest.
Tipps aus der Praxis
- Ein Abruf mit der Kennung eines Crawlers zeigt, was dieser bekommt: Entwickler nutzen dafür den Befehl curl mit dem Parameter -A und der Kennung GPTBot. Wenn das Ergebnis ein fast leeres HTML mit Skriptverweisen ist, lädt Ihre Seite ihren Inhalt nach.
- Ein Abruf durch ChatGPT-User richtet sich nach Aussage von OpenAI möglicherweise nicht nach der robots.txt. Sperren in der robots.txt halten das Training fern, und nicht unbedingt den einzelnen Nutzer, der Ihre Seite im Chat öffnen lässt.
- Öffnungszeiten, Preise und Adresse gehören als Text in die Seite, in kein Bild und in kein nachgeladenes Modul. Ein Crawler ohne JavaScript liest den Text.
Weiter im Prüfbereich Performance
- Was ist LCP und warum soll er unter 2,5 Sekunden liegen?LCP misst, wann der größte Inhalt einer Seite sichtbar ist. Google wertet bis 2,5 Sekunden als gut, über 4 Sekunden als schlecht.
- Was ist INP und warum soll die Reaktionszeit unter 200 Millisekunden liegen?INP misst, wie schnell eine Website sichtbar auf Klicks und Eingaben reagiert. Google wertet bis 200 Millisekunden als gut, über 500 als schlecht.
- Was ist CLS und warum verspringen Inhalte beim Laden einer Website?CLS misst, wie stark Inhalte beim Laden verspringen. Google wertet bis 0,1 als gut, über 0,25 als schlecht. Ursache sind meist Bilder ohne Größenangabe.
- Was bedeutet FCP und wann zeigt eine Website ihren ersten Inhalt?FCP misst die Zeit bis zum ersten sichtbaren Inhalt einer Seite. Google wertet bis 1,8 Sekunden als gut, über 3 Sekunden als schlecht.
Dieser Artikel gehört zum Prüfbereich Performance; dort stehen alle Prüfpunkte im Überblick. Was die Prüfung insgesamt leistet, zeigt die Leistungsseite; wie ein Ergebnis zustande kommt, erklärt das Prüfverfahren. Alle Prüfbereiche im Überblick: Wissensbasis.




