Technische Umsetzung: robots.txt, Cloudflare und Bot-Management

Zwei Ebenen, die zusammengehören

Bot-Management funktioniert auf zwei strukturell verschiedenen Ebenen:

Deklaration – Die robots.txt teilt Crawlern mit, welche Inhalte sie besuchen dürfen und welche nicht. Sie ist das Standardwerkzeug, das seit Jahrzehnten existiert und von allen seriösen Bots respektiert wird.

Durchsetzung – Eine Firewall oder ein WAF (Web Application Firewall) wie Cloudflare entscheidet aktiv, welche Anfragen überhaupt den Server erreichen. Hier werden Regeln nicht nur deklariert, sondern technisch erzwungen.

Wer nur eine der beiden Ebenen nutzt, hat eine Lücke. Die robots.txt hilft nichts gegen Bots, die sie ignorieren. Cloudflare allein kann legitime Bots versehentlich blockieren, wenn keine klare Deklaration der Erwartungen vorhanden ist.

Eine funktionierende Bot-Strategie kombiniert beides.

robots.txt: Deklaration, nicht Durchsetzung

Die robots.txt ist eine Textdatei im Wurzelverzeichnis einer Website (/robots.txt), die das Robots Exclusion Protocol implementiert. Jeder Crawler, der das Protokoll respektiert, liest diese Datei und richtet sein Verhalten danach.

Wichtige Grundlage vorab: Die robots.txt ist eine Policy-Datei, keine Sicherheitsmaßnahme. Sie erklärt Absichten — erzwingt sie nicht. Missverständnisse darüber führen zu falschen Erwartungen.

Das Protokoll ist freiwillig. Es gibt keine technische Erzwingung. Googlebots, Bingbot, GPTBot, ClaudeBot und PerplexityBot halten sich erfahrungsgemäß daran. Aggressive Scraper, Spam-Bots oder schlecht konfigurierte Crawler tun das oft nicht.

Ein vollständiges Beispiel für eine gut strukturierte robots.txt mit Kommentaren:

# ===========================
# robots.txt – Stand April 2026
# ===========================

# Suchmaschinen – explizit erlauben (Pflicht)
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: Slurp
Allow: /

# KI-Bots – seriöse Anbieter erlauben
# Dokumentation: platform.openai.com/docs/gptbot
User-agent: GPTBot
Allow: /

# Dokumentation: anthropic.com/en/research/building-effective-agents
User-agent: ClaudeBot
Allow: /

# Perplexity nutzt eigenen Bot für Echtzeit-Antworten
User-agent: PerplexityBot
Allow: /

# Apple-Suche (kein klares Crawl-Programm, vorsichtig erlauben)
User-agent: Applebot
Allow: /

# ===========================
# Aggressive Scraper – blockieren
# ===========================

User-agent: AhrefsBot
Disallow: /

User-agent: SemrushBot
Disallow: /

User-agent: MJ12bot
Disallow: /

User-agent: DotBot
Disallow: /

# ===========================
# Standard für alle anderen
# ===========================

User-agent: *
Disallow: /intern/
Disallow: /admin/
Disallow: /api/
Disallow: /search

# Sitemap
Sitemap: https://example.com/sitemap.xml

Wichtig: Die expliziten Allow: / Einträge für Suchmaschinen und KI-Bots sind nicht technisch nötig, wenn der *-Block keine globale Sperrung enthält – aber sie machen die Absicht klar und erleichtern spätere Anpassungen.

Feinsteuerung: Crawl-Budget, Parameter, Pfade

Für Seiten mit vielen URLs lohnen sich drei zusätzliche Einträge:

Crawl-delay — verlangsamt KI-Crawler, die viele Seiten in kurzer Zeit besuchen. Google ignoriert das für Googlebot, aber viele KI-Crawler respektieren es:

User-agent: GPTBot
Allow: /
Crawl-delay: 2

Query-Parameter sperren — Bots crawlen parametrisierte URLs oft aggressiv und erzeugen Duplicate Content:

Disallow: /*?*
Disallow: /*&*

Pfade priorisieren — nicht nur sperren, sondern lenken. Wer KI-Bots als Quelle haben möchte, lenkt sie auf zitierfähige Inhalte:

Allow: /blog/
Disallow: /tag/
Disallow: /author/

Tag-Seiten und Autorenarchive sind selten zitierfähig. Blogartikel sind es. Die robots.txt kann das steuern — ohne Cloudflare-Konfiguration.

Wer das Projekt mit Astro.js betreibt: astro-crawler-policy ist ein Astro-Integration, die die robots.txt-Konfiguration direkt aus der Astro-Config generiert – inklusive KI-Bot-Regeln, ohne die Datei manuell zu pflegen.

Content Signals: Nutzungsrechte maschinenlesbar machen

Seit September 2025 gibt es eine ergänzende Ebene zur robots.txt: Cloudflare Content Signals. Keine Blockade, keine Durchsetzung — sondern eine maschinenlesbare Deklaration, wofür Inhalte genutzt werden dürfen.

Drei Signale decken die relevanten Nutzungsarten ab:

search — Erlaubt Indexierung für klassische Suchmaschinen
ai-input — Erlaubt die Nutzung als Live-Eingabe in KI-Antworten (z. B. Perplexity, ChatGPT Overviews)
ai-train — Erlaubt Training oder Fine-Tuning von Sprachmodellen

Die Signale werden direkt in die robots.txt eingebettet:

# Content Signals Policy
Content-Signal: search=yes, ai-input=yes, ai-train=no

Das erlaubt Zitationen in KI-Antworten, sperrt aber die Nutzung als Trainingsdaten. Umgekehrt lässt sich KI-Eingabe sperren und nur Suchindexierung erlauben — je nachdem, was das Ziel ist.

Content Signals sind freiwillig, genau wie die robots.txt selbst. Seriöse Crawler respektieren sie; aggressive Scraper nicht. Die Durchsetzung übernimmt weiterhin die Firewall. Die Kombination funktioniert so: Content Signals definieren die Absicht, Cloudflare-Regeln setzen sie technisch durch.

Kein Enforcement, kein Audit. Es gibt keinen Nachweis, ob sich ein Crawler an die deklarierten Signale hält. Content Signals sind kein Schutzmechanismus — sie sind ein Verhandlungsangebot an seriöse Anbieter. Wer tatsächlich durchsetzen will, braucht Firewall-Regeln.

Cloudflare: Drei Bot-Kategorien

Cloudflare klassifiziert Bots in einer mehrstufigen Taxonomie. Für die praktische Bot-Strategie sind drei Kategorien relevant:

Verified Bots – Crawler von Google, Bing, Apple und anderen großen Suchmaschinen, deren Identität Cloudflare aktiv verifiziert. Diese Bots bekommen standardmäßig freien Durchgang, weil sie von Cloudflare als legitim eingestuft werden.

AI Bots – Seit 2024 hat Cloudflare eine eigene Kategorie für KI-Crawler eingeführt: GPTBot, ClaudeBot, PerplexityBot und vergleichbare Systeme. Diese sind separat konfigurierbar – ohne sie mit dem Verified-Bot-Traffic oder dem allgemeinen Bot-Traffic zu vermischen.

Unknown/Bad Bots – Alle anderen Bots, die nicht als verifiziert oder KI-klassifiziert sind. Das sind die aggressiven Scraper, Spam-Bots, Vulnerability-Scanner und schlecht dokumentierte Crawler.

Die drei Kategorien lassen sich in Cloudflare Custom Rules direkt adressieren:

Regel-Typ	Trigger	Aktion	Zweck
Verified Bots	`cf.verified_bot = true`	Allow	SEO-Traffic sicherstellen
AI Bots	`cf.bot_management.type = "ai"`	Allow + Log	Zitationen trackbar machen
Unknown Bots	Bot-Score < 30	Challenge / Rate-Limit 100/min	Scraper abwehren
Bekannte Scraper	User-Agent: AhrefsBot, SemrushBot	Block	Bandbreite schützen

Konkrete Rule-Syntax für vier häufige Setups:

AI Bots erlauben, aber Rate-limitieren — verhindert, dass KI-Crawler die Site in einer Session vollständig durchlaufen:

(cf.bot_management.type eq "ai")
→ Allow + Rate Limit: 300 Requests / 10 Minuten

Unknown Bots nach Score abstufen:

(cf.bot_management.score lt 30) → Managed Challenge
(cf.bot_management.score lt 10) → Block

Geo + Bot kombinieren — blockiert internationalen Scraper-Traffic ohne bekannte Bots zu treffen:

(cf.bot_management.score lt 30 and ip.geoip.country ne "DE")
→ Block

Sinnvoll für Seiten mit primär deutschsprachigem Publikum, bei denen unbekannter Bot-Traffic aus anderen Regionen kein legitimer Use Case ist.

API-Endpunkte direkt schützen — robots.txt reicht hier nicht, weil viele Scraper direkt auf JSON-APIs gehen:

(http.request.uri.path contains "/api/")
→ Block (für Bots mit Score < 20)

Praktisches Setup: Schritt für Schritt

Eine funktionierende Kombination aus robots.txt und Cloudflare lässt sich in fünf Schritten aufbauen:

1. robots.txt konfigurieren Deklaration der Erwartungen: Suchmaschinen erlauben, KI-Bots selektiv, bekannte Bad Bots blockieren, interne Bereiche sperren.

2. Cloudflare Bot Management aktivieren Im Cloudflare Dashboard unter Security → Bots. Bot Fight Mode oder Bot Management je nach Plan.

3. AI-Bot-Regeln setzen Firewall-Regel: if (cf.bot_management.ja3_fingerprint in $ai_bots) → Allow. Oder Challenge für unbekannte Bots.

4. Rate-Limits für unbekannte Bots Unbekannte Bots bekommen Rate-Limits statt vollständige Blockierung – das fängt Scraper ohne false positives bei legitimen Crawlern.

5. Monitoring aufsetzen Cloudflare Analytics zeigt Bot-Traffic nach Kategorie. Eigene Monitoring-Schicht für verdächtige Muster parallel dazu.

Zu Schritt 2: Der “Bot Fight Mode” (kostenlos) blockiert automatisch erkannte Bad Bots. Das “Bot Management” (Pro/Enterprise) gibt granularere Kontrolle und die AI-Bot-Kategorie. Für die meisten Setups reicht Bot Fight Mode als Einstieg.

Zu Schritt 3: In Cloudflare Custom Rules kann eine Regel nach cf.bot_management.type filtern. AI Bots haben einen eigenen Typwert, der direkt adressierbar ist. So lässt sich eine Regel bauen: “AI Bots erlauben, Unknown Bots challengen.”

Zu Schritt 4: Rate-Limiting für Unknown Bots verhindert aggressive Scraping, ohne legitime Bots mit fehlerhafter Klassifizierung zu blockieren. Eine typische Regel: Mehr als 100 Anfragen pro Minute von einem Unknown Bot → Temporary Block für 1 Stunde.

Was Cloudflare nicht löst

Cloudflare ist ein starkes Werkzeug – aber kein vollständiges. Drei Grenzen sind relevant:

robots.txt-Respekt liegt beim Bot, nicht bei Cloudflare. Cloudflare sieht nur, ob ein Bot ankommt. Ob der Bot vorher die robots.txt gelesen und respektiert hat, ist Sache des Bot-Betreibers. Cloudflare und robots.txt ergänzen sich – sie ersetzen sich nicht.

False Positives sind möglich. Cloudflares Bot-Klassifizierung ist gut, aber nicht fehlerfrei. Ein neuer KI-Bot, der noch nicht in der Datenbank ist, wird als Unknown Bot eingestuft – auch wenn er legitim ist. Neue Bot-User-Agents regelmäßig prüfen und ggf. manuell whitelisten.

Monitoring bleibt eigene Aufgabe. Cloudflare liefert Bot-Traffic-Daten, aber keine Aussagen darüber, ob als Quelle zitiert wurde oder nicht. Dafür braucht es separate Beobachtungsmethoden – zum Beispiel die direkte Abfrage in ChatGPT, Perplexity oder Claude, oder spezialisierte Tools für LLM-Visibility-Tracking.

Logging & Analyse

Cloudflare-Monitoring ist nur dann nützlich, wenn klar ist, was beobachtet wird. Drei Metriken sind relevant:

AI Bots vs. klassische Bots — Anteil im Traffic-Mix. Wächst KI-Bot-Traffic? Welche Crawler kommen am häufigsten? Das gibt früh Hinweise darauf, welche Anbieter aktiv sind.

Requests pro URL — Welche Inhalte interessieren KI-Crawler besonders? Seiten mit auffällig hoher Bot-Anfragerate sind häufig zitierfähige Inhalte — oder ungeschützte Schwachstellen.

Response Codes für bekannte Bots — 403 oder 429 bei Googlebot oder GPTBot ist ein Konfigurationsproblem, kein Erfolg. Regelmäßige Prüfung der Response Codes verhindert, dass legitime Crawler silent geblockt werden.

Cloudflare Logs lassen sich via Logpush exportieren — in BigQuery, Elastic oder als CSV. Für die meisten Setups reicht das Cloudflare Analytics-Dashboard als Einstieg; Logpush lohnt sich ab mittlerer Traffic-Größe.

Honeypots: Regelbrecher identifizieren

Eine einfache Methode, um robots.txt-Ignorierer zu erkennen: Fake-Endpunkte.

Die robots.txt sperrt einen Pfad:

Disallow: /private-test/

Die Seite unter diesem Pfad existiert trotzdem — leer, aber erreichbar. Jeder Bot, der trotz Disallow darauf zugreift, hat die robots.txt aktiv ignoriert. Diese Bot-IPs oder User-Agents lassen sich in Cloudflare direkt identifizieren und blockieren.

Das ist kein vollständiges Sicherheitssystem, aber ein verlässlicher Indikator für aggressives Crawling ohne Protokoll-Respekt.

Typische Fehlkonfigurationen

Alles sperren — der häufigste robots.txt-Fehler:

User-agent: *
Disallow: /

Das killt SEO und KI-Sichtbarkeit vollständig. Wenn dieser Eintrag in einer Live-Site vorhanden ist, wird nichts mehr gecrawlt.

KI-Bots blocken, aber Content für sie optimieren — widersprüchlich. Wer LLM-SEO betreibt, muss KI-Bots durchlassen. Beides gleichzeitig ist kein Setup, sondern ein Konfigurationsfehler.

Cloudflare zu aggressiv eingestellt — wenn Googlebot oder Bingbot Managed Challenges bekommen, sinken Rankings. Bot Fight Mode sollte Verified Bots nie challengen. Regelmäßige Prüfung der Response Codes für bekannte Bots ist Pflicht.

robots.txt für Subdomains vergessen — jede Subdomain braucht eine eigene /robots.txt, eine eigene Sitemap und eigene Cloudflare-Regeln. Bots behandeln blog.example.com und www.example.com als separate Entitäten. Was für eine Zone gilt, gilt nicht automatisch für eine andere.

Das Zusammenspiel in der Praxis

robots.txt und Cloudflare decken verschiedene Szenarien ab:

Seriöser KI-Bot, der robots.txt respektiert: Er liest die Datei, kommt gar nicht erst auf Sperr-Pfade, Cloudflare sieht ihn als Verified oder AI Bot, er passiert problemlos.
Aggressiver Scraper, der robots.txt ignoriert: Er kommt trotzdem an, aber Cloudflares Bot Fight Mode oder Rate-Limits greifen.
Neuer, unbekannter Bot: Cloudflare klassifiziert ihn als Unknown, eine Challenge wird ausgelöst, manuelle Prüfung kann folgen.

Das ergibt eine Verteidigungsstrategie in der Tiefe – keine perfekte, aber eine belastbare.

Gecrawlt ≠ zitiert

Ein erlaubter Crawl bedeutet nicht automatisch Nutzung in KI-Antworten. Das ist die entscheidende Unterscheidung:

Google (klassisches SEO) — Indexierung: robots.txt und Sitemap bestimmen, welche Seiten in den Index aufgenommen werden. Relevanz-Signale entscheiden über Rankings.

LLMs — Retrieval und Sampling: KI-Crawler lesen Inhalte, aber die Entscheidung, was zitiert wird, erfolgt nicht durch Crawlbarkeit. Sie folgt aus Struktur, Klarheit und Zitierfähigkeit. Ein gecrawlter Artikel heißt nicht, dass das Modell ihn in Antworten einbaut.

Die technische Konfiguration (robots.txt, Cloudflare) regelt den Zugang. Was danach passiert, ist eine inhaltliche Frage.

Selective Exposure: Gezielt statt maximal öffnen

Nicht alles muss für KI zugänglich sein. Das Ziel ist nicht maximale Sichtbarkeit, sondern gezielte Sichtbarkeit dort, wo Zitation sinnvoll ist.

Eine pragmatische Unterscheidung:

Blogartikel und Guides → offen für KI-Bots, zitierfähig strukturiert
Tools, Rechner, interaktive Elemente → blockieren sinnvoll, da nicht extrahierbar
Premium-Inhalte oder Paywall-Bereiche → kontrolliert via Content Signals oder Cloudflare-Regeln

Wer das von Anfang an in der robots.txt und den Cloudflare-Regeln abbildet, hat ein Setup, das nicht nur Schutz bietet, sondern aktiv auf LLM-Sichtbarkeit ausgerichtet ist.

Was als nächstes kommt

Cloudflares AI Crawl Control zeigt eine Richtung, die über Allow/Block hinausgeht: Pay per Crawl. Die Idee ist experimentell, aber technisch konkret — der Server antwortet mit HTTP 402 Payment Required. Der Bot entscheidet dann, ob er den Zugriff kauft. Wer zahlt, bekommt den Inhalt. Wer nicht zahlt, nicht.

Das ist kein Standard und noch nicht flächendeckend umgesetzt. Aber es zeigt, wohin sich das Modell entwickeln könnte: Nicht mehr nur Blockade oder freier Zugang, sondern lizenzierter Zugang — mit Contentrechten, die maschinenlesbar verhandelt werden.

Wer den Zugang für KI-Bots konfiguriert hat, steht vor der nächsten Frage: Wie muss Content strukturiert sein, damit er nicht nur gecrawlt, sondern als Quelle zitiert wird? Das ist das Thema von Teil 4 dieser Serie.