Finanzierung: CypherpunkGuide kann für qualifizierte Käufe über deutlich gekennzeichnete Affiliate-Links in passenden Artikeln eine Provision erhalten. Wir schalten keine Überwachungswerbung, binden keine Skripte von Werbenetzwerken oder Tracking-Pixel ein und veröffentlichen keine gesponserten Artikel.
Korrektur vom 24. September 2026: Der ursprüngliche Artikel überschätzte, was IP-Abgleiche über Crawler-Identität und Sperren belegen können. Er beschrieb llms.txt außerdem als Ausschlussmechanismus und machte aus 14 Bezeichnungen 14 Unternehmen. Wir haben diese Aussagen und die Datenzusammenfassung korrigiert sowie unbelegte Schlussfolgerungen zu Amazonbot und DNS zurückgenommen. Der Beobachtungszeitraum bleibt der 19. Juni bis 5. Juli 2026. Diese Aktualisierung enthält kein neues Crawling-Experiment.
Wer eine Website betreibt, muss drei Fragen auseinanderhalten: Wie nennt sich der Besucher? Passt seine Quelladresse zu einem dokumentierten Adressbereich des Crawlers? Hat eine Zugriffsregel die Auslieferung von Inhalten tatsächlich verhindert? Unsere Protokolle helfen bei den ersten beiden Fragen. Die dritte beantworten sie nicht.
Ein User-Agent ist eine Zeichenfolge, mit der sich ein Programm bei einer Anfrage bezeichnet. Der Absender kann sie frei wählen. Der Abgleich einer IP-Adresse mit einer Referenzliste liefert zusätzliche Hinweise. Dabei zählen aber Geltungsbereich und Erfassungsdatum der Liste. robots.txt bittet unterstützende Crawler, bestimmte Pfade nicht abzurufen. Eine Regel auf dem Server oder im Content Delivery Network, kurz CDN, kann einen Zugriff dagegen technisch verweigern. Beides unterscheidet sich von llms.txt, einem Vorschlag, Sprachmodellen nützliche Informationen über eine Website bereitzustellen.
Unser Bedrohungsmodell für das KI-Zeitalter sah vor, den Crawler-Verkehr dieser Website zu prüfen. Die 17 Tage Protokolldaten zeigen, wie wenig ein Name allein belegt — und wo auch unsere ursprüngliche Auslegung zu weit ging.
Was die Aufzeichnungen aus 17 Tagen enthalten#
Die gespeicherten Aggregate umfassen 1.635 Anfragen in 14 KI-bezogenen User-Agent-Familien. Eine Familie ist eine Kategorie, die anhand einer Bezeichnung im User-Agent-Text zugewiesen wurde. Sie ist weder ein eigenständiges Unternehmen noch eine einmalige vollständige User-Agent-Zeichenfolge. Auch CCBot und eine Google-Extended-Bezeichnung gehören dazu. Die Kategorien sind daher kein Verzeichnis von 14 kommerziellen Trainings-Crawlern.
Die korrigierte Zusammenfassung bewahrt die Zählwerte und erläutert ihre Grenzen. Sie enthält Aggregate und ausgewählte Netzwerkpräfixe, aber keine vollständigen Quell-IP-Adressen oder einzelnen Anfrageprotokolle. Du kannst die Summen prüfen, die ursprüngliche Analyse der Quelladressen aus dieser Datei jedoch nicht unabhängig wiederholen.
| User-Agent-Kategorie | Anfragen | Im Juli protokollierte Übereinstimmungen | Einschränkung |
|---|---|---|---|
| ClaudeBot | 553 | 546 (99 %) | Abgleich mit den damals verwendeten Referenzbereichen |
| Amazonbot | 344 | 120 (35 %), vorläufig | Extraktion der Referenz nicht validiert; siehe unten |
| GPTBot | 310 | 301 (97 %) | Abgleich mit den damals verwendeten Referenzbereichen |
| meta-externalagent | 179 | Nicht geprüft | In dieser Analyse kein Zuordnungsverfahren angewendet |
| Bytespider | 112 | Nicht geprüft | In dieser Analyse kein Zuordnungsverfahren angewendet |
| PerplexityBot | 24 | 5 (21 %) | Kleine Stichprobe; Aktualität der Referenz begrenzt die Aussage |
| GoogleOther | 12 | 12 (100 %) | Kleine Stichprobe; keine Messung von Google-Extended |
Auf die übrigen sieben Kategorien entfallen 101 Anfragen. Die gerundeten Prozentsätze beziehen sich auf Anfragen, nicht auf einzelne Besucher, Seiten oder Quelladressen.
Eine Übereinstimmung bedeutet hier, dass eine beobachtete Quell-IP zum Referenzbestand der Juli-Auswertung passte. Damit ist weder die Software authentifiziert noch die handelnde Person identifiziert oder die spätere Nutzung des Inhalts geklärt. Eine fehlende Übereinstimmung kann auf einen anderen Absender, eine unvollständige oder veraltete Referenz oder einen Verarbeitungsfehler zurückgehen. Für sich genommen beweist sie keine vorgetäuschte Identität.
Ein IP-Abgleich misst nicht, ob eine Sperre wirkt#
Die erfassten Quoten für GPTBot und ClaudeBot betreffen Quelladressen. Wir haben keinen kontrollierten Vorher-nachher-Versuch mit einer Sperre durchgeführt und keine Verwendung von Inhalten im Training beobachtet. Die ursprüngliche Aussage, diese Quoten bewiesen die Wirksamkeit von robots.txt, war nicht gedeckt.
Die Crawler-Dokumentation von OpenAI unterscheidet verschiedene Aufgaben und Steuerungsmöglichkeiten. Die Hinweise von Anthropic beschreiben robots.txt-Anweisungen und warnen, dass IP-Sperren den Crawler am Lesen dieser Anweisungen hindern können. Das sind Angaben der Betreiber zu ihren Systemen, keine Ergebnisse unseres Experiments.
Auch Googles Hinweise zur Verifizierung richten sich nach der Crawler-Kategorie und ihrem dokumentierten Prüfverfahren. GoogleOther ist ein Crawler für allgemeine Zwecke. Google-Extended ist dagegen eine separate Kennung zur Steuerung bestimmter Nutzungen, kein eigener HTTP-User-Agent. Anfragen mit dieser Bezeichnung in unseren Protokollen messen nicht, wie Google diese Vorgabe umgesetzt hat.
Für einen Sperrtest musst du die Regel, den Aktivierungszeitpunkt, die Crawler-Kategorie und die anschließende Inhaltsauslieferung erfassen. Halte Herkunftsprüfung und Zugriffsergebnis getrennt fest. Unser veröffentlichter Datensatz enthält diesen Versuch nicht. Er liefert daher weder eine Erfolgsquote für Sperren noch eine Quote für den Ausschluss vom Training.
Vier Netze, vierzehn Bezeichnungen, unbekannte Betreiber#
Die historische Netzwerkzusammenfassung erfasst 99 Anfragen aus vier /24-Präfixen mit 14 Bezeichnungen. Alle 14 kamen innerhalb eines dieser Präfixe vor. Ein /24 umfasst 256 IPv4-Adressen. Hier dient es zur Gruppierung, ist aber weder die kleinste mögliche Zuteilung noch eine Identitätsgrenze.
Unter den 14 Bezeichnungen sind mehrere Produkte desselben Unternehmens und Programme, die Seiten auf Nutzeranfrage abrufen. Diese Netzwerkzählung beruht auf einer anderen Auswahl als die Tabelle mit 1.635 Anfragen. Sie ist keine einfache Teilmenge, die sich dazuaddieren oder davon abziehen lässt.
Die erste Zeile dient dem Vergleich. Die vier weiteren Präfixe bilden die Zählung mit 99 Anfragen.
| Präfix im historischen Datensatz | Beobachtung | Damals verzeichnete registrierte Organisation |
|---|---|---|
216.73.216.0/24 | 281 Anfragen mit ClaudeBot-Bezeichnung | Anthropic, PBC |
185.213.174.0/24 | Alle 14 Bezeichnungen beobachtet | NextGenWebs |
45.45.237.0/24 | Teil der Zählung über vier Präfixe | Infraly, LLC |
23.161.169.0/24 | Teil der Zählung über vier Präfixe | Infraly, LLC |
154.58.229.0/24 | Teil der Zählung über vier Präfixe | Limestone Networks |
Im benachbarten Block 216.73.217.0/24 kamen weitere 265 ClaudeBot-Anfragen hinzu. Zusammen ergeben sie die 546 erfassten Übereinstimmungen. Die Zahlen beschreiben diese Stichprobe. Daraus folgt keine Regel, nach der legitime Infrastruktur immer nur einen Namen verwendet.
RDAP liefert die öffentlichen Registrierungsangaben für die Organisationsspalte. Sie sagen aus, auf wen ein Adressbereich registriert ist, nicht welcher Kunde eine Anfrage ausgeführt hat. Zwei Präfixe desselben Hosting-Anbieters belegen keinen gemeinsamen Akteur. Die Vielzahl der Bezeichnungen ist ein Anlass zur weiteren Prüfung. Sie beweist nicht, dass ein Betreiber 14 Unternehmen nachahmte oder robots.txt missachtete.
Amazonbot: Die Referenzliste ist noch nicht validiert#
Die gespeicherte Auswertung nennt 120 Übereinstimmungen bei 344 Anfragen mit Amazonbot-Bezeichnung. Die 35 % lassen sich nicht als validierte Quote für die Identität von Amazonbot darstellen. Die Analyse extrahierte 525 Adressen aus einer Seite, für die die Forschungsnotizen einen angegebenen Listenumfang von 489 festhielten. Die Notizen warnten bereits davor, dass auch fremde Adressen aus dem Seitencode enthalten sein könnten. Die Abweichung blieb ungeklärt.
Die korrigierte Zusammenfassung behält die 120 Übereinstimmungen und 224 Nichtübereinstimmungen als historische Verarbeitungsergebnisse bei. Bevor diese Aufteilung als Abgleich mit der offiziellen Liste gelten kann, muss der extrahierte Referenzbestand erneut geprüft werden.
Der ursprüngliche Text behauptete außerdem, 18 nicht passende Adressen hätten allesamt Amazons DNS-Prüfung nicht bestanden. Das erhaltene DNS-Aggregat beschreibt jedoch eine andere Stichprobe mit 14 Adressen. Es stützt diese Aussage nicht. Wir nehmen die Schlussfolgerung über die 18 Adressen zurück, statt sie mit einer anderen Stichprobe zu begründen. Für die 224 nicht passenden Anfragen ist keine vorgetäuschte Identität nachgewiesen.
Nutze für eine neue Prüfung die aktuelle Amazonbot-Dokumentation und bewahre den genauen Referenzbestand samt Extraktionsverfahren auf. Dass eine Adresse einem Cloud-Anbieter gehört, identifiziert weder einen bestimmten Crawler noch dessen Kunden.
Ein fehlender DNS-Name klärt die Identität nicht#
Die Juli-Auswertung konnte die 179 als meta-externalagent und die 112 als Bytespider bezeichneten Anfragen nicht zuordnen. Das ist eine Grenze dieser Analyse. Es bedeutet nicht, dass diese Crawler grundsätzlich nicht prüfbar sind oder heute kein Prüfverfahren existiert.
Bei neun Adressen mit Meta-Bezeichnung enthält das gespeicherte DNS-Ergebnis keinen Namen. Das Prüfskript kennzeichnete sämtliche Abfragefehler als NXDOMAIN, auch solche, die andere Ursachen haben konnten. Wir können daher nicht von neun bestätigten Fällen nicht vorhandener DNS-Namen sprechen. Ebenso wenig zeigt eine erfolglose DNS-Abfrage, ob der Absender eine Crawling-Regel beachtet hat.
llms.txt verweist auf Inhalte und schließt Crawler nicht aus#
llms.txt soll Sprachmodelle auf nützliche Website-Inhalte hinweisen, nicht sie vom Zugriff ausschließen. Der Vorschlag hat einen anderen Zweck als robots.txt. Schon seine ursprüngliche Fassung von 2024 diente der Information. Es geht nicht um eine Ausschlussfunktion, die erst nach unserer Untersuchung hinzugekommen wäre.
Die Forschungsnotiz vom Juli nennt im Beobachtungszeitraum null als KI-Verkehr klassifizierte Anfragen an unsere Datei /llms.txt. Diese pfadbezogene Zahl lässt sich aus den für die Korrektur erhaltenen JSON-Aggregaten nicht neu berechnen. Wir führen sie mit dieser Einschränkung als damals berichtete Beobachtung weiter. Die 310 GPTBot-Anfragen sind weder 310 verschiedene Seiten noch 310 erfolgreiche Downloads.
Selbst wenn die berichtete Null stimmt, bedeutet sie nur, dass die Erfassung und Klassifizierung dieser Website im betreffenden Zeitraum keine solchen Anfragen registrierte. Sie misst weder die Verbreitung von llms.txt im Web noch KI-Zitate oder die Wirksamkeit eines Ausschlussmechanismus. Der frühere Vergleich mit einer externen Studie zu Zitaten stützte diesen Schluss nicht und wurde entfernt.
Prüfe Herkunft und Zugriff getrennt#
Das brauchbare Ergebnis ist enger als ursprünglich behauptet: User-Agent-Bezeichnungen, Übereinstimmungen mit IP-Referenzen und wirksame Zugriffskontrollen sind unterschiedliche Belege. Trenne sie, wenn du entscheidest, was deine Protokolle aussagen.
- Nutze die dokumentierten Vorgaben für den jeweiligen Zweck. Unterscheide Trainings-Crawler, Such-Crawler und Abrufe auf Nutzeranfrage. Ein IP-Treffer prüft keine Regelbefolgung.
- Bewahre Referenz und Verfahren auf. Notiere Erfassungsdatum, genauen Adressbestand, Abgleichregeln und ungeklärte Fehler. Gemeinsam genutztes Hosting oder ein fehlender Treffer verlangt Vorsicht, keine automatische Zuordnung.
- Teste Zugriffsregeln anhand der Ergebnisse. Wenn Inhalte privat bleiben müssen, verlange vor der Auslieferung eine Berechtigung und prüfe, ob unberechtigte Anfragen abgewiesen werden. Eine öffentlich abrufbare Datei mit Nutzungsvorgaben ist keine Zugangssperre.
- Entscheide, was öffentlich werden soll. Bereits andernorts angefertigte Kopien sind ein anderes Problem als künftige Zugriffe auf deinen Server. Dazu gehören die Grenzen beim vollständigen Löschen von Veröffentlichungen und Rückschlüsse aus öffentlichen Einzelinformationen.
Häufige Fragen#
Kann robots.txt KI-Crawler sperren?#
Du kannst Anweisungen für Crawler veröffentlichen, die die betreffenden Regeln beachten. robots.txt erzwingt aber keine Zugriffskontrolle. Unsere IP-Abgleiche messen nicht, ob die Regeln befolgt wurden. Nutze die dokumentierten Vorgaben des Betreibers und teste den tatsächlichen Zugriff getrennt davon. Wenn Inhalte privat sein müssen, beschränke, wer sie abrufen darf.
Wie prüfst du eine Anfrage mit GPTBot- oder ClaudeBot-Bezeichnung?#
Gleiche die Quell-IP mit der passenden Betreiberreferenz ab und halte Version und Erfassungsdatum fest. Befolge das für diesen Crawler dokumentierte Prüfverfahren. Ein Treffer stützt die Herkunftszuordnung innerhalb dieser Grenzen. Ein fehlender Treffer beweist allein keine vorgetäuschte Identität. Der Abgleich zeigt auch nicht, ob Inhalte in Trainingsdaten gelangt sind.
Hält llms.txt KI von meinen Inhalten fern?#
Nein. Der Vorschlag weist Sprachmodelle auf nützliche Inhalte hin; er untersagt weder Crawling noch Training. Unsere Juli-Notiz nennt null als KI-Verkehr klassifizierte Anfragen an diese Datei in 17 Tagen. Die Zählung ist kein Ausschlusstest und lässt sich aus den erhaltenen JSON-Aggregaten nicht nachberechnen.
Was ist ein gefälschter KI-Crawler?#
Dabei verwendet eine Anfrage den Namen eines Crawlers, ohne von ihm zu stammen. Der Absender kann den User-Agent-Text frei wählen. Eine unstimmige Bezeichnung oder gemeinsam genutztes Hosting allein beweist jedoch keine Täuschung. Unsere Beobachtungen aus vier Präfixen rechtfertigen Vorsicht. Sie klären weder die Betreiber noch eine mögliche Missachtung von robots.txt.
Was kannst du tun, wenn sich nicht jeder Crawler zuordnen lässt?#
Nutze und teste Zugriffskontrollen für Inhalte, die nicht öffentlich sein sollen. Wende bei öffentlichen Seiten die dokumentierten Crawling-Vorgaben an, beobachte die Ergebnisse und benenne Unsicherheiten. Kein Anfrageprotokoll kann beweisen, dass eine Kopie niemals anderswo beschafft oder später verwendet wurde.
Quellen#
Externe Dokumentation am 24. September 2026 geprüft. Die Archivdaten weichen vom Beobachtungszeitraum ab und rekonstruieren die ursprünglichen IP-Listen nicht.
Die korrigierte Zusammenfassung erhält die historischen Zählwerte und dokumentiert die zurückgenommenen Schlussfolgerungen. Die Aktualisierung vom 24. September prüft die erhaltenen Aggregate und Methoden. Sie enthält weder eine neue 90-Tage-Messung noch einen kontrollierten Sperrversuch.
Diese Fallstudie ergänzt unsere Überlegungen zur Einhegung des offenen Webs. Die Protokolle einer einzelnen Website beweisen deren weiter reichende Aussagen jedoch nicht. Unser Werkzeug zur Selbstprüfung behandelt eine andere Frage: Welche öffentlichen Informationen über dich lassen sich finden und prüfen?
