Bot-Schutz, der Kunden, Googlebot und KI-Bots durchlässt

Mehr Bots als Menschen

Das Dilemma beginnt mit einer einfachen Zahl. Laut dem Bad Bot Report 2026 von Imperva kamen 2025 53 % des gesamten Web-Traffics von automatisierten Programmen, 40 % von schädlichen Bots. Im Jahr davor waren es 51 % und 37 %. Die Aufgabe für Website-Betreiber ist deshalb, Missbrauch zu stoppen, ohne dabei echte Nutzer und erwünschte Bots zu vergraulen.

Quelle ist Imperva (Thales), Bad Bot Report 2025 und 2026. Den Anteil der erwünschten Bots nennt Imperva nicht ausdrücklich, er ergibt sich aus der Differenz. Je nach Branche liegt der Anteil höher. Für Reise-Websites nannte Imperva im Blog zum Report 2025 einen Anteil schädlicher Bots von 48 %, die Pressemitteilung vom selben Tag spricht von 41 %.

Was kosten schädliche Bots?

Schädliche Bots greifen Preise ab, testen gestohlene Zugangsdaten (Credential Stuffing), übernehmen Kundenkonten und belasten die Server. Belastbare Kostenzahlen kommen fast nur von Herstellern von Bot-Abwehr. Ein White Paper von F5 aus dem März 2025 rechnet ein Beispiel durch. Ein großer Online-Händler mit 31 Millionen Kundenkonten und 54 US-Dollar Monatsumsatz je Konto verliert durch Bot-Angriffe geschätzt eine Million US-Dollar im Jahr. Für die Zeit nach dem Wechsel zu einer modernen Bot-Abwehr hat F5 mit dem eigenen Rechner diesen Nutzen modelliert.

Das sind Projektionen eines Herstellers für seine eigene Lösung. Interessant ist, woher der größte Posten kommt. Der Gewinn entsteht vor allem durch weniger Reibung für echte Kunden, also dadurch, dass die Abwehr die Richtigen durchlässt.

KI-Crawler als neue Last

Mit den KI-Diensten ist eine neue Art von Bot-Traffic dazugekommen. ChatGPT hatte laut OpenAI im November 2023 100 Millionen wöchentliche Nutzer, im Februar 2025 400 Millionen, im Oktober 2025 über 800 Millionen und im Februar 2026 900 Millionen. Die Crawler dahinter rufen viele Seiten ab und schicken wenig Besucher zurück. Cloudflare misst dafür das Verhältnis von Crawls zu Weiterleitungen.

Cloudflare weist selbst darauf hin, dass die Claude-App keinen Referrer sendet und die Werte für Anthropic deshalb zu hoch ausfallen können. Aktuelle Werte zeigt Cloudflare Radar unter AI Insights.

Wie teuer das für kleine Websites werden kann, hat Read the Docs im Juli 2024 beschrieben. Ein einzelner Crawler lud im Mai 2024 73 TB gezippte HTML-Dateien herunter, an einem Tag fast 10 TB, und verursachte über 5.000 US-Dollar Bandbreitenkosten. Nachdem das Team KI-Crawler blockiert hatte, sank die Bandbreite um 75 %, von rund 800 GB auf rund 200 GB am Tag. Hätte all dieser Traffic die eigenen Server erreicht, hätte er laut Read the Docs rund 50 US-Dollar am Tag gekostet, also etwa 1.500 US-Dollar im Monat.

Damit steht jeder Betreiber vor der Wahl, KI-Crawler zu sperren und in KI-Antworten zu fehlen oder sie zuzulassen und die Last zu tragen. Es gibt einen dritten Weg, der weiter unten im Abschnitt zur Angriffsfläche steht.

Wenn die Abwehr die Falschen trifft

Im Kampf gegen Bots werden viele Websites zu ihrem eigenen Gegner. Jede Hürde, die einen Bot aufhält, kostet auch einen Teil der echten Besucher. Am deutlichsten zeigt sich das bei CAPTCHAs.

Eine Umfrage von Fastly unter 881 US-Onlinekäufern ergab, dass 18,7 % nach einem gescheiterten CAPTCHA aufgeben. Auch das ist eine Herstellerumfrage, die Richtung deckt sich aber mit den Studien.

VPN-Nutzer und Firmennetze

Viele Menschen surfen über ein VPN, aus Gründen des Datenschutzes oder weil ihr Arbeitgeber es verlangt. Laut Security.org nutzten 2026 42 % der Erwachsenen in den USA ein VPN, 2025 waren es 32 %. Diese Nutzer teilen sich wenige IP-Adressen mit vielen anderen, darunter auch Angreifern. Cloudflare schreibt, dass Besucher aus geteilten Netzen, VPNs und Tor oft eine schlechte IP-Reputation haben und deshalb eher eine Challenge-Seite sehen. Dasselbe gilt für Firmen-Gateways und Mobilfunknetze, die viele Nutzer hinter einer Adresse bündeln. Was Bots fernhalten soll, hält dann auch echte Kunden fern.

Was bedeutet Bot-Schutz für SEO und GEO?

Für Suchmaschinen und KI-Dienste ist die Bot-Abwehr eine stille Fehlerquelle. Die robots.txt kann einen Bot erlauben, während die Firewall oder der Bot-Schutz des CDN ihn mit einer Challenge-Seite oder Status 403 abweist. Googlebot bekommt dann statt deiner Seite eine Prüfseite, und KI-Dienste können deine Inhalte nicht abrufen.

• Brauchst du kurzfristig weniger Crawling, sende laut Google 500, 503 oder 429 statt 200, gern mit Retry-After. Google warnt, dass das nicht länger als ein bis zwei Tage dauern sollte, sonst leidet die Website in Google-Produkten.
• 403 und 404 eignen sich laut Google nicht zum Drosseln. Google behandelt sie als Antwort auf die URL, mit Folgen für die Indexierung.
• Prüfe in deinen Logfiles, ob Googlebot und die KI-Bots, die du zulassen willst, Status 200 bekommen. Wie das geht, steht im Ratgeber Logfile-Analyse.

KI-Bots und die Standards von Cloudflare

Viele Websites liegen hinter Cloudflare, und dort haben sich die Standards für KI-Bots zweimal geändert. Am 01.07.2025 hat Cloudflare angekündigt, KI-Crawler für neue Domains standardmäßig zu blockieren, solange sie die Inhalte-Anbieter nicht bezahlen. Seit dem 01.07.2026 teilt Cloudflare KI-Traffic in drei Klassen auf, Search, Agent und Training. Je Klasse wählst du, ob sie auf allen Seiten, nur auf Seiten mit Werbung oder gar nicht gesperrt wird.

Ab dem 15.09.2026 gelten für Domains, die neu zu Cloudflare kommen, neue Standards. Bots der Klassen Training und Agent sind auf Seiten mit Werbung gesperrt, Search bleibt erlaubt. Crawler, die Suche und Training verbinden, fallen dabei unter die Sperre für Training. Ob und wie bestehende Domains betroffen sind, sagt Cloudflare in der Ankündigung nicht. Lies die Einstellungen deshalb selbst aus.

Daneben bietet Cloudflare eine verwaltete robots.txt mit Content Signals an, also Angaben dazu, ob Inhalte für Suche (search), als Eingabe für KI-Antworten (ai-input) oder für Training (ai-train) genutzt werden dürfen. Der Standard von Cloudflare ist search=yes, ai-train=no. Google hat am 30.10.2026 angekündigt, einen gemeinsamen Training-Token in der robots.txt zu unterstützen, der gerade bei der IETF als Entwurf entsteht. Welche KI-Crawler es gibt und wie du sie per robots.txt steuerst, steht im Ratgeber KI-Crawler, die Einstellungen von Cloudflare im Ratgeber Cloudflare für SEO und GEO.

Echte Bots von gefälschten unterscheiden

Den User-Agent kann jeder setzen. Viele Angreifer geben sich deshalb als Googlebot aus. Eine sichere Bot-Regel lässt einen Bot nur durch, wenn er sich auf einem dieser drei Wege ausweist.

1. Veröffentlichte IP-Listen. Google stellt seine Listen seit März 2026 unter developers.google.com/static/crawling/ipranges/ bereit, aufgeteilt nach Crawlern, Spezial-Crawlern, nutzergestarteten Abrufen und Agenten. Bing veröffentlicht bingbot.json, OpenAI Listen für GPTBot, OAI-SearchBot und ChatGPT-User, Perplexity für PerplexityBot und Perplexity-User.
2. Reverse DNS. Google empfiehlt, die IP rückwärts aufzulösen, die Domain zu prüfen (googlebot.com, google.com oder googleusercontent.com) und dann vorwärts aufzulösen. Nur wenn beide Richtungen zur selben IP führen, ist die Anfrage echt.
3. Signaturen nach Web Bot Auth. Bots signieren ihre Anfragen mit HTTP Message Signatures nach RFC 9421. Cloudflare führt solche signierten Agenten seit dem 01.07.2026 als Verified Bots. Google testet Web Bot Auth für einige KI-Agenten, der Cloud-Browser von ChatGPT signiert mit dem Header Signature-Agent: "https://chatgpt.com". Eine Arbeitsgruppe der IETF arbeitet am Standard.

So prüfst du eine IP aus deinem Log per Reverse DNS.

Bei Cloudflare übernimmt die Bot-Verwaltung diese Prüfung für alle Bots auf der Liste der Verified Bots. Eine eigene Regel, die alles mit „bot“ im User-Agent sperrt oder durchlässt, umgeht sie.

Abgestuft reagieren, vom Drosseln bis zum Sperren

Gute Bot-Abwehr unterscheidet zuerst und entscheidet dann. Drei Grundsätze helfen dabei.

1. Verhalten auswerten. Moderne Systeme bewerten Verhalten und Kontext einer Anfrage. Cloudflare vergibt dafür einen Bot Score.
2. Abgestuft reagieren. Drossle verdächtige Anfragen, liefere ihnen Inhalte aus dem Cache oder prüfe sie, bevor du sperrst. Lass die Bots warten und die Nutzer durch.
3. Angriffsfläche verkleinern. Je weniger überflüssige URLs deine Website hat, desto weniger finden gute und schlechte Bots zum Abrufen. Dazu mehr im nächsten Abschnitt.

Für Nutzer aus geteilten Netzen gibt es mit Privacy Pass zudem ein Verfahren, mit dem ein Browser belegen kann, dass dort ein Mensch sitzt, ohne die Person zu identifizieren.

CAPTCHAs barrierefrei einsetzen

Seit dem 28.06.2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz, das die EU-Richtlinie 2019/882 umsetzt. Es betrifft unter anderem viele Onlineshops. Der übliche Maßstab für Websites ist die WCAG. Erfolgskriterium 3.3.8 der WCAG 2.2 (Stufe AA) verlangt, dass ein Login keinen kognitiven Test wie das Abtippen verzerrter Zeichen erfordert, außer es gibt eine Alternative oder Hilfe. Ausgenommen ist das Erkennen von Objekten. Die W3C-Notiz „Inaccessibility of CAPTCHA“ beschreibt, warum klassische CAPTCHAs Menschen mit Behinderungen ausschließen. Cloudflare gibt für Turnstile an, dass es WCAG 2.2 AA erfüllt. Dieser Abschnitt ist keine Rechtsberatung.

Weniger URLs, weniger Angriffsfläche

Während viele Websites immer höhere Mauern bauen, hilft oft der umgekehrte Weg. Mach deine Website für Crawler weniger ergiebig, indem du das Labyrinth aus überflüssigen URLs abbaust, in dem gute wie schlechte Bots Ressourcen verschwenden.

Google schreibt, dass Websites mit weniger als ein paar tausend URLs meist ohne Eingriff effizient gecrawlt werden. Relevant wird das Crawl Budget laut Google bei großen Websites mit über einer Million Seiten, die sich etwa wöchentlich ändern, und bei mittleren Websites mit über 10.000 Seiten, die sich täglich ändern. Google warnt, dass seine Crawler den Rest der Website womöglich nicht erkunden, wenn sie zu viel Zeit mit URLs verbringen, die sie nicht crawlen sollten.

Wenn Filter Millionen URLs erzeugen

Laut Google ist die facettierte Navigation mit Abstand die häufigste Ursache für Overcrawling, die Website-Betreiber melden. Eine Kategorieseite mit fünf Filtern wie Farbe, Größe, Preis, Verfügbarkeit und Sortierung kann Tausende eigener URLs erzeugen. Builtvisible beschreibt den Fall von Very.co.uk mit über 11,2 Millionen indexierten URLs bei rund 160.000 eigentlichen Seiten. Nach der Bereinigung stiegen die organischen Umsätze um 325 % und der organische Traffic um 220 %, gemessen gegenüber August 2012.

Warum senken noindex und Canonical das Crawling kaum?

noindex und Canonical steuern, was in den Index kommt. Um die Angaben zu lesen, muss ein Bot die Seite aber abrufen und verbraucht dabei Bandbreite und Serverleistung. Google schreibt zum Crawl Budget ausdrücklich, dass noindex dafür nicht taugt, weil Google die Seite trotzdem anfragt. Ebenso rät Google davon ab, die robots.txt nur vorübergehend zu nutzen, um Crawl Budget umzuverteilen.

Was hilft in der Praxis?

• PRG-Muster für Filter. Post/Redirect/Get wurde ursprünglich gegen doppelt abgeschickte Formulare entwickelt. Filter laufen dabei über ein POST-Formular, der Server leitet auf die gefilterte Seite weiter. Weil Crawler POST-Formularen in der Regel nicht folgen, entstehen keine crawlbaren Filter-URLs. Das ist eine Praxis aus der SEO-Szene, beschrieben etwa im Seobility-Wiki. Eine Empfehlung von Google dazu gibt es nicht.
• Filter per robots.txt sperren, etwa mit Platzhaltern für ganze Parametermuster. Google nennt das in der Doku zur facettierten Navigation, ebenso URL-Fragmente (#) für Filter und Status 404 für leere Filterkombinationen.
• Interne Links aufräumen. Entferne Links auf sortierte oder gefilterte Varianten, die niemand finden muss.
• Parameter sparsam nutzen. Vermeide Session-IDs und Tracking-Parameter in internen Links. Das Parameter-Werkzeug der Search Console gibt es nicht mehr.
• Inhalte bereinigen. Lösche oder bündele Seiten, die über Monate keinen Traffic bringen, und leite sie weiter.

Was haben andere erreicht?

Der griechische Preisvergleich Skroutz hat 2018 und 2019 die Zahl seiner indexierten URLs von 25 Millionen auf 7,6 Millionen gesenkt. Das Team setzte 2,2 Millionen interne Suchseiten auf noindex und leitete 300.000 URLs auf passende Kategorien weiter. Neue URLs kamen danach in wenigen Tagen in den Index statt in zwei bis drei Monaten. In der Conductor Academy beschreibt Conductor, wie das durchschnittliche Crawl Budget der eigenen Website in zwei Jahren von 27 auf 253 Seiten am Tag stieg.

Auch die Forschung zeigt, wie viel Crawling verpufft. Laut der Studie Crawl4LLM von 2025 verwirft bisherige Arbeit oft über 90 % der gesammelten Rohdaten. Der Ansatz der Autoren erreicht über 95 % der bestmöglichen Leistung, obwohl er nur 2,2 % der Daten crawlt. Gleichzeitig schränken immer mehr Websites den Zugang ein. Die Data Provenance Initiative fand im Juli 2024, dass über 5 % der Tokens im Datensatz C4 und über 28 % der aktivsten, wichtigsten Quellen darin per robots.txt vollständig gesperrt waren. Über die Nutzungsbedingungen waren sogar 45 % eingeschränkt.

So misst du den Erfolg

• Crawl-Effizienz. Anteil der Crawls auf wichtige Seiten an allen Crawls, aus deinen Logfiles.
• Bot-Anteil an der Bandbreite. Bandbreite des Bot-Traffics im Verhältnis zur gesamten Bandbreite.
• Fehlerquote. Anteil der Antworten mit 4xx und 5xx an Bots, aus den Logs.
• Verhältnis von URLs zu Seiten. Alle auffindbaren URLs im Verhältnis zu den eigentlichen Inhaltsseiten, aus einem kompletten Crawl.
• Crawl-Statistik der Search Console. Anfragen pro Tag, Antwortzeit und Antworten nach Statuscode.

Typische Schritte je System

• Onlineshops. Filterparameter sperren oder per PRG-Muster umbauen, Canonicals für Produktvarianten setzen, Paginierung sauber lösen.
• WordPress. Unnötige Archive, Feeds und Parameter-URLs abbauen, die Crawl-Optimierung des SEO-Plugins nutzen.
• Enterprise-CMS. Eigene robots.txt-Regeln, facettierte Navigation umbauen, Session-IDs aus URLs entfernen.

So gehst du vor

1. Lies die Bot- und KI-Einstellungen deines CDN und deiner Firewall aus, auch die Standards, die ohne dein Zutun gelten.
2. Vergleiche sie mit deiner robots.txt. Beide sollten dasselbe wollen.
3. Prüfe in den Logfiles, welchen Status Googlebot, Bingbot und die gewünschten KI-Bots bekommen. Challenge-Seiten und 403 an erwünschte Bots sind ein Fehler.
4. Lass Bots nur nach Verifizierung über IP-Liste, Reverse DNS oder Signatur durch.
5. Ersetze harte Sperren, wo es geht, durch Drosseln und unauffällige Prüfungen. Setz CAPTCHAs nur an sensiblen Stellen ein und biete barrierefreie Alternativen.
6. Miss neben den abgewehrten Bots auch die Falsch-Positiven, also echte Nutzer und erwünschte Bots, die eine Prüfung oder Sperre trifft.
7. Bau überflüssige URLs ab, vor allem aus Filtern und Parametern.
8. Prüfe die Einstellungen regelmäßig. Bots, Anbieter und Standards ändern sich laufend, und manche Bots verdienen ausdrücklich einen Platz am Tisch.

Häufige Fehler

• Die robots.txt erlaubt einen Bot, aber das CDN blockiert ihn trotzdem.
• Eine Regel lässt alles mit „Googlebot“ im User-Agent durch und öffnet damit Angreifern die Tür.
• Rechenzentrums-IPs werden pauschal gesperrt und treffen Cloud-Agenten echter Kunden. Was KI-Browser brauchen, steht im Ratgeber Website für KI-Browser optimieren.
• Zum Drosseln wird 403 oder 404 gesendet, statt kurzzeitig 429 oder 503.
• Ein CAPTCHA auf jeder Produktseite statt nur bei Login und Kasse.
• Filter erzeugen Millionen URLs, und das Team versucht, sie nur mit noindex und Canonical in den Griff zu bekommen.

Häufige Fragen