LW IT Solutions
« Blog-Übersicht /Digital Marketing / robots.txt für Such-, Trainings- und Assistenten-Crawler: Was...
Diesen Artikel in anderen Sprachen lesen:

robots.txt für Such-, Trainings- und Assistenten-Crawler: Was jede Sperre bewirkt

robots.txt für Such-, Trainings- und Assistenten-Crawler: Was jede Sperre bewirkt
Inhalt
  1. Drei Arten, die verschiedene Arbeit tun
  2. Was jede Sperre verhindert und kostet
  3. Google-Extended ist nicht Googlebot
  4. Rückwirkend geht nichts
  5. llms.txt: eine Karte, keine Regel
  6. Was robots.txt nicht leistet
  7. Drei Einzelheiten hinter den Namen
  8. Fragen und Antworten
  9. Quellen

Eine Datei, drei Leserschaften, die nichts miteinander zu tun haben. Ein Suchcrawler holt eine Seite, damit sie gefunden wird; ein Trainingscrawler holt sie, damit daraus ein Modell entsteht; ein Assistent holt sie, weil vor einer Minute jemand eine Frage gestellt hat. Auseinanderhalten lassen sich die drei allein an dem Namen, mit dem sie sich melden, und eine Sperre für den einen sagt nichts über die anderen.

Deshalb ist die übliche Anweisung – die KI-Crawler sperren – keine Entscheidung, sondern drei, und zwei davon kosten etwas, das beim Hinzufügen der Zeile selten dazugesagt wird.

Drei Entscheidungen für drei Arten von Crawlern - Suche, Training und Assistenten - je mit den zugehörigen Kennungen und damit, was eine Sperre verhindert und was sie kostet
Drei Entscheidungen in der robots.txt. Nur die mittlere ist ohne Folgen für die Sichtbarkeit.

Drei Arten, die verschiedene Arbeit tun

Suchcrawler – Googlebot, Bingbot und der Rest – bauen den Index, aus dem gewöhnliche Ergebnisse stammen. Eine Sperre nimmt die Seite binnen Wochen aus der Suche, weshalb es niemand absichtlich tut und weshalb es aus Versehen geschieht: ein Disallow: / aus der Testumgebung, das den Umzug überlebt hat.

Trainingscrawler – GPTBot, Google-Extended, ClaudeBot, CCBot und andere – sammeln Material, aus dem Modelle entstehen. Sie holen einmal und lesen alles; nichts davon kommt als Besuch zurück.

Assistenten-Crawler – OAI-SearchBot, ChatGPT-User, PerplexityBot – holen eine Seite, weil gerade eine Frage beantwortet wird. Was sie holen, kommt oft zurück: als Quellenangabe, als Verweis, als jener Satz, den jemand statt des Suchergebnisses liest.

Was jede Sperre verhindert und kostet

Gesperrt wird Verhindert Kostet
Suche Nichts, was zu verhindern wäre. Die Seite verschwindet aus Google und Bing.
Training Dass neues Material ins nächste Modell gelangt. Nichts Messbares – weder Platzierung noch Sichtbarkeit.
Assistenten Dass die Seite in einer Antwort zitiert wird. Genau diese Sichtbarkeit – die Nennung und den Verweis dazu.

Die mittlere Zeile ist die, über die sich aus Grundsatz entscheiden lässt, ohne dafür zu bezahlen. Die untere ist die, über die aus Versehen entschieden wird, weil die Kennungen in jeder herumgereichten Liste direkt neben denen fürs Training stehen.

Google-Extended ist nicht Googlebot

Die Unterscheidung, die das meiste Zögern verursacht: Google-Extended regelt, ob Inhalte für das Training von Gemini und der Vertex-Modelle sowie für das Grounding in den Gemini-Apps und bei Grounding with Google Search auf Vertex AI verwendet werden. Auf das Erfassen für die Suche, auf die Indexierung und auf die Platzierung wirkt sie nicht. Eine Sperre ändert nichts daran, wie eine Seite bei Google abschneidet, und das ist keine Behauptung, die Vertrauen verlangt – dafür ist die Kennung da.

Dieselbe Trennung zieht sich durch die anderen Anbieter. GPTBot ist Training; OAI-SearchBot speist den Suchindex hinter dem Assistenten; ChatGPT-User ist der Abruf, der geschieht, wenn ein Mensch fragt. Alle drei zu sperren, weil die Namen ähnlich aussehen, ist der häufigste Weg, auf dem eine Seite stillschweigend aus den Antworten verschwindet, in denen sie stehen wollte.

Rückwirkend geht nichts

Eine Sperre gilt ab dem Augenblick, in dem sie gelesen wird. Was bereits geholt wurde, sitzt in Sammlungen, die daraus entstanden sind, und die schauen nicht noch einmal in die robots.txt. Eine Seite, die seit Jahren online ist und heute die Zeilen ergänzt, hat über künftige Abrufe entschieden und nicht über vergangene.

Das gehört deutlich gesagt, weil die Entscheidung oft als Entfernen dargestellt wird. Sie ist kein Entfernen, sondern ein Zaun um das, was noch nicht geholt wurde.

llms.txt: eine Karte, keine Regel

Die Datei unter /llms.txt ist in ihrer Absicht das Gegenteil der robots.txt: sie verbietet nicht, sie weist hin. Ein kurzes Markdown-Dokument, das benennt, worum es auf der Seite geht und welche Seiten den Gehalt tragen – ein Inhaltsverzeichnis für etwas, das ohne Navigation gelesen wird.

Zwei Dinge gehören dazu klargestellt. Es ist ein Vorschlag und kein Standard, und kein Crawler ist verpflichtet, danach zu suchen. Und es beschränkt nichts: eine dort aufgeführte Seite ist damit nicht erlaubt, und eine fehlende ist damit nicht geschützt. Das Schreiben kostet zehn Minuten und ist genau so viel wert wie ein gutes Inhaltsverzeichnis – nämlich gar nichts, wenn die Seiten dahinter dünn sind.

Was robots.txt nicht leistet

Sie ist eine Bitte und kein Schloss. Jeder Crawler entscheidet selbst, ob er sich daran hält, und jene, die es tun, sind genau die, die eine Kennung veröffentlichen, unter der sich eine Sperre setzen lässt. Was die Datei ignoriert, ist von nichts darin betroffen.

Und sie hält eine Seite nicht aus den Suchergebnissen heraus. Eine gesperrte Seite, auf die andere verweisen, kann trotzdem erscheinen, nur ohne Beschreibung, weil der Crawler nicht lesen durfte, was darauf steht. Etwas aus dem Index zu halten verlangt ein noindex – wofür der Crawler hineindürfen muss, um es zu lesen – und etwas privat zu halten verlangt eine Anmeldung. Die robots.txt steht unterhalb von beidem und taugt gut für genau das, was sie ist: Verkehrsführung für die Crawler, die sich führen lassen.

Drei Einzelheiten hinter den Namen

Google-Extended lässt sich am Server nicht sperren

Google-Extended hat keine eigene User-Agent-Kennung. Googles Crawler-Dokumentation hält fest, dass mit den vorhandenen Google-User-Agents gecrawlt wird und die Kennung in der robots.txt allein der Steuerung dient. Unter diesem Namen kommt nie eine Anfrage an. Eine Firewall- oder Serverregel darauf greift also ins Leere, und eine Regel gegen den Abrufer, der tatsächlich holt, also Googlebot, nimmt die Seite aus der Suche. Für Googles Frage nach Training und Grounding bleibt der Eintrag in der robots.txt der einzige Hebel.

CCBot speist ein öffentliches Archiv

CCBot ist der Crawler von Common Crawl. Er meldet sich als CCBot/2.0 und befolgt die robots.txt. Die Crawl-Daten liegen auf Amazon S3 und werden als offener Datensatz mit so wenigen Einschränkungen wie möglich veröffentlicht. Was CCBot holt, bleibt deshalb nicht bei einem einzelnen Modellanbieter, sondern steht allen offen, die das Archiv herunterladen. Eine Sperre für die Trainingscrawler einzelner Anbieter bei offenem CCBot lässt diesen Umweg bestehen.

Ein doppelt genannter Name wird zusammengeführt, nicht ausgelost

Dateien, die über Jahre wachsen, nennen denselben Crawler mitunter in zwei Gruppen. RFC 9309 regelt diesen Fall: Crawler vergleichen den Namen ohne Rücksicht auf Groß- und Kleinschreibung, und passt mehr als eine Gruppe, werden deren Regeln zu einer einzigen Gruppe zusammengeführt. Innerhalb dieser Gruppe entscheidet wie in jeder anderen die längste passende Regel. Zwei Gruppen für GPTBot, die eine mit Disallow: /, die andere mit Allow: /blog/, lassen /blog/ deshalb offen. Beim Ergänzen der Sperrgruppe war das womöglich nicht beabsichtigt. Eine Suche nach jedem Crawler-Namen in der Datei zeigt solche Doppelungen in Sekunden.

Fragen und Antworten

Gilt eine Regel unter User-agent: * auch für einen Crawler, der in der Datei eine eigene Gruppe hat?

Nein, und genau daran scheitert das Ergänzen der KI-Kennungen leicht. Nach RFC 9309 folgt ein Crawler der Gruppe, die seinen Namen trägt, und nur wenn es keine solche Gruppe gibt, der Gruppe unter User-agent: *. Zusammengelegt werden die beiden nicht. Eine eigene Gruppe für OAI-SearchBot mit Allow: /, die die Assistenten ausdrücklich zulassen soll, hebt für diesen Crawler deshalb auch jede Sperre auf, die unter * steht, etwa die für den Verwaltungsbereich.

Regeln, die für alle gelten sollen, müssen daher in jeder benannten Gruppe wiederholt werden. Innerhalb einer Gruppe entscheidet dann die längste passende Regel, und bei Gleichstand soll nach dem RFC Allow gewinnen. So lässt sich eine Seite bis auf ein Verzeichnis sperren, ohne jeden Pfad einzeln aufzuzählen.

Woran lässt sich erkennen, ob ein Abruf wirklich von Googlebot oder ChatGPT-User stammt und nicht nur so heißt?

Am Namen nicht, denn die Kennung im User-Agent kann jeder Absender frei wählen. Belastbar ist erst die Herkunft der Anfrage, und dafür gibt es zwei Wege:

  1. Rückwärts- und Vorwärtsauflösung. Zur IP-Adresse wird der Hostname abgefragt; bei Google-Crawlern endet er auf googlebot.com, google.com oder googleusercontent.com. Danach muss derselbe Hostname wieder auf dieselbe Adresse auflösen, sonst ist der Eintrag gefälscht. Dieses Verfahren beschreibt Google selbst.
  2. Veröffentlichte Adressbereiche. Mehrere Anbieter, darunter Google und OpenAI, veröffentlichen die IP-Bereiche ihrer Crawler als maschinenlesbare Listen, getrennt nach Art des Crawlers. Der Abgleich damit lässt sich automatisieren und kommt ohne DNS-Abfrage je Anfrage aus.

Für die robots.txt spielt das keine Rolle: Ein Abruf, der sich als Googlebot ausgibt und die Datei ignoriert, ist ohnehin von nichts darin betroffen. Wichtig wird die Prüfung, sobald eine Sperre auf dem Server durchgesetzt werden soll, etwa in der Firewall. Dann gehört sie vor jede Regel, die nach dem Namen entscheidet, damit eine Ausnahme für echte Suchcrawler nicht jedem offensteht, der sich so nennt.

Was geschieht, wenn die robots.txt selbst nicht erreichbar ist oder einen Fehler liefert?

Das hängt am Statuscode, und die beiden Fälle wirken entgegengesetzt. Nach RFC 9309 gilt eine Antwort im Bereich 400 bis 499 als fehlende Datei: Der Crawler darf alles abrufen. Ein Serverfehler im Bereich 500 bis 599 oder ein Netzwerkfehler gilt dagegen als vollständige Sperre; erst wenn der Zustand lange anhält, der RFC nennt als Beispiel 30 Tage, darf der Crawler auf eine zwischengespeicherte Fassung ausweichen oder die Datei als fehlend behandeln.

Daraus folgen zwei Fallen im übrigen Aufbau. Eine Regel in der Serverkonfiguration, die versehentlich auch die robots.txt erfasst und dort mit 403, 404 oder 410 antwortet, hebt jede Sperre der Datei auf. Ein überlasteter Server, der die robots.txt mit 503 beantwortet, hält dagegen auch die Suchcrawler fern. Außerdem wirkt jede Änderung erst, wenn der Crawler die Datei neu holt; der RFC empfiehlt, eine zwischengespeicherte Fassung nicht länger als 24 Stunden zu verwenden.

Wirkt eine Sperre für Google-Extended auch auf die KI-Übersichten in der Google-Suche?

Nein. KI-Übersichten gehören zur Suche und stützen sich auf das, was Googlebot erfasst hat, und darauf wirkt Google-Extended nicht. Wie viel einer Seite dort erscheint, lässt sich nur über die Snippet-Steuerung wie nosnippet oder max-snippet begrenzen oder mit noindex ganz verhindern, und beides wirkt dann auch auf das gewöhnliche Suchergebnis.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Kommentar schreiben

Erfahrungen aus der Praxis und Rückfragen zur Umsetzung sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.

Artikel & Kategorien

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Alle 17 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Data Privacy

Alle 19 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Analytics

Alle 58 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Marketing

Alle 37 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

IT & Networks

Alle 18 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Music Production

Alle 17 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

SaaS & Internet Earning

Diese Rubrik per RSS verfolgen

Smart Home

Alle 18 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Web Entwicklung

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

WordPress-Plugins & Tricks

Alle 14 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen