KI-Crawler steuern: GPTBot, ClaudeBot und die anderen

Dominik Breitbach · Founder & Lead SEO Stratege bei taismo

Dominik Breitbach ist Gründer der taismo GmbH und als Lead SEO Stratege auf SEO-Betreuung und Sichtbarkeit in KI-Antworten (GEO) spezialisiert. Seit 2010 begleitet er Unternehmen bei SEO und Google Ads, mit taismo seit 2019 auch bei SEOcruiting.

⏱ Lesedauer: 14 Min 🔄 Zuletzt aktualisiert: 05.10.2026

KI-Crawler sind keine einheitliche Gruppe, und genau daran scheitern die meisten robots.txt-Dateien. Hinter GPTBot, ClaudeBot und PerplexityBot stehen drei verschiedene Aufgaben: Modelle trainieren, einen Suchindex füllen und eine Seite live abrufen, weil gerade jemand danach gefragt hat. Wer alle drei mit einer Zeile sperrt, verliert die Nennung in KI-Antworten und schützt seine Inhalte trotzdem nicht. Dieser Artikel zeigt, welche Kennungen es 2026 wirklich gibt, wie die Regeln ausgewertet werden, wo die robots.txt aufhört zu wirken und nach welchen Kriterien du entscheidest.

👉 Bevor du etwas änderst, sieh dir an, wie deine Seite heute dasteht: kostenloser SEO- und GEO-Check

Drei Rollen, ein Anbieter: warum „alle Bots“ die falsche Kategorie ist

Die Frage „sollen wir KI-Crawler zulassen?“ ist so gestellt nicht beantwortbar, weil sie drei Vorgänge zusammenwirft, die nichts miteinander zu tun haben. Was ein solcher Bot grundsätzlich ist und wer ihn betreibt, steht im Glossar unter KI-Crawler. Hier geht es um die Handlung, also um die Steuerung im laufenden Betrieb.

Trennscharf sind diese drei Rollen:

1. Training. Der Bot sammelt Text, aus dem später ein Modell lernt. Was er mitnimmt, steckt irgendwann im Modellgewicht und lässt sich nicht zurückholen. Eine Nennung deiner Marke folgt daraus nicht automatisch, eine Quellenangabe schon gar nicht.
2. Suchindex. Der Bot baut einen eigenen Index auf, aus dem das KI-System zitiert, sobald ein Nutzer fragt. Hier entsteht die Nennung mitsamt Verweis auf deine Seite. Das ist die Rolle, die für deine Sichtbarkeit zählt.
3. Live-Abruf. Ein Mensch hat gerade eine Frage gestellt, und das System holt deine Seite in diesem Moment. Formal ist das kein Crawling, sondern ein Aufruf im Auftrag eines Nutzers. Genau deshalb halten sich mehrere dieser Bots ausdrücklich nicht an die robots.txt.

Der Punkt, der in der Praxis Sichtbarkeit kostet: ein Anbieter betreibt mehrere Bots mit unterschiedlichen Rollen, und sie tragen unterschiedliche Kennungen. OpenAI hat vier, Anthropic drei, Meta drei. Wer nur die bekannteste Kennung sperrt, trifft fast immer die falsche.

Die Bot-Liste 2026: Kennungen, Betreiber und Zweck

Die folgende Tabelle ist an den Dokumentationen der Betreiber geprüft, nicht aus Fachartikeln übernommen, denn genau diese Angaben veralten schnell. Was in der ersten Spalte steht, gehört so in die Zeile User-agent:. Groß- und Kleinschreibung spielt dabei keine Rolle, das Feld ist nach der Spezifikation von Google unempfindlich dagegen.

Drei Zeilen lohnen den zweiten Blick. OAI-AdsBot ist neu und prüft Seiten, die als Anzeige in ChatGPT eingereicht wurden; er besucht ausschließlich eingereichte Adressen. Applebot-Extended crawlt selbst gar nicht, die Kennung ist ein reines Signal dafür, wie bereits erfasste Inhalte verwendet werden dürfen. Und CCBot gehört keinem KI-Anbieter, sondern einer gemeinnützigen Stiftung. Sein offenes Archiv ist trotzdem eine der meistgenutzten Trainingsquellen überhaupt, weshalb eine Sperre dort mittelbar auf viele Modelle wirkt.

OpenAI, Anthropic, Perplexity und Common Crawl veröffentlichen die IP-Bereiche ihrer Bots als JSON-Datei. Das ist der einzige belastbare Weg, einen echten Bot von einem gefälschten zu unterscheiden; die Adressen stehen unten in den Quellen.

Die zwei Schalter, die am häufigsten verwechselt werden

Der teuerste Irrtum in diesem Feld lautet: „Wir haben GPTBot gesperrt, also sind wir aus ChatGPT raus.“ Das stimmt nicht, und zwar in beide Richtungen.

GPTBot steuert das Training, OAI-SearchBot den Suchindex. Das sind zwei unabhängige Schalter. Wer GPTBot sperrt und OAI-SearchBot zulässt, wird weiterhin in ChatGPT-Antworten zitiert, gibt seine Texte aber nicht fürs Modelltraining frei. Wer umgekehrt nur OAI-SearchBot sperrt, verschwindet aus den Antworten und trägt trotzdem zum Training bei, solange GPTBot durchkommt.

Bei Google ist die Trennung noch klarer dokumentiert. Zu Google-Extended schreibt Google, die Kennung steuere, ob Inhalte für das Training künftiger Gemini-Modelle genutzt werden dürfen, und sie habe „keinen Einfluss darauf, ob eine Website in die Google-Suche aufgenommen wird, und ist auch kein Ranking-Signal“. Nach derselben Dokumentation steuert die Kennung aber nicht nur das Training: Sie entscheidet auch über das Grounding, also darüber, ob Gemini Apps und Vertex AI beim Antworten Inhalte aus der Google-Suche heranziehen dürfen. Eine Sperre von Google-Extended reicht damit weiter als bis zum Training. Apple formuliert es für Applebot-Extended genauso: Seiten, die diese Kennung sperren, können weiterhin in den Suchergebnissen erscheinen.

Praktisch heißt das: Eine Trainings-Sperre ist eine urheberrechtliche Entscheidung. Eine Suchindex-Sperre ist eine Sichtbarkeitsentscheidung. Wer beides in dieselbe Zeile schreibt, hat keine Entscheidung getroffen, sondern zwei ungeprüft zusammengelegt. Wonach KI-Systeme überhaupt auswählen, wen sie nennen, steht ausführlich im Artikel zum GEO-Ranking.

Wie die robots.txt wirklich gelesen wird

Die robots.txt wirkt einfacher, als sie ist. Vier Regeln entscheiden darüber, ob deine Datei das tut, was du glaubst.

Erstens: Ein Bot folgt genau einer Gruppe. Er sucht die Gruppe mit der speziellsten passenden Kennung, alle anderen Gruppen ignoriert er. Wenn also User-agent: * eine Regel enthält und weiter unten eine eigene Gruppe für GPTBot steht, dann gilt für GPTBot ausschließlich seine eigene Gruppe. Die Sternchen-Regel wird nicht zusätzlich angewendet. Das ist der Grund, warum eine neu ergänzte Bot-Gruppe eine vorhandene Sperre versehentlich aufheben kann.

Zweitens: Bei widersprüchlichen Regeln gewinnt die längere. Maßstab ist die Zeichenlänge des Regelpfads, und bei gleicher Länge die am wenigsten einschränkende Regel. So lässt sich gezielt ein Verzeichnis freigeben, obwohl der Rest gesperrt ist.

Drittens: Antwortet die Datei mit einem Serverfehler, wird zunächst gar nicht mehr gecrawlt. Ein 404 bedeutet für Google „keine Einschränkungen“. Ein 5xx dagegen stoppt das Crawling der Website für die ersten 12 Stunden, danach nutzt Google bis zu 30 Tage lang die letzte gültige Fassung. Eine robots.txt, die unter Last einen 503 wirft, ist damit gefährlicher als gar keine.

Viertens, und das ist der wichtigste Punkt: Disallow ist kein noindex. Google formuliert es so: Inhalte gesperrter Seiten könnten nicht indexiert werden, aber die Adresse selbst könne „dennoch indexiert und ohne Snippet in den Suchergebnissen angezeigt werden“. Wer eine Seite wirklich aus dem Index halten will, braucht ein Meta-Robots-Tag oder den X-Robots-Tag im HTTP-Header, und die Seite muss dafür crawlbar bleiben. Beides gleichzeitig zu setzen bewirkt genau das Gegenteil: Der Bot darf die Seite nicht laden und liest dein noindex deshalb nie.

Ein Beispiel, das die getrennten Schalter umsetzt: Training gesperrt, Suchindex und Live-Abruf offen.

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://deine-domain.de/sitemap_index.xml

Wichtig dabei: Diese Datei sperrt Googlebot nicht, und das muss so sein. Googlebot speist die klassische Suche und die AI Overviews. Wer ihn aussperrt, verliert nicht ein bisschen KI-Sichtbarkeit, sondern die Suche insgesamt.

Was die robots.txt nicht kann

Drei Lücken bleiben, und sie sind der Grund, warum eine saubere robots.txt allein nie die ganze Antwort ist.

Die Live-Abruf-Bots halten sich nicht daran, und sie sagen das offen. OpenAI schreibt zu ChatGPT-User, die robots.txt-Regeln könnten hier nicht gelten, weil der Abruf von einem Nutzer ausgelöst wurde. Perplexity formuliert für Perplexity-User, der Bot ignoriere robots.txt-Regeln in aller Regel. Meta sagt dasselbe über meta-externalfetcher. Fragt also ein Mensch ein KI-System nach deiner Seite, wird sie geladen, egal was in deiner Datei steht. Anthropic macht bei Claude-User die Ausnahme und hält sich nach eigener Angabe auch dort an die robots.txt.

Eine Kennung lässt sich fälschen. Der User-Agent ist ein frei wählbarer Text im Anfrage-Header. Eine .htaccess-Regel, die nur auf diesen Text hört, sperrt genau die Bots aus, die sich korrekt zu erkennen geben, und lässt jeden ernsthaften Scraper durch. Wer serverseitig sperren will, muss die IP gegen die veröffentlichten Bereiche prüfen.

Andere sperren für dich, ohne dass du es merkst. Cloudflare hat am 1. Juli 2025 angekündigt, KI-Crawler für neue Domains standardmäßig zu blockieren. Dazu kommen Schutzmechanismen, die bei hoher Abrufrate mit einem 429 antworten, und Hoster, die auf Infrastrukturebene filtern. Das Ergebnis ist ein Widerspruch, den niemand im Quelltext sieht: In der robots.txt steht Allow, an der Tür steht ein Fehlercode.

Cloudflare nennt zur Begründung ein Verhältnis, das die Debatte gut erklärt. Um von OpenAI so viel Zugriff zu bekommen wie früher von Google, brauche es rund das 750-fache an Crawl-Vorgängen, bei Anthropic das 30.000-fache. KI-Systeme lesen also sehr viel und schicken sehr wenig zurück. Wer daraus ableitet, dass sich Zulassen nicht lohnt, verwechselt allerdings zwei Größen: Der Wert einer Nennung in einer KI-Antwort liegt in der Vorauswahl, nicht im Klick. Genau deshalb ist Sichtbarkeit in KI-Systemen schlecht über Besucherzahlen zu bewerten.

Der Vollständigkeit halber gehört hier auch das Recht hin. In Deutschland regelt Paragraf 44b UrhG das Text und Data Mining. Absatz 3 sagt, dass ein Nutzungsvorbehalt bei online zugänglichen Werken „nur dann wirksam“ ist, „wenn er in maschinenlesbarer Form erfolgt“. Die robots.txt ist damit mehr als eine Bitte. Sie ist der praktisch gängigste Weg, diesen Vorbehalt überhaupt formwirksam zu erklären. Ob eine einzelne Sperre im Streitfall trägt, ist eine Rechtsfrage und keine SEO-Frage. Dass ohne maschinenlesbaren Vorbehalt aber gar nichts vorbehalten ist, steht im Gesetz.

Aussperren oder zulassen: die Abwägung, die wirklich zählt

Wir verkaufen Sichtbarkeit in KI-Antworten, deshalb die Offenlegung vorweg: Wir haben ein Interesse daran, dass Unternehmen Such-Crawler zulassen. Das ändert nichts daran, dass es Fälle gibt, in denen eine Sperre richtig ist. Die Entscheidung hängt an einer einzigen Frage.

Ist dein Inhalt das Produkt oder die Werbung für das Produkt?

Wenn Menschen für deine Texte bezahlen, weil die Texte selbst der Wert sind, dann kostet dich jede Übernahme in eine KI-Antwort Umsatz. Das gilt für Fachverlage, Kursanbieter, Datenbanken, Bildarchive und Redaktionen mit Bezahlschranke. Hier ist eine Trainings-Sperre die naheliegende Entscheidung, häufig auch eine Sperre des Suchindex.

Wenn deine Texte dagegen erklären, was du verkaufst, ist die Rechnung umgekehrt. Eine Leistungsseite, ein Ratgeber oder ein Glossar hat genau einen Zweck: gefunden und verstanden zu werden. Wer hier sperrt, verliert die Nennung bei genau den Fragen, bei denen ein Mensch nach einem Anbieter sucht, und schützt dafür Texte, die ohnehin verschenkt sind. Das trifft auf die meisten Unternehmen mit erklärungsbedürftiger Leistung zu.

Der Mittelweg, den wir in den meisten Fällen empfehlen

Trainings-Crawler sperren, Such-Crawler zulassen. Damit behältst du die Nennung samt Verweis und erklärst gleichzeitig den Nutzungsvorbehalt nach Paragraf 44b. Der Preis dieser Variante gehört ehrlich dazu: Wenn ein Modell deine Marke nicht aus dem Training kennt, wirst du seltener genannt, sobald gerade keine Websuche läuft. Für Marken mit wenig Bekanntheit kann es deshalb sinnvoll sein, das Training bewusst mitzunehmen. Wie sich das eine vom anderen unterscheidet, zeigt der Vergleich zwischen GEO und SEO.

Eine dritte Variante wird selten genannt und passt oft am besten: nicht alles oder nichts, sondern pro Verzeichnis entscheiden. Der Ratgeberbereich bleibt offen, der Mitgliederbereich, der Download-Ordner oder das Archiv mit bezahlten Inhalten wird gesperrt. Weil die längere Regel gewinnt, lässt sich das in derselben Gruppe sauber abbilden.

Was bei der Entscheidung keine Rolle spielen sollte

Serverlast ist fast nie das ausschlaggebende Argument. Wenn ein Bot wirklich zu viel abruft, ist die richtige Antwort eine Crawl-delay-Angabe oder eine Ratenbegrenzung, nicht eine Totalsperre. Anthropic unterstützt Crawl-delay ausdrücklich und nennt es in der eigenen Dokumentation. Und was durch häufiges Crawlen an Budget verbraucht wird, betrifft das Crawl-Budget sehr großer Seiten, nicht die typische Unternehmenswebsite mit ein paar hundert Adressen.

Ebenso wenig taugt das Argument „die anderen machen es auch“. Was für einen Verlag richtig ist, ist für einen Maschinenbauer falsch, und umgekehrt. Die Kennungen sind bei allen gleich, die Entscheidung ist es nicht.

Unser eigener Stand, offengelegt

Wer Empfehlungen ausspricht, sollte sagen, was er selbst macht. Unsere robots.txt ist absichtlich kurz. Sie sperrt eine einzige Sache, nämlich die paginierten Archivseiten unter /page/*, und verweist auf die Sitemap. Kein einziger KI-Crawler ist bei uns gesperrt, weder fürs Training noch für den Suchindex. Das ist eine Entscheidung und keine Nachlässigkeit: Unsere Texte sind die Werbung für unsere Leistung, nicht die Leistung selbst.

Die zweite Hälfte ist das positive Gegenstück. Unter taismo.de/llms.txt liegt ein Briefing-Dokument für Sprachmodelle, das wir redaktionell pflegen: derzeit 19.136 Zeichen mit 94 kommentierten Verweisen, zweisprachig in einer Datei. Es sagt einem Modell in geordneter Form, wer wir sind, was davon belegt ist und welche Seite welche Frage beantwortet. Was das Format kann und was nicht, steht im Glossareintrag zur llms.txt; den Weg vom Entwurf bis zum Livegang beschreibt der Praxis-Guide.

Zwei Betriebserfahrungen daraus, die man so nirgends nachlesen kann.

Erstens: Die Datei ist statisch und gehört deshalb in einen Ausrollweg mit Sicherung, Funktionsprüfung und Rücknahme. Wir spielen sie per Skript ein, das vorher den Live-Stand sichert, nach dem Upload den Abruf prüft und bei einem Fehler automatisch zurückrollt. Eine per Hand hochgeladene Textdatei im Web-Root ist der klassische Weg, sich unbemerkt etwas kaputtzumachen. Dazu ein Detail, das uns eine Fehldiagnose gekostet hat: Vergleicht man die lokale Fassung mit der Live-Fassung, muss man die Zeilenenden erhalten. Sonst meldet der Prüfvergleich eine Abweichung, die es gar nicht gibt.

Zweitens, und das tut genau einmal weh: Wir wollten eine eigene llms.txt für die englische Sprachversion anlegen. Das hätte die englische Startseite lahmgelegt. Der Grund ist unscheinbar. Die Sprachroute ist im Mehrsprachensystem ein Umschreibe-Pfad und kein echtes Verzeichnis, und die Umschreibe-Regel greift nur, solange kein realer Ordner existiert. Legt man die Datei als en/llms.txt ab, entsteht dieser Ordner wirklich, die Bedingung fällt weg, und die Anfrage erreicht das Content-Management-System nicht mehr. Die saubere Lösung ist eine virtuelle Route im Code, nie eine Datei.

Und eine Einordnung, die ehrlich sein muss: Die llms.txt ist kein Steuerungsinstrument. Sie wurde im September 2024 von Jeremy Howard vorgeschlagen, ist aber kein Standard, dessen Beachtung ein Anbieter zusagt. Sie ersetzt weder die robots.txt noch strukturierte Daten. Sie ist ein Angebot, kein Schalter.

Die Gegenprobe: woran du siehst, dass deine Einstellung wirkt

Der häufigste Zustand in der Praxis ist nicht die falsche Entscheidung, sondern die unbemerkte. In der robots.txt steht das eine, an der Serverwand passiert das andere. Vier Schritte klären das in einer Viertelstunde.

1. Ruf deine robots.txt selbst ab und prüfe den Statuscode. Erwartet wird 200. Ein 5xx ist ein Notfall, ein 404 bedeutet, dass überhaupt keine Regeln gelten.

2. Frag deine Seite einmal als Bot. Genau hier trennt sich, was du eingestellt hast, von dem, was tatsächlich ankommt. Der Aufruf mit gesetzter Kennung zeigt den echten Statuscode:

curl -sI -A "GPTBot" https://deine-domain.de/
curl -sI -A "OAI-SearchBot" https://deine-domain.de/
curl -sI -A "ClaudeBot" https://deine-domain.de/
curl -sI -A "PerplexityBot" https://deine-domain.de/

Kommt hier ein 403, ein 429 oder eine Weiterleitung auf eine Prüfseite, dann sperrt eine Firewall, ein Schutzdienst oder dein Hoster. Diese Sperre steht in keiner robots.txt und fällt bei keinem gewöhnlichen Crawl auf, weil dabei niemand als Bot fragt.

3. Sieh in die Zugriffsprotokolle. Leg eine eigene Auswertung nach User-Agent an und beobachte über vier Wochen, welche Kennungen wie oft kommen und welchen Statuscode sie bekommen. Eine Sperre, die du gesetzt hast, muss sich dort als 403 zeigen. Tut sie das nicht, greift sie nicht. Und ein Bot, der überwiegend 404 sieht, hat kein Zugriffsproblem, sondern ein Strukturproblem.

4. Prüfe auffällige Zugriffe gegen die IP-Listen. Wenn eine Kennung ungewöhnlich oft kommt, gleiche die IP gegen die veröffentlichte JSON-Datei des Anbieters ab. Steht sie nicht darin, ist es kein Bot dieses Anbieters, sondern jemand, der sich so nennt. Diese Unterscheidung entscheidet darüber, ob du eine Kennung sperrst oder eine einzelne Adresse.

Fünf Fehler, die uns regelmäßig begegnen

Die folgenden fünf sehen wir in Audits immer wieder, quer durch Branchen und Systeme.

• Alles gesperrt, weil eine Vorlage es so vorschlug. Fertige Bot-Blocklisten aus dem Netz sind meist von Publishern für Publisher geschrieben. Übernimmt sie ein Dienstleister, der gefunden werden will, kostet ihn das genau die Sichtbarkeit, für die er anderswo zahlt.
• Disallow und noindex gleichzeitig. Die Seite bleibt im Index, nur ohne Snippet. Gewollt war das Gegenteil.
• Eine neue Bot-Gruppe hebt die Sternchen-Regel auf. Weil nur eine Gruppe gilt, verliert ein Bot mit eigener Gruppe alle allgemeinen Sperren. Wer /intern/ unter User-agent: * sperrt und später eine GPTBot-Gruppe ergänzt, hat /intern/ für GPTBot geöffnet.
• Serverseitige Sperre ohne IP-Prüfung. Eine Regel, die nur auf den User-Agent-Text hört, trifft die ehrlichen Bots und verfehlt alle anderen.
• Die Datei ist von 2023 und niemand schaut hin. Das Feld verändert sich quartalsweise. OAI-SearchBot, Claude-SearchBot, meta-webindexer und OAI-AdsBot existierten beim Start der Debatte noch gar nicht. Eine robots.txt gehört einmal im Quartal auf den Tisch, zusammen mit dem Blick in die Protokolle.

Keiner dieser fünf Fehler ist teuer zu beheben. Teuer ist, dass sie unbemerkt bleiben, weil niemand die Datei liest, nachdem sie einmal angelegt wurde. Genau deshalb steht die Gegenprobe oben als eigener Arbeitsschritt und nicht als Nebensatz. Wer das nicht selbst im Blick behalten will, hängt den Quartalscheck an die laufende SEO-Betreuung, dort gehört er ohnehin hin.

Häufige Fragen zu KI-Crawlern und der robots.txt

Halten sich KI-Crawler an die robots.txt?

Die Trainings- und Suchindex-Crawler der großen Anbieter geben an, sich daran zu halten, und veröffentlichen dafür ihre Kennungen und IP-Bereiche. Anders ist es bei den Bots, die eine Seite abrufen, weil ein Mensch gerade danach gefragt hat: Mehrere Anbieter schreiben ausdrücklich, dass die robots.txt für diesen Fall nicht gilt. Und Bots, die sich gar nicht zu erkennen geben, halten sich ohnehin an nichts. Die robots.txt regelt also die kooperativen Zugriffe, nicht alle.

Verliere ich Sichtbarkeit in KI-Antworten, wenn ich den Trainings-Crawler sperre?

Nicht unmittelbar. Training und Suchindex sind getrennte Kennungen und damit getrennte Schalter. Wer nur den Trainings-Crawler sperrt, wird weiterhin zitiert, sobald das System live sucht. Mittelbar gibt es aber einen Effekt: Kennt ein Modell eine Marke nicht aus dem Training, wird sie seltener genannt, wenn gerade keine Websuche läuft. Für wenig bekannte Marken ist das ein Argument, das Training bewusst zuzulassen.

Reicht eine llms.txt aus, um KI-Crawler zu steuern?

Nein. Die llms.txt ist ein freiwilliges Briefing-Dokument und kein Steuerungsinstrument. Sie sagt einem Modell, was auf einer Website wichtig ist, aber sie erlaubt oder verbietet nichts, und kein Anbieter sagt zu, dass er sie auswertet. Zugriff regelt ausschließlich die robots.txt beziehungsweise die Serverebene. Beides ergänzt sich, ersetzt sich aber nicht.

Wie erkenne ich gefälschte KI-Crawler?

Über die IP-Adresse, nie über den Namen. Die großen Anbieter veröffentlichen die IP-Bereiche ihrer Crawler als JSON-Datei zum Abgleich. Taucht eine Kennung aus einem Bereich auf, der dort nicht gelistet ist, gibt sich jemand nur so aus. Deshalb sind serverseitige Sperren, die allein auf den User-Agent-Text hören, wirkungslos gegen Scraper und zugleich schädlich gegenüber echten Crawlern.

Verhindert eine Disallow-Regel, dass eine Seite im Index auftaucht?

Nein. Eine Disallow-Regel verhindert das Lesen des Inhalts, nicht die Aufnahme der Adresse. Ist die Seite von außen verlinkt, kann sie ohne Beschreibungstext im Index landen. Wer eine Seite wirklich heraushalten will, setzt ein noindex im Meta-Tag oder im HTTP-Header und lässt die Seite crawlbar, damit diese Anweisung überhaupt gelesen werden kann.

Quellen

• OpenAI: „Overview of OpenAI crawlers“, OpenAI Developer Documentation, abgerufen am 18.09.2026.
• Anthropic: „Does Anthropic crawl data from the web, and how can site owners block the crawler?“, Anthropic Support, abgerufen am 18.09.2026.
• Google: „Google-Crawler und -Fetcher: Übersicht“, Google Search Central, abgerufen am 18.09.2026.
• Google: „robots.txt-Spezifikationen“, Google Search Central, abgerufen am 18.09.2026.
• Perplexity: „PerplexityBot“, Perplexity Documentation, abgerufen am 18.09.2026.
• Meta: „Web crawlers“, Meta for Developers, abgerufen am 18.09.2026.
• Apple: „About Applebot“, Apple Support, abgerufen am 18.09.2026.
• Common Crawl Foundation: „CCBot“, Common Crawl, abgerufen am 18.09.2026.
• Bundesamt für Justiz: „§ 44b UrhG: Text und Data Mining“, Gesetze im Internet, abgerufen am 18.09.2026.
• Matthew Prince: „Content Independence Day: no AI crawl without compensation“, The Cloudflare Blog, 01.07.2025.
• Jeremy Howard: „The /llms.txt file“, llmstxt.org, abgerufen am 18.09.2026.
• OpenAI: „IP-Bereiche des GPTBot (JSON)“, OpenAI, abgerufen am 18.09.2026.
• Anthropic: „IP-Bereiche der Anthropic-Crawler (JSON)“, Anthropic, abgerufen am 18.09.2026.