Wie man eine robots.txt schreibt, die KI-Scraper tatsächlich blockiert

Die unbequeme Wahrheit über robots.txt

Eine robots.txt-Datei ist kein Schloss. Sie ist ein Schild an der Tür.

Dieser Unterschied ist wichtig, wenn Teams fragen, ob sie „KI-Scraper blockieren“ können — mit einer kleinen Textdatei. Für seriöse Crawler, die das Robots Exclusion Protocol befolgen, gilt: ja. Eine korrekt geschriebene robots.txt kann ihnen sagen, dass sie Ihre Seiten nicht crawlen sollen. Gegen unbekannte Scraper, Nachahmer, Browser-Automatisierung und Bots, denen es schlicht egal ist, bewirkt sie für sich allein nichts.

Das praktische Ziel lautet also nicht: „Scraping unmöglich machen.“ Es lautet:

• Konformen KI-Crawlern mitteilen, dass sie Ihre Website nicht nutzen sollen.
• Vermeiden, versehentlich Suchmaschinen oder nützliche Dienste zu blockieren.
• Stärkere serverseitige Kontrollen gegen Missbrauch ergänzen.
• Die Richtlinie wartbar halten, wenn sich Crawler-Namen ändern.

Das ist die langweilige Version. Es ist auch die Version, die funktioniert.

Was robots.txt leisten kann und was nicht

Eine robots.txt-Datei liegt im Stammverzeichnis einer Website:

https://example.com/robots.txt

Crawler rufen sie ab, bevor sie crawlen. Die Datei enthält Gruppen von Regeln. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, gefolgt von Allow- oder Disallow-Direktiven.

Eine einfache Sperre für die gesamte Website sieht so aus:

User-agent: GPTBot
Disallow: /

Das bedeutet: Wenn du GPTBot bist, crawle nichts auf dieser Website.

Aber robots.txt hat klare Grenzen:

1. Sie ist freiwillig. Böswillige Akteure können sie ignorieren.
2. Sie verhindert nicht, dass eine URL von einem normalen Browser oder Skript angefordert wird.
3. Sie entfernt keine Inhalte, die bereits anderswo gesammelt wurden.
4. Sie definiert für sich allein kein Urheberrecht, keine Lizenzierung und keine Trainingsrechte.
5. Sie kann so falsch konfiguriert werden, dass die falschen Bots blockiert werden.

Wenn Sie echte Zugriffskontrolle benötigen, verwenden Sie Authentifizierung, Autorisierung, Rate Limiting, IP-basierte Kontrollen, Bot-Management oder rechtliche Maßnahmen. Robots.txt ist weiterhin nützlich, gehört aber in eine breitere Strategie zum Schutz von Inhalten.

Das ähnelt anderen Governance-Problemen im Web: Die sichtbare Kontrolle ist selten die ganze Kontrolle. Wenn Ihre Organisation intern bereits unverwaltete KI-Nutzung hat, gilt dasselbe Prinzip; ein kurzer Shadow-AI-Audit ist oft nützlicher als die Annahme, ein einzelnes Richtliniendokument löse das Problem.

Beginnen Sie mit Ihrer Richtlinienentscheidung

Bevor Sie die Datei bearbeiten, entscheiden Sie, was Sie eigentlich blockieren möchten.

Mit „KI-Scraper“ meinen Menschen mindestens vier verschiedene Dinge:

• Crawler, die zum Sammeln von Trainingsdaten verwendet werden.
• KI-Such- oder Antwortmaschinen-Crawler.
• Vom Nutzer ausgelöste Fetcher, etwa wenn jemand ein KI-Produkt bittet, eine URL zusammenzufassen.
• Generische Scraper, die sich als gewöhnliche Browser ausgeben.

Vielleicht möchten Sie alle blockieren. Oder Sie möchten Auffindbarkeit in der Suche beibehalten, aber Modelltraining ausschließen. Das ist nicht dieselbe Richtlinie.

OpenAI dokumentiert zum Beispiel getrennte User Agents für verschiedene Zwecke, darunter GPTBot, ChatGPT-User und OAI-SearchBot. Google verwendet Google-Extended als Kontroll-Token für einige Gemini- und Vertex AI-Anwendungsfälle, während normales Crawling für Google Search von anderen Googlebot-User-Agents übernommen wird.

Diese Trennung ist wichtig. Wenn Sie breite User Agents unbedacht blockieren, können Sie die normale Sichtbarkeit in der Suche beeinträchtigen, während Sie eigentlich KI-Training blockieren wollen.

Eine vernünftige robots.txt-Vorlage zum Blockieren von KI

Hier ist ein konservativer Ausgangspunkt, um mehrere häufig dokumentierte KI-bezogene Crawler zu blockieren und allgemeine Such-Crawler unangetastet zu lassen:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Das ist keine magische universelle Liste. Es ist ein wartbares Muster.

Ein paar Hinweise:

• Disallow: / bedeutet: „keinen Pfad crawlen.“
• User-agent: * gilt für Crawler, die keiner spezifischeren Gruppe zugeordnet werden.
• Allow: / ist für die Standardgruppe nicht zwingend erforderlich, macht Ihre Absicht aber klar.
• Halten Sie Kommentare kurz. Einige Parser sind tolerant, aber robots.txt sollte langweilig bleiben.
• Nehmen Sie keine privaten URLs in robots.txt auf. Die Datei ist öffentlich, und das Auflisten sensibler Pfade kann sie erst bekannt machen.

Der letzte Punkt verdient Wiederholung. Robots.txt ist kein Geheimhaltungsmechanismus. Wenn /client-contracts/ nicht öffentlich sein soll, schützen Sie es mit Authentifizierung. Verbieten Sie es nicht nur per Disallow.

Vorsicht mit Google-Extended

Google-Extended wird häufig missverstanden. Es ist nicht dasselbe wie das Blockieren von Google Search.

Laut Googles Dokumentation ist Google-Extended ein eigenständiger Produkt-Token, mit dem Publisher steuern können, ob Website-Inhalte zur Verbesserung bestimmter Gemini- und Vertex AI-Funktionen beitragen dürfen. Ihn zu blockieren sollte für sich allein Googlebot nicht daran hindern, für Search zu crawlen.

Ersetzen Sie dennoch nicht alle Google-Direktiven durch eine breite Sperre wie diese, es sei denn, Sie meinen es wirklich so:

User-agent: Googlebot
Disallow: /

Das würde dem Haupt-Crawler von Google Search mitteilen, Ihre Website nicht zu crawlen. Für die meisten öffentlichen Websites ist das nicht gewünscht.

Dieselbe Unterscheidung gilt auch anderswo. Manche Anbieter trennen Trainings-Crawler von nutzerseitig ausgelöstem Browsing oder KI-Such-Crawlern. Andere tun das nicht. Sie müssen die Dokumentation der Bots lesen, die für Sie relevant sind, und Ihre robots.txt als lebende Datei behandeln, nicht als einmalig abzuhakendes Kontrollkästchen.

Testen Sie die Datei wie Produktionscode

Robots.txt sieht einfach aus, und genau deshalb kann sie leicht kaputtgehen.

Häufige Fehler sind:

• Sie an den falschen Ort hochzuladen, etwa nach /assets/robots.txt statt nach /robots.txt.
• Typografische Anführungszeichen aus einem Dokumenteditor zu übernehmen.
• Versehentlich alle Crawler mit User-agent: * und Disallow: / zu blockieren.
• Anzunehmen, dass die Datei einer Domain auch für eine andere Subdomain gilt.
• Zu vergessen, dass http://, https://, www und Nicht-www-Hosts je nach Setup unterschiedlich behandelt werden können.

Prüfen Sie bei Websites mit mehreren Domains jeden kanonischen Host. Eine robots-Datei unter https://www.example.com/robots.txt regelt nicht automatisch https://app.example.com/robots.txt.

Prüfen Sie beim Debugging die tatsächliche HTTP-Antwort, nicht nur das, was die Vorschau Ihres CMS zeigt. Sie möchten eine 200 OK-Antwort, möglichst den Content-Type text/plain und genau die Datei, die Sie erwarten. Wenn Weiterleitungen, Caching oder CDN-Regeln beteiligt sind, hilft die Prüfung der Roh-Header. Der Workflow aus Weiterleitungen und HTTP-Header in Produktion debuggen gilt hier direkt.

Ergänzen Sie serverseitige Kontrollen für Bots, die die Regeln ignorieren

Wenn der Crawler konform ist, ist robots.txt das sauberste Signal. Wenn der Crawler missbräuchlich handelt, brauchen Sie Durchsetzung.

Praktische Kontrollen sind unter anderem:

Rate Limiting

Legen Sie Schwellenwerte für ungewöhnliche Anfragemuster fest: zu viele Seiten pro Minute, tiefes Durchlaufen von Pagination, wiederholte 404-Fehler oder hohes Anfragevolumen von einer kleinen Gruppe von IPs. Rate Limits sollten großzügig genug sein, um echte Nutzer nicht zu bestrafen, und streng genug, um Massenauslesung teuer zu machen.

User-Agent-Filterung

Sie können dokumentierte KI-Crawler-User-Agents auf Webserver-, Reverse-Proxy-, CDN- oder Anwendungsebene blockieren. Das ist stärker als robots.txt, weil tatsächlich eine Ablehnungsantwort zurückgegeben wird.

Nginx kann zum Beispiel ein User-Agent-Muster blockieren, auch wenn Produktionsregeln sorgfältig getestet werden sollten:

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

Das ist nicht narrensicher. User-Agent-Strings lassen sich leicht fälschen. Aber es stoppt den ehrlichen oder bequemen Traffic und reduziert die Last.

IP- und ASN-Kontrollen

Einige Betreiber veröffentlichen IP-Bereiche, viele Scraper-Ökosysteme jedoch nicht. IP-basiertes Blocking kann bei offensichtlichem Missbrauch funktionieren, besonders bei Cloud-Hosting-Bereichen ohne normalen Nutzer-Traffic, kann aber auch False Positives erzeugen. Nutzen Sie Logs, bevor Sie Regeln setzen.

Authentifizierung und Paywalls

Wenn Inhalte nicht in großem Umfang kopiert werden dürfen, stellen Sie den vollständigen Inhalt nicht unter einer öffentlichen URL bereit. Robots.txt ist ungeeignet für vertrauliches Material, lizenzierte Datenbanken, private Communities oder bezahlte Archive.

Content-Minimierung

Manchmal ist die beste Schutzmaßnahme architektonisch. Stellen Sie keine unnötigen APIs, großen JSON-Payloads, versteckten Metadaten, Entwurfsendpunkte oder vollständigen Archive bereit, wenn die öffentliche Seite nur eine kleine Teilmenge benötigt. Bildlastige Websites sollten auch darüber nachdenken, welche Metadaten sie veröffentlichen; die Datenschutzlogik aus EXIF-Metadaten vor dem Teilen von Fotos online entfernen gilt auch für Content-Operations.

Verwenden Sie Robots-Meta-Tags für Regeln auf Seitenebene

Robots.txt steuert das Crawling. Robots-Meta-Tags und X-Robots-Tag-Header steuern Indexierung und Snippet-Verhalten für konforme Suchmaschinen und Crawler.

Zum Beispiel:

<meta name="robots" content="noindex, noarchive">

Oder als HTTP-Header:

X-Robots-Tag: noindex, noarchive

Das sind keine KI-spezifischen Schutzschilde. Sie sind nützlich, wenn eine Seite zugänglich, aber nicht indexiert sein soll. Wenn Sie einen Crawler jedoch per robots.txt daran hindern, eine Seite abzurufen, sieht er das Meta-Tag auf Seitenebene möglicherweise nie. Verlassen Sie sich nicht auf ein noindex-Tag auf einer URL, die der Crawler nicht crawlen darf.

Die grobe Regel:

• Verwenden Sie robots.txt, um Crawling zu reduzieren oder zu verhindern.
• Verwenden Sie Meta Robots oder X-Robots-Tag, um Indexierungsverhalten zu steuern.
• Verwenden Sie serverseitige Kontrollen, um Zugriff durchzusetzen.

Überwachen Sie nach der Veröffentlichung die Logs

Die Veröffentlichung der Datei ist nur der erste Schritt. Prüfen Sie danach Ihre Logs.

Achten Sie auf:

• Anfragen an /robots.txt von den von Ihnen genannten User Agents.
• Fortgesetztes Crawling, nachdem Disallow-Regeln ausgeliefert wurden.
• Verdächtige User Agents mit hohem Volumen.
• Browserähnliche User Agents, die tausende Seiten nacheinander anfordern.
• Wiederholte Zugriffe auf Feeds, Sitemaps, Suchseiten und Pagination.

Wenn ein Bot robots.txt anfordert, eine vollständige Disallow-Regel sieht und dann stoppt, hat robots.txt ihren Job erledigt. Wenn er weitermacht, überführen Sie diesen Bot in die Durchsetzung: Rate Limits, Sperren oder Authentifizierung.

Überprüfen Sie auch die Sichtbarkeit Ihrer Sitemap. Sitemaps sind für Suchmaschinen nützlich, aber auch bequeme Karten für Scraper. Das bedeutet nicht, dass Sie sie von normalen Websites entfernen sollten. Es bedeutet, dass Sie keine URLs aufnehmen sollten, die öffentliche Systeme nicht entdecken sollen.

Halten Sie die Datei klein und geprüft

Robots.txt neigt dazu zu veralten. Ein Marketingteam fügt eine Kampagnen-Microsite hinzu. Ein Entwickler ergänzt einen Staging-Pfad. Ein Anbieter ändert den Namen seines Crawlers. Zwei Jahre später weiß niemand mehr, warum die Hälfte der Regeln existiert.

Behandeln Sie sie als Konfiguration:

• Speichern Sie sie nach Möglichkeit in der Versionskontrolle.
• Fügen Sie für jede KI-Crawler-Gruppe einen kurzen Kommentar hinzu.
• Überprüfen Sie sie vierteljährlich.
• Prüfen Sie die Anbieter-Dokumentation, bevor Sie breite Regeln hinzufügen.
• Testen Sie nach Änderungen an CDN, CMS oder Hosting.

Wenn Ihre Website KI-unterstützte Inhalte veröffentlicht, trennen Sie außerdem Crawler-Richtlinien von redaktioneller Transparenz. Das Blockieren von KI-Scrapern betrifft Zugriff und Wiederverwendung. Offenlegung betrifft das Vertrauen der Leser. Ethisch überschneiden sie sich, aber sie sind nicht dieselbe Kontrolle. Ein praktischer Ansatz zur Offenlegung wird in wie ehrliche KI-Offenlegung auf einer kleinen Website aussieht behandelt.

<!-- tool-cta:start -->

💡 Probieren Sie dies aus: Nachdem Sie Regeln für KI-Crawler hinzugefügt haben, überprüfen Sie die Syntax mit dem Robots.txt Tester, damit Sie nicht versehentlich auch legitime Bots blockieren.

<!-- tool-cta:end -->

Das Fazit

Eine gute robots.txt-Datei blockiert konforme KI-Crawler. Sie stoppt kein entschlossenes Scraping, keine kopierten User-Agent-Strings, keine kompromittierten Browser und keine Menschen, die Ihre Inhalte manuell in KI-Systeme einfügen.

Das macht sie nicht nutzlos. Es macht sie zu einer Schicht.

Schreiben Sie explizite Regeln für dokumentierte KI-Crawler. Vermeiden Sie breite Sperren, die die Sichtbarkeit in der Suche beeinträchtigen. Testen Sie die ausgelieferte Datei, nicht den Entwurf. Beobachten Sie Logs. Setzen Sie serverseitige Kontrollen dort ein, wo Verhalten von unerwünscht zu missbräuchlich wird.

Das Web beruhte schon immer auf einer Mischung aus Protokoll, Normen und Durchsetzung. Robots.txt ist die Normen-Schicht. Nutzen Sie sie, aber verwechseln Sie sie nicht mit einer Mauer.