Kontakt

Pay-per-Crawl & Co.: Wie Unternehmen KI-Crawlern begegnen

AI and bot traffic (1)
Inhalte

AI-Traffic-Serie · Teil 4 von 5

Abschließend wollen wir im vierten Teil unserer AI-Traffic-Blog-Serie noch einen Blick auf Best Practices werfen, wie Unternehmen bereits mit diesem Thema umgehen, aber auch aktuelle Entwicklungen beleuchten, die das Bot-Problem auf einer höheren Ebene angehen sollen.

Denn klar ist: Content-Anbieter und Website-Betreiber suchen nach strategischen Lösungen, um sich gegen unkontrolliertes Crawling zu wehren – oder wenigstens eine Kompensation dafür zu erhalten.

Die Serie im Überblick

Vorige Artikel:

Nächster Artikel:

 

Benchmarking und Best Practices

Zum Abschluss betrachten wir kurz einige konkrete Fälle, wie Unternehmen und Projekte mit dem KI-Bot-Problem umgehen:

 

Publisher und Medienhäuser

Viele große Verlage haben früh reagiert und in ihren robots.txt-Dateien bestimmten Bots den Zugriff verboten.

So blockieren z. B. The New York Times, CNN und Co. OpenAIs GPTBot sowie andere Scraper. Apple reagierte darauf mit Applebot-Extended, das es Seiten erlaubt, nur das KI-Training auszuschließen, ohne aus der normalen Suche zu fliegen.

Mehr als die Hälfte der News-Sites nutzt diese Opt-out-Möglichkeiten inzwischen. Zudem sind viele dieser Publisher Teil von Cloudflares Crawler-Governance-Initiative: über 20 % des Webs, gemessen an Cloudflares Anteil, wird KI-Bots künftig standardmäßig blocken.

Große Namen wie BuzzFeed, TIME, The Atlantic, Quora und Stack Overflow haben sich Cloudflare angeschlossen, um entweder Pay-per-Crawl durchzusetzen oder zumindest harte Zugriffskontrollen einzuführen.

Analytics-seitig bedeutet das: weniger Bot-Belastung, weil schon vorgelagert blockiert wird – und klarere Verhältnisse, da die meisten KI-Crawler die Inhalte dieser Seiten gar nicht mehr bekommen. Das ist allerdings eine bewusste strategische Entscheidung, auf die wir im nächsten Abschnitt genauer eingehen.

 

Tech-Plattformen und Open Source

Projekte wie SourceHut, ein Entwickler-Git-Hosting, bemerkten drastische Performance-Probleme durch KI-Crawler – teils waren es so viele Zugriffe, dass es wie eine DDoS-Attacke wirkte.

Deren Lösung: Netzsperren. Man hat beispielsweise komplette IP-Ranges von Google Cloud und Microsoft Azure auf die Blacklist gesetzt, da aus diesen die meisten Bot-Zugriffe kamen.

Das kappt natürlich auch legitime Nutzer*innen, die zufällig über diese Cloud-Netze kommen, aber für SourceHut war die Stabilität wichtiger. Linux Weekly News litt unter einem ähnlichen „Bot-Sturm“ und meldete, dass AI-Bots das Seitenladen für echte Leser*innen verlangsamen bis unmöglich machen.

Solche Projekte greifen teils zu drastischen Mitteln: Einige haben laut ModX-Blog sogar ganze Länder blockiert, weil aus bestimmten Regionen unverhältnismäßig viele Scraper kamen und man anders keinen Erfolg hatte.

Für Analytics bedeutet das: Hier wird das Problem an der Wurzel bekämpft – der Traffic taucht gar nicht erst auf, muss also auch nicht mehr gefiltert werden. Allerdings sind solche Maßnahmen wirklich Ultima Ratio.

 

E-Commerce und kleinere Sites

Im Mittelstand und bei Shops stellt man verstärkt fest, dass z. B. Conversion-Rate-Abfälle oft mit Bot-Wellen korrelieren.

Ein Online-Händler fand heraus, dass plötzlich ein „neuer Referral“ in Google Analytics auftauchte, der massig Traffic schickte. Es war aber in Wirklichkeit ein Bot, der einen UTM-Parameter hinterlassen hatte, den GA als Quelle interpretierte.

Die Lösung hier war, auf der Referral-Exclusion-List den entsprechenden Host einzutragen sowie in GA4 einen zusätzlichen Filter auf die „Campaign Source“ zu legen, per Regex auf verdächtige Muster.

Wieder andere Shops berichten in Foren, dass sie Captchas auf bestimmten Seiten eingeführt haben, um Bots vom Weiterklicken abzuhalten – etwa vor dem Checkout.

So soll verhindert werden, dass Bots massenhaft Test-Bestellungen generieren, die zwar nicht abgeschlossen werden, aber Events triggern könnten. Aus Analytics-Sicht sind Captchas zweischneidig, da sie die Conversion auch für echte Kunden bremsen können, aber in schweren Fällen gerechtfertigt sind.

Zusammengefasst zeigt sich: Die meisten Organisationen setzen auf eine Kombination – präventiv blocken, wo möglich, über robots.txt, Firewall oder spezielle Anti-Bot-Dienste, und analytisch filtern, was dennoch durchkommt. Damit fahren viele zweigleisig: Betriebsfähigkeit der Website sicherstellen und Datenqualität wahren.

Jetzt Bot-Management-Strategie besprechen:

Kontaktieren Sie uns

 

„Pay per Crawl“ – wenn Bots zur Kasse gebeten werden

Anfang Juli 2025 sorgte Cloudflare, ein großer CDN- und Security-Anbieter, für Schlagzeilen mit der Einführung eines „Pay Per Crawl“-Modells.

Die Idee dahinter: Betreiber von Websites, die über Cloudflare laufen – das sind ca. 20 % aller Websites –, können künftig festlegen, dass KI-Crawler zahlen müssen, um ihre Inhalte zu erhalten.

Cloudflare blockiert per Default erst einmal alle AI-Bots auf neuen Sites. Dann gibt es drei Optionen pro Bot: Allow (kostenlos durchlassen), Block (komplett verweigern) oder Charge (Zugriff nur gegen Bezahlung).

Das technische Rückgrat dafür ist der lange inaktive HTTP-Statuscode 402 Payment Required. Fragt ein KI-Bot eine Seite an, kann Cloudflare überprüfen, ob für diese Domain eine „Charge“-Regel für den Bot besteht. Ist dem so, erhält der Bot anstelle des Inhalts eine 402-Aufforderung mit Preisangabe. Nur wenn der Bot dann einen Payment-Token präsentiert, wobei Cloudflare als Abrechnungsstelle dient, wird der Request mit 200 OK bedient. Bots, die keine Bezahlbeziehung haben, bekommen faktisch 403 Forbidden – jedoch mit dem Hinweis, dass künftig bezahlt werden könnte.

Für die Publisher bedeutet das: Sie können erstmals monetarisieren, wenn KI-Modelle ihre Inhalte zum Training nutzen. Viele große Verlage und Plattformen haben sich laut Cloudflare bereits in diese Richtung positioniert, etwa Getty Images oder News Corp. Sie wollen Geld sehen, wenn KI-Anbieter ihre Daten brauchen.

Cloudflare Pay-per-Crawl schafft einen Rahmen dafür, ohne dass jeder einzeln Verträge schließen muss. Die Preisgestaltung obliegt den Website-Betreibern als domainweites Request-Preisschild, und die KI-Firmen können entscheiden, ob sie zu dem Tarif crawlen wollen oder nicht.

Kurzfristig hat dieses Modell keine direkten Auswirkungen auf Ihre Analytics-Daten – ein Bot, der blockiert oder abgewiesen wird, erscheint erst gar nicht in Ihrer Statistik, das ist ja gut. Langfristig könnte es jedoch das Crawling-Volumen insgesamt reduzieren, wenn Bezahlhürden Einzug halten.

Für uns Analyst*innen spannend: Sollte Pay-per-Crawl zum Standard werden, bekäme man eventuell Wirtschaftlichkeits-Kennzahlen, z. B. „Der Bot X hat diesen Monat für 1.000 Requests bezahlt“. Das wäre dann de facto der Beweis für den Wert Ihrer Inhalte, aus Sicht der KI-Industrie. Aber bis dahin ist es noch ein weiter Weg.

Fürs Erste zeigt Pay-per-Crawl: Die Branche erkennt an, dass unlimitierter KI-Zugriff ein Problem ist, und sucht nach Marktlösungen. Cloudflare selbst sagt:

„Wenn das Internet im KI-Zeitalter überleben soll, müssen wir den Publishern die Kontrolle zurückgeben und ein neues, faires Geschäftsmodell etablieren.“

Das ist ein starkes Statement.

Aus Analytics-Perspektive sollten Sie die Entwicklung im Auge behalten: Wenn Sie Cloudflare nutzen, überlegen Sie, ob Sie an deren AI-Crawler-Management teilnehmen, etwa dem Super Bot Fight Mode.

Schon jetzt bietet Cloudflare an, KI-Bots standardmäßig zu blocken, bis Sie sie manuell erlauben. Es gibt zudem ein Crawler-Verifizierungsprogramm, bei dem Bots angeben müssen, ob sie zum Training oder für die Suche crawlen. Das erlaubt granulareres Blocken – Sie könnten z. B. den Suchbot erlauben, aber den Trainingsbot sperren. All das kann Ihre Bot-Traffic-Last deutlich mindern – und damit Ihre Analytics entlasten.

 

Bot-Täuschung und Tar Pits

Neben Pay-per-Crawl geistern andere Ideen durch die Community, wie man Bots austricksen könnte. Ein besonders kreativer Ansatz ist das Konzept des Honeypots oder Bot-Labyrinths.

Cloudflare experimentiert hier ebenfalls, im Projekt Skywire alias AI Labyrinth: Anstatt Bots einfach zu blocken, leitet man sie auf einen Endlos-Pfad aus künstlichen Seiten um. Die Bots merken gar nicht, dass sie in eine Falle gegangen sind, bekommen aber nur automatisch generierten Quatsch-Content vorgesetzt.

Vorteil: Der Bot belastet dann nicht die echten Server, weil die Labyrinth-Seiten an der CDN-Edge generiert werden, und verschwendet seine Ressourcen an Daten, die keinen Wert haben. So ein Tar Pit kann Bots beschäftigen und abschrecken, ohne echten Nutzertraffic zu beeinflussen.

Für Analytics heißt das: Im Idealfall verschwinden diese Bot-Zugriffe ebenfalls aus Ihren echten Traffic-Zahlen, weil sie nie Ihre Origin treffen. Allerdings sollte man aufpassen: Wenn ein Bot stundenlang im Labyrinth hängt, könnte er tausende Hits generieren, die ggf. doch wieder irgendwo mitgezählt werden. Hoffentlich landen diese aber nicht in Ihrer Haupt-Property, da Cloudflare sie anders routet.

Andere Admins setzen auf Challenge-Systeme: Entwickler Xe Iaso etwa baute ein System namens „Anubis“, das jedem Besuch eine Rechenaufgabe stellt, die ca. 30 Sekunden dauert, bevor die Seite lädt. Menschliche Besucher*innen nervt das natürlich extrem, weshalb er es auch nur testweise bei einer von Bots extrem geplagten Seite einsetzte. Das Ergebnis: Bots ohne besondere Anpassung geben auf, weil sie die Aufgabe nicht lösen – aber leider verlieren auch 90 % der echten Nutzer*innen die Geduld. Solche radikalen Maßnahmen zeigen aber, wie ernst die Lage mancherorts wahrgenommen wird.

Als Daten-Analyst*in kann man hier nur appellieren, eng mit den Technik-Teams zusammenzuarbeiten: Wenn solche Mechanismen eingeführt werden, muss man vorher definieren, wie man deren Auswirkungen misst. Man sollte z. B. messen, wie viele Challenges ausgeliefert wurden und wie viele gelöst wurden, und diese Info in Beziehung zu Traffic-Anomalien setzen. Sonst wundert man sich evtl., warum der Traffic droppt, obwohl in Wahrheit alle echten Nutzer*innen aufgegeben haben.

Sie wollen wissen, wie andere Unternehmen mit KI-Crawlern umgehen – und ob Pay-per-Crawl oder ein eigenes Bot-Management auch für Sie relevant wären? Unsere Expert*innen zeigen Ihnen Best Practices und entwickeln gemeinsam mit Ihnen ein Zukunftsmodell, das zu Ihrer Branche passt.

Kontaktieren Sie uns

 

Zum nächsten Artikel:
Das könnte Sie auch interessieren AI-Bot-Traffic filtern: So bereinigen Sie GA4, Adobe & Piano Mehr lesen
Zurück zur Übersicht