Unser Vorbehalt gegen KI-Training war an niemanden adressiert. Die Zeile Content-Signal: search=yes, ai-input=yes, ai-train=no stand in der Datei robots.txt von wppoland.com genau einmal, in der Gruppe User-agent: *, und darunter lagen zwanzig benannte Crawler-Gruppen. Nach RFC 9309 erbt keine dieser zwanzig Gruppen irgendetwas aus der Sternchen-Gruppe. GPTBot, ClaudeBot, PerplexityBot, Google-Extended und der Rest der Liste lasen ausschließlich ihre eigenen Abschnitte, und dort stand diese Zeile nicht.
Wir schreiben darüber, weil es unsere Datei und unser Fehler ist. Wir haben die robots.txt immer daraufhin geprüft, ob sie versehentlich etwas blockiert, und nie daraufhin, ob die Erklärung ihren Empfänger überhaupt erreicht.
Was genau in der Datei stand
Der Aufbau sah so aus, wie er in den meisten Dateien aussieht, die uns begegnet sind: eine allgemeine Gruppe oben, darunter eine Liste benannter Bots mit erweiterten Allow-Regeln für maschinenlesbare Endpunkte.
User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Disallow: /cdn-cgi/
Sitemap: https://wppoland.com/sitemap-index.xml
Agentmap: https://wppoland.com/.well-known/ai-catalog.json
User-agent: GPTBot
Allow: /
Allow: /llms.txt
Allow: /facts.json
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /Das wirkt sauber. Das Signal ist da, die benannten Gruppen sind da, die Endpunkte für Agenten sind separat aufgeführt. Das Problem ist, dass diese beiden Teile keinen Kontakt zueinander haben.
Warum eine Zeile nicht die ganze Datei abdeckt
RFC 9309 beschreibt das Gruppen-Matching auf eine Weise, die sich selbstverständlich liest, solange man sie nicht neben die eigene Datei legt. Der Client vergleicht sein Product Token mit den Namen in den User-agent-Zeilen, ohne auf Groß- und Kleinschreibung zu achten, und wendet eine Gruppe an: die, die ihn nennt. Der Stern ist nicht das unspezifischste Muster, sondern der Rückfall, und RFC 9309 greift nur dann darauf zurück, wenn keine Gruppe den Client beim Namen nennt. Das Sternchen ist das unspezifischste Muster, es verliert also gegen jede benannte Gruppe. Existiert eine benannte Gruppe, wendet der Client ausschließlich deren Direktiven an, und die Sternchen-Gruppe betrifft ihn komplett nicht mehr.
Das ist keine Ausnahme für Content Signals. Dieselbe Regel gilt seit jeher für Allow und Disallow, und genau deshalb schützt eine Datei, in der jemand Disallow: /wp-admin/ nur in die Sternchen-Gruppe geschrieben hat, gar nichts vor einem Bot, der weiter unten seinen eigenen Abschnitt hat. Der Unterschied: bei Disallow sieht man die Folge. Die Seite taucht im Index auf oder eben nicht. Bei Content-Signal sieht man nichts. Eine Rechteerklärung hat keine Rückkopplung, sie kann also monatelang falsch sein und dabei exakt so aussehen wie eine korrekte.
Content Signals ist ein Vorschlag von Cloudflare und nicht Teil von RFC 9309. Cloudflare aktiviert diese Richtlinie in seiner verwalteten robots.txt standardmäßig. Aber der Gruppenmechanismus, in dem diese Zeile wohnt, stammt vollständig aus RFC 9309, also gilt die Ein-Gruppen-Regel für sie genauso wie für alles andere in dieser Datei. Eine neue Direktive im alten Container erbt die Regeln des Containers.
Drei Signale und das, was sie nicht versprechen
Die Spezifikation definiert drei Signale, jeweils mit dem Wert yes oder no:
| Signal | Worum es geht |
|---|---|
search | Aufbau eines Suchindex und Ausliefern von Ergebnissen, also Links und kurze Textausschnitte |
ai-input | Zuführen von Inhalten an ein KI-Modell während der Antwort, also RAG und Grounding |
ai-train | Training und Feintuning von Modellen |
Unsere Kombination search=yes, ai-input=yes, ai-train=no ist eine bewusste Entscheidung. Wir wollen in generativen Antworten zitiert werden, weil das heute einer der Kanäle ist, über die uns jemand findet, und wir wollen unseren Korpus nicht fürs Training hergeben. Ein fehlendes Signal bedeutet etwas Drittes als no: der Betreiber erteilt auf diesem Weg weder Zustimmung noch Absage.
Keines dieser Signale blockiert irgendetwas. Es ist eine Textzeile in einer Datei, die ein Client abrufen kann oder nicht, lesen kann oder nicht und respektieren kann oder nicht. Der Server beantwortet die Anfrage unabhängig davon, was in dieser Datei steht. Blockieren ist eine eigene Schicht, ausgewertet vor der Anwendung, und sie entsteht aus WAF-Regeln, Rate Limits oder der Verifikation der Bot-Identität, nicht aus einer Textdatei. Ein Signal ist genau so viel wert wie eine eindeutige Nachricht an die richtige Adresse. Unsere war eindeutig und ging an die falsche.
Prüfen Sie Ihre eigene Datei mit einem Kommando
Das dauert ein paar Sekunden und funktioniert auf jeder Domain:
curl -s https://ihre-domain.de/robots.txt \
| awk 'tolower($0) ~ /^user-agent:/ {ua++} tolower($0) ~ /^content-signal:/ {cs++} END {print "User-agent-Gruppen: " ua "\nContent-Signal-Zeilen: " cs}'Ist die Zahl der Gruppen größer als die Zahl der Signale, sagt die Differenz, wie viele Gruppen Ihren Vorbehalt nicht sehen. Bei uns lautete das Ergebnis einundzwanzig zu eins.
Die genauere Variante gibt die Namen der Gruppen aus, in denen das Signal fehlt:
curl -s https://ihre-domain.de/robots.txt \
| awk '/^[Uu]ser-agent:/ {if (name != "" && !sig) print "kein Signal: " name; name=$2; sig=0} /^[Cc]ontent-[Ss]ignal:/ {sig=1} END {if (name != "" && !sig) print "kein Signal: " name}'Das zweite Kommando gehört in die Pipeline, denn seine Ausgabe ist eine Liste zum Abarbeiten und keine Zahl zum Interpretieren.
Wie man es repariert
Die Korrektur ist langweilig: die Zeile Content-Signal in jeder Gruppe wiederholen, für die sie gelten soll. Es gibt keine Abkürzung, keine Kurzform und keine Vererbung, die man einschalten könnte.
User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Disallow: /cdn-cgi/
User-agent: GPTBot
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Allow: /llms.txt
Allow: /facts.json
User-agent: ClaudeBot
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
User-agent: PerplexityBot
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /In unserem Repository ist diese Änderung noch nicht umgesetzt. Der Beitrag entstand im Moment des Fundes und nicht nach dem Schließen des Fehlers, und so ist er zu lesen.
Bei der Korrektur ist eine Sache zu entscheiden, die eine Datei mit wiederholter Zeile nicht von selbst entscheidet: ob derselbe Signalsatz zu jeder Gruppe passt. Für einen indexierenden Crawler und für einen Crawler, der Trainingskorpus sammelt, fällt die Antwort unterschiedlich aus, und eine Datei mit zwanzig identischen Zeilen legt nahe, dass niemand darüber nachgedacht hat. Eine Gruppe, in der search=yes keinen Sinn ergibt, weil der Client keinen Index baut, braucht ihren eigenen Eintrag.
Das Zweite, was uns fehlte: Gruppen für einzelne Rollen
Beim selben Lesen der Datei kam heraus, dass wir nur die Gruppe ClaudeBot hatten und die beiden anderen nicht: Claude-User für vom Nutzer ausgelöste Abrufe und Claude-SearchBot für das Grounding der Suche. Das sind drei verschiedene Rollen und drei verschiedene Absichten auf der Clientseite. Ein Bot, der eine Seite abruft, weil ein Mensch gerade deren Adresse in ein Gespräch geklebt hat, tut etwas anderes als ein Bot, der einen Korpus aufbaut, und es ist sinnvoll, ihm etwas anderes zu antworten.
Die Folge der fehlenden Gruppen ist dieselbe wie oben, nur von der anderen Seite: ein Client ohne eigenen Abschnitt fällt auf die Sternchen-Gruppe zurück. In unserem Fall hieß das ausgerechnet, dass Claude-User das korrekte Signal sah, weil es im Sternchen stand. In einer Datei, in der das Signal zwanzig benannte Bots nicht erreichte, erreichte es also die unbenannten. Genau umgekehrt zur Absicht.
Warum dieser Fehler eine Durchsicht so leicht übersteht
Drei Gründe, alle strukturell, keiner davon Unaufmerksamkeit.
Eine robots.txt liest man von oben nach unten, und der allgemeine Abschnitt wirkt übergeordnet. Etwas dort hineinzuschreiben weckt die Intuition aus CSS oder aus Serverkonfigurationen, wo die allgemeine Einstellung der Default ist und die spezifische sie überschreibt. In RFC 9309 gibt es kein Überschreiben. Es gibt die Wahl einer Gruppe und das Verwerfen des restlichen Dateiinhalts.
Zweiter Grund: es gibt kein Werkzeug, das das meldet. robots.txt-Tester prüfen, ob eine bestimmte Adresse für einen bestimmten Bot erlaubt ist, und von Content-Signal wissen sie nichts, weil es keine Direktive aus dem RFC ist. Die Zeile geht in den Augen des Validators als Kommentar durch und in den Augen des Menschen als Richtlinie.
Dritter und wichtigster Grund: eine Rechteerklärung hat kein Rücksignal. Setzen Sie Disallow falsch, sehen Sie es eine Woche später im Indexierungsbericht. Setzen Sie Content-Signal falsch, passiert nichts, was sich beobachten ließe, und das Ausbleiben eines Ereignisses sieht in beiden Fällen identisch aus. Diese Fehlerklasse findet man durch Lesen der Datei, nicht durch Beobachten der Wirkung.
Zeilen außerhalb von Gruppen führen in die Irre, weil sie tatsächlich global gelten
In dieser Datei steckt etwas, das die falsche Intuition direkt nahelegt. Neben den User-agent-Gruppen kennt robots.txt gruppenunabhängige Records, und Sitemap ist so ein Record. In unserer Datei steht er nach der Sternchen-Gruppe:
Sitemap: https://wppoland.com/sitemap-index.xml
Agentmap: https://wppoland.com/.well-known/ai-catalog.jsonSitemap gilt für die ganze Datei, unabhängig davon, wo Sie ihn hinschreiben und wie viele Gruppen darunter stehen. Niemand wiederholt ihn zwanzigmal, und niemand muss das. Wer weiß, wie sich Sitemap verhält, und Content-Signal in derselben Gegend der Datei sieht, zwei Zeilen darüber, hat jedes Recht anzunehmen, dass sich diese Zeile genauso verhält. Tut sie nicht. Das eine ist ein globaler Record, das andere eine Direktive innerhalb einer Gruppe, und nichts in der Syntax weist darauf hin. Beide sind eine zweiteilige Zeile mit einem Doppelpunkt, direkt nebeneinander.
Praktischer Schluss beim Lesen fremder Dateien: Einrückung und Reihenfolge bedeuten nichts, es zählt allein, ob eine Direktive als gruppenbezogen definiert ist. Allow, Disallow und Content-Signal sind gruppenbezogen. Sitemap ist es nicht.
Was dieser Beitrag nicht klärt
Zwei Dinge lassen wir bewusst außerhalb des Rahmens, weil sie nicht unsere sind.
Erstens die rechtliche Wirkung des Vorbehalts. Content Signals beruft sich auf einen urheberrechtlich formulierten Rechtevorbehalt, und genau so ein Text steht im Kommentar oben in unserer Datei. Ob und wann dieser Vorbehalt wirksam ist, entscheidet eine Anwältin oder ein Anwalt und nicht die Person, die robots.txt bearbeitet. Unser Beitrag ist rein technisch: wenn eine Erklärung irgendein Gewicht haben soll, muss sie wenigstens den Client erreichen, an den sie adressiert ist, und unsere erreichte ihn nicht.
Zweitens das Verhalten einzelner Betreiber. Wir haben nicht gemessen, welcher Crawler Content-Signal liest, welcher es respektiert und was er mit widersprüchlichen Signalen in verschiedenen Gruppen anstellt. Ohne eigene Messung haben wir dazu nichts zu sagen, und fremde Zahlen wiederholen wir nicht. Die beschriebene Korrektur lohnt sich unabhängig von diesem Wissen, denn sie repariert eine Datei, die etwas anderes sagt, als ihr Autor gemeint hat, und das ist für sich genommen ein Defekt.
Was daraus für den Prozess folgt
Die Reichweite des Signals einmal zu prüfen kostet ein paar Minuten, sie zu halten ist keine einmalige Arbeit. Jede neue Gruppe in der Datei, und die kommen regelmäßig dazu, weil die Liste der KI-Crawler von Monat zu Monat wächst, ist eine Gruppe ohne Signal, bis jemand daran denkt. Deshalb gehört das zweite Kommando oben in die Tests und nicht in eine Notiz. Eine Regel, die sich selbst prüft, überlebt; eine Regel in einem Dokument überlebt bis zur nächsten Bearbeitung der Datei durch jemanden, der das Dokument nicht gelesen hat.
Es lohnt sich auch, im Kopf zu behalten, über welchen Anteil des Traffics wir hier reden. In unserer Messung vom August 2026, beschrieben im Beitrag über Bot-Traffic auf einer kleinen Website, kamen 72 % der Requests nicht aus einem Browser. Die Datei robots.txt ist der einzige Ort, an dem wir mit dieser Mehrheit überhaupt sprechen, und das Einzige, was diese Mehrheit über unsere Bedingungen weiß. Ist der Satz darin an die falsche Gruppe adressiert, ist das kein weicher Fehler, sondern Schweigen.
Kurze Checkliste
- Zählen Sie die
User-agent-Gruppen und dieContent-Signal-Zeilen in Ihrer Datei. Stimmen die Zahlen nicht überein, ist die Differenz die Menge der Gruppen ohne Vorbehalt. - Wiederholen Sie die Zeile in jeder Gruppe, für die sie gelten soll. Die Wiederholung ist hier die korrekte Form und kein Duplikat.
- Entscheiden Sie bewusst, ob jede Gruppe denselben Signalsatz bekommt. Zwanzig identische Zeilen sind meist ein Zeichen dafür, dass niemand entschieden hat.
- Prüfen Sie, ob Sie eigene Gruppen für die Rollen desselben Anbieters haben, etwa für vom Nutzer ausgelöste Abrufe und für das Sammeln von Korpus.
- Hängen Sie die Prüfung in die Pipeline. Die Crawler-Liste wächst, und jede neue Gruppe startet ohne Signal.
- Reden Sie sich nicht ein, dass ein Signal irgendetwas blockiert. Blockieren ist die Schicht vor der Anwendung, das hier ist eine Erklärung.
