KI-Bots auf Ihrem Server blockieren

Warum sollte man KI-Bots blockieren?

KI-Crawler sind zu einem normalen Bestandteil des Internetverkehrs geworden. Einige durchsuchen Inhalte für die Modellentwicklung, andere bauen Indizes für KI-gestützte Suchdienste auf, und wieder andere rufen eine Seite ab, weil ein einzelner Nutzer einen KI-Dienst dazu aufgefordert hat.

Das sind unterschiedliche Anwendungsfälle. Ein Publisher möchte vielleicht in KI-Suchen auffindbar bleiben, aber Crawling für das Training von Modellen ablehnen. Ein Online-Shop kann Referral-Traffic begrüßen und gleichzeitig unbekannte Scraper daran hindern wollen, immer wieder aufwendige Produkt-, Such- oder API-Seiten zu rendern.

Typische Gründe, automatisierten KI-Traffic einzuschränken, sind:

• unerwünschte Scraper daran hindern, eigene Inhalte zu konsumieren;
• PHP-, Anwendungs-, Datenbank-, Such- und Bandbreitenlast reduzieren;
• teure dynamische Endpunkte und APIs schützen;
• gefälschte Such- oder KI-Crawler fernhalten;
• kontrollieren, welche Dienste für die Modellentwicklung crawlen dürfen;
• Rauschen in Logs, Analytics und Betriebsmonitoring reduzieren.

Methode 1: Die Richtlinie in robots.txt veröffentlichen

Der übliche Ausgangspunkt ist /robots.txt. Das Robots Exclusion Protocol gibt Crawler-Betreibern eine maschinenlesbare Möglichkeit zu erkennen, welche Pfade sie nach Wunsch des Website-Betreibers aufrufen dürfen oder nicht.

Eine einfache Richtlinie, die mehrere Crawler für die Modellentwicklung blockiert und suchorientierten Zugriff zulässt, könnte so aussehen:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Allow: /

Das ist eine Beispielrichtlinie, keine allgemeingültige Empfehlung. Die richtige Konfiguration hängt davon ab, ob Sie Training, Auffindbarkeit in KI-Suchen und nutzerinitiierte Abrufe auf Ihre Inhalte zugreifen lassen möchten.

OpenAI: GPTBot und OAI-SearchBot sind getrennte Steuerungen

OpenAI dokumentiert GPTBot und OAI-SearchBot derzeit als voneinander unabhängige robots.txt-Steuerungen. Eine Website kann OAI-SearchBot zulassen, um in der ChatGPT-Suche sichtbar zu bleiben, und GPTBot gleichzeitig ablehnen, um anzugeben, dass gecrawlte Inhalte nicht für das Training der generativen KI-Basismodelle von OpenAI verwendet werden sollen.

Anthropic: unterschiedliche Bots für unterschiedliche Zwecke

Anthropic dokumentiert ClaudeBot für Inhalte, die zur Modellentwicklung beitragen können, Claude-SearchBot für die Suche und Claude-User für nutzerinitiierte Abrufe. Anthropic gibt an, dass diese Bots robots.txt-Anweisungen berücksichtigen.

Google-Extended ist ein robots.txt-Steuertoken

Google-Extended ist ein Sonderfall, weil es keinen eigenen HTTP-User-Agent-String besitzt. Google erklärt, dass dieses Token bestimmte Nutzungen bereits von Google gecrawlter Inhalte für Gemini-Modelltraining und Grounding steuert und dass Google-Extended die Aufnahme oder das Ranking in der Google-Suche nicht beeinflusst.

Perplexity unterscheidet Such-Crawling und nutzerinitiierte Abrufe

Perplexity dokumentiert PerplexityBot, um Websites in Suchergebnissen sichtbar zu machen, und Perplexity-User für Abrufe, die von einem Nutzer ausgelöst werden. Laut Dokumentation ignoriert Perplexity-User robots.txt im Allgemeinen, weil der Abruf vom Nutzer angefordert wurde. Das zeigt, warum sich die heutige Crawler-Landschaft nicht auf einen einzigen globalen „KI-Bot“-Schalter reduzieren lässt.

Warum robots.txt nicht genügt, wenn Zugriff wirklich blockiert werden muss

Die wichtigste Einschränkung steht bereits im Standard selbst. RFC 9309 stellt klar, dass robots.txt-Regeln keine Form der Zugriffsautorisierung sind. Google weist in seiner Dokumentation praktisch auf dasselbe hin: robots.txt kann einen beliebigen Crawler nicht technisch zur Einhaltung zwingen.

Der Request erreicht Ihren Server trotzdem. Ein kooperativer Crawler liest die Richtlinie und entscheidet, ob er fortfährt. Ein unbekannter Scraper kann die Datei vollständig ignorieren.

Das macht robots.txt nicht nutzlos. Es bedeutet lediglich, dass robots.txt und Zugriffskontrolle unterschiedliche Probleme lösen.

Methode 2: bekannte User-Agents in nginx oder Apache blockieren

Wenn Sie eine einfache harte Sperre wünschen, kann der Webserver ausgewählte User-Agent-Strings ablehnen, bevor der Request die Anwendung erreicht.

if ($http_user_agent ~* "(GPTBot|ClaudeBot|PerplexityBot)") {
    return 403;
}

Mit Apache und mod_rewrite lässt sich dieselbe Grundidee so umsetzen:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|PerplexityBot) [NC]
RewriteRule ^ - [F,L]

Diese Beispiele sind nützlich, wenn Sie eine bekannte Crawler-Identität bewusst ablehnen möchten. Sie verifizieren jedoch nicht, ob der Crawler tatsächlich der ist, für den er sich ausgibt.

Das Identitätsproblem: Ein User-Agent ist nur ein String

Jeder HTTP-Client kann behaupten, Googlebot, GPTBot, ClaudeBot oder ein normaler Chrome-Browser zu sein. Google warnt ausdrücklich davor, dass Crawler-User-Agents gefälscht werden können, und empfiehlt eine Verifikation statt blindem Vertrauen in den Namen.

Einfaches User-Agent-Blocking scheitert daher in zwei Richtungen:

• ein Scraper kann die Regel umgehen, indem er seinen User-Agent wie einen Browser aussehen lässt;
• ein bösartiger Client kann sich als vertrauenswürdiger Crawler ausgeben und hoffen, dass Ihre Allow-Regeln nur dem Namen vertrauen.

Wenn die Identität eines Crawlers wichtig ist, sollten Netzwerk-, Reputations- und Request-Kontextsignale mit der behaupteten Identität kombiniert werden.

Methode 3: serverseitige Bot-Intelligenz mit BotDetect

BotDetect ist für Situationen gedacht, in denen eine statische User-Agent-Regel nicht ausreicht, Sie Ihre Website aber auch nicht hinter ein anderes CDN oder einen zusätzlichen Reverse Proxy verschieben möchten.

Ihr Backend sendet Request-Metadaten an einen regionalen BotDetect-API-Knoten und erhält eine nachvollziehbare Entscheidung, die Ihre Anwendung verwenden kann:

Bot intelligence as an API — not another CDN

Der entscheidende architektonische Unterschied ist Kontrolle. Sie behalten Ihr Hosting, DNS, Ihr bestehendes CDN, den Reverse Proxy und die Anwendung. BotDetect ergänzt eine Intelligence-Schicht, statt selbst zum zwingenden Pfad für Ihren gesamten Traffic zu werden.

Nachvollziehbarkeit statt Blackbox-Entscheidung

BotDetect liefert einen Score von 0 bis 10 zusammen mit einem Grund und den beitragenden Signalen. Eine verdächtige Crawler-Entscheidung kann dadurch operativ erklärt werden, zum Beispiel:

{
  "score": 9,
  "reason": "fakecrawler",
  "action": "block",
  "signals": [
    "googlebot_asn_mismatch",
    "browser_headers_missing",
    "ip_reputation"
  ]
}

Welche Signale konkret verfügbar sind, hängt vom Request und der aktuellen Scoring-Logik ab. Entscheidend ist, dass der Administrator nachvollziehen kann, warum ein Request als verdächtig eingestuft wurde, statt nur blocked=true zu erhalten.

Gemeinsame Reputation: von anderswo beobachtetem Missbrauch profitieren

Eine einzelne Website sieht nur ihren eigenen Traffic. BotDetect nutzt zusätzlich gemeinsame Reputation, die aus Sicherheitsbeobachtungen über geschützte Dienste hinweg entsteht und an regionale Detection-Knoten verteilt wird. Taucht dieselbe missbräuchliche Quelle später an anderer Stelle auf, kann ihre Reputation bereits als zusätzliches Signal vorliegen.

Reputation ist keine dauerhafte automatische Bestrafung. Sie ist ein Eingangssignal, das mit dem aktuellen Request-Kontext und weiteren Signalen kombiniert wird.

Warum das stärker ist als robots.txt

BotDetect ersetzt robots.txt nicht. Es ergänzt die Ebene der Durchsetzung und Verifikation:

• robots.txt teilt legitimen Crawler-Betreibern mit, welche Richtlinie Sie wünschen;
• BotDetect hilft, den tatsächlich eingetroffenen Request zu bewerten;
• Ihr Server entscheidet, ob er ihn zulässt oder ablehnt.

Bei WordPress ist Bot-Schutz auch Einblick in automatisierten Traffic

Bei WordPress können unerwünschte Requests überproportional teuer sein, weil ein einzelner Request PHP, den WordPress-Bootstrap, Plugins, Datenbankabfragen und das Rendern des Themes auslösen kann.

Das BotDetect-WordPress-Plugin ist deshalb für mehr nützlich als nur für eine Block-Antwort. Website-Betreiber können im Monitor-Modus starten, sehen, an welchen Stellen Automatisierung auf die Website trifft, Entscheidungen prüfen und erst danach eine stärkere Durchsetzung aktivieren.

Typische WordPress-Bereiche, die man beobachten sollte:

• wp-login.php und Authentifizierungs-Traffic;
• XML-RPC;
• die WordPress REST API;
• admin-ajax.php;
• Suche, Formulare, Kommentare und parametrisierte URLs;
• Frontend-Inhalte, die von KI-Scrapern oder Fake-Crawlern angegriffen werden.

Unerwünschter KI-Traffic verursacht reale Infrastrukturkosten

Ein einzelner HTTP-Request wirkt fast kostenlos. In großer Menge kann er TLS-Verarbeitung, Anwendungsausführung, Cache-Misses, Datenbank- und Suchabfragen, API-Aufrufe, Logging, Speicher und Bandbreite auslösen.

Als bewusst vereinfachtes Beispiel: Wenn die effektiven Infrastrukturkosten eines dynamischen Requests nur €0,0001 betragen würden:

Diese Zahlen dienen nur der Veranschaulichung und sind keine allgemeine Kostenschätzung. Die tatsächlichen Request-Kosten hängen von Hosting, Caching, Anwendungsarchitektur, Datenbankarbeit, Bandbreite und Workload ab.

Der Punkt ist wirtschaftlich: Winzige Kosten pro Request werden relevant, sobald automatisierter Traffic Millionen von Requests erreicht. Unerwünschte Automatisierung früh abzuweisen kann daher echte Infrastrukturkapazität sparen.

robots.txt vs. User-Agent-Blocking vs. BotDetect

Eine praktische mehrschichtige Richtlinie

1. Entscheiden Sie, welchen KI-Zugriff Sie tatsächlich möchten. Trennen Sie Crawling für Modellentwicklung, KI-Suche und nutzerinitiierte Abrufe.
2. Veröffentlichen Sie die Richtlinie in robots.txt. Kooperative Crawler-Betreiber brauchen ein klares Standardsignal.
3. Beobachten Sie realen Traffic. Gehen Sie nicht davon aus, dass nur die Bots aus der Dokumentation Ihre Website treffen.
4. Vertrauen Sie Crawler-Namen nicht allein. Ein User-Agent ist selbst deklariert und kann gefälscht werden.
5. Erzwingen Sie wichtige Beschränkungen serverseitig. Wenn Zugriff wirklich verweigert werden muss, muss Ihr Server die endgültige Entscheidung treffen.
6. Beginnen Sie mit Monitoring statt sofort aggressiv zu blockieren. Prüfen Sie, was blockiert würde, und reduzieren Sie das Risiko von False Positives.

Häufig gestellte Fragen