Warum werden KI-Shopping-Agenten auf Websites blockiert?

Sagt ein Nutzer einem KI-Assistenten „Finde mir wasserdichte Wanderschuhe in Größe 42, die in mein Budget passen, und leg sie in den Warenkorb", versucht der Assistent es wie ein Mensch: Er sucht, öffnet Shops, vergleicht Produktseiten, wählt die Größe und bewegt sich Richtung Kasse. Und sehr oft bleibt er irgendwo stehen. Statt der Produktseite erscheint ein Prüfbildschirm, die Anfrage zum Hinzufügen in den Warenkorb wird abgelehnt, oder die Zahlungsseite markiert eine verdächtige Transaktion. Aus Sicht des Nutzers ist der Assistent gescheitert; aus Sicht des Shops wurde ein Bot gestoppt.

In diesem Artikel erklären wir, was ein KI-Shopping-Agent ist, warum Websites diese Agenten blockieren, und den Kern des Problems: warum es für eine Website schwer ist, einen Menschen, einen bösartigen Bot und einen mit Autorisierung des Nutzers handelnden Agenten auseinanderzuhalten. Danach behandeln wir die Lösungen, die für dieses Problem entstehen (signierte Agenten, Web Bot Auth und neue Protokolle auf der Zahlungsseite), und den richtigen Weg für Händler und Agentenentwickler. Dieser Artikel erklärt nicht, wie Agenten am Bot-Schutz vorbeikommen; er dreht sich darum, dass Agentenverkehr sich ordnungsgemäß ausweist.

Was ist ein KI-Shopping-Agent?#

Ein KI-Shopping-Agent ist ein KI-System, das das Einkaufsziel eines Nutzers übernimmt und es umsetzt, indem es selbst auf Websites handelt. Der allgemeine Mechanismus ist die Schleife aus Wahrnehmen, Planen, Handeln und Bewerten, die wir in Wie funktionieren KI-Agenten? beschreiben; bei einem Shopping-Agenten sind die Tools der Schleife Shop-Websites und Zahlungssysteme.

Was ein Shopping-Agent tut, lässt sich in drei Ebenen teilen:

1. Recherche: Produkte suchen, Preise und Merkmale vergleichen, Bewertungen lesen.
2. Vorbereitung: Größe, Farbe und Menge wählen, in den Warenkorb legen, Versandoptionen bewerten.
3. Transaktion: Die Bestellung mit Zahlungsdaten abschließen.

Jede Ebene birgt für die Website ein anderes Risiko. Recherche ähnelt dem, was ein Scraper tut. Das Hinzufügen zum Warenkorb betrifft Bestands- und Sitzungssysteme der Website. Zahlung bedeutet Geld und Betrugsrisiko. Websites reagieren auf jeder Ebene anders auf Agenten.

Warum blockieren Websites Agenten?#

Stoppt ein Onlineshop Agentenverkehr, liegt das meist nicht an einer besonderen Haltung gegenüber Agenten, sondern daran, dass seit Jahren bestehende Abwehrmaßnahmen auch Agenten erfassen.

Bot-Schutz. Onlineshops setzen Bot-Management-Systeme gegen Preis-Scraping, Bestandshortung (limitierte Produkte in Warenkörbe legen, damit andere sie nicht kaufen können), Kontoübernahmen und Kartentest-Angriffe ein. Diese Systeme bewerten Anfragen mit Signalen wie Geschwindigkeit, IP-Reputation, Browser-Fingerprint und Verhalten. Ein Shopping-Agent läuft oft aus einem Rechenzentrum, mit einem Headless-Browser und öffnet Seiten weit schneller als ein Mensch; er trägt also fast jedes Signal, nach dem Bot-Schutzsysteme suchen. Ein Beispiel, wie diese Signale bewertet werden, finden Sie in Cloudflare Precursor.

Zahlungsbetrugsrisiko. Zahlungssysteme prüfen mit verschiedenen Signalen, ob eine Karte von ihrem Inhaber genutzt wird: Gerät, Standort, Gewohnheiten und zusätzliche Prüfschritte wie 3-D Secure. Versucht ein Agent mit Kartendaten zu bezahlen, passen die meisten dieser Signale nicht zum normalen Profil des Karteninhabers. Aus Sicht des Zahlungssystems ähnelt das Bild automatisiertem Einkaufen mit einer gestohlenen Karte.

Nutzungsbedingungen. Die Nutzungsbedingungen vieler Onlineshops beschränken automatisierten Zugriff, automatische Bestellungen oder das Erfassen von Website-Inhalten mit automatisierten Werkzeugen. Nach den eigenen Regeln der Website ist ein Agent ein nicht autorisiertes Automatisierungswerkzeug, auch wenn er im Auftrag des Nutzers handelt.

Kundenbeziehung und Daten. Für den Händler ist der Agent ein Vermittler zwischen ihm und dem Kunden. Ein großer Teil des Verkaufserlebnisses, etwa Produktseite, Empfehlungen, Kampagnen und Treueprogramme, wird umgangen, wenn der Agent dem Nutzer nur eine Zusammenfassung zeigt. Manche Händler sind aus diesem Grund gegenüber Agentenverkehr vorsichtig.

Unklare Haftung. Legt der Agent die falsche Größe in den Warenkorb, kauft ein Produkt ohne Zustimmung des Nutzers oder liest den Preis falsch, wer übernimmt Rückgabe und Streitfall? Solange diese Fragen keine klaren Antworten haben, blockieren Händler und Zahlungsunternehmen womöglich lieber, um das Risiko zu senken.

Warum ist es schwer, Menschen, Bots und autorisierte Agenten zu unterscheiden?#

Historisch arbeitet der Bot-Schutz einer Website mit zwei Kategorien: Mensch und Bot. Ein Shopping-Agent ist eine dritte Kategorie, die nicht in diese Teilung passt.

Das Problem: In den ersten vier Zeilen der Tabelle sieht der Agent wie ein bösartiger Bot aus, in den letzten beiden wie ein Mensch. Weil Bot-Schutzsysteme nur Verhaltens- und Netzwerksignale betrachten können, fehlt in der HTTP-Anfrage genau die Information, die sie zur Unterscheidung bräuchten: „Wer steht hinter dieser Automatisierung und mit welcher Befugnis?"

Diese Lücke lässt sich mit dem User-Agent-Header nicht füllen, denn dieser Header ist Klartext, und jeder kann jeden Wert hineinschreiben. Damit eine Website glaubt, dass eine Anfrage mit „KnownShoppingAgent/1.0" wirklich vom Agenten dieses Unternehmens kommt, braucht sie einen überprüfbaren Nachweis. IP-Adresslisten helfen bis zu einem gewissen Grad, doch Adressen werden in Cloud-Infrastrukturen geteilt und ändern sich.

Deshalb löst ein Agent, der sich versteckt oder menschlich wirken will, das Problem nicht, sondern verschärft es. Ein Agent, der seinen Browser-Fingerprint fälscht und IPs über Proxy-Pools wechselt, wird genau zu dem Verkehr, den Bot-Schutzsysteme blockieren sollen. Die Lösung geht in die entgegengesetzte Richtung: Der Agent weist sich überprüfbar aus.

Signierte Agenten und Web Bot Auth#

Der wichtigste Ansatz in diese Richtung ist, dass der Agent jede HTTP-Anfrage kryptografisch signiert. Darunter liegt der IETF-Standard HTTP Message Signatures (RFC 9421). Der Standard legt fest, wie ausgewählte Bestandteile einer HTTP-Nachricht (Methode, Adresse, bestimmte Header) mit einem privaten Schlüssel signiert werden und der Empfänger die Signatur mit dem öffentlichen Schlüssel prüft.

Web Bot Auth ist der Name des Ansatzes, der diesen Standard zur Authentifizierung von Bots und Agenten nutzt. Laut der Web-Bot-Auth-Dokumentation von Cloudflare funktioniert er so:

1. Der Agentenbetreiber erzeugt ein Schlüsselpaar und veröffentlicht den öffentlichen Schlüssel als Schlüsselverzeichnis auf seiner eigenen Domain unter /.well-known/http-message-signatures-directory.
2. Der Agent fügt jeder Anfrage drei Header hinzu: Signature-Input (die von der Signatur abgedeckten Bestandteile, die Schlüssel-ID, Erstellungs- und Ablaufzeit sowie eine Nonce), Signature (die Signatur selbst) und Signature-Agent (die Adresse des Schlüsselverzeichnisses).
3. Die Website oder das vorgelagerte CDN prüft die Signatur: Es liest das Schlüsselverzeichnis, prüft die Signatur mit dem öffentlichen Schlüssel und stellt sicher, dass sie nicht abgelaufen ist.
4. Die geprüfte Anfrage wird einem bekannten Agenten zugeordnet. Auf dieser Grundlage kann die Website die Anfrage zulassen, ihre Geschwindigkeit begrenzen oder ihren Zugriff auf bestimmte Pfade beschränken.

Ein wichtiges Merkmal dieses Ansatzes: Die Prüfung hängt nicht von der IP-Adresse ab; von welchem Server der Agent auch läuft, die Signatur verweist auf denselben Betreiber. Auch das Schlüsselverzeichnis selbst ist signiert, was es erschwert, sich mit einem gefälschten Verzeichnis als Betreiber auszugeben.

Seit dem 1. Juli 2026 behandelt Cloudflare Agenten, die sich auf diese Weise kryptografisch ausweisen, in seiner Klassifizierung verifizierter Bots. In der Praxis heißt das, dass Websitebetreiber in ihren Bot-Schutzregeln einen eigenen Weg für verifizierte Agenten öffnen können.

Neue Protokolle auf der Zahlungsseite#

Dass ein Agent eine Website erreichen kann, ist die Hälfte des Problems. Die andere Hälfte ist die Prüfung seiner Befugnis zu zahlen. Seit 2025 sind in diesem Bereich mehrere Protokolle entstanden. Sie sind weniger Konkurrenten als Protokolle, die sich auf verschiedene Schritte des Ablaufs konzentrieren:

• Visa Trusted Agent Protocol: Laut der Ankündigung von Visa beruht das im Oktober 2025 vorgestellte Protokoll auf dem Standard HTTP Message Signatures, ist auf Web Bot Auth abgestimmt und wurde gemeinsam mit Cloudflare entwickelt. Ziel ist, dass Händler von Visa anerkannte Agenten mit Kaufabsicht von bösartiger Automatisierung unterscheiden können.
• Agentic Commerce Protocol (ACP): eine offene Spezifikation, die von OpenAI und Stripe gepflegt wird. Laut der Projektseite standardisiert es den Kaufablauf zwischen Käufer, Agent, Händler und Zahlungsanbieter; der Agent zeigt dem Nutzer die Kassenoberfläche, während der Händler seine eigene Infrastruktur und Zahlungsabwicklung behält.
• Agent Payments Protocol (AP2): Das von Google mit Partnern angekündigte Protokoll will die Befugnis eines Agenten, im Namen des Nutzers zu zahlen, mit kryptografisch signierten Autorisierungsdokumenten übermitteln. So können Händler und Zahlungsunternehmen prüfen, ob die Transaktion innerhalb der vom Nutzer genehmigten Grenzen liegt.

Einige dieser Protokolle sind noch in der Beta-Phase, und ihr Umfang ändert sich schnell. Planen Sie eine Integration, prüfen Sie die aktuelle Dokumentation des jeweiligen Protokolls.

Wer löst was?#

Was können Händler tun?#

Agentenverkehr komplett zu blockieren oder komplett offen zu lassen, ist für einen Händler womöglich nicht richtig. Ein schrittweiser Ansatz ist gesünder:

1. Messen Sie den Verkehr. Sehen Sie, wie viel des automatisierten Verkehrs auf Ihrer Website von Suchmaschinen, bekannten KI-Crawlern und Automatisierung unbekannter Identität stammt.
2. Schreiben Sie Ihre Richtlinie. Legen Sie fest, welche Agenten welche Seiten (Katalog, Warenkorb, Kasse) erreichen dürfen. Katalogseiten offen zu halten und die Kasse an verifizierte Protokolle zu binden, ist ein verbreiteter Ausgangspunkt.
3. Aktualisieren Sie robots.txt und Ihre Bedingungen. Halten Sie Ihre Präferenzen für Agenten sowohl maschinenlesbar als auch klar in Ihren Nutzungsbedingungen fest. Wie die Datei geschrieben wird, erklären wir in Was ist robots.txt und wie liest man die Datei?.
4. Erkennen Sie signierte Agenten. Nutzen Sie die Einstellungen Ihres Bot-Management-Dienstes für verifizierte Agenten; bewerten Sie Agentenverkehr mit geprüfter Identität getrennt von Verkehr unbekannter Identität.
5. Bieten Sie strukturierte Daten an. Schema.org-Daten auf Produktseiten und, falls vorhanden, offizielle Produkt-Feeds lassen Agenten korrekte Informationen erreichen, ohne die Seite scrapen zu müssen.
6. Verfolgen Sie die Agentenprotokolle Ihrer Zahlungspartner. Unterstützt Ihr Zahlungsanbieter diese Protokolle, lassen sich von Agenten ausgelöste Transaktionen in einem von Betrugsregeln getrennten Ablauf behandeln.

Für Aufgaben wie das Überwachen von Agenten- und Bot-Verkehr auf Ihrer eigenen Website und das Prüfen von Anzeigen- und Preisansichten aus verschiedenen Ländern sehen Sie sich die Szenarien auf unseren Seiten zur E-Commerce-Proxy-Lösung und zur Anzeigenverifizierung an.

Der richtige Weg für Agentenentwickler#

Entwickeln Sie einen Shopping-Agenten, ist die falsche Antwort auf Blockierungen, den Agenten besser zu verstecken. Den Browser-Fingerprint zu fälschen, Prüfbildschirme lösen zu lassen oder Verkehr über Proxy-Pools zu verteilen, um den Bot-Schutz zu umgehen, verstößt gegen die Regeln der Websites und stellt Ihren Agenten genau in die Klasse von Verkehr, die blockiert werden soll. Wie Browser-Fingerprinting funktioniert, erklären wir in Browser-Fingerprinting, warum Prüfbildschirme erscheinen, in Puppeteer und CAPTCHA.

Der richtige Weg führt über diese Schritte:

• Weisen Sie Ihren Agenten aus. Nutzen Sie einen User-Agent mit festgelegtem Produkttoken und Kontaktadresse; signieren Sie Ihre Anfragen nach Möglichkeit mit Web Bot Auth.
• Bevorzugen Sie offizielle Integrationen. Hat der Händler eine API, einen Produkt-Feed oder ein unterstütztes Kaufprotokoll, nutzen Sie diese statt Seiten zu scrapen.
• Befolgen Sie robots.txt und die Bedingungen. Erzwingen Sie keine Pfade, die eine Website für Agenten gesperrt hat, auch nicht im Auftrag eines Nutzers.
• Machen Sie die Freigabe durch den Nutzer zum Teil des Ablaufs. Holen Sie vor unumkehrbaren Schritten wie der Zahlung die ausdrückliche Zustimmung des Nutzers ein; Ausgabenlimits legt der Nutzer fest, nicht der Agent.
• Begrenzen Sie die Geschwindigkeit. Für den Einkauf eines Nutzers müssen Sie nicht Dutzende Seiten in Sekunden öffnen.
• Akzeptieren Sie Misserfolge. Blockiert eine Website Ihren Agenten, sagen Sie das dem Nutzer klar und bieten Sie eine Alternative; versuchen Sie nicht, die Sperre zu umgehen.

Wie Sie den Webzugriff von Agenten mit Rate-Limits, Positivlisten und Protokollierung sicher machen, erklären wir in Sicherer Webzugriff für LLMs: Rate-Limits und Berechtigungen. In diesem Aufbau dient ein Proxy nicht dazu, den Agenten zu verstecken, sondern zu steuern und zu protokollieren, von welcher Adresse und welchem Standort Agentenverkehr ausgeht.

Häufige Fehler#

• Den Agenten menschlich wirken lassen wollen. Ein gefälschter Fingerprint und IP-Rotation stellen den Agenten in dieselbe Klasse wie bösartige Bots.
• Als Händler allen automatisierten Verkehr als eine Kategorie behandeln. Verifizierte Agenten nicht von Bots unbekannter Identität zu trennen, kann legitime Vertriebswege schließen.
• Den User-Agent-Header als Authentifizierung behandeln. Jeder kann den Header schreiben; die Prüfung braucht eine Signatur.
• Ohne Freigabe des Nutzers bezahlen. Das löst Betrugsregeln aus und schafft ein ernstes Vertrauensproblem beim Nutzer.
• Eine Integration planen, ohne den Stand der Protokolle zu prüfen. Die meisten Protokolle in diesem Bereich ändern sich schnell.
• Eine Sperre als technischen Fehler behandeln. Meist ist sie eine bewusste Richtlinie der Website.

Entscheidungshilfe#

Häufig gestellte Fragen#

Warum stoßen KI-Shopping-Agenten auf Prüfbildschirme?#

Bot-Schutzsysteme bewerten Agentenverkehr mit Signalen wie Geschwindigkeit, Browsermerkmalen und IP-Quelle. Weil Agenten bei diesen Signalen wie bösartige Automatisierung aussehen, stoßen sie auf Prüfbildschirme oder Sperren. Solange die Anfrage keine überprüfbare Information darüber trägt, wer dahintersteht, kann die Website beide nicht unterscheiden.

Was ist Web Bot Auth?#

Ein Ansatz, mit dem Bots und Agenten ihre Identität nachweisen, indem sie ihre HTTP-Anfragen kryptografisch signieren. Er nutzt den Standard RFC 9421 HTTP Message Signatures. Der Agent veröffentlicht seinen öffentlichen Schlüssel auf seiner eigenen Domain, und Website oder CDN prüfen die Signatur jeder Anfrage mit diesem Schlüssel.

Funktioniert ein signierter Agent auf jeder Website?#

Nein. Eine Signatur beweist nur, wer der Agent ist; sie gewährt keinen Zugang zur Website. Jede Website entscheidet, wie weit sie signierte Agenten zulässt. Auf Websites, die Signaturen nicht prüfen, hat die Signatur keine Wirkung.

Kann mein Agent eine Sperre mit einem Proxy umgehen?#

Den Bot-Schutz durch IP-Wechsel über einen Proxy umgehen zu wollen, heißt, eine ausdrückliche Präferenz der Website zu ignorieren, und stellt Ihren Agenten in dieselbe Kategorie wie bösartige Automatisierung. Die legitime Nutzung eines Proxys ist hier, den Ausgang des Agentenverkehrs zu steuern und zu protokollieren und bei Bedarf von einem bestimmten Standort aus zu erscheinen.

Sollten Händler Agentenverkehr komplett blockieren?#

Das ist eine geschäftliche Entscheidung. Komplettes Blockieren senkt das Betrugsrisiko, kann aber Kunden kosten, die Agenten nutzen. Für viele Händler ist der ausgewogene Weg, Katalogseiten offen zu halten, verifizierte Agenten mit eigenen Regeln zu steuern und die Kasse an unterstützte Protokolle zu binden.

Werden diese Protokolle in Türkiye genutzt?#

Die meisten dieser Protokolle sind neu, und ihr Umfang sowie ihre regionale Unterstützung ändern sich schnell. Als Händler oder Entwickler in Türkiye fragen Sie am zuverlässigsten direkt Ihren eigenen Zahlungsanbieter und Ihr CDN, welche Protokolle zur Agentenprüfung und Zahlung sie unterstützen.

Fazit#

KI-Shopping-Agenten werden auf Websites blockiert, weil Bot-Schutzsysteme einen für einen Nutzer arbeitenden Agenten nicht von bösartiger Automatisierung unterscheiden können und Zahlungssysteme nicht prüfen können, ob der Agent mit der Befugnis des Karteninhabers handelt. Die Lösung ist nicht, den Agenten zu verstecken, sondern ihn sich überprüfbar ausweisen zu lassen: Signierte Anfragen mit Web Bot Auth auf Basis von RFC 9421, Rahmen für anerkannte Agenten wie das Visa Trusted Agent Protocol sowie Kauf- und Zahlungsautorisierungsprotokolle wie ACP und AP2 gehen in diese Richtung. Händler sollten Agentenverkehr messen und eine Richtlinie festlegen, Agentenentwickler auf offizielle Integrationen und die Freigabe durch den Nutzer setzen. Um Preis- und Inhaltsansichten von verschiedenen Standorten regelkonform zu prüfen, sehen Sie sich unsere Seite zur Preisbeobachtung an.