Amazonbot: Was Amazons Crawler auf Ihrer Website sucht
Am 3. Oktober 2026 kam Amazonbot plötzlich nicht mehr durch – auf einer Website, die ihn in ihrer robots.txt seit Monaten erlaubte. An der Textdatei hatte sich nichts geändert. Cloudflares AI Crawl Control hatte für ihn, zusammen mit GPTBot und ClaudeBot, einen “Block Crawler”-Schalter aktiviert, und die Edge beantwortete jede dieser Anfragen fortan mit einem 403 – “Your request was blocked.” In den sieben Tagen davor war GPTBot bei null von fünfzehn Versuchen durchgekommen. ClaudeBot: null von vierzehn. Die robots.txt, die ein Besucher im Browser lesen konnte, verriet davon nichts.
Genau diese Lücke zwischen Datei und Edge macht die Entscheidung schwierig, ob man Amazonbot zulässt. Die Entscheidung selbst ist einfach, sobald klar ist, was der Bot wirklich tut – und das ist enger gefasst, und ungewöhnlicher, als die meisten “KI-Crawler blockieren”-Ratgeber unterstellen.
Was nimmt Amazonbot eigentlich mit?
Amazons eigene Entwicklerdokumentation fasst sich kurz, kürzer als die Frage verdient: Amazonbot diene dazu, “unsere Produkte und Dienste zu verbessern”, und was er sammelt, könne “zum Training von Amazons KI-Modellen genutzt werden”. Das ist der gesamte angegebene Zweck. Alexa wird nicht erwähnt. Rufus, Amazons Shopping-Assistent, kommt auf keiner der Amazon-Seiten zu ihren Crawlern vor – nicht als etwas, das Amazonbot füttert, und auch unter keinem anderen Namen. Drittanbieter-Verzeichnisse für Crawler beschreiben Amazonbot regelmäßig als Datenquelle für Alexa und Rufus zugleich; Amazons eigene Dokumentation behauptet keines von beidem.
Zwei Verhaltensweisen lohnen sich zu kennen, bevor jemand an der robots.txt schraubt. Erstens hält sich Amazonbot an das Robots-Exclusion-Protokoll und befolgt Allow/Disallow-Regeln pro Crawler, unterstützt aber die crawl-delay-Direktive nicht – wer ihn nur bremsen statt ganz blockieren will, hat dafür keinen Hebel. Zweitens liest er entweder eine aktuelle robots.txt oder greift auf eine bis zu dreißig Tage alte zwischengespeicherte Version zurück, und laut Amazon dauert es rund vierundzwanzig Stunden, bis eine Regeländerung wirkt – eine heute gesetzte Disallow-Zeile gilt also nicht sofort.
Es gibt einen zweiten, feineren Hebel, den kaum jemand nutzt. Amazons Dokumentation beschreibt einen Meta-Tag auf Seitenebene, noarchive, der Amazonbot gezielt untersagt, die Seite für das Modelltraining zu verwenden – getrennt von noindex, das die Seite komplett aus Amazons Ergebnissen entfernt. Das ist präziser als eine robots.txt-Regel: Eine Seite kann in Amazons Produkten sichtbar bleiben und trotzdem vom Training ausgenommen werden, was ein pauschales Disallow allein nicht leisten kann.
Ist Amazonbot der Bot, der Alexa füttert?
Nicht ganz – und genau hier gerät die Annahme “blockieren, um aus Alexa herauszukommen” ins Wanken. Amazon nennt zwei weitere Agenten, jeweils mit eigener Dokumentation und eigener Aufgabe. Amzn-SearchBot entscheidet, ob eine Seite in Amazons Sucherlebnissen auftauchen darf, Alexa eingeschlossen – wird er zugelassen, kann die Seite dort erscheinen; wird er blockiert, kann sie es nicht. Amzn-User ist der Live-Abruf: Er läuft genau in dem Moment, in dem jemand Alexa eine Frage stellt, die aktuelle Informationen aus dem Web braucht, statt bereits Indexiertes.
Beide Seiten stellen in fast identischem Wortlaut klar, dass der jeweilige Bot “nicht für das Training generativer KI-Modelle” eingesetzt wird. Nur Amazonbots eigene Seite enthält dieses Zugeständnis nicht. Das Bild teilt sich also in drei statt in eines: Eine Seite kann über Amzn-SearchBot und Amzn-User vollständig für Alexa sichtbar bleiben und trotzdem aus dem heraushalten, was Amazonbot selbst sammelt – und wer nur Amazonbot blockiert, ändert nichts an der Präsenz in Alexas Antworten, weil dieser Datenverkehr nie über ihn lief.
Diese Aufteilung bestimmt auch, was eine Crawler-Prüfung einem Seitenbetreiber tatsächlich sagen kann. Die Prüf-Engine hinter dieser Website verfolgt achtzehn namentlich benannte KI-Crawler über ihre robots.txt-Einträge, und der kostenlose KI-Crawler-Check schickt Amazonbot eine echte Anfrage, um zu sehen, ob der Server tatsächlich einhält, was die Datei verspricht – dieselbe Behandlung, die der Beitrag zu ClaudeBot für jenen Crawler beschreibt. Amzn-SearchBot und Amzn-User stehen auf dieser Liste noch nicht. Wer gezielt wissen will, ob Alexas Live-Antwortpfad eine Website erreichen kann, hat dafür heute kein automatisiertes Werkzeug – weder dieses noch die meisten anderen, nur Amazons eigenen, langsameren, nicht überprüfbaren Kanal.
Was robots.txt nicht zeigt
Der Vorfall vom Oktober oben ist der Grund, warum dieser Unterschied in der Praxis zählt, nicht nur auf dem Papier. Cloudflares AI Crawl Control sitzt an einer völlig anderen Stelle im Dashboard als die robots.txt, und ihre Crawler-spezifischen “Block Crawler”-Schalter können eine Anfrage an der Edge mit 403 abweisen – unabhängig davon, was die Textdatei sagt. Wer nur die Datei prüft – genau das, wozu jede “KI-Crawler zulassen”-Anleitung rät – sieht nicht, dass der Server den Crawler trotzdem leise abweist. Die Werte null von fünfzehn und null von vierzehn stammen aus Cloudflares eigenen Protokollen pro Crawler, nicht aus der Datei, und die Datei gab keinen Hinweis, dass etwas nicht stimmte. Erst die Prüfung dessen, was tatsächlich beim Server ankam, statt dessen, was die robots.txt versprach, deckte es auf.
Amazonbot ist dem genauso ausgesetzt wie GPTBot und ClaudeBot es waren. Ihn in robots.txt zu erlauben ist notwendig, aber nicht ausreichend; ob diese Erlaubnis an der Edge tatsächlich eingehalten wird, lässt sich nur durch einen Test der echten Antwort herausfinden – so, wie der Vorfall oben am Ende aufgedeckt wurde.
Sollte man ihn blockieren?
Die ehrliche Antwort hängt davon ab, was ein Unternehmen tatsächlich vermeiden will, und die dreigeteilte Aufgabenverteilung oben zeigt: “Amazonbot blockieren” und “aus Alexa heraushalten” sind nicht dieselbe Entscheidung. Amazonbot per robots.txt zu blockieren – oder, wo das Ziel enger gefasst ist, stattdessen noarchive zu setzen – stoppt einen einzelnen benannten Crawler, der nach Amazons eigener Aussage Seiten sammelt, die am Ende in das Training seiner Modelle einfließen können. An der Sichtbarkeit eines Unternehmens in Alexas tatsächlichen Antworten ändert das nichts, weil dafür zwei andere Agenten zuständig sind, die den Trainingszweck ausdrücklich verneinen und die dieses Produkt serverseitig noch nicht prüft. Wer das zweite Anliegen mit einer Regel angeht, die für das erste gedacht ist, löst das falsche Problem – und hat allein anhand der Datei keine Möglichkeit zu erkennen, dass das eigentliche Anliegen unberührt bleibt.
Häufig gestellte Fragen
Was macht Amazonbot eigentlich mit den Seiten, die er liest?
Amazons eigene Entwicklerdokumentation sagt, Amazonbot diene dazu, Amazons Produkte und Dienste zu verbessern, und was er sammelt, könne zum Training von Amazons KI-Modellen genutzt werden. Zu Rufus, Amazons Shopping-Assistenten, sagt die Dokumentation unter keinem der drei Bot-Namen etwas.
Wenn ich Amazonbot blockiere, beantwortet Alexa dann keine Fragen mehr zu meinem Unternehmen?
Nicht direkt. Amazon nennt dafür zwei weitere Agenten: Amzn-SearchBot, der eine Seite für Alexas Suchergebnisse zulässt, und Amzn-User, der eine Seite live abruft, wenn jemand Alexa eine Frage stellt, die aktuelle Informationen braucht. Amazons Dokumentation stellt klar, dass keiner der beiden für das Training von KI-Modellen genutzt wird – nur bei Amazonbot selbst steht das so.
Kann ich das Training verhindern, ohne die Indexierung durch Amazon zu blockieren?
Amazon unterstützt dafür einen Meta-Tag auf Seitenebene, noarchive: Die eigene Dokumentation beschreibt ihn als Anweisung an Amazonbot, die Seite nicht für das Modelltraining zu verwenden – getrennt von noindex, das die Seite komplett aus den Ergebnissen entfernt.
Reagiert Amazonbot auf die crawl-delay-Direktive?
Nein. Amazons Dokumentation sagt ausdrücklich, dass Amazonbot die crawl-delay-Direktive nicht unterstützt, anders als manche Such-Crawler.
Wie finde ich heraus, ob Amazonbot meine Website tatsächlich erreicht – nicht nur, was robots.txt erlaubt?
Zuerst lesen, was robots.txt erlaubt. Dann getrennt prüfen, was der Server tut, wenn eine Anfrage eintrifft, die sich als Amazonbot ausgibt. Beides kann widersprüchlich sein – eine Bot-Management-Regel beim CDN kann einen Crawler blockieren, den die Textdatei weiterhin erlaubt, und die Datei selbst zeigt das nie an.