# Der 15. September 2026: Cloudflare stellt die Crawler-Defaults um

> Search, Agent, Training — Cloudflare sortiert Bots neu und sperrt auf Werbeseiten zwei Kategorien standardmäßig. Warum das Googlebot mitreißen kann.

Source: https://www.jpkc.com/db/blog/cloudflare-crawler-defaults/

Meine eigene Seite liegt nicht hinter Cloudflare — sie läuft auf einem eigenen Apache, und meine `Content-Signal`-Zeile ist genau das, was sie zu sein vorgibt: eine Bitte. Genau deshalb schaue ich auf das, was Cloudflare am 1. Juli 2026 angekündigt hat, mit einer gewissen Nüchternheit. Denn dort wird aus der Bitte eine Sperre, und sie greift zum **15. September 2026** — für über 20 Prozent aller Web-Domains, die hinter dem Netzwerk liegen. Wenn deine Seite dazugehört, entscheidet sich in den nächsten Wochen, welche Crawler dich künftig noch sehen. Und ein Detail in der Auswertungslogik kann dich ausgerechnet Googlebot kosten.

## Was sich am 15. September ändert

Cloudflare stellt die Standardeinstellungen für Bot-Zugriffe um. Die neue Regel in einem Satz: **Auf Seiten, die Werbung ausspielen, werden Crawler der Kategorien *Training* und *Agent* künftig standardmäßig blockiert — *Search* bleibt erlaubt.**

Die Begründung dahinter ist ökonomisch und ziemlich geradeaus: Werbung auf einer Seite ist das Signal, dass dort ein Mensch landen und etwas sehen soll. Auf solchen Seiten behandelt Cloudflare menschliche Aufmerksamkeit als das eigentliche Ziel und hält die Bots fern, die diese Aufmerksamkeit abgreifen, ohne sie zurückzugeben. Suche dagegen schickt traditionell Besucher zurück — die bleibt offen.

Wen es trifft:

- **Alle neu bei Cloudflare aufgeschalteten Domains** bekommen die neuen Defaults automatisch.
- **Bestehende Free-Kunden**, die ihre Einstellungen bis zum 15. September nicht angefasst haben, ebenfalls — das steht so in der [Pressemitteilung](https://www.cloudflare.com/press/press-releases/2026/cloudflare-allows-the-agentic-internet-to-flourish-with-a-simple-philosophy-your-content-your-rules/) (englisch).
- Wer die Umstellung nicht will, kann das **jederzeit bis zum 15. September** in den Security-Einstellungen hinterlegen.

Ein ehrlicher Hinweis zum Stand: Cloudflare hat angekündigt, die Defaults und Klassifizierungen bis zum Stichtag mit Feedback aus dem Ökosystem und eigenen Tests zu finalisieren. Die Richtung steht, einzelne Details können sich also noch bewegen.

## Die neue Taxonomie: Search, Agent, Training

Der interessantere Teil ist die Sortierung dahinter. Bisher lief die Debatte auf „KI-Bot ja oder nein" hinaus — eine Frage, die von Jahr zu Jahr sinnloser wird, weil inzwischen in praktisch allem KI steckt. Cloudflare stellt deshalb nicht mehr die Frage, *ob* ein Bot „KI" ist, sondern **was er auf deiner Seite tut**. Drei Kategorien stehen jetzt allen Kunden zur Steuerung offen, auch im Free-Tier:

| Kategorie | Was der Bot tut |
| --- | --- |
| **Search** | Baut proaktiv einen Index deiner Inhalte auf, um später Fragen dazu zu beantworten — mit Referral-Traffic oder anderer Gegenleistung als Erwartung |
| **Agent** | Handelt in Echtzeit im Auftrag eines Menschen: Chat-Fetch-Bots wie `ChatGPT-User`, aber auch Browser-Agenten, die Chrome fernsteuern |
| **Training** | Nimmt deine Inhalte auf, um damit ein Modell zu trainieren oder zu verfeinern — der Inhalt wandert dauerhaft in die Modellarchitektur |

Darunter liegt eine breitere Klassifizierung mit elf Verhaltensweisen: neben den drei genannten noch *Transact* (Checkout im Auftrag von Nutzern), *Data Collection*, *Security Testing*, *SEO*, *Ads Verification*, *Social / Link Preview*, *Feed Fetching* sowie *Monitoring & Operations*. Ein Bot bekommt dabei ausdrücklich **alle** zutreffenden Kategorien, nicht nur eine — und genau daraus entsteht das Problem im nächsten Abschnitt.

Nebenbei ändert sich damit auch, was „Verified" bedeutet. Bisher war ein verifizierter Bot standardmäßig erlaubt. Künftig macht das Label einen Bot nur noch *erlaubbar* — durchgelassen wird er über die Kategorie, die du freigegeben hast. Nicht verifizierte Bots bleiben wie bisher standardmäßig draußen.

## Die Googlebot-Falle

Hier liegt der Punkt, den ich für den praktisch gefährlichsten halte. Ab dem 15. September werden Mehrzweck-Crawler nach **allen** ihren Verhaltensweisen bewertet, und es gilt die **restriktivste zutreffende Regel**.

Googlebot, Applebot und BingBot crawlen für Suche *und* für Training. Wer also Training blockiert — über die neuen Optionen oder über den alten „Block AI bots"-Schalter —, sperrt damit auch diese drei komplett aus. Inklusive der klassischen Suchindexierung.

Das ist keine Nebenwirkung, sondern Absicht: Cloudflare will Bot-Betreiber dazu bringen, ihre Crawler nach Zweck zu trennen, statt Suche und Training im selben User-Agent zu bündeln. Der Druck dafür wird bewusst auf die Seitenbetreiber und damit auf die Crawler-Betreiber weitergegeben. Für dich heißt das trotzdem: Ein Schalter, den du vielleicht vor zwei Jahren aus guten Gründen umgelegt hast, kann ab Mitte September deine Google-Sichtbarkeit kosten.

Und anders als eine `robots.txt`-Zeile ist das kein Appell. Die Sperre greift auf Netzwerkebene, bevor der Request deinen Server erreicht — ein Crawler kann sie nicht ignorieren, weil er gar nicht erst durchkommt.

## Was du bis zum 15. September prüfen solltest

Wenn deine Seite hinter Cloudflare liegt, sind das die vier Handgriffe, die ich für sinnvoll halte — in dieser Reihenfolge:

1. **Schau nach, ob „Block AI bots" bei dir aktiv ist.** Das ist der Legacy-Schalter, der in die neue Training-Kategorie übersetzt wird. Wenn er an ist, betrifft dich die Googlebot-Frage direkt.
2. **Entscheide bewusst über *Agent*.** Diese Kategorie ist neu und wird gern übersehen. Ein Agent handelt für einen echten Menschen, der gerade auf eine Antwort wartet — das ist näher an einem Besucher als an einem Scraper. Wer Agenten pauschal sperrt, schneidet sich von einem Kanal ab, der gerade erst entsteht.
3. **Prüfe, ob deine Seiten überhaupt als „mit Werbung" gelten.** Die neuen Defaults hängen genau daran. Auf einer werbefreien Firmen- oder Doku-Seite ändert sich zunächst weniger, als die Schlagzeilen vermuten lassen.
4. **Halte deine `robots.txt` und deine Content Signals konsistent.** Die Präferenz-Ebene bleibt ja bestehen, und ein Widerspruch zwischen „KI willkommen" in der `Content-Signal`-Zeile und einer harten Sperre im CDN ist genau die Art von Inkonsistenz, die niemandem hilft. Genau diesen Konflikt meldet der [SEO-&-GEO-Analyzer](https://www.jpkc.com/db/tools/seo/) auch als Hinweis.

Liegt deine Seite *nicht* hinter Cloudflare, ändert sich für dich unmittelbar nichts — dann bleibt es bei `robots.txt` und `Content-Signal` als Willenserklärung. Die Details dazu stehen in [Content Signals & C2PA](https://www.jpkc.com/db/blog/content-signals-c2pa/), inklusive des neuen `use`-Felds, das Cloudflare am selben Tag in die Direktive eingeführt hat.

## Der wirtschaftliche Hintergrund

Die Umstellung kommt nicht aus dem Nichts. Cloudflares eigene Zahlen zum Jahrestag zeichnen ein deutliches Bild davon, warum der alte Tausch — wir crawlen dich, du bekommst Besucher — nicht mehr trägt:

- **Über 50 Prozent** des Internet-Traffics sind inzwischen nicht-menschlich.
- **52 Prozent** aller Crawler-Requests entfielen im Juni 2026 auf Training — im Frühjahr 2025 waren es noch 22 Prozent.
- **Über 36 Prozent** der Aktivität stammen von Mehrzweck-Crawlern, die Suche, Agenten-Nutzung und Training vermischen.
- Das Verhältnis von Crawls zu zurückgeschickten Besuchern lag bei großen KI-Crawlern zwischen **118:1 und knapp 50.000:1**.
- Eine [Pew-Studie von 2025](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/) (englisch) fand: Zeigt Google eine KI-Zusammenfassung, klicken Nutzer nur noch in **8 Prozent** der Besuche auf ein klassisches Ergebnis — ohne Zusammenfassung sind es **15 Prozent**, also fast doppelt so oft. Auf einen Link *innerhalb* der Zusammenfassung klicken sie in **1 Prozent** der Besuche.

Cloudflares Antwort darauf besteht aus mehr als Sperren. Das bisherige **Pay Per Crawl** wird zu **Pay Per Use** umgebaut: Bezahlt werden soll nicht mehr der Abruf, sondern der tatsächliche Nutzen — eine Seite kann einmal gecrawlt und danach tausendfach zitiert werden oder umgekehrt hundertmal geholt und nie verwendet. Erste Partner sind Ceramic.ai mit einem Pay-per-Query-Modell und You.com, wo ein Agent gezielt für ein einzelnes Premium-Dokument zahlt. Dazu kommen ein neues **Attribution-Business-Insights**-Dashboard für Bot-Management-Kunden und ein Forschungsprogramm zur Crawl-Effizienz — laut Cloudflare gehen über 50 Prozent des Crawl-Traffics guter Bots für Seiten drauf, die sich gar nicht geändert haben.

Ob daraus ein funktionierender Markt wird, ist offen; Cloudflare nennt es selbst ein Experiment. Für die Praxis zählt erst einmal die Frist.

## FAQ

### Betrifft mich die Umstellung, wenn ich nicht bei Cloudflare bin?

Nicht direkt. Die neuen Defaults sind eine Konfiguration im Cloudflare-Netzwerk und wirken nur für Domains, die dort liegen. Indirekt betrifft es dich trotzdem, weil sich das Crawler-Verhalten insgesamt verschiebt: Wenn ein relevanter Teil des Webs Training und Agenten sperrt, ändern die Betreiber ihre Crawler — und die neuen, getrennten Bots erscheinen dann auch bei dir in den Logs.

### Verliere ich Google-Rankings, wenn ich Training blockiere?

Möglich, und genau das ist das Risiko. Weil ab dem 15. September die restriktivste Regel gilt und Googlebot sowohl für Suche als auch fürs Training crawlt, sperrt eine Training-Blockade ihn vollständig aus. Ohne Zugriff keine Indexierung, ohne Indexierung kein Ranking. Wenn dir Suchsichtbarkeit wichtig ist, ist die Training-Sperre keine risikofreie Standardeinstellung mehr.

### Was ist der Unterschied zwischen Agent und Search?

Der Zeitpunkt und der Zweck. Ein Search-Crawler baut auf Vorrat einen Index auf, um später Fragen beantworten zu können. Ein Agent kommt, weil *jetzt gerade* ein Mensch etwas von deiner Seite will — er liest eine Seite, füllt ein Formular aus oder holt eine Information, auf die jemand wartet. Wirtschaftlich sind das zwei völlig verschiedene Dinge: Der eine verspricht künftigen Traffic, der andere *ist* bereits der Besuch, nur ohne Browser.

### Muss ich jetzt etwas an meiner `robots.txt` ändern?

Zwingend nicht. Die `robots.txt` bleibt die Präferenz-Ebene und wird von der Cloudflare-Umstellung nicht angefasst. Sinnvoll ist trotzdem, beide Ebenen aufeinander abzustimmen: Was du im CDN blockierst, solltest du auch in der `Content-Signal`-Zeile nicht ausdrücklich einladen. Wer die Gelegenheit nutzen will, ergänzt gleich das neue `use`-Feld.

## Weiterlesen

Die Präferenz-Ebene mit allen Signalen, dem neuen `use`-Feld und den pfad-spezifischen Regeln steht in [Content Signals & C2PA](https://www.jpkc.com/db/blog/content-signals-c2pa/). Das technische Crawler-Management und der Rest des GEO-Fundaments stehen in [Structured Data & Technical GEO](https://www.jpkc.com/db/blog/structured-data-technical-geo/); den Rahmen liefert der Pillar [Was ist GEO?](https://www.jpkc.com/db/blog/was-ist-geo/). Wie du die Wirkung überhaupt misst, steht in [GEO messen — und der Ausblick auf Agenten](https://www.jpkc.com/db/blog/geo-messen-ausblick/). Deine eigenen Crawler-Regeln prüfst du mit dem [SEO-&-GEO-Analyzer](https://www.jpkc.com/db/tools/seo/).

Cloudflares Originalquellen: der Blogpost [„Ihre Seite, Ihre Regeln"](https://blog.cloudflare.com/de-de/content-independence-day-ai-options/) zu Taxonomie und Defaults sowie der [Bot-Report zum agentischen Internet](https://blog.cloudflare.com/de-de/agentic-internet-bot-report/) mit den Zahlen.