Was ist Pay per Crawl?

Pay per crawl fügt der Beziehung zwischen einer Website und einem KI-Crawler eine dritte Option hinzu. Bisher gab es genau zwei: den Zugriff ohne Bedingungen erlauben, oder ihn mit robots.txt sperren. Pay per crawl führt «erlauben, aber nur gegen Bezahlung» ein, eine Zwischenstufe, die es vorher schlicht nicht gab.

Der technische Mechanismus ist der HTTP-Statuscode 402, Payment Required. Diesen Code gibt es seit den ersten HTTP-Standards, ursprünglich gedacht für ein Mikrozahlungssystem, das sich nie durchgesetzt hat, und der jahrzehntelang praktisch ungenutzt blieb. Pay per crawl holt ihn zurück: fragt ein Crawler eine Seite mit aktivierter Kontrolle an, antwortet der Server mit 402 statt den Inhalt auszuliefern, und hängt den Preis für diesen Besuch in einem Header an. Der Crawler kann die Anfrage wiederholen und die Zahlung akzeptieren, oder aufgeben, ganz ähnlich wie ein menschlicher Besucher vor einer Bezahlschranke im Web.

Es ist bisher kein W3C- oder IETF-Standard mit breiter Verbreitung: es ist ein Modell, das zum Zeitpunkt dieser Redaktion vor allem von einem großen Anbieter von Web-Infrastruktur umgesetzt wird, und dessen genaues Verhalten (Header, Signatur, Währung) davon abhängt, wie der jeweilige Anbieter es implementiert. Für eine Website ändert das die bisher gewohnte Logik von robots.txt: statt einer festen Regel für alle entsteht eine Preisliste, die sich Crawler für Crawler unterscheiden kann.

Der typische Ablauf hat zwei Varianten. In der reaktiven fragt der Crawler die Seite ohne Vorwarnung an, erhält einen 402 mit dem Preis in einem Header, und wiederholt bei Akzeptanz die Anfrage mit einem zusätzlichen Header, der die Zahlung bestätigt. In der proaktiven Variante schickt der Crawler von vornherein einen Header mit dem Höchstpreis mit, den er zu zahlen bereit ist; liegt der vom Anbieter festgelegte Preis darunter, erhält er den Inhalt ohne den Zwischenschritt über 402, was für stark frequentierte Crawler Zeit spart.

Die Identität des Crawlers wird über kryptografische Signaturen (HTTP Message Signatures mit Ed25519-Schlüsseln) verifiziert, nicht über den User-Agent, der sich fälschen lässt und deshalb allein keine verlässliche Grundlage für eine Abrechnung wäre. Der Publisher legt einen Preis pro Crawl für die gesamte Domain fest und entscheidet, Crawler für Crawler, zwischen kostenlosem Zugang, Berechnung oder Sperrung, ohne für jede einzelne Anfrage manuell eingreifen zu müssen.

Zum Zeitpunkt dieser Redaktion, August 2026, ist Cloudflare der Anbieter, der dieses Modell öffentlich umgesetzt hat, in privater Beta seit der Ankündigung vom 1. Juli 2025. Am 1. Juli 2026 kündigte das Unternehmen zudem an, dass ab dem 15. September 2026 Crawler, die mehrere Zwecke kombinieren, etwa Indexierung für die Suche und Training von Modellen gleichzeitig, auf Seiten mit Werbung standardmäßig gesperrt werden, sofern die Website diese Einstellung nicht ändert. Es gibt zum Zeitpunkt dieser Redaktion keine öffentlich bekannte, gleichwertige Umsetzung durch andere CDN-Anbieter, sodass Aussagen über das Modell allgemein zugleich Aussagen über diese eine Implementierung sind.

Der Code 402 war seit der Definition des HTTP-Protokolls reserviert und praktisch ungenutzt, ein technisches Relikt ohne echte Anwendung im Alltag des Webs. Dass ein großer Infrastrukturanbieter ihn zu einem aktiven Mechanismus macht, und zusätzlich eine Änderung der Standardeinstellungen für September 2026 ankündigt, verändert die Frage, die sich jeder Website mit Traffic von KI-Crawlern stellt: nicht mehr nur «erlauben oder sperren», sondern «wer entscheidet, was passiert, wenn ich nichts konfiguriere».

Für einen Publisher oder eine Website mit wertvollem Inhalt, etwa eigener Recherche oder redaktionell erarbeiteten Texten, hat es ab diesem Datum eine konkrete Folge, nichts zu entscheiden: manche Crawler werden auf Seiten mit Werbung standardmäßig gesperrt, andere kommen weiter kostenlos rein, je nachdem, wie der Infrastrukturanbieter sie einordnet. Die Regel ausdrücklich selbst festzulegen, statt die Standardeinstellung zu übernehmen, ist der einzige Weg, damit die Entscheidung bei der Website liegt und nicht beim Anbieter, auch wenn das einen zusätzlichen Konfigurationsschritt bedeutet.

Für einen ZDS-Kunden mit eigenem redaktionellem Inhalt oder eigener Recherche bedeutet das konkret: vor diesem Datum prüfen, welche KI-Crawler heute Zugriff haben, welche man weiterhin kostenlos zulassen will, zum Beispiel solche, die mit Rücklink zitieren, und welche berechnet oder gesperrt werden sollten. Wer diese Entscheidung aufschiebt, überlässt sie am Stichtag automatisch der Voreinstellung des Anbieters.

• Prüfe, welchen CDN- oder Bot-Schutz-Anbieter die Website nutzt und ob er bereits eine Bezahl- oder Sperrfunktion nach Crawler-Typ anbietet.
• Verwechsle Pay per crawl nicht mit einer allgemeinen Firewall oder Sperre: es wirkt nur auf Anfragen, die als KI-Crawler erkannt werden, die den Mechanismus respektieren.
• Lege die Regel pro Crawler ausdrücklich fest (erlauben, berechnen, sperren), statt die Standardeinstellung des Anbieters zu übernehmen, besonders vor angekündigten Änderungsterminen.
• Aktivierst du einen Preis, dokumentiere die Bedingungen zusätzlich in robots.txt oder einem Lizenzstandard wie RSL, damit sie außerhalb des eigenen Servers festgehalten sind.
• Prüfe regelmäßig die Server-Logs, um zu sehen, wie viele 402-Anfragen tatsächlich entstehen und von welchen Crawlern, bevor du annimmst, der Mechanismus bringe Einnahmen.
• Unterscheide zwischen dem Sperren eines Trainings-Crawlers und eines Such-Crawlers: eine falsch eingestellte Regel kann auch den Traffic eines Suchdienstes sperren, den man behalten möchte.

• Annehmen, Pay per crawl sei bereits ein offener Standard mit vielen Anbietern: zum Zeitpunkt dieser Redaktion hängt es vor allem an der Umsetzung eines einzigen Anbieters.
• Denken, das Aktivieren einer Bezahlung sperre automatisch jeden unerwünschten Bot: es wirkt nur auf Crawler, die den Mechanismus erkennen und sich für Zahlung oder Rückzug entscheiden.
• Nicht prüfen, dass ein Crawler mit mehreren Zwecken gleichzeitig, etwa Suche und Training, komplett gesperrt werden kann, wenn nur einer dieser Zwecke gesperrt wird.
• Die Konfiguration nach einem vom Anbieter angekündigten Änderungstermin im Automatikmodus belassen, ohne zu prüfen, was erlaubt und was gesperrt bleibt.
• Das Modell als Einnahmegarantie darstellen: die Zahlung hängt davon ab, dass der Crawler zu zahlen bereit ist, sie erfolgt nicht automatisch.