Zusammenfassung

  • Bei Pay Per Crawl entsteht ein Abrechnungsereignis, wenn ein authentifizierter Crawler Zahlungsbereitschaft signalisiert und eine erfolgreiche Antwort mit crawler-charged erhält. Das belegt bezahlten Zugang, nicht Zitat, Training oder wirtschaftlichen Nutzen.
  • Cloudflare bezeichnet die Zahl der Crawls inzwischen selbst als grobes Wertmaß. Pay-Per-Use-Tests verlagern den Auslöser: Ceramic.ai zahlt für das Erscheinen in einem Suchergebnis, You.com lässt einen Agenten gezielt einen Premium-Inhalt kaufen.
  • Bot Preference Sync, am 21. August angekündigt, überträgt die Einstellungen für Search, Agent und Training in robots.txt. Deklaration und Durchsetzung passen besser zusammen; der spätere Verwendungszweck benötigt dennoch eigene Nachweise.
  • Monetization Gateway befindet sich auf einer Early-Access-Warteliste. Allgemeine Verfügbarkeit, Transaktionsvolumen, Ausschüttungen, Cloudflare-Gebühren und Produktumsatz sind nicht offengelegt.

Der Lieferbeleg hat eine klare Kante

Im Pay-Per-Crawl-Modell entscheidet der Domaininhaber je Crawler zwischen Allow, Charge und Block. Er setzt einen einheitlichen Preis pro Anfrage für die gesamte Site. Der Crawler kann zunächst eine Antwort 402 Payment Required mit dem Preis erhalten und danach mit exakter Zustimmung wiederkommen. Alternativ nennt er bei der ersten Anfrage seinen Höchstpreis.

Das abrechenbare Ereignis ist eng definiert. Identität, Richtlinie und Preis müssen stimmen; die Anfrage muss Zahlungsabsicht tragen; anschließend wird der Inhalt erfolgreich mit dem Header crawler-charged ausgeliefert. Cloudflare will diese Ereignisse zusammenführen, dem Crawler in Rechnung stellen und den Erlös als Merchant of Record an den Publisher verteilen. Hat der Crawler keine Abrechnungsbeziehung zu Cloudflare, wirkt Charge wie eine Netzsperre – nicht wie eine offene Forderung.

Damit entsteht ein brauchbarer Beleg: Gegenpartei, Preis, Zugangsentscheidung und Lieferung lassen sich abgleichen. Doch hinter der Auslieferung endet die Beobachtung. Dieselbe Seite kann tausend Antworten speisen, in einem Retrieval-System liegen, in ein Training einfließen oder ungenutzt bleiben.

Cloudflare benennt die Lücke beim Übergang von Pay Per Crawl zu Pay Per Use. Ein Crawl sei ein grobes Maß. Ein einmal abgerufener Inhalt könne häufig zitiert werden, ein oft abgerufener nie. Auslieferung und Wertentstehung haben unterschiedliche Auslöser und Zeitpunkte.

Eine Erklärung wird erst durch Durchsetzung belastbar

Vor einer Zahlung müssen vier Ebenen zusammenpassen. Der Betreiber veröffentlicht seine Präferenz. Die Netzregel setzt sie um. Der Crawler weist seine Identität nach. Sein erklärter Zweck fällt tatsächlich unter die erlaubte Kategorie.

Bot Preference Sync schließt die erste Lücke. Die Zonenentscheidungen für Search, Agent und Training werden in robots.txt abgebildet; vorhandene Disallow-Regeln bleiben bestehen. Cloudflare weist selbst auf die Gefahr hin: Eine Datei kann den Zugriff ablehnen, während die Edge-Regel ihn nicht blockiert. Manche Crawler nehmen die Inkonsistenz zum Anlass, die Präferenz zu ignorieren oder die Sperre zu umgehen.

Synchronisierung verbessert die Konsistenz, nicht die Granularität jeder Geschäftsbeziehung. Cloudflare verwendet die in BotBase geführten Identitäten und schreibt Regeln auf Kategorieebene. Einzelverträge, Pfadausnahmen und kundenspezifische Logik werden nicht automatisch eingelesen. Ein Publisher kann einen lizenzierten Partner zulassen und gleichzeitig dessen Kategorie für alle anderen sperren.

Auch die Identität darf nicht auf einer User-Agent-Zeichenfolge beruhen. Pay Per Crawl setzt auf Web Bot Auth und signierte Nachrichten. Für Betreiber, die Search und Training vermischen und bei einem Trainingsverbot trotzdem Suchzugang erhalten möchten, verlangt Cloudflare zusätzliche Transparenz: die No-Training-Präferenz respektieren, einen Ausstieg aus KI-Zusammenfassungen anbieten, URL-genaue Einblicke und Suchmetriken liefern und öffentlich zeigen, dass der Verzicht auf Training die klassische Suche nicht verschlechtert.

Diese Verpflichtungen machen das Zwecketikett überprüfbarer. Sie bleiben auf Daten des Crawler-Betreibers angewiesen. Eine stimmige robots.txt-Datei beweist nicht allein, dass ein Modell einen Inhalt später nicht verwendet hat.

Der 15. September ist ein Ausführungstest

Cloudflares Juli-Mitteilung zu Klassifikationen und Standardwerten setzte den 15. September 2026 als Frist. Nach der damaligen Beschreibung sollten neue Sites Search zulassen, Training und Agent auf werbefinanzierten Seiten aber blockieren. Misch-Crawler ohne getrennte Zwecke sollten dort ebenfalls gesperrt werden. Bestehende kostenlose Kunden ohne eigene Auswahl sollten einbezogen werden.

Der August-Beitrag beschreibt den Einstieg differenzierter. Publisher und werbefinanzierte Sites können Training beim Onboarding auf Disallow setzen; andere neue Sites starten ohne Sperre; Nutzer der älteren verwalteten robots.txt sollen den Übergang prüfen und bestätigen. Die Richtlinie wird noch in einen Betriebszustand übersetzt. Nach dem Stichtag zählen die tatsächlich aktive Matrix, die Überschreibungen der Kunden und die Frage, ob Misch-Crawler Identität und Zweck wirklich trennen.

Der Standardwert beeinflusst Verhandlungen, weil Cloudflare an einem großen Verteilungspunkt sitzt. Im Jahresbericht zur Bot-Ökonomie gibt das Unternehmen an, dass im Juni 2026 52% der auf seinem Netz gemessenen Crawler-Anfragen dem Training dienten; mehr als 36% der Aktivität stammten von Misch-Crawlern. Außerdem liege mehr als 20% des Webs hinter dem eigenen Netz. Das sind Cloudflare-Messungen und -Definitionen, keine globale Vollerhebung. Sie erklären trotzdem, weshalb eine Voreinstellung an dieser Grenze Knappheit erzeugen kann.

Knappheit schafft Verhandlungsmacht. Sie ist noch keine Zahlung und kein Nutzungsrecht.

Die Nutzung wird dort verbucht, wo das Ergebnis entsteht

Die Versuche mit Ceramic.ai und You.com verschieben das Zahlungsereignis. Bei Ceramic.ai soll ein teilnehmender Publisher Geld erhalten, wenn sein Inhalt in einem Suchergebnis auftaucht. Dazu sollen Suchanfrage, Seite, Ausschnitt und Position sichtbar werden. Im You.com-Beispiel kauft ein Agent bei Bedarf einen bestimmten Premium-Inhalt.

Das liegt näher am Nutzen als ein Download-Zähler, ist aber schwerer zu prüfen. Wie wird eine Antwort aufgeteilt, die mehrere Quellen zusammenführt? Beweist ein sichtbares Zitat einen ursächlichen Beitrag? Wie behandelt man ähnliche Seiten, fehlende Quellen oder einen Abruf aus dem Cache? Die Einheit könnte Anfrage, Ergebnis, erfolgreich erledigte Aufgabe, Token oder Lizenzzeitraum sein.

Cloudflare nennt Pay per Query, Pay per Result und weitere Ansätze ausdrücklich Experimente. Die eine Markteinheit existiert noch nicht. Zugang ist leicht zu zählen, aber oft weit vom Wert entfernt. Ein Ergebnis liegt näher am Wert, hängt jedoch vom internen Protokoll des Käufers ab und ist strittiger.

Attribution Business Insights zeigt Bot-Management-Kunden erfolgreiche Zugriffe, Crawl-zu-Referral-Verhältnisse, Bandbreite, Betreiber und Verhaltenskategorie. Das stärkt die Verhandlungsposition des Publishers. Aus Netzbeobachtungen allein lässt sich weder ein Trainingskorpus noch der vollständige Entstehungsweg einer Antwort rekonstruieren.

x402 vergrößert das bepreisbare Sortiment

Das geplante Monetization Gateway soll Webseiten, Datensätze, APIs und MCP-Toolaufrufe erfassen. Der Client erhält x402-Zahlungsanweisungen, bezahlt in Stablecoins, wiederholt die Anfrage mit Nachweis und erreicht den Origin erst nach der Prüfung. Regeln könnten nach Route, Methode oder Aufwand variieren und im Dashboard, per API oder Terraform verwaltet werden.

Für eine kleine digitale Einheit kann das den unverhältnismäßigen Aufwand von Konto, API-Schlüssel und Monatsabo vermeiden. Der Verkäufer hält unbezahlte Last vom Origin fern; der Agent kauft genau im Bedarfszeitpunkt. Cloudflare verbindet Identität, Richtlinie, Zahlungsverifikation und Lieferung in einer Steuerungsebene.

Die Ankündigung bleibt jedoch im Futur. Aktuell gibt es eine Early-Access-Warteliste. Nicht veröffentlicht sind ein Termin für die allgemeine Freigabe, Produktionsvolumen, Nettoerlöse der Verkäufer, Cloudflare-Gebühren, Erstattungs- und Streitregeln, operative Details zu Assets und Rechtsräumen sowie gemessene Latenzen. Eine angestrebte Abwicklung unter einer Sekunde ist kein Leistungsnachweis.

Auch die Konzernzahlen dürfen die Lücke nicht füllen. Cloudflare meldete 696,1 Millionen US-Dollar Quartalsumsatz, 36% mehr als im Vorjahr, sowie 56,4 Millionen Dollar Free Cashflow. Im Formular 10-Q heißt es, Abonnement und Support machten nahezu den gesamten Umsatz aus; die genannte nutzungsabhängige Gegenleistung betreffe vor allem überschüssige Bandbreite. Kunden, Umsatz oder RPO der Initiativen werden nicht separat ausgewiesen. Ein starkes Bestandsgeschäft ist kein Nachweis für die Kommerzialisierung des neuen Marktes.

Zwei Bücher brauchen zwei Abstimmungen

Im Zugangsbuch müssen bezahlte Anfragen, erfolgreiche Lieferungen, Nettoerlös, Abwicklungszeit, Ausfälle, Ausnahmen und Streitfälle zusammenpassen. Im Nutzungsbuch muss jede Anfrage oder Aufgabe mit der beitragenden Ressource, der geltenden Lizenz, der Attribution und der Zahlung verbunden werden.

HTTP kann Preis und Zahlungsnachweis transportieren, schreibt aber keine Nutzungsrechte hinzu. Eine 200-Antwort nach 402 ist nicht automatisch Zustimmung zu Training, Speicherung oder Weitergabe. Cloudflare stärkt den Zugangsbeleg. Die Bewegung zu Pay Per Use ist das Eingeständnis, dass der Wertbeleg an anderer Stelle entsteht.

Quellen