KI-Bots richtig steuern: GPTBot, ClaudeBot, PerplexityBot & Common Crawl im Überblick

Warum KI-Bot-Management kein Pauschalthema mehr ist

Wer heute über Sichtbarkeit im Web spricht, spricht längst nicht mehr nur über den Googlebot. Auf modernen Websites treffen inzwischen sehr unterschiedliche Systeme aufeinander: klassische Suchmaschinen-Crawler, KI-Suchbots, Trainingscrawler, userinitiierte Fetcher und offene Archiv-Crawler wie Common Crawl.

Die Frage „Darf KI meine Website crawlen?“ greift deshalb zu kurz. Es geht um eine genauere Entscheidung.

Die bessere Frage lautet: Welche Bots sollen auf welche Inhalte zugreifen dürfen, und zu welchem Zweck?

Für Unternehmen, Publisher und SEO-Verantwortliche ist diese Unterscheidung entscheidend. Je nach Bot-Typ geht es um unterschiedliche Ziele: Sichtbarkeit in KI-Suchsystemen, Ausschluss von Trainingsnutzung, Schutz vor unnötiger Serverlast, Kontrolle sensibler Bereiche oder Präsenz in offenen Webdatensätzen. Wer alle KI-Bots gleich behandelt, blockiert im Zweifel erwünschte Sichtbarkeit oder erlaubt Zugriffe, die strategisch gar nicht gewünscht sind.

Was ist ein LLM-Crawler?

Ein LLM-Crawler ist ein automatisierter oder userinitiierter Abrufmechanismus, mit dem KI-Anbieter Webinhalte für unterschiedliche Zwecke erfassen: Modelltraining, AI-Search-Indexierung, Live-Abruf auf Nutzeranfrage oder offene Webdatensätze.

Der Begriff „LLM-Crawler“ wird häufig sehr breit verwendet. Tatsächlich sind damit mehrere Bot-Klassen gemeint. Einige Bots sammeln Inhalte, die potenziell für das Training oder die Verbesserung von KI-Modellen genutzt werden. Andere indexieren Inhalte für KI-Suchfunktionen. Wieder andere rufen eine URL erst dann ab, wenn ein Nutzer in einem KI-Tool konkret danach fragt.

Welche Arten von KI-Bots gibt es?

„KI-Bots“ sind keine homogene Gruppe. Für ein sinnvolles Bot-Management können mindestens vier Kategorien unterschieden werden. Diese Einteilung hilft dabei, technische Entscheidungen nicht aus dem Bauch heraus zu treffen, sondern nach Funktion und Ziel zu bewerten.

1. Trainingscrawler erfassen öffentliche Webinhalte, die potenziell in die Weiterentwicklung oder das Training von KI-Modellen einfließen können.

2. AI-Search-Bots unterstützen Such-, Indexierungs- oder Retrieval-Funktionen in KI-Suchsystemen.

3. Userinitiierte Fetcher rufen Inhalte im Zusammenhang mit einer konkreten Nutzeranfrage ab.

4. Archiv- und Dataset-Crawler erfassen Inhalte für offene Webarchive oder Datensätze, zum Beispiel Common Crawl.

Der wichtigste Unterschied im KI-Bot-Management liegt zwischen Training und Search. Trainingsbots können Inhalte für künftige Modellgenerationen erfassen. Search-Bots helfen dagegen, Inhalte in KI-Suchumgebungen auffindbar und zitierbar zu machen.

Bot-Klassifizierung: GPTBot, ClaudeBot, PerplexityBot, CCBot und Google-Extended

Die folgende Übersicht ordnet die wichtigsten Bots nach Zweck und Steuerungslogik.

Anbieter	Bot / User-Agent	Hauptzweck	Steuerung
OpenAI	GPTBot	potenzielle Trainingsnutzung	robots.txt, IP-Verifikation, ggf. WAF
OpenAI	OAI-SearchBot	Search-Sichtbarkeit in ChatGPT	robots.txt erlauben, technische Blockaden prüfen
OpenAI	ChatGPT-User	userinitiierter Abruf	robots.txt-Wirkung nicht garantiert; Logs/WAF prüfen
Anthropic	ClaudeBot	potenzielle Trainings- bzw. Modellverbesserungsnutzung	robots.txt, Crawl-delay möglich, technische Prüfung
Anthropic	Claude-SearchBot	Suchqualität und Sichtbarkeit	robots.txt, Monitoring
Anthropic	Claude-User	Abruf auf Nutzeranfrage	robots.txt wirksam; technische Regeln prüfen
Perplexity	PerplexityBot	Search-Index / Sichtbarkeit in Perplexity	robots.txt, IP-Ranges, WAF-Allowlisting
Perplexity	Perplexity-User	userinitiierter Abruf	robots.txt greift laut Anbieter nicht; WAF/IP-Verifikation, Rate-Limit und Log-Monitoring relevant
Common Crawl	CCBot	offener Webdatensatz	robots.txt, Opt-out, Indexprüfung
Google	Google-Extended	robots.txt-Produkt-Token für bestimmte Gemini-/Grounding-Nutzungen	robots.txt-Token, kein eigener HTTP-User-Agent

Perplexity unterscheidet zum Beispiel zwischen PerplexityBot und Perplexity-User. PerplexityBot ist für die Auffindbarkeit und Verlinkung von Websites in Perplexity-Suchergebnissen gedacht und laut Perplexity nicht für das Training von Foundation Models vorgesehen. Perplexity-User ist dagegen ein userinitiierter Fetcher, der im Kontext konkreter Nutzeranfragen Seiten abrufen kann. Laut Anbieter greift robots.txt für Perplexity-User nicht. Für die technische Kontrolle sollten diese Zugriffe deshalb vor allem über WAF-Regeln, IP-Ranges, Rate-Limits und Log-Monitoring bewertet werden.

Auch bei Google-Extended ist Präzision wichtig: Wer in seinen Logs nach einem HTTP-User-Agent „Google-Extended“ sucht, wird ihn nicht finden. Google-Extended ist kein separater Crawler; es ist ein Steuerungs-Token in der robots.txt. Die tatsächlichen Abrufe erfolgen weiterhin über bestehende Google-Crawler. Google dokumentiert außerdem, dass Google-Extended keinen Einfluss auf die klassische Google-Suche hat. Ergänzend sollte klar sein: Google-Extended steuert Gemini-Training und -Grounding, nicht die Sichtbarkeit in AI Overviews. AI Overviews sind Teil der Google-Suche und werden nicht über Google-Extended gesteuert. Wer eine Darstellung in Such-Snippets oder AI-Overviews-Auszügen verhindern möchte, müsste mit Snippet-Steuerungen wie nosnippet arbeiten; das kann sich auch auf reguläre Google-Snippets auswirken.

Trainingscrawler wie GPTBot und ClaudeBot steuern

Trainingscrawler sind für viele Unternehmen und Publisher die strategisch sensibelste Kategorie. Hier geht es nicht um klassische Suchmaschinen-Sichtbarkeit, sondern um die Frage, ob öffentlich erreichbare Inhalte für potenzielle Trainings- oder Modellverbesserungszwecke genutzt werden dürfen.

Wer diese Nutzung einschränken möchte, sollte Trainingscrawler gezielt über die robots.txt adressieren. OpenAI weist Publisher darauf hin, GPTBot per robots.txt zu disallowen, wenn Inhalte von potenziellem Training ausgeschlossen werden sollen. Gleichzeitig sollte OAI-SearchBot nicht automatisch mit blockiert werden, wenn Sichtbarkeit in ChatGPT-Suchfunktionen erwünscht ist. Ein Disallow wirkt in der Regel nur für künftige Abrufe. Bereits erhobene Daten oder bereits trainierte Modelle werden dadurch nicht rückwirkend entfernt. Das gilt auch für offene Datensätze wie Common Crawl: Ein CCBot-Disallow verhindert künftiges Crawling, entfernt aber keine bestehenden Crawl-Archive.

Bevor Trainingsbots erlaubt oder blockiert werden, sollte jedoch zuerst die Serverlog-Realität geprüft werden. Für die Bewertung zählt neben der theoretischen Erlaubnis vor allem die tatsächliche Aktivität auf der Website: Wie viele Requests entstehen pro Tag? Welche Pfade werden angefragt? Werden vor allem öffentliche Ratgeber- und Leistungsseiten gecrawlt oder treffen die Abrufe API-, Filter-, Such- oder Archivbereiche? Erst diese Daten zeigen, ob ein Bot strategisch relevant, technisch unauffällig oder potenziell belastend ist.

Wenn Trainingsbots grundsätzlich erlaubt bleiben sollen, aber zu viele Requests erzeugen, ist nicht zwingend ein vollständiger Block die beste Lösung. In solchen Fällen können Crawl-delay, Rate-Limits oder WAF-Regeln sinnvoller sein. Dabei ist wichtig: Crawl-delay ist keine standardisierte und universell unterstützte robots.txt-Regel. Anthropic unterstützt Crawl-delay für ClaudeBot, Google unterstützt das Feld dagegen nicht. Für belastbare Laststeuerung bleiben daher Server-, CDN-, WAF- und Rate-Limit-Regeln die verlässlichere Ebene.

Auch strategisch ist die Entscheidung nicht trivial. Wer Trainingscrawler dauerhaft ausschließt, kann potenzielle Trainingsnutzung begrenzen, verzichtet aber möglicherweise darauf, dass die eigenen Inhalte in zukünftigen Modellgenerationen als gelerntes Hintergrundwissen berücksichtigt werden. Für aktuelle AI-Search-Sichtbarkeit sollte diese Frage jedoch sauber von Search-Bots getrennt werden: Bei OpenAI ist OAI-SearchBot für die Sichtbarkeit in ChatGPT-Suchfunktionen relevant, während GPTBot für potenzielle Trainingsnutzung steht.

Der typische Fehler besteht darin, alle OpenAI-, Anthropic- oder Perplexity-Bots undifferenziert zu sperren. Das wirkt zunächst konsequent, kann aber dazu führen, dass Inhalte nicht mehr in KI-Suchumgebungen berücksichtigt werden, obwohl eigentlich nur die Trainingsnutzung ausgeschlossen werden sollte.

AI-Search-Bots erlauben, ohne Trainingsnutzung freizugeben

AI-Search-Bots verfolgen ein anderes Ziel als Trainingscrawler. Sie helfen KI-Systemen dabei, aktuelle oder indexierte Webinhalte in Such- und Antwortumgebungen zu finden, zu bewerten, zu verlinken oder zu zitieren.

Für Unternehmen ist das strategisch relevant. Wer Ratgeberinhalte, Produktseiten, Glossare oder Pressebereiche in KI-Suchsystemen sichtbar halten möchte, sollte Search-Bots nicht vorschnell blockieren. Als einfache Grundlogik hat sich bewährt: Trainingsbots werden bewusst bewertet, Search-Bots in relevanten öffentlichen Bereichen eher erlaubt, sensible oder irrelevante Pfade technisch geschützt und die Wirkung anschließend über Logs kontrolliert.

ChatGPT-User, Claude-User und Perplexity-User verstehen

Userinitiierte Fetcher sind ein Sonderfall. Sie crawlen nicht dauerhaft im klassischen Sinn, sondern rufen Inhalte häufig erst dann ab, wenn eine konkrete Nutzeraktion vorliegt. Das kann zum Beispiel passieren, wenn jemand eine URL in ein KI-Tool eingibt oder nach einer aktuellen Information fragt.

Deshalb sollten diese Fetcher nicht 1:1 wie Trainingscrawler behandelt werden. Strategisch kann ihr Zugriff sogar erwünscht sein, weil sie es einem KI-System ermöglichen, eine Seite live abzurufen, auszuwerten und als Quelle zu nennen.

Die Steuerungslogik unterscheidet sich je Anbieter. Bei Claude-User kann robots.txt laut Anbieter wirksam sein. Bei ChatGPT-User ist die Wirkung von robots.txt nicht garantiert, und bei Perplexity-User greift robots.txt laut Anbieter nicht. Gerade bei userinitiierten Abrufen sollten deshalb Logfile-Analyse, IP-Verifikation, WAF-Regeln, Rate-Limits und laufendes Monitoring stärker gewichtet werden.

Crawler-Sichtbarkeit ist nicht gleich AI-Antwort-Sichtbarkeit

Ein häufiger Denkfehler im GEO– und AI-Search-Kontext lautet: „Wenn der Bot meine Seite crawlen darf, erscheint meine Marke automatisch in KI-Antworten.“ So einfach ist es nicht.

Bot-Zugriff ist nur eine technische Voraussetzung für AI-Search- oder GEO-Sichtbarkeit. Ob eine Marke, URL oder Aussage tatsächlich in KI-Antworten erscheint, hängt zusätzlich von Autorität, inhaltlicher Eindeutigkeit, semantischer Struktur, Aktualität, Erwähnungen auf Drittquellen und der jeweiligen Retrieval-Logik des Systems ab.

Crawler-Steuerung sorgt also dafür, dass Inhalte technisch erreichbar sind oder bewusst ausgeschlossen werden. Sie ersetzt aber keine inhaltliche Optimierung, keine Markenautorität, keine strukturierte Informationsarchitektur und keine saubere Quellenlage.

Für SEO- und Content-Teams bedeutet das: Bot-Management ist ein technischer Grundpfeiler. Sichtbarkeit in KI-Antwortsystemen entsteht aber erst durch das Zusammenspiel aus Crawlability, Content-Qualität, klaren Entitäten, Reputation und externer Erwähnung.

Warum robots.txt KI-Bots nicht zuverlässig blockiert

Die robots.txt ist die klassische Sprache, mit der Website-Betreiber Crawling-Präferenzen ausdrücken. Sie teilt kooperativen Bots mit, welche Bereiche gecrawlt werden dürfen und welche nicht. Im Alltag wird sie aber oft überschätzt: Sie ist keine technische Zugriffssperre. Sie verhindert nicht, dass ein Request überhaupt ankommt. Sie funktioniert nur dann, wenn ein Bot die Regeln respektiert.

robots.txt ist Policy, nicht Enforcement

Eine robots.txt-Datei ist sehr sinnvoll, um kooperativen Bots klare Regeln zu geben. Sie ersetzt aber keine WAF, keine Authentifizierung, keine Serverregeln und kein Rate-Limiting. Das gilt besonders bei unkooperativen Bots, gefälschten User-Agents, sensiblen Pfaden, Login- oder Account-Bereichen, API-Endpunkten, Lastspitzen durch aggressive Abrufe und userinitiierten Fetchern.

Auch Crawl-delay sollte nicht überschätzt werden. Anthropic unterstützt laut eigener Dokumentation Crawl-delay als nicht standardisierte robots.txt-Erweiterung, um Crawling-Aktivität zu begrenzen. Google unterstützt crawl-delay hingegen nicht als robots.txt-Feld. Crawl-delay kann also für einzelne Anbieter sinnvoll sein, ersetzt aber kein Rate-Limiting auf Server-, CDN- oder WAF-Ebene.

Praxisbeispiel robots.txt: Öffentliche Inhalte sichtbar halten, sensible Pfade begrenzen

Eine gute robots.txt sollte die eigene Zielsetzung abbilden, statt „alle KI-Bots“ ohne Differenzierung zu blockieren. Für viele Unternehmen ist Sichtbarkeit auf öffentlichen Marketing-, Ratgeber-, Produkt- oder redaktionellen Seiten erwünscht. Gleichzeitig sollen Admin-Bereiche, APIs, interne Suche, Checkout-, Account- oder Staging-Pfade nicht unnötig gecrawlt werden.

Das folgende Beispiel ist bewusst fiktiv. Es zeigt eine Policy für eine Website, die öffentliche Inhalte für relevante Such- und KI-Crawler zugänglich machen möchte, sensible und ressourcenintensive Bereiche aber ausschließt. Es ist kein Universalvorschlag für jede Website, sondern ein Muster, das auf Basis von Geschäftsmodell, Rechtsbewertung, Content-Strategie und Serverlog-Daten angepasst werden sollte.

# Fiktives Beispiel: Öffentliche Marketing- und redaktionelle Inhalte

# für relevante Such- und KI-Crawler zugänglich machen.

# Sensible, technische und administrative Pfade bleiben ausgeschlossen.

User-agent: GPTBot

User-agent: ChatGPT-User

User-agent: OAI-SearchBot

User-agent: Google-Extended

User-agent: GoogleOther

User-agent: Googlebot

User-agent: ClaudeBot

User-agent: Claude-SearchBot

User-agent: Claude-User

User-agent: PerplexityBot

User-agent: Perplexity-User

User-agent: CCBot

User-agent: Applebot

User-agent: Applebot-Extended

User-agent: Meta-ExternalAgent

User-agent: FacebookBot

User-agent: Bingbot

User-agent: DuckAssistBot

Allow: /

Disallow: /admin/

Disallow: /account/

Disallow: /checkout/

Disallow: /api/

Disallow: /internal/

Disallow: /staging/

Disallow: /suche/

Disallow: /*?filter=

Disallow: /*?sort=

User-agent: *

Allow: /

Disallow: /admin/

Disallow: /account/

Disallow: /checkout/

Disallow: /api/

Disallow: /internal/

Disallow: /staging/

Disallow: /suche/

Disallow: /*?filter=

Disallow: /*?sort=

Sitemap: https://www.example.com/sitemap.xml

Der Ansatz dahinter ist bewusst sichtbarkeitsorientiert: Große Suchmaschinen-, KI-Search-, User-Fetch- und Trainingsbots dürfen öffentliche Inhalte grundsätzlich abrufen. Gleichzeitig werden typische Pfade ausgeschlossen, die für Sichtbarkeit meist keinen Mehrwert liefern oder technisch sensibler sind: Admin-Bereiche, Account- und Checkout-Pfade, API-Endpunkte, interne Bereiche, Staging-Umgebungen, Suchseiten und parameterbasierte Filter- oder Sortier-URLs.

Diese robots.txt entscheidet sich nicht gegen einzelne Anbieter. Sie behandelt OpenAI, Anthropic, Perplexity, Google, Apple, Meta, Bing und Common Crawl nach derselben Grundlogik: öffentliche Inhalte erlauben, problematische Pfade begrenzen. Wenn ein Unternehmen potenzielle Trainingsnutzung restriktiver bewerten möchte, können einzelne Trainings- oder Dataset-Bots wie GPTBot, ClaudeBot, Google-Extended oder CCBot separat eingeschränkt werden. Diese Entscheidung sollte auf Zielsetzung, Rechtsbewertung und Logfile-Analyse basieren.

Gerade bei Trainingsbots sollte vor einer Freigabe geprüft werden, ob und wie stark sie bereits auf der Website aktiv sind. Sind es nur wenige Requests auf strategisch wichtige Inhalte, kann eine Freigabe vertretbar sein. Entstehen dagegen Lastspitzen, viele Abrufe irrelevanter URL-Muster oder Zugriffe auf technische Randbereiche, sollten Crawl-delay, Rate-Limits, WAF-Regeln oder zusätzliche Pfadausschlüsse geprüft werden. robots.txt bleibt dabei eine Policy-Ebene, keine technische Zugriffssperre.

Common Crawl prüfen: Ist meine Website im KI-Datensatz?

Common Crawl ist eine eigene Kategorie im Bot-Management. Anders als bei einem klassischen Suchmaschinenbot geht es hier nicht unmittelbar um Rankings oder Snippets, sondern um offene Webdatensätze. Die Organisation betreibt mit CCBot einen Crawler, sammelt öffentlich erreichbare Webinhalte und stellt daraus regelmäßig Datensätze bereit, die von Forschung, Suchsystemen und auch KI-nahen Anwendungen genutzt werden können.

Für Online-Marketer entstehen daraus zwei praktische Fragen. Erstens: Möchte das Unternehmen überhaupt in solchen offenen Datensätzen vorkommen? Zweitens: Falls ja, sind die strategisch wichtigen Inhalte dort tatsächlich enthalten oder werden vor allem irrelevante URLs, alte Inhalte oder Parameterseiten erfasst?

Die Prüfung ist deshalb weniger ein technischer Selbstzweck als ein strategischer Realitätscheck. Common Crawl stellt mit dem CDXJ Index und dem URL Index Werkzeuge bereit, mit denen sich nach Domains, URL-Mustern und einzelnen Page Captures suchen lässt. So lässt sich nachvollziehen, ob eine Website oder bestimmte Seitentypen in einem Crawl enthalten waren.

Common Crawl in der Praxis prüfen

Der erste Schritt besteht darin, neben der Startseite bewusst mehrere repräsentative URL-Muster zu prüfen. Dazu gehören zum Beispiel zentrale Ratgeber, Leistungsseiten, Kategorien, Pressebereiche oder andere Inhalte, die für Marke, Sichtbarkeit und Expertise wichtig sind. So wird schnell sichtbar, ob Common Crawl nur einzelne Einstiegsseiten erfasst hat oder ob auch die inhaltlich wertvollen Bereiche im Datensatz auftauchen.

Im zweiten Schritt sollten die Treffer nach Crawl-Monat und Statuscode eingeordnet werden. Ein Treffer aus einem alten Crawl-Zyklus ist anders zu bewerten als eine aktuelle Aufnahme. Ebenso macht es einen Unterschied, ob Seiten mit Statuscode 200 erfasst wurden oder ob auffällig viele Weiterleitungen, 404-Fehler oder Serverfehler auftauchen. Gerade für SEO-Teams ist diese Einordnung hilfreich, weil sie zeigt, ob technische Muster den Zugriff erschweren.

Danach lohnt sich der Blick auf die Verteilung der Seitentypen. Wenn hauptsächlich Parameter-URLs, Filterseiten oder andere wenig relevante Bereiche erscheinen, ist das ein Hinweis auf ein mögliches Crawl-Budget- oder Steuerungsproblem. Wenn dagegen zentrale Content-Hubs fehlen, muss nicht automatisch ein Fehler vorliegen; es kann aber ein Anlass sein, interne Verlinkung, Sitemaps und robots.txt-Regeln zu prüfen.

Für die Erwartungshaltung zählt: Common Crawl ist kein vollständiges Abbild des Webs. Eine fehlende URL bedeutet nicht automatisch, dass die Seite technisch blockiert ist oder ein schwerwiegendes Problem besteht. Es kann schlicht sein, dass sie in einem bestimmten Crawl-Zyklus nicht berücksichtigt wurde. Aussagekräftig wird die Prüfung vor allem dann, wenn sie wiederholt und mit den eigenen wichtigsten Seitentypen abgeglichen wird.

Wenn eine künftige Aufnahme in offene Datensätze nicht gewünscht ist, sollte CCBot gezielt über die robots.txt gesteuert werden. Auch hier verhindert ein Disallow künftiges Crawling, entfernt aber keine bestehenden Common-Crawl-Archive. Zusätzlich kann geprüft werden, ob ein Opt-out-Prozess relevant ist. Die Entscheidung hängt davon ab, ob offene Datensatz-Präsenz für das Geschäftsmodell erwünscht, neutral oder problematisch ist.

KI-Crawler in Logfiles erkennen und bewerten

Die operative Wahrheit liegt in den Logs. Erst die Logfile-Analyse zeigt, welche Bots tatsächlich auf eine Website zugreifen, welche Pfade sie anfragen, welche Statuscodes entstehen und ob es Lastspitzen gibt. Für Online-Marketer ist das wichtig, weil Bot-Management sonst schnell abstrakt bleibt: Es wird über bekannte Bot-Namen diskutiert, aber es ist unklar, ob diese Bots auf der eigenen Website überhaupt relevant sind.

Für einen ersten Überblick reicht in vielen Fällen ein Analysezeitraum von 30 Tagen. Dieser Zeitraum ist lang genug, um wiederkehrende Muster zu erkennen, aber noch überschaubar genug, um einzelne Regeländerungen, Kampagnen oder technische Auffälligkeiten einordnen zu können. Bei sehr großen Websites oder stark saisonalen Zugriffen kann der Zeitraum später erweitert werden.

Für die Analyse sollten zunächst die bekannten User-Agents gefiltert werden, etwa GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User, CCBot und Googlebot. Diese Liste ist kein endgültiger Maßstab, aber ein guter Startpunkt. Danach zählt das Verhalten des Bots, nicht allein seine Existenz in den Logs.

Aussagekräftig sind vor allem Requests je Bot oder Bot-Gruppe, die am häufigsten angefragten Pfade, die Statuscode-Verteilung und die Anzahl der Abrufe der robots.txt. Ergänzend sollten HTML-, API-, Asset- und Parameter-URL-Anteile betrachtet werden. So lässt sich erkennen, ob ein Bot vor allem relevante Inhalte abruft oder ob er technische Randbereiche, Filterkombinationen oder ressourcenintensive URLs trifft.

Noch klarer wird das Bild, wenn die Daten segmentiert werden. Sinnvoll ist zum Beispiel die Trennung zwischen erlaubten und blockierten Bots, Search-Bots und Trainingsbots, userinitiierten Fetchern und klassischen Crawlern sowie verifizierten und nicht verifizierten Bot-Identitäten. Ebenso wichtig ist die Unterscheidung zwischen öffentlichen Inhalten und sensiblen oder ressourcenintensiven Pfaden.

Ein zentraler Punkt dabei: Der User-Agent allein ist keine sichere Identität. Jeder Client kann einen Bot-User-Agent fälschen. Für belastbare Entscheidungen sollten deshalb IP-Ranges, Reverse-DNS/Forward-DNS und Anbieter-Dokumentationen einbezogen werden. Erst dann lässt sich beurteilen, ob ein Request tatsächlich von dem Anbieter stammt, als der er sich ausgibt.

robots.txt, WAF oder Rate-Limit: Was passt wann?

Nach der Logfile-Analyse stellt sich die Umsetzungsfrage: Reicht die robots.txt oder braucht es technische Durchsetzung? Die Antwort hängt davon ab, welches Problem gelöst werden soll. Die robots.txt eignet sich gut, um kooperativen Bots klare Präferenzen mitzuteilen. Eine WAF ist dann sinnvoll, wenn Regeln technisch erzwungen werden müssen. Rate-Limits helfen, wenn Zugriff grundsätzlich erlaubt bleiben soll, aber nicht in beliebiger Frequenz.

Problem	robots.txt	WAF	Rate-Limit
Trainingsnutzung opt-out signalisieren	stark	mittel	schwach
unkooperative Bots blockieren	schwach	stark	mittel
Serverlast reduzieren	schwach	mittel	stark
sensible Pfade schützen	schwach	stark	mittel
erwünschte Bots kontrolliert zulassen	mittel	stark	stark
AI-Search-Sichtbarkeit erhalten	stark	mittel	mittel

Als Faustregel gilt: robots.txt reicht aus, wenn es um kooperative Bots, strategische Opt-out-Signale und öffentlich zugängliche Inhalte geht. Sie ist besonders geeignet, wenn Search-Bots weiterhin Zugriff erhalten sollen und keine akuten Last- oder Sicherheitsprobleme bestehen.

WAF-Regeln werden relevant, wenn reine Hinweise nicht mehr genügen. Das ist etwa der Fall, wenn sensible Pfade geschützt werden müssen, Bots die robots.txt ignorieren, User-Agents gefälscht werden oder Regeln nach IP-Ranges, Ländern, Headern und Pfaden kombiniert werden sollen. Eine WAF ist also weniger ein SEO-Werkzeug als eine technische Durchsetzungsebene.

Rate-Limits sind vor allem dann sinnvoll, wenn ein Bot grundsätzlich willkommen ist, aber zu viele Requests erzeugt. Das betrifft häufig Search-Bots, Parameter-URLs, APIs oder dynamische Seiten. Rate-Limiting ist deshalb oft die bessere Alternative zum Full Block: Der Zugriff bleibt möglich, während die Infrastruktur geschützt wird.

Welche KI-Bots erlauben, begrenzen oder blockieren?

Die passende Entscheidung leitet sich aus dem eigenen Ziel ab: Welche Inhalte sollen sichtbar sein? Welche Inhalte sollen nicht für potenzielle Trainingsnutzung verfügbar sein? Welche Pfade verursachen unnötige Last? Und welche Bots sind in den Logs wirklich sichtbar?

Bot-Klasse	Eher erlauben, wenn …	Eher begrenzen, wenn …	Eher blockieren, wenn …
Trainingscrawler	Trainingsnutzung akzeptiert oder strategisch erwünscht ist	nur bestimmte Bereiche ausgeschlossen werden sollen oder die Request-Last zu hoch ist	Inhalte nicht für potenzielles Training genutzt werden sollen
AI-Search-Bots	KI-Sichtbarkeit, Zitationen und Auffindbarkeit wichtig sind	hohe Request-Last entsteht	kein Interesse an AI-Search-Sichtbarkeit besteht
User-Fetcher	Live-Abruf und Quellenverweise erwünscht sind	Abrufe sensible oder teure Pfade treffen	Missbrauch, Scraping oder Sicherheitsrisiken auftreten
Common Crawl / CCBot	Präsenz in offenen Webdatensätzen erwünscht ist	nur bestimmte Bereiche problematisch sind	Aufnahme in offene Datensätze unerwünscht ist
Klassische Suchbots	SEO-Sichtbarkeit relevant ist	Crawl-Budget oder Last optimiert werden müssen	Inhalte nicht indexiert oder gecrawlt werden sollen

Die Matrix ist deshalb kein starres Regelwerk; sie ist eine Entscheidungshilfe. Gutes Bot-Management beginnt bei der Definition der eigenen Ziele. Erst danach lassen sich robots.txt-Regeln, WAF-Logik und Rate-Limits sinnvoll miteinander kombinieren.

Bot-Management-Policy nach Seitentyp

Noch präziser wird Bot-Management, wenn es nach Seitentypen gedacht wird. Nicht jede URL einer Website hat denselben strategischen Wert. Ein öffentlicher Ratgeberartikel verfolgt ein anderes Ziel als ein Checkout, eine API oder ein Staging-System.

Seitentyp	Empfehlung
Öffentliche Ratgeber und Glossare	Search-Bots erlauben, Trainingsbots strategisch bewerten
Produkt- und Leistungsseiten	Search-Bots meist erlauben, Monitoring aktivieren
Presse- und News-Bereich	gezielt Search-Bots erlauben, Common Crawl bewusst entscheiden
Login- und Account-Bereiche	technisch sperren; robots.txt reicht nicht
Warenkorb und Checkout	technisch sperren, Crawling vermeiden
Interne Suche und Filterseiten	häufig begrenzen oder blockieren
API-Endpunkte	WAF, Rate-Limits, Authentifizierung und Pfadregeln nutzen
Duplicate- und Parameter-URLs	Crawl-Budget und Serverlast schützen
Staging- und Testsysteme	Authentifizierung, IP-Sperren; noindex allein reicht nicht

Für öffentliche Ratgeber, Glossare, Produkt- und Leistungsseiten ist Sichtbarkeit oft erwünscht. Hier sollten Search-Bots in der Regel Zugriff erhalten, während Trainingsbots bewusst bewertet werden. Presse- und News-Bereiche können ebenfalls für KI-Suchsysteme relevant sein, sollten aber im Hinblick auf Aktualität, Zitationen und Common-Crawl-Präsenz separat betrachtet werden.

Anders sieht es bei Login-, Account-, Checkout-, API- oder Staging-Bereichen aus. Diese Bereiche sollten technisch geschützt sein; ein Ausschluss über robots.txt reicht nicht. Wenn Inhalte nicht öffentlich zugänglich sein sollen, braucht es Authentifizierung, IP-Sperren, Serverregeln, WAF-Konfigurationen oder vergleichbare Zugriffskontrollen. noindex oder robots.txt reichen dafür nicht aus.

Häufige Fehler im KI-Bot-Management

Viele Fehler im KI-Bot-Management entstehen, weil unterschiedliche Bot-Typen gleich behandelt werden. Das wirkt zunächst einfach, führt aber häufig zu Nebenwirkungen: erwünschte Sichtbarkeit geht verloren, technische Last bleibt bestehen oder sensible Bereiche werden nur scheinbar geschützt.

Ein häufiger Fehler ist das Blockieren aller KI-Bots. Das kann zwar Trainingsnutzung begrenzen, beeinträchtigt aber unter Umständen auch AI-Search-Sichtbarkeit. Besser ist die Trennung nach Trainingsbots, Search-Bots und User-Fetchern.

Ebenso problematisch ist es, GPTBot und OAI-SearchBot gleich zu behandeln. GPTBot und OAI-SearchBot erfüllen unterschiedliche Zwecke. Wer beide blockiert, schließt potenzielle Trainingsnutzung aus und kann auch die Sichtbarkeit in ChatGPT-Suchfunktionen reduzieren.

Ein weiterer typischer Denkfehler betrifft Google-Extended. Google-Extended ist kein eigener HTTP-User-Agent, sondern ein robots.txt-Produkt-Token. Wer danach in Serverlogs sucht, sucht an der falschen Stelle.

Besonders kritisch ist es, robots.txt als Sicherheitsmaßnahme zu verstehen. robots.txt ist eine Crawling-Policy, aber kein Zugriffsschutz. Für nicht öffentliche Inhalte braucht es Authentifizierung, Serverregeln, WAF oder andere technische Schutzmechanismen.

Auch Crawl-delay wird häufig überschätzt. Es wird nicht von allen Anbietern unterstützt und kann punktuell helfen, ersetzt aber kein echtes Rate-Limiting. Genauso wenig sollte einem User-Agent ohne IP- oder DNS-Verifikation vertraut werden, denn User-Agents können gefälscht werden.

Schließlich sollten WAF-Regeln immer gegen Logs geprüft werden. Eine Regel im Dashboard ist noch kein Beweis für Wirkung. Entscheidend ist, ob Requests tatsächlich erlaubt, blockiert oder begrenzt werden und ob dabei unerwünschte Seiteneffekte entstehen.

Auch Common Crawl sollte nicht mit einer vollständigen Webarchivierung verwechselt werden. Es handelt sich um ein Sample des Webs, nicht um einen vollständigen Index aller Seiten. Und auch für AI-Search-Sichtbarkeit gilt: Crawlability ist wichtig, aber nicht ausreichend. Inhalt, Struktur, Entitäten, Autorität, Aktualität und externe Erwähnungen bleiben zentrale Faktoren.

Monitoring: Welche KPIs ins KI-Bot-Reporting gehören

Bot-Management endet nicht mit einer robots.txt und auch nicht mit einer einmal gesetzten WAF-Regel. Anbieter ändern ihre Bots, Websites entwickeln sich weiter, neue Verzeichnisse entstehen und technische Seiteneffekte zeigen sich oft erst im laufenden Betrieb. Deshalb sollte KI-Bot-Management regelmäßig gemonitort werden.

Ein gutes Reporting beantwortet mehr als die Frage, wie viele Bot-Requests stattgefunden haben. Es zeigt auch, welche Bot-Klassen aktiv sind, welche Pfade besonders häufig angefragt werden, ob technische Fehler entstehen und ob gesetzte Regeln wie gewünscht wirken.

Zu den wichtigsten KPIs gehören deshalb Requests je Bot und Bot-Gruppe, der Anteil von Search-Bots, Trainingsbots und User-Fetchern, die Top-Pfade, die Statuscode-Verteilung sowie die Häufigkeit von /robots.txt-Abrufen. Ergänzend sollten 4xx- und 5xx-Anteile, disallowte Pfade mit Request-Aktivität, geblockte Requests, rate-limited Requests und auffällige User-Agent-/IP-Kombinationen beobachtet werden.

Zentral ist dabei die Unterscheidung zwischen Aktivität und Problem. Eine hohe Request-Zahl ist nicht automatisch kritisch. Relevant wird sie erst dann, wenn sie sensible Pfade betrifft, Serverlast erzeugt, Fehlerraten erhöht oder gegen definierte Regeln läuft. Deshalb sollte das Reporting immer mit klaren Zielwerten und Handlungsempfehlungen verbunden werden.

Praxisbox: Vom Bauchgefühl zur Bot-Policy

Ausgangslage

Ein Unternehmen stellt Lastspitzen auf der Website fest. Intern entsteht schnell die Vermutung, dass „die KI-Bots“ blockiert werden sollten. Dieser Reflex ist nachvollziehbar, aber selten die beste erste Maßnahme.

Logrealität

Die Logfile-Analyse zeigt, dass ein einzelner KI-Bot nicht das Hauptproblem ist. Stattdessen werden bestimmte URL-Muster überproportional häufig angefragt, etwa interne Suchergebnisse, Filterseiten, Parameter-URLs oder tiefe Archivbereiche. Das Problem liegt damit in der Kombination aus URL-Struktur, Bot-Zugriff und fehlender Begrenzung.

Maßnahme

Die Lösung besteht deshalb nicht aus einem pauschalen Full Block. Stattdessen werden Trainingscrawler nach einer ersten Logfile-Analyse bewusst bewertet, während AI-Search-Bots auf strategisch wichtigen Ratgeber- und Leistungsseiten erlaubt bleiben. Filter- und Suchseiten werden zusätzlich per robots.txt und WAF-Regeln begrenzt. Für ressourcenintensive Pfade wird ein Rate-Limit gesetzt, und Bot-Identitäten werden über User-Agent sowie IP-/DNS-Prüfung validiert.

Ergebnis

Das Ergebnis ist eine deutlich ausgewogenere Policy: Die Website reduziert unnötige Last, erhält relevante AI-Search-Sichtbarkeit und gewinnt ein klareres Bild davon, welche Bots tatsächlich geschäftsrelevant sind. Nicht der Reflex „KI-Bots blockieren“ führt zur besten Lösung, sondern die Kombination aus Zieldefinition, Logfile-Analyse und differenzierter technischer Steuerung.

Fazit: KI-Bot-Management ist eine Governance-Aufgabe

KI-Bot-Management ist kein einzelner Schalter. Es ist ein Steuerungsmodell.

Unternehmen sollten verstehen, dass unterschiedliche Bots unterschiedliche Ziele verfolgen: Training, Search, userinitiierter Abruf oder offene Datensammlung. Daraus folgen unterschiedliche technische und strategische Entscheidungen.

Für die praktische Umsetzung hilft eine klare Reihenfolge: Zuerst sollten Bot-Klassen verstanden und die eigenen Ziele definiert werden. Danach wird anhand der Serverlogs geprüft, welche Bots tatsächlich aktiv sind und welche Last entsteht. Auf dieser Basis wird die robots.txt differenziert aufgesetzt, während Search-Bots und Trainingsbots getrennt bewertet werden. Anschließend sollten Common-Crawl-Präsenz und Logfiles weiter geprüft werden, bevor WAF-Regeln und Rate-Limits gezielt eingesetzt und regelmäßig gemonitort werden.

Die bessere Leitfrage lautet damit:

„Welche Inhalte sollen sichtbar, indexierbar, abrufbar oder begrenzt sein, und wie setzen wir das technisch und organisatorisch sauber um?”

Genau dort beginnt modernes KI-Bot-Management.

FAQ: Häufige Fragen zu LLM-Crawlern und KI-Bot-Management

Was ist ein LLM-Crawler?

Ein LLM-Crawler ist ein Bot oder Fetcher, der Webinhalte für KI-bezogene Zwecke abruft. Dazu gehören potenzielles Modelltraining, KI-Suchindexierung, Live-Abrufe auf Nutzeranfrage und offene Webdatensätze.

Was ist der Unterschied zwischen GPTBot und OAI-SearchBot?

GPTBot ist bei OpenAI der Bot, den Publisher per robots.txt ausschließen können, wenn Inhalte nicht für potenzielles Training genutzt werden sollen. OAI-SearchBot ist dagegen für Such- und Sichtbarkeitsfunktionen in ChatGPT relevant und sollte nicht blockiert werden, wenn Inhalte dort erscheinen sollen.

Kann ich Trainingsnutzung blockieren und trotzdem in KI-Suchsystemen sichtbar bleiben?

Ja, grundsätzlich ist genau diese Differenzierung sinnvoll. Trainingsbots und Search-Bots sollten getrennt bewertet und gesteuert werden. Wer Trainingsnutzung ausschließen möchte, muss nicht automatisch alle KI-Search-Bots blockieren.

Sollte ich Trainingsbots vor der Freigabe in den Serverlogs prüfen?

Ja. Vor einer Freigabe sollte geprüft werden, ob Trainingsbots überhaupt aktiv sind, wie viele Requests pro Tag entstehen, welche Pfade betroffen sind und ob Lastspitzen auftreten. Wenn die Nutzung strategisch erwünscht ist, aber zu viel Last erzeugt, sind Crawl-delay, Rate-Limits, WAF-Regeln oder zusätzliche Pfadausschlüsse oft sinnvoller als ein Full Block.

Reicht robots.txt aus, um KI-Bots zu blockieren?

Die robots.txt reicht nur für kooperative Bots, die diese Regeln respektieren. Sie ist keine technische Zugriffssperre. Für unkooperative Bots, sensible Pfade, APIs oder Lastprobleme braucht es zusätzlich WAF-Regeln, Rate-Limits, Authentifizierung oder Serverkonfigurationen.

Wie erkenne ich echte KI-Bots in Logfiles?

Der User-Agent ist nur der erste Hinweis. Für belastbare Entscheidungen sollten zusätzlich IP-Ranges, Reverse-DNS/Forward-DNS, Anbieter-Dokumentationen und Request-Muster geprüft werden.

Sollte ich CCBot blockieren?

Das hängt vom Ziel ab. Wer nicht in offenen Webdatensätzen wie Common Crawl erscheinen möchte, kann CCBot über robots.txt blockieren. Wer dagegen Präsenz in offenen Datensätzen strategisch akzeptiert oder wünscht, sollte CCBot differenziert bewerten und Logs, Sitemaps und relevante Seitentypen prüfen.

Was ist Google-Extended?

Google-Extended ist kein eigener HTTP-User-Agent, sondern ein robots.txt-Produkt-Token. Website-Betreiber können damit steuern, ob Inhalte für bestimmte Gemini-Trainings- und Grounding-Nutzungen verwendet werden dürfen. Google-Extended hat laut Google keinen Einfluss auf die Google-Suche.

Welche KPIs gehören ins KI-Bot-Monitoring?

Wichtige KPIs sind Requests je Bot, Top-Pfade, Statuscodes, robots.txt-Abrufe, 4xx-/5xx-Anteile, Burst-Zeiträume, blockierte Requests, rate-limited Requests und die Segmentierung nach Bot-Klassen.

Wann brauche ich WAF-Regeln?

WAF-Regeln sind sinnvoll, wenn robots.txt nicht ausreicht, etwa bei sensiblen Pfaden, gefälschten User-Agents, unkooperativen Bots, API-Zugriffen, bestimmten IP-/Länderregeln oder wenn erwünschte Bots gezielt zugelassen und unerwünschte technisch blockiert werden sollen.

Was ist der Unterschied zwischen Search-Bot und User-Fetcher?

Ein Search-Bot crawlt oder indexiert Inhalte für Such- und Retrieval-Funktionen. Ein User-Fetcher ruft Inhalte meist im Kontext einer konkreten Nutzeranfrage ab. Deshalb sollten User-Fetcher nicht automatisch wie klassische Trainingscrawler behandelt werden; je nach Anbieter unterscheiden sich robots.txt-Wirkung, WAF-/Rate-Limit-Steuerung und Monitoring-Bedarf deutlich.