robots-observatory: Ich messe, ob KI-Crawler die robots.txt wirklich respektieren

Die robots.txt ist keine technische Sperre, sondern eine höfliche Bitte. Jeder grosse KI-Anbieter versichert, dass seine Crawler sich daran halten. Überprüfbar ist das kaum, weil die Datenlage fehlt. Genau diese Lücke schliesst mein neues Projekt: Unter observatory.ramhee.ch läuft seit dem 22. August 2026 ein öffentlicher, kontinuierlich fortgeschriebener Datensatz.

Der Code liegt vollständig auf GitHub.

Das Messprinzip

Auf dem Host liegen Honeypot-Pfade. Jeder davon ist in der robots.txt für genau einen Crawler per Disallow gesperrt und von keiner Seite aus verlinkt. Wer diesen Pfad findet, hat zwingend die robots.txt gelesen. Jeder eintreffende Request wird als eine JSON-Zeile protokolliert.

Entscheidend ist die Klassifikation danach. Ein Treffer zählt nur dann als Violation, wenn die Client-Adresse in den IP-Ranges liegt, die der Vendor selbst publiziert. Ein Request mit dem User-Agent eines Crawlers von irgendeiner anderen Adresse wird separat als Spoofing geführt und niemals als Verstoss gewertet. Dazu kommt eine Grace Period von 48 Stunden nach jeder Änderung der robots.txt, denn ein Crawler darf ein altes Regelwerk noch kurz im Cache haben. Massgeblich ist immer der Stand der robots.txt zum Zeitpunkt des Treffers, nicht der heutige.

Wer überwacht wird

Aktuell sind zwölf Honeypots aktiv, verteilt auf acht Vendoren / Anbieter:

Die Spalte «Attribution» ist der unangenehme Teil. Wo ein Vendor eine einzige Range-Liste für mehrere Crawler publiziert, lässt sich ein Treffer keinem einzelnen Bot zuordnen. Diese Zeilen zeigen deshalb Volumen, aber grundsätzlich keine Violations. Für Google-Extended und Applebot-Extended gilt das doppelt, weil diese Tokens gar nie in einem realen User-Agent auftauchen.

Die technische Umsetzung

Der Collector ist ein einzelnes CGI-Skript, honeypot.cgi, ohne jede Third-Party-Dependency. Das ist die langweiligste verfügbare Lösung und genau darum die richtige. Es läuft auf Apache mod_cgid, auf nginx mit fcgiwrap, auf lighttpd und auf praktisch jedem Shared Host. Kein Daemon, kein Reverse-Proxy, kein Framework, das gepatcht werden will. Bei einstelligen Hits pro Tag wäre jede Optimierung an Process-per-Request eine Optimierung an nichts.

Zwei Details, die mir wichtig waren: Ein einzelner O_APPEND-Write pro Zeile macht konkurrierende Requests unkritisch, es gibt keinen Lock, der lecken kann. Und das Skript liefert unter keinen Umständen einen 5xx zurück. Ein fehlschlagender Honeypot würde Crawler zu Retries verleiten und damit seine eigene Messung aufblähen. Scheitert der Spool-Write, geht die Antwort trotzdem als 200 raus und der Fehler landet im Error-Log des Webservers.

Die Aggregation läuft einmal täglich als systemd-Timer unter einem unprivilegierten Service-User und pusht über einen SSH-Deploy-Key. Git ist hier die Datenbank. Jede Zahl hat damit eine History und jede Änderung daran ist ein Diff. Jede publizierte Datei ist eine reine Funktion der committeten Inputs, ein erneuter Lauf über unveränderte Daten erzeugt also keinen Diff. Die verifizierten IP-Ranges kommen aus dem separaten Repository ai-crawler-ipranges, dieses Projekt holt bewusst keine Vendor-Feeds selbst. Der ganze Stack braucht Python 3.11+ und ausschliesslich die Standard Library.

Was die Zahlen nicht sagen

Stand heute steht in jeder Zelle der Scorecard eine Null. Das ist kein Erfolg und kein Misserfolg, sondern schlicht die Baseline. Meines Erachtens ist die ehrliche Benennung der Grenzen wichtiger als die Zahlen selbst:

• Keine Hits sind kein Beweis für Compliance. Ein Crawler, der die robots.txt nie gelesen hat, kennt den Honeypot gar nicht. Respekt und Desinteresse sehen in dieser Tabelle identisch aus.
• Ein Honeypot misst einen Pfad. Nicht, was anderswo gecrawlt wurde, und schon gar nicht, wofür Inhalte danach verwendet wurden.
• Spoofing-Zahlen sagen nichts über den Vendor aus. Jeder kann jeden User-Agent senden.
• Kleine Zahlen bleiben kleine Zahlen. Werte von einer einzigen Site sind keine Hochrechnung.
• Die Verifikation ist nur so gut wie das, was Vendoren publizieren. Crawlt ein Anbieter aus nicht publizierten Adressen, erzeugt das ein spoofed und keine Violation.

Fazit

Das Projekt ist bewusst so gebaut, dass es weniger behauptet, als technisch möglich wäre. Die Klassifikationsregeln in der METHODOLOGY.md reduzieren an mehreren Stellen absichtlich die Aussagekraft, etwa bei den ambiguous Vendoren. Wer eine reisserische Schlagzeile über Crawler-Verstösse sucht, wird hier nicht bedient. Wer eine nachvollziehbare, versionierte und reproduzierbare Messung sucht, hoffentlich schon.

Das Schema ist von Beginn weg multi-site, jeder Record trägt eine site_id. Version 1 läuft auf einem einzigen Host, weitere Sites brauchen keine Schema-Änderung. Wer mitmessen will, braucht drei Dinge: wirklich unverlinkte Honeypot-Pfade, eine robots.txt, die diese wirklich sperrt, und einen unveränderten Aggregator. Zugriff auf Logs oder Besucherdaten verlange ich ausdrücklich nicht.

Korrekturen an der Methodik sind mir übrigens wertvoller als zusätzliche Bots. Wenn eine Regel mehr behauptet, als die Daten hergeben, ist das ein Bug.

Live-Scorecard: observatory.ramhee.ch

Quellcode und Daten: github.com/ramhee98/robots-observatory