Warum dein WordPress KI-Crawler heimlich blockiert – und deine SEO-Tools schweigen

Executive Summary

Managed-WordPress-Hosts setzen Platform-Level-Schutzmechanismen ein, die KI-Crawler als potenzielle Scraper behandeln. Die Blocks liegen unterhalb von Cloudflare und Security-Plugins – und sind deshalb für klassische SEO-Monitoring-Tools unsichtbar. Cache-Hits geben HTTP 200, Cache-Misses geben 429: Dasselbe User-Agent, dieselbe Site, zwei verschiedene Outcomes.

Die Konsequenz ist direkt: Crawl-Zugang korreliert direkt mit Citation-Präsenz. Wenn die Plattform AI-Crawler blockiert, verschwinden Citations – nicht wegen mangelnder Content-Qualität, sondern wegen fehlenden Zugangs. Diagnose, nicht Content-Optimierung, ist der erste Schritt.

Das unsichtbare Problem: Warum SEO-Tools schweigen

Klassische SEO-Monitoring-Tools prüfen Crawler-Zugang aus einer User-Perspektive oder mit Googlebot-User-Agent. Sie prüfen nicht, ob GPTBot, ClaudeBot oder OAI-SearchBot HTTP 200, 429 oder 403 bekommen. Das ist die Lücke.

Wenn ein Managed-WordPress-Host einen Platform-Level-Block für AI-Crawler aktiviert, passiert Folgendes:

• Googlebot: voller Zugang → klassisches SEO unauffällig
• GPTBot: 429 auf Cache-Misses → ChatGPT: keine Citations für neue/aktualisierte Inhalte
• ClaudeBot: 429 auf Cache-Misses → Claude: keine Citations
• SEO-Tool-Check: Alles grün – kein Crawling-Problem erkannt

Merksatz: Die Platform-by-Platform-Aufteilung in Citations entspricht direkt der Platform-by-Platform-Aufteilung im Crawl-Zugang. Das ist kein Zufall – es ist Kausalität. Wer AI-Crawler blockiert, blockiert AI-Citations.

Die drei Blocking-Schichten

AI-Crawler-Blocks können auf drei verschiedenen Ebenen entstehen – jede mit anderen Diagnose- und Lösungsansätzen:

1

Platform-Level des Managed-Hosts Unsichtbar

WP Engine, Kinsta, Pressable und ähnliche Hosts setzen Server-Level-Regeln ein, die AI-Crawler als Scraper klassifizieren. HTTP 429 auf Cache-Misses. Cloudflare und Security-Plugins sind nicht die Ursache. Der Block liegt tiefer. Diagnose nur über Server-Logs und direktes Support-Ticket.

2

WAF und CDN (Cloudflare) Sichtbar im Dashboard

Cloudflares „Block AI Bots"-Toggle, Super Bot Fight Mode und WAF Custom Rules können AI-Crawler blockieren. Auch wenn „Block AI Bots" deaktiviert ist: Custom Rules, die „definitely automated" Traffic challengen, können AI-Crawler erfassen. Cloudflare Dashboard → Security → Bots → AI Crawl Control.

3

Security-Plugin und robots.txt Prüfbar

WordPress Security-Plugins (Wordfence, Sucuri) haben eingebaute Bot-UA-Blocklists. robots.txt mit „bot" als Disallow-Muster blockt alle benannten Crawler unbeabsichtigt. Beide sind prüfbar und direkt korrigierbar.

Das Cache-Miss-Problem: Warum curl lügt

Das Muster zeigt sich in Server-Log-Analysen immer wieder: In einem 24-Stunden-Zeitraum kommt ein Teil der ClaudeBot-Requests mit HTTP 200 zurück (Cache-Hits) und ein anderer Teil mit HTTP 429 (Cache-Misses). Gleicher User-Agent, gleiche Site, zwei Outcomes – abhängig allein davon, ob die angeforderte URL gerade im Cache liegt.

Ein curl-Test auf die Startseite ist notwendig, aber nicht ausreichend. Die Startseite ist fast immer gecacht. Neue Blogposts und Long-tail-URLs sind am häufigsten betroffen.

Crawl-Ratio: Warum Hosts AI-Crawler blockieren

Die Crawl-to-Referral-Ratio erklärt, warum Hosting-Infrastruktur begonnen hat, AI-Crawler abzuwehren. Verschiedene Crawler erzeugen sehr unterschiedliche Server-Last für sehr unterschiedlichen Traffic-Return:

Aus Hosting-Perspektive rational: ClaudeBot erzeugt deutlich mehr Requests als andere Crawler – aber nur einen Bruchteil davon führt zu Referral-Traffic. Massive Server-Last ohne entsprechenden Traffic-Gegenwert. Ob das die richtige Entscheidung für die eigene Site ist, ist eine separate Frage.

AI-Crawler User-Agents: Training vs. Search

Die kritische Unterscheidung: GPTBot und OAI-SearchBot nie gemeinsam blockieren. Wer GPTBot blockiert (Training), muss OAI-SearchBot explizit erlauben (Search) – sonst ist die Site unsichtbar für ChatGPT-Suchergebnisse.

Diagnose: 5 Schritte um den Block zu finden

1. curl-Test mit AI-Crawler-User-Agents

Den User-Agent simulieren und Response-Code prüfen:

# GPTBot testen
curl -A 'GPTBot' https://yourdomain.com/ -I

# ClaudeBot testen
curl -A 'ClaudeBot' https://yourdomain.com/ -I

# OAI-SearchBot testen
curl -A 'OAI-SearchBot' https://yourdomain.com/ -I

2. Server-Logs auf 429-Muster für AI-User-Agents prüfen

Wenn curl 200 zeigt, aber Server-Logs 429 für AI-User-Agents zeigen: Cache-Miss-Problem auf Platform-Level. Server-Access-Logs filtern nach User-Agent und HTTP-Status:

# Nginx-Log nach GPTBot filtern
grep 'GPTBot' /var/log/nginx/access.log | grep ' 429 '

# Apache-Log nach ClaudeBot filtern
grep 'ClaudeBot' /var/log/apache2/access.log | awk '$9==429'

3. Cloudflare Dashboard: AI Crawl Control und WAF

Cloudflare Dashboard → Security → Bots → AI Crawl Control. Prüfen: Ist „Block AI Bots" aktiv? Welche individuellen Bots sind geblockt? Super Bot Fight Mode-Einstellungen: Wenn „definitely automated" gechallenged wird, erfasst das auch AI-Crawler. WAF Custom Rules auf AI-User-Agent-spezifische Regeln durchsuchen.

4. Hosting-Panel und Support-Ticket für Platform-Level-Block

Für WP Engine: Utilities → Redirect Bots (muss aus sein) + Web Rules (keine AI-UA-Blocks). Dann Support-Ticket mit konkreter Beschreibung:

"Wir haben über curl reproduziert, dass Requests mit
ClaudeBot/GPTBot User-Agent-Strings HTTP 429 erhalten
für Cache-Miss-Requests in unserer Umgebung.
Cloudflare und Security-Plugins sind nicht die Ursache.
Handelt es sich um ein Platform-Level
AI-Crawler-Mitigation-Feature?
Kann es deaktiviert oder per-Bot konfiguriert werden?"

5. robots.txt live prüfen und korrigieren

https://yourdomain.com/robots.txt live abrufen. Achtung: Die live-ausgelieferte Datei kann von der Datei im WordPress-Backend abweichen – CDN-Cache oder Hosting-Panel können eine andere Version ausliefern. Auf unbeabsichtigte Muster prüfen: Disallow: / für alle Bots, bot als generisches Disallow-Pattern das alle named Crawler trifft.

Der Fix: Was wo eingestellt werden muss

robots.txt richtig konfigurieren für AI-Crawler

Die robots.txt sollte Search-Crawler explizit erlauben und Training-Crawler separat behandeln. Niemals beides mit einem einzigen Muster zusammenfassen:

# Alle Standard-Crawler erlauben
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*preview=true

# ChatGPT-Suche explizit erlauben
User-agent: OAI-SearchBot
Allow: /

# ChatGPT-Browsing explizit erlauben
User-agent: ChatGPT-User
Allow: /

# Claude erlauben (Anthropic-Suche)
User-agent: ClaudeBot
Allow: /

# Perplexity erlauben
User-agent: PerplexityBot
Allow: /

# OpenAI Training-Crawler: eigene Entscheidung
# User-agent: GPTBot
# Disallow: / ← wenn Training-Daten-Schutz gewünscht

Sitemap: https://yourdomain.com/sitemap.xml

Häufige Fragen

Warum blockiert mein managed WordPress GPTBot und ClaudeBot ohne dass ich es bemerke?

Managed-Hosts setzen Platform-Level-Blocks ein, die AI-Crawler als Scraper behandeln. Die Blocks feuern auf Server-Level, bevor Cloudflare oder Security-Plugins eingreifen. SEO-Tools prüfen keine AI-User-Agent-Responses. Der Block ist unsichtbar bis fehlende GEO-Citations Monate später sichtbar werden.

Was bedeutet HTTP 429 für AI-Crawler?

HTTP 429 bedeutet Rate Limit überschritten – für AI-Crawler ein effektiver Block. Der Crawler kann die Seite nicht abrufen und zitiert die Quelle nicht. Besonders heimtückisch: Cache-Hits geben 200, Cache-Misses geben 429. Ein einfacher curl-Test zeigt deshalb oft 200, obwohl der tatsächliche Crawler geblockt wird.

Wie unterscheiden sich GPTBot und OAI-SearchBot?

GPTBot ist OpenAIs Training-Crawler für LLM-Training. OAI-SearchBot ist OpenAIs Search-Crawler für ChatGPT-Suchanfragen in Echtzeit. Wer GPTBot blockiert, blockiert Training-Daten. Wer OAI-SearchBot blockiert, blockiert ChatGPT-Suchergebnisse. Beide separat in robots.txt und WAF behandeln.

Wie prüfe ich ob mein WordPress AI-Crawler blockiert?

Schritt 1: curl -A 'GPTBot' https://yourdomain.com/ -I ausführen. Schritt 2: Server-Logs auf 429-Einträge für AI-User-Agents prüfen. Schritt 3: Cloudflare Dashboard → Security → Bots → AI Crawl Control. Schritt 4: Hosting-Panel auf Platform-Level-Blocks prüfen. Schritt 5: robots.txt live abrufen auf unbeabsichtigte Bot-Disallow-Muster.

Überschreibt WAF die robots.txt?

Ja. WAF- und CDN-Regeln werden vor robots.txt ausgewertet. Ein WAF-Block überschreibt jede robots.txt-Allow-Direktive. Eine saubere robots.txt allein garantiert keinen Crawler-Zugang wenn WAF-Regeln blockieren. Beide Layer separat prüfen und konfigurieren.

Fazit

Crawl-Zugang und Citation-Präsenz sind direkt korreliert. Wenn die Plattform blockiert, verschwinden Citations – unabhängig von Content-Qualität oder Schema. Diagnose kommt vor Content-Optimierung.

• Platform-Level-Blocks bei Managed-Hosts blockieren AI-Crawler mit HTTP 429 ohne SEO-Tool-Alert.
• Cache-Miss-Problem: Cache-Hits geben 200, Cache-Misses geben 429. curl auf die Homepage reicht als Diagnose nicht aus.
• Crawl-zu-Referral-Verhältnis bei ClaudeBot und GPTBot ist deutlich höher als bei Google – das erklärt, warum Hosts AI-Crawler abwehren.
• Drei Blocking-Schichten: Platform-Level, WAF/Cloudflare, Security-Plugin/robots.txt. Jede separat diagnostizieren.
• GPTBot ≠ OAI-SearchBot: Training vs. Search separat behandeln. Nie beide gemeinsam blockieren.
• WAF überschreibt robots.txt: Eine saubere robots.txt allein garantiert keinen Crawler-Zugang.
• Support-Ticket mit curl-Beweis ist der direkte Weg bei Platform-Level-Blocks auf Managed-Hosts.