Die Verteidigungsmechanismen des Webs wurden um eine einfache Trennung herum gebaut: Menschen auf der einen Seite, Automatisierung auf der anderen. Ein KI-Agent ist keines von beidem. Er handelt auf Anfrage einer Person, läuft aber auf einem Server, liest in Maschinengeschwindigkeit und kommt oft von einer Cloud-IP. Für Teams, die KI-Agenten bauen, die das Web nutzen, ist das Ergebnis ein Fehlschlag, mit dem niemand geplant hat: Der Agent stößt auf eine Wand, und was als Nächstes passiert, hängt von Details ab, die die meisten Tool-Schichten ignorieren.
Dieser Leitfaden erklärt, warum Agenten zwischen die Kategorien fallen, wie die Wand von innerhalb eines Tool-Aufrufs aussieht, und wie man einen Agenten baut, der ehrlich damit umgeht.
Weder Crawler noch Mensch
Anbieter beschreiben diese Agenten mittlerweile als eigene Klasse. OpenAI sagt, ChatGPT-User werde “nicht zum automatischen Crawlen des Webs verwendet”. Google sagt, Google-Agent werde verwendet, “um auf Anfrage des Nutzers im Web zu navigieren und Aktionen auszuführen”. Anthropic hat einen Claude-User-Agent für den Fall, dass Personen Claude Fragen stellen.
Die Regeln haben nicht Schritt gehalten, und die Anbieter sind sich nicht einig:
| Anbieter | Nutzerausgelöste Abrufe und robots.txt |
|---|---|
| OpenAI | ”robots.txt rules may not apply” |
| ”generally ignore robots.txt rules” | |
| Anthropic | Seine Bots respektieren robots.txt-Anweisungen |
RFC 9309 fügt hinzu, dass robots.txt-Regeln “keine Form der Zugriffsautorisierung” sind, also waren sie nie dazu gedacht, dies allein zu klären. Gleichzeitig wächst der Traffic: Cloudflare berichtet, dass KI-”User-Action”-Crawling 2025 um mehr als das 15-fache zugenommen hat, und der Bad Bot Report 2026 von Thales beziffert Bots auf über 53% des gesamten Traffics im Jahr 2025. Seiten haben mehr Grund denn je, Automatisierung zu filtern, und Agenten geraten in diesen Filter.
Wie die Wand von einem Tool-Aufruf aus aussieht
| Was zurückkommt | Was es bedeutet | Was der Agent tun sollte |
|---|---|---|
| 200 mit einer Challenge-Seite | Ein Bot-Check, nicht die Seite | Melden, dass die Seite nicht gesehen werden konnte |
| 401 oder eine Login-Seite | Der Inhalt erfordert ein Konto | Den Nutzer bitten, sich anzumelden |
| 402 | Die Seite verlangt Zahlung | Vor jeder Zahlung nachfragen |
| 403 | Der Server verweigert | Melden, und die Seite nicht bombardieren |
| 429 | Zu viele Anfragen | Retry-After respektieren, oder stoppen |
| 404 oder 410 | Die Seite existiert nicht | Nicht erneut versuchen |
Die erste Zeile ist die gefährliche. Ein 403 sieht zumindest wie ein Fehlschlag aus. Eine Challenge-Seite kommt oft als ein 200 mit einem wohlgeformten HTML-Body an, sodass ein einfaches Fetch-Tool sie dem Modell übergibt, als wäre es der Artikel.
Das ist wichtig wegen des Verhaltens von Modellen bei schlechter Tool-Ausgabe. Ein Preprint vom September 2026 zu tool-gestützten Agenten fand heraus, dass bei einer Tool-Rückgabe von status:error Unehrlichkeit nicht vorkam (0,0%), aber bei einer Rückgabe von status:ok mit einem geschwärzten, beschädigten, veralteten, fehlerhaften, leeren oder abgeschnittenen Wert erreichte sie 45,3%. Diese Studie testete interne Systeme statt Webseiten, daher ist die Anwendung auf Block-Seiten unsere Schlussfolgerung. Dennoch gilt die Lehre auch hier: Ein ehrlicher Fehler ist weitaus sicherer als ein Erfolg, der nichts Nützliches enthält. Wir haben auch behandelt, wie Challenge-Seiten das verfälschen, was KI-Tools produzieren.
Ein Fetch-Tool, das die Wahrheit sagt
Die Lösung gehört in die Tool-Schicht. Die folgende Funktion klassifiziert jede Antwort, bevor das Modell sie sieht, und gibt Seitentext nur zurück, wenn die Seite echt ist. Sie benötigt nur requests. Wir haben sie unter Python 3.9 gegen einen lokalen Testserver laufen lassen, der jeden Fall zurückgibt.
from __future__ import annotations
from dataclasses import asdict, dataclass
import requests
# Text that marks a page as a wall, not content. Extend it from your own logs.
WALL_MARKERS = ("verify you are human", "unusual traffic", "enable javascript and cookies",
"attention required", "access denied", "captcha")
LOGIN_MARKERS = ("sign in to continue", "log in to continue")
@dataclass
class FetchResult:
outcome: str # ok, wall, login, payment, rate_limited, not_found, error
status: int | None
text: str # only ever page content, empty unless outcome is ok
retry_after: str | None
note: str # what the model should be told
NOTES = {
"wall": "The site showed a bot check. You did not see this page. Say so, do not guess its content.",
"login": "This page needs a login. Ask the user to sign in or to provide the content.",
"payment": "The site asks for payment (HTTP 402). Ask the user before paying anything.",
"rate_limited": "The site asked you to slow down. Wait, or tell the user it is unavailable now.",
"not_found": "The page does not exist. Do not retry it.",
"error": "The fetch failed. You did not see this page. Say so, do not guess its content.",
"ok": "",
}
def classify(status, body):
low = body.lower()
if status == 402:
return "payment"
if status == 429:
return "rate_limited"
if status in (404, 410):
return "not_found"
if any(m in low for m in WALL_MARKERS): # walls often arrive with a 200
return "wall"
if status in (401, 403):
return "login" if status == 401 or any(m in low for m in LOGIN_MARKERS) else "wall"
if status == 200 and any(m in low for m in LOGIN_MARKERS):
return "login"
return "ok" if status == 200 else "error"
def agent_fetch(url, agent_name="example-agent/1.0 (+https://example.com/agent)"):
"""A fetch tool that never hands the model a block page as if it were content."""
try:
r = requests.get(url, headers={"User-Agent": agent_name}, timeout=(10, 30))
except requests.RequestException as exc:
return FetchResult("error", None, "", None, f"{NOTES['error']} ({type(exc).__name__})")
outcome = classify(r.status_code, r.text)
return FetchResult(outcome, r.status_code, r.text if outcome == "ok" else "",
r.headers.get("Retry-After"), NOTES[outcome])Ausgabe, als Status, Outcome, ob das Modell Seitentext erhält, und Retry-After:
/article 200 ok content
/challenge 200 wall -
/blocked 403 wall -
/members 200 login -
/priced 402 payment -
/busy 429 rate_limited - 120
/gone 404 not_found -
/broken 503 error -
(no server)None error -Nur einer der neun Fälle gibt dem Modell überhaupt Seitentext. Die /challenge-Zeile ist diejenige, bei der ein einfaches Fetch falschliegt, da ein 200 zurückgegeben wurde. Betrachten Sie die Markerlisten als Ausgangspunkt und erweitern Sie sie anhand Ihrer eigenen Logs, denn keine Liste erfasst jede Wand. Wenn Sie Tools über einen MCP-Server bereitstellen, hat die Spezifikation dafür einen Platz: Ausführungsfehler werden mit isError: true gemeldet, und Clients “SHOULD provide tool execution errors to language models”.
Das CAPTCHA nicht lösen
Bei diesem Punkt sind sich die Anbieter ungewöhnlich einig. OpenAI beschrieb Operator als darauf trainiert, den Nutzer bei Logins, Zahlungsdetails und CAPTCHAs um Übernahme zu bitten. Anthropics Claude-in-Chrome-Dokumentation besagt, dass er bei einer Login-Seite oder einem CAPTCHA “pausiert und Sie bittet, es manuell zu erledigen”. Googles empfohlene Anweisungen zur Computernutzung besagen: “You MUST NEVER attempt to solve or bypass” eine Liste, die “CAPTCHAs (of any kind)” einschließt.
Ein CAPTCHA ist eine Seite, die nach einem Menschen fragt, also ist die richtige Reaktion, an einen zu übergeben. Das ergibt auch ein besseres Produkt: Die Person weiß, was passiert ist, und kann entscheiden.
Identität ist der Weg hindurch
Die langfristige Antwort besteht darin, dass Agenten auf überprüfbare Weise sagen, wer sie sind. Web Bot Auth ermöglicht es einem Client, seine Anfragen kryptografisch mit HTTP Message Signatures zu signieren. OpenAI signiert bereits Anfragen von seinem Cloud-Browser mit einem Signature-Agent-Header, der auf https://chatgpt.com gesetzt ist, und Google sagt, es experimentiere mit dem Protokoll. Cloudflare führte im August 2025 eine Kategorie für signierte Agenten ein und unterscheidet seit Juli 2026 zwischen direktem und vermitteltem Zugriff gegenüber verifizierten Bots. Die IETF-Arbeit ist noch ein Entwurf, also sind Änderungen zu erwarten.
Wenn Sie heute einen Agenten bauen, senden Sie einen beschreibenden User-Agent mit Kontaktdaten, veröffentlichen Sie, was Ihr Agent tut, und planen Sie für das Signieren.
Die rechtliche Lage ist ungeklärt
Der erste große Fall zeigt, wie offen das ist. Amazon verklagte Perplexity im November 2025 wegen seines agentischen Browsers und warf Verstöße gegen den US Computer Fraud and Abuse Act und dessen kalifornisches Äquivalent vor, und das Urteil besagt, der Kern des Streits sei Perplexitys Entscheidung gewesen, keinen User-Agent-String zu verwenden. Im August 2026 hob der Ninth Circuit eine einstweilige Verfügung auf und stellte fest, dass es unwahrscheinlich sei, dass Amazon zeigen könne, dass Perplexity seine Computer im Sinne dieses Gesetzes “zugegriffen” habe.
Das Gericht war vorsichtig damit, wie weit das reicht: “We do not establish a new legal regime governing agentic AI.” Es sagte auch, das Ergebnis beeinträchtige nicht Amazons Fähigkeit, den Zugriff über seine Nutzungsbedingungen zu regeln. Dies war also keine Lizenz für Agenten, die Wünsche einer Seite zu ignorieren. Dies sind allgemeine Informationen, keine Rechtsberatung, und der Fall ist an das Bezirksgericht zurückverwiesen worden.
Für die Wand bauen
- Davon ausgehen, dass Wände normal sind. Gestalten Sie den Plan des Agenten rund um Seiten, die er nicht erreichen kann, mit Fallbacks wie einer anderen Quelle oder dem Nachfragen beim Nutzer.
- Klassifizieren, bevor das Modell etwas sieht. Verwenden Sie ein Tool wie das obige, und protokollieren Sie die Ergebnisse, damit Sie sehen können, welche Seiten fehlschlagen.
- Offizielle Wege zuerst anbieten. Wo eine Seite eine API oder ein Datenprodukt hat, nutzen Sie es. Es ist zuverlässiger als eine Browser-Sitzung.
- Sitzungen konsistent halten. Mehrstufige Aufgaben brechen, wenn sich die IP mitten im Vorgang ändert. Unser Leitfaden zu Proxys für KI-Agenten, die das Web durchsuchen behandelt Rotation und Sticky Sessions.
- Wissen, wofür ein Proxy da ist. Residential Proxies helfen einem Agenten, öffentliche Seiten so zu sehen, wie lokale Besucher sie sehen, im richtigen Land und von einer konsistenten Adresse aus. Sie ändern nicht, was eine Seite erlaubt, und sind kein Weg an einer Seite vorbei, die Nein gesagt hat. Wenn eine Seite einen Login, eine Zahlung oder eine Person möchte, respektieren Sie das.
Fazit
Agenten erreichten das Web, bevor das Web eine Kategorie für sie hatte, und vorerst ist die Wand Teil der Aufgabe. Behandeln Sie sie als normales Ergebnis: klassifizieren Sie sie in der Tool-Schicht, sagen Sie dem Modell und dem Nutzer die Wahrheit, geben Sie CAPTCHAs an Menschen zurück, und identifizieren Sie Ihren Agenten. Ein Agent, der sagt “Ich konnte diese Seite nicht sehen”, ist weit mehr wert als einer, der rät.
Quellen und Referenzen
- OpenAI, Bots-Dokumentation: developers.openai.com
- OpenAI, Allowlisting für ChatGPT Works Cloud-Browser: help.openai.com
- OpenAI, Introducing Operator (23. Januar 2025): openai.com
- Google, nutzerausgelöste Fetcher: developers.google.com
- Google, Gemini Computer Use: ai.google.dev
- Anthropic, zum Crawlen und wie Seitenbetreiber blockieren können: support.claude.com
- Anthropic, Claude in Chrome: code.claude.com
- Cloudflare, signierte Agenten (28. August 2025, Dokumentation aktualisiert November 2026): blog.cloudflare.com, developers.cloudflare.com
- Cloudflare Radar 2025 Year in Review: blog.cloudflare.com
- Thales, Bad Bot Report 2026: cpl.thalesgroup.com
- IETF, Web Bot Auth Protokollentwurf: datatracker.ietf.org
- RFC 9309, Robots Exclusion Protocol: rfc-editor.org
- RFC 9110 und RFC 6585, HTTP-Statuscodes: rfc-editor.org, rfc-editor.org
- Model Context Protocol, Tools-Spezifikation: modelcontextprotocol.io
- Sethi et al., Fabrication After Tool Failure (Preprint, September 2026): arxiv.org/abs/2609.14758
- Ninth Circuit, Amazon.com Services v. Perplexity AI, No. 26-1444 (4. August 2026): uscourts.gov