Das Web benotet jetzt seine CrawlerTrust Bands, der 429 als Vertrag und wie ein guter Crawler heute aussieht

Fast die gesamte Geschichte des Webs hindurch wurde ein Crawler einmal beurteilt, an der Tür. Ein Server sah sich den User-Agent an, vielleicht die IP, und entschied, ob die Anfrage hineindarf oder nicht. Was der Crawler danach tat, ging niemanden etwas an, bis eine Site in die Knie ging, und selbst dann landete die Beschwerde in einem Abuse-Postfach, das niemand las.

In der dritten Oktoberwoche 2026 änderte sich das, dreimal in vier Tagen. Am 13. Oktober dokumentierte Google, dass sein Fetcher Google-Agent einen Teil seiner Anfragen mit Web Bot Auth signiert. Am 15. und 16. Oktober las ein Forschungs-Crawler, der sich mit einer Roblox-Adresse auswies, die robots.txt von drei Hobby-Sites für 3D-Modelle, ignorierte sie und zog 145,5 GB. Und am 16. Oktober kündigte Cloudflare an, dass Verified bots von nun an laufend danach bewertet werden, ob sie robots.txt respektieren und ob sie langsamer werden nach einem 429.

Zusammengenommen beschreiben diese drei Ereignisse die neue Regel. Identität bringt Sie durch die Tür. Verhalten entscheidet, ob Sie nächsten Monat noch willkommen sind. Für jeden, der einen Crawler betreibt, lautet die Frage nicht mehr „Darf ich das abrufen?“, sondern „Was wird in der Akte über mich stehen?“

Drei Dinge, die in einer Woche passiert sind

Zuerst der Crawler. Open3DLab, SFMLab und SmutBase sind drei kleine Sites, die von denselben Leuten betrieben werden und nutzergemachte 3D-Modelle hosten. Am 26. Oktober veröffentlichten sie ihre Logs: über 34 Stunden am 15. und 16. Oktober stellte ein Client, der sich trellis2-data-sourcing/1.0 (3D foundation model research; [redacted]@roblox.com) nannte, 26.429 Anfragen von einer einzigen AWS-Adresse, las die Seiten von 18.926 Projekten und lud 1.027 Dateien aus 712 davon herunter. Er rief robots.txt ab und hielt sich nicht daran. 423 der Projekte waren ausschließlich für nicht-kommerzielle Nutzung lizenziert. Als die Sites ihn am 18. Oktober sperrten, kam er am 19. wieder und am 20. noch einmal und, in den Worten der Sites, „reduzierte seine Download-Versuche angesichts unserer Sperren nicht“. Roblox erklärte laut einer später berichteten Stellungnahme, der Agent eines Forschers habe die Sites versehentlich gescrapt und sei stillgelegt worden.

Nichts an diesem Crawler war versteckt. Er hatte einen User-Agent mit einer E-Mail-Adresse darin. Er kam von einer einzigen IP. Nach den Maßstäben des Verified-bots-Programms war er ehrlich, was seine Identität angeht. Er zeigte aber auch genau das Verhalten, das dieses Programm jetzt misst und bestraft, und die Sites konnten es aus ihren eigenen Logs belegen. Deshalb landete die Geschichte auf der Titelseite von Hacker News statt in einem Abuse-Postfach.

Cloudflares Ankündigung, veröffentlicht am Tag nach dem Hauptlauf des Crawlers, ist knapp beim Mechanismus und präzise bei der Absicht. „Continuous accountability for Verified bots“ beschreibt zwei erste Signale. Das erste fragt, ob der beobachtete Traffic eines Bots über die Zeit mit den veröffentlichten Präferenzen der Site übereinstimmt, mit RFC 9309 als Referenz dafür, wie robots.txt zu lesen ist. Das zweite fragt, was passiert, nachdem eine Site einen 429 zurückgibt: „Wird er langsamer, pausiert er, oder schickt er weiter Anfragen im selben Tempo?“ Die Ergebnisse fließen in ein „erklärbares Trust Band“, ein Label, das der Beitrag bewusst eine Historie nennt und kein Urteil, weil „einzelne Verstöße“ wenig zählen und „wiederholte Verhaltensmuster, die Site-Präferenzen missachten“ viel. Die Scores werden auf Radar veröffentlicht, und Site-Betreiber können wählen, ab welchem Band Verified-Traffic noch durchgelassen wird.

Googles Beitrag ist leiser und in mancher Hinsicht folgenreicher. Seine Seite zu Web Bot Auth, aktualisiert am 13. Oktober, sagt, dass ein Teil der Anfragen von Google-Agent, dem Fetcher hinter den auf Google-Infrastruktur gehosteten Agenten, signiert ist und sich als https://agent.bot.goog authentifiziert. Die Implementierung ist als experimentell markiert. Aber die Google-Agent-Seite steht in der Liste der nutzerausgelösten Fetcher, und die Anleitung für diese Liste hat sich nicht geändert: „Weil der Abruf von einem Nutzer angefordert wurde, ignorieren diese Fetcher in der Regel die robots.txt-Regeln.“ Der größte Crawler-Betreiber der Welt signiert also jetzt Anfragen eines Agenten, der laut eigener Dokumentation die Datei nicht liest, nach der alle anderen bewertet werden. Das ist keine Heuchelei; es ist die Form des Streits, der noch kommt. Signaturen klären, wer eine Anfrage geschickt hat. Sie sagen nichts darüber, ob die Anfrage willkommen war.

Was ein Trust Band tatsächlich misst

Es hilft, beim Maßstab konkret zu werden. Auf der Cloudflare Connect, die vom 19. bis 21. Oktober stattfand, sagte Matthew Conroy, Senior Director of Product Management des Unternehmens, dass Agenten mehr als 600 Milliarden Anfragen im letzten Quartal über sein Netzwerk gestellt haben, fast das Vierfache des Werts von Ende 2025, und dass „weniger als eine von zehn automatisierten Anfragen von einem Bot kommt, der sich zu erkennen gibt“. Matthew Princes Prognose in derselben Session: Agenten-Traffic werde innerhalb von fünf Jahren das Tausendfache des menschlichen Traffics erreichen, mit dem Vorbehalt, dass seine früheren Vorhersagen alle zu konservativ gewesen seien. DataDomes Q3-Bericht, veröffentlicht am 15. Oktober, liefert das Detail, das erklärt, warum Identität plötzlich ein Produkt ist: In einer Stichprobe des Traffics von Metas Muse-Agent kamen 99,3% der Anfragen aus Cloud- und CDN-Bereichen, 81,2% davon aus Cloudflares eigenen, und der Agent gibt sich nicht zu erkennen. IP-Reputation, das Werkzeug, auf das sich die ganze Branche zwanzig Jahre lang gestützt hat, kann einen Agenten nicht vom Edge-Netzwerk unterscheiden, auf dem er läuft.

Die Bewertung muss sich also auf Verhalten stützen, und Verhalten muss über die Zeit beobachtet werden. Genau das ist das Trust Band. Als technische Spezifikation gelesen statt als Policy-Beitrag hat es vier Eingaben.

Identität ist die Voraussetzung, nicht der Score. Web Bot Auth, das Ed25519-Signaturverfahren, das wir behandelt haben, als es zusammen mit Pay-per-Crawl erschien, ist seit September ein Working-Group-Dokument der IETF und trägt seit der Überarbeitung vom 29. Oktober den Namen draft-ietf-webbotauth-httpsig-protocol-01. OpenAI und AWS signieren; Google experimentiert; Cloudflares eigene Web Search API, gestartet am 2. Oktober mit Ceramic.ai, Exa und Linkup dahinter, merkt an, dass sich alle drei „zu Cloudflares Verified-Bot-Crawling-Standards verpflichtet haben“. Ohne stabile Identität gibt es nichts, woran sich eine Historie heften ließe, weshalb unsignierter Traffic gar nicht bewertet wird. Er ist schlicht die Default-Deny-Klasse.

Veröffentlichte Präferenzen sind das erste Signal, und das Vokabular ist noch in Bewegung. RFC 9309 ist die Basis: Gruppen, Allow und Disallow, der längste Treffer gewinnt. Darüber liegen Cloudflares Content Signals, die den Zweck statt den Pfad transportieren: search, ai-input, ai-train und seit dem 31. August ein viertes Feld, use, mit den Werten reference und full. Cloudflares eigener Crawl-Endpunkt weist eine Anfrage inzwischen mit einem 400 ab, wenn das deklarierte contentUse des Crawlers freizügiger ist als das der Site. Die parallele Anstrengung der IETF, das AI-Preferences-Vokabular, erreichte am 14. September Draft 08 und ist weiterhin ein Internet-Draft; der August-Meilenstein der Working Group verstrich ohne Standard. Die Bewertung hat, mit anderen Worten, begonnen, bevor die Grammatik fertig war.

Reaktion auf Feedback ist das zweite Signal und das, an dem die meisten Crawler scheitern, ohne es zu merken. Ein 429 ist kein Fehler, den man wiederholt; er ist eine Anweisung, und wenn er Retry-After mitbringt, ist er eine Anweisung mit einer Zahl darin. Cloudflares Beitrag sagt es unverblümt: Langsamer werden oder pausieren nach einem 429 „erhöht das Vertrauen, während wiederholtes Ignorieren des Signals es senkt“. Die meisten Retry-Bibliotheken tun das Gegenteil. Sie wiederholen die gescheiterte Anfrage mit kurzer Verzögerung und lassen die Parallelität, die den 429 ausgelöst hat, genau da, wo sie war.

Effizienz ist noch nicht Teil der ersten Bewertung und wird es werden. Cloudflares Pressemitteilung vom Juli behauptete, „über 50% des Crawl-Traffics von KI-Crawlern entfallen auf das erneute Abrufen unveränderter Seiten“, und sein Pilot mit OpenAI, der seit Juli auf etwa 1% seines Netzwerks läuft, liefert dem Crawler Änderungssignale und filtert Seiten heraus, die nicht existieren oder nur weiterleiten. Der Beitrag meldet Hunderte Millionen neu entdeckter Seiten, und einen Satz, den man sich merken sollte: „Ein Signal über eine Seite erteilt keine Erlaubnis, auf sie zuzugreifen.“ Die Signale werden für Crawler gebaut, die sich bereits benehmen; sie sind kein Weg hinein.

Hinter allen vier steht Geld. Pay Per Use, seit dem 30. September in der Beta, bezahlt einen Publisher, wenn ein KI-Unternehmen meldet, dass es eine Seite genutzt hat, nicht wenn es sie abgerufen hat, denn, wie Cloudflare es formuliert, „wer für jeden Crawl kassiert, lässt den Käufer zahlen, bevor er weiß, was er braucht“. Monetization Gateway, vom selben Tag, beantwortet eine Anfrage mit 402 Payment Required und einem Preis, abgerechnet über das x402-Protokoll. Beide brauchen einen Käufer mit verifizierbarer Identität und sauberer Historie. Das Trust Band ist die Bonitätsnote für diesen Markt.

Was Sites verlangen, heute Morgen gemessen

Wie viel davon ist in der Praxis schon in der robots.txt angekommen? Am 30. Oktober haben wir robots.txt der 2.000 Top-Domains der Tranco-Liste mit einem als Forschungs-Crawler ausgewiesenen User-Agent abgerufen, eine Anfrage pro Host. 1.130 lieferten eine lesbare Datei. Der Rest waren API- und CDN-Hosts, die nichts zu sagen hatten, 434 Namen, die gar nicht antworteten, und 145, die einem Crawler, der sich vorgestellt hatte, mit 403 antworteten, was für sich genommen ein kleiner Befund ist.

Zwei Details zählen mehr als die Schlagzeile. Erstens wird der Zweck bereits von Hand aufgetrennt: Von den 208 Sites, die GPTBot komplett sperren, nennen 21 OAI-SearchBot und lassen ihn durch, und 18 tun dasselbe für ChatGPT-User. Betreiber sagen „indexier mich, zitier mich, trainier nicht auf mir“ mit dem einzigen Vokabular, das sie haben, nämlich ein User-Agent pro Zweck. Zweitens: Von den 71 Sites, die Content-Signal als Zeile enthalten, tragen 39 die identische Zeile search=yes, ai-train=no, use=reference, und das ist Cloudflares verwalteter Standardwert. Das neue Vokabular kommt über das CDN an, nicht über die Editoren der Site-Betreiber, und 35% der Dateien, die wir abgerufen haben, kamen mit dem Header cf-ray zurück. Das ist der Mechanismus, durch den ein Scoreboard zu den Regeln wird.

Eine Fetch-Schleife, die besteht

Keine der vier Gewohnheiten ist schwierig. Schwierig ist, sie durchzuhalten, wenn ein Crawl spät dran ist und die Queue voll, und deshalb gehören sie in den Fetcher und nicht in ein Runbook. Was folgt, ist eine 226 Zeilen lange Referenzschleife in Standardbibliotheks-Python, zitiert in den vier Teilen, auf die es ankommt, ausgeführt gegen einen lokalen Origin mit eigener Meinung: eine robots.txt , die /private/ verbietet, ein ETag auf jeder Seite und ein 429 mit Retry-After: 2 für jeden Client über zwei Anfragen pro Sekunde.

Die Regeln lesen, bevor die erste Anfrage rausgeht

RFC 9309 sagt, ein Crawler, der robots.txt liest, muss sie befolgen, darf sie cachen und sollte die gecachte Kopie nicht länger als 24 Stunden behalten. Er sagt auch, was zu tun ist, wenn die Datei nicht lesbar ist: Ein 4xx bedeutet, es gibt keine Regeln, ein 5xx oder ein Netzwerkfehler bedeutet, gehen Sie davon aus, dass Sie nicht dürfen, und versuchen Sie es später noch einmal. Der Cache unten tut genau das, pro Host, und stellt Crawl-delay bereit, damit das Budget ihn nutzen kann.

def _load(self, scheme: str, host: str) -> urllib.robotparser.RobotFileParser | None:
    url = f"{scheme}://{host}/robots.txt"
    req = urllib.request.Request(url, headers={"User-Agent": self.user_agent})
    parser = urllib.robotparser.RobotFileParser(url)
    try:
        with urllib.request.urlopen(req, timeout=10) as resp:
            parser.parse(resp.read().decode("utf-8", "replace").splitlines())
            return parser
    except urllib.error.HTTPError as e:
        if 400 <= e.code < 500:
            parser.parse([])
            return parser
        return None
    except Exception:
        return None

def allowed(self, url: str) -> bool:
    parts = urllib.parse.urlsplit(url)
    host = parts.netloc
    with self._lock:
        cached = self._cache.get(host)
        if cached is None or time.time() - cached[0] > ROBOTS_TTL:
            cached = (time.time(), self._load(parts.scheme, host))
            self._cache[host] = cached
    parser = cached[1]
    return parser is not None and parser.can_fetch(self.user_agent, url)

Beim ersten Lauf der Demo war der Testserver noch nicht fertig hochgefahren. Jede URL kam als disallowed zurück, auch die, die die Regeln erlaubt hätten, weil die Schleife die Regeln nicht lesen konnte. Das ist das richtige Ergebnis. Ein Crawler, der nicht herausfinden kann, was eine Site will, sollte nicht zu seinen eigenen Gunsten raten.

Einen 429 als Vertrag behandeln

Das Budget pro Host ist ein Token Bucket, nichts Besonderes. Entscheidend ist, was es tut, wenn ein 429 eintrifft. Es respektiert Retry-After , falls vorhanden, zieht sich mit Jitter zurück, falls nicht, halbiert seine Rate und, der Teil, den die meisten Implementierungen auslassen, senkt seine Obergrenze auf 80% der Rate, die den 429 ausgelöst hat. Die Site hat Ihnen gerade ihr Limit mitgeteilt. Sich alle paar Minuten wieder bis dorthin hochzutasten ist das „wiederholte Muster“, für das das Trust Band gebaut wurde. Fünf 429 innerhalb einer Minute öffnen einen Breaker, und der Host wird fünf Minuten lang in Ruhe gelassen, der Moment, in dem ein Mensch das Log lesen sollte.

def on_429(self, retry_after: float | None) -> float:
    """Honour Retry-After when given, else back off exponentially with jitter."""
    with self._lock:
        now = time.monotonic()
        self._recent_429 = [t for t in self._recent_429 if now - t < self.trip_window] + [now]
        # The rate that drew the 429 is the host's limit: cap recovery
        # below it so one 429 is a lesson, not a cycle.
        self._ceiling = max(self.rate * 0.8, 0.05)
        self.rate = max(self.rate / 2, 0.05)
        if len(self._recent_429) >= 5:
            self._open_until = now + self.cooldown
            return self.cooldown
        if retry_after is not None:
            pause = retry_after
        else:
            pause = min(60.0, 2 ** len(self._recent_429)) * random.uniform(0.5, 1.5)
        self._open_until = now + pause
        return pause

Fragen, ob sich die Seite geändert hat, bevor man nach der Seite fragt

Dass die Hälfte des KI-Crawl-Traffics auf das erneute Abrufen unveränderter Seiten entfällt, ist eine Zahl, an der Cloudflare ein kommerzielles Interesse hat, aber unplausibel ist sie nicht, und die Lösung ist fünfundzwanzig Jahre älter als das Problem. Merken Sie sich die Validatoren, die eine Seite schickt, schicken Sie sie zurück und akzeptieren Sie ein 304 als Antwort. Der Store unten ist absichtlich naiv; in Produktion ist er eine Spalte in der URL-Tabelle.

class ConditionalStore:
    """Remember validators per URL so a re-crawl asks 'has this changed?' first."""

    def __init__(self):
        self._validators: dict[str, dict[str, str]] = {}

    def headers_for(self, url: str) -> dict[str, str]:
        v = self._validators.get(url, {})
        out = {}
        if "etag" in v:
            out["If-None-Match"] = v["etag"]
        if "last-modified" in v:
            out["If-Modified-Since"] = v["last-modified"]
        return out

    def remember(self, url: str, headers) -> None:
        v = {}
        if headers.get("ETag"):
            v["etag"] = headers["ETag"]
        if headers.get("Last-Modified"):
            v["last-modified"] = headers["Last-Modified"]
        if v:
            self._validators[url] = v

Jede Entscheidung aufschreiben

Die Fetch-Methode führt die drei zusammen und protokolliert jedes Ergebnis als eine Zeile JSON: was angefragt wurde, was die Regeln sagten, was die Site antwortete, wie lange die Schleife gewartet hat und mit welcher Rate sie lief. Als Open3DLab seine Logs veröffentlichte, war die vernichtendste Zeile die, dass der Crawler „seine Download-Versuche angesichts unserer Sperren nicht reduzierte“. Ein Audit-Log ist der Weg, das Gegenteil zu behaupten und geglaubt zu werden. Es ist auch, nicht zufällig, das, was der EDPB in den Web-Scraping-Leitlinien verlangt hat, deren Konsultation heute endete: verlässliche Quellen, ein Zeitstempel pro Datensatz und Validierung vor der Nutzung.

def fetch(self, url: str) -> tuple[str, int, bytes | None]:
    """Return (outcome, status, body). Outcomes: fetched, unchanged, disallowed, throttled, error."""
    if not self.robots.allowed(url):
        self._record(url=url, outcome="disallowed")
        return "disallowed", 0, None
    budget = self._budget(url)
    waited = budget.acquire()
    req = urllib.request.Request(url, headers={"User-Agent": self.user_agent, **self.store.headers_for(url)})
    try:
        with urllib.request.urlopen(req, timeout=30) as resp:
            body = resp.read()
            self.store.remember(url, resp.headers)
            budget.on_success()
            self._record(url=url, outcome="fetched", status=resp.status, bytes=len(body), waited=round(waited, 2))
            return "fetched", resp.status, body
    except urllib.error.HTTPError as e:
        if e.code == 304:
            budget.on_success()
            self._record(url=url, outcome="unchanged", status=304, waited=round(waited, 2))
            return "unchanged", 304, None
        if e.code == 429:
            pause = budget.on_429(parse_retry_after(e.headers.get("Retry-After")))
            self._record(url=url, outcome="throttled", status=429, retry_after=e.headers.get("Retry-After"), pause=round(pause, 2), rate=round(budget.rate, 3))
            return "throttled", 429, None
        self._record(url=url, outcome="error", status=e.code)
        return "error", e.code, None

Wie der Trace aussieht

Zwei Läufe gegen die lokale Site. Der höfliche mit einer Anfrage pro Sekunde holt drei Produktseiten, bekommt einen Pfad von den Regeln verweigert, ohne dass ein Paket die Maschine verlässt, holt die drei Seiten dann erneut und bekommt dreimal 304. Der ungeduldige startet mit fünf Anfragen pro Sekunde gegen ein Limit von zwei.

polite pass 1: ['fetched', 'fetched', 'fetched', 'disallowed']
polite pass 2: ['unchanged', 'unchanged', 'unchanged'] (4.0s for 7 fetches)
impatient run: ..T..T..T...............................
               3 x 429 in 40 tries, 33.2s, 1.11 pages/s achieved
rate trajectory: [5.0, 2.76, 0.76, 0.92, 1.12, 1.22, 1.22, 1.22, 1.22, 1.22]

{"url": ".../private/report", "outcome": "disallowed"}
{"url": ".../products/1", "outcome": "unchanged", "status": 304, "waited": 1.0}
{"url": ".../catalog/2", "outcome": "throttled", "status": 429, "retry_after": "2", "pause": 2.0, "rate": 2.5}
{"url": ".../catalog/8", "outcome": "throttled", "status": 429, "retry_after": "2", "pause": 2.0, "rate": 0.76}
{"url": ".../catalog/39", "outcome": "fetched", "status": 200, "bytes": 67, "waited": 0.82}

naive run:     ..T..T..T..T..T..T..T..T..T..T..T..T..T.

Dreimal 429, jeder für die zwei Sekunden respektiert, um die die Site gebeten hat, jeder halbiert die Rate und senkt die Obergrenze. Nach dem dritten 31 Abrufe in Folge ohne Drosselung, eingependelt bei 1,2 Anfragen pro Sekunde unter einem Limit von 2. Die übliche Retry-Schleife, die Retry-After abwartet und dann im selben Tempo weitermacht, fing sich 13 429 in denselben 40 Anfragen ein, einen bei jeder dritten Anfrage, und holte trotzdem weniger Seiten pro Sekunde: 0,94 gegen 1,11. Über einen Tag sind das Tausende Einträge in irgendjemandes Vertrauenshistorie, jeder einzelne das wiederholte Muster, für das das Band gebaut wurde.

Was sich ändert, wenn Sie über Crawlbase crawlen

Crawlbase liest robots.txt nicht für Sie und wird das auch nicht vorgeben. Die Policy gehört Ihnen, und die Historie auch. Was die Crawling API tut, ist, die Seite der Site in diesem Gespräch sichtbar zu machen, damit Ihre Schleife darauf reagieren kann. Jede Antwort trägt den eigenen Status des Ziels in original_status und Crawlbases Urteil in cb_status: Eine Site, die mit 403 antwortet, kommt als 705 zurück, eine Site, die mit 429 antwortet, als 706, und keines von beiden wird berechnet, Zurückziehen kostet also nichts außer Zeit. Mit get_headers=true kommen auch die Antwort-Header der Site zurück, und dort wohnen Retry-After, ETag und Last-Modified . Das Budget und der Validator-Store oben funktionieren unverändert mit diesen Feldern anstelle der rohen Antwort.

Beim Enterprise Crawler sind das Parallelitätslimit (standardmäßig 20) und die Push-Rate (30 URLs pro Sekunde pro Token) die Obergrenzen des Budgets pro Host, kein Ersatz dafür. Lassen Sie die Schleife oben entscheiden, was in die Queue kommt, und den Crawler das sein, was es abruft.

Die praktische Haltung für das nächste Jahr

Es gibt ein Gegenargument, und es kommt mit Daten, von einem Entwickler, der Scraper auf Apify verkauft. Am 20. Oktober veröffentlichte er die Telemetrie von 169.941 Läufen seiner Scraper und stellte fest, dass Aufrufe, die über MCP ankamen, also von KI-Agenten, in 86,9% der Fälle erfolgreich waren, gegenüber 47,9% bei Menschen in der Konsole, und dass 0,6% von ihnen seine Missbrauchssperre auslösten. „Ich hatte die Geschichte komplett falsch herum“, schrieb er. Agenten, die eine API aufrufen, sind die bestbenommenen Clients im Web, weil die API ihnen die Regeln in einer Form mitteilt, die sie lesen können. Der Roblox-Crawler benahm sich auf Sites daneben, die keine solche Schnittstelle hatten, nur eine Textdatei, die er nicht parsen wollte.

Das ist das ganze Argument in einem Kontrast. Das Web schließt sich nicht für Crawler. Es ersetzt eine Tür durch ein Kontobuch, und ein Kontobuch belohnt genau eines: lesbar zu sein. Signieren Sie Ihre Anfragen, wenn Sie können, lesen Sie die Präferenzen, ob Sie ihnen zustimmen oder nicht, lassen Sie einen 429 Ihre Rate bestimmen, schicken Sie Validatoren und führen Sie das Log. Tun Sie das, und das Trust Band ist ein kostenloser Vermögenswert, der sich verzinst. Lassen Sie es, und jeder Crawl, den Sie fahren, ist Beweismaterial für die Gegenseite, mit Zeitstempel von jemand anderem.

Fazit

Der Oktober 2026 war der Monat, in dem Crawler-Verhalten eine Akte bekam. Cloudflare begann, Verified bots nach ihrer Konsistenz mit robots.txt und ihrer Reaktion auf 429 zu bewerten, Google fing an, einen Agenten zu signieren, der robots.txt überspringt, und ein Crawler, der keins von beidem tat, landete mit seinen Logs im Anhang auf der Titelseite. Die Bewertung steht am Anfang, das Vokabular ist noch ein Entwurf, und nur ein Drittel der größten Sites hat überhaupt eine KI-Direktive geschrieben. Aber die Richtung steht, und die Technik, die sie verlangt, ist zwanzig Jahre altes HTTP, sorgfältig gemacht: zuerst die Regeln lesen, aus einem Budget ausgeben, den 429 befolgen, vor dem Abruf validieren und alles aufschreiben. Wenn Sie einen Crawler betreiben, lassen Sie die Schleife oben über Crawlbase laufen und lesen Sie ihr Log, bevor es jemand anderes tun muss.

Häufig gestellte Fragen (FAQs)

Gilt das Trust Band für einen Crawler, der kein Verified Bot ist?

Nein. Die Bewertung hängt an einer Identität, unsignierter und unverifizierter Traffic wird also nicht bewertet; er wird wie bisher von den Bot-Regeln der Site behandelt. Der praktische Effekt ist derselbe: Ein Crawler ohne Identität hat keine Historie, die er sich verdienen könnte, und kommt deshalb nicht aus der Default-Deny-Klasse heraus.

Ist es je sicher, einen 429 sofort zu wiederholen?

Nur wenn die Antwort das sagt, und das tut sie nie. Ein 429 mit Retry-After gibt Ihnen eine Zahl; respektieren Sie sie. Einer ohne sagt Ihnen, exponentiell zurückzuziehen und Ihre Dauerrate zu senken. Dieselbe Anfrage mit derselben Parallelität zu wiederholen ist genau das, was der Score erwischen soll.

Muss ich Content Signals und das aipref-Vokabular befolgen?

Beides sind Präferenzen, keine Zugriffskontrollen, und keines von beiden ist bisher ein veröffentlichter Standard. Cloudflares Crawl-Endpunkt setzt die Stufe use bereits durch, und das Trust Band liest die Konsistenz mit den „veröffentlichten Präferenzen“ einer Site, die um beides wachsen werden. Sie jetzt zu lesen kostet nichts und beginnt die Historie früh.

Was ist daran anders als bei dem, was Google und Bing schon immer getan haben?

Googlebot liest seit zwei Jahrzehnten robots.txt und zieht sich bei Fehlern zurück, und dieses Verhalten hat nie jemand gemessen außer Google. Neu ist, dass ein Dritter das Verhalten jetzt über Millionen von Sites hinweg beobachtet, das Ergebnis veröffentlicht und Site-Betreiber in ihren Edge-Regeln darauf reagieren lässt.

Was berechnet Crawlbase, wenn eine Site mich rate-limitet?

Nichts. Ein Ziel, das mit 429 antwortet, kommt als cb_status 706 zurück, ein 403 als 705, und keines von beiden zählt als erfolgreiche Anfrage, also kostet Zurückziehen und späteres Wiederholen nur Zeit.

VP

Viktor Petrov

Data-Science-Architekt · Crawlbase

Data-Science-Architekt bei Crawlbase. Arbeitet an den Modellen, die groß angelegtes Crawling auch gegen moderne Bot-Abwehr zuverlässig halten.