KI-Crawler in WordPress blockieren (ehrlich betrachtet)

Um GPTBot daran zu hindern, eine WordPress-Seite zu crawlen, füge diese Zeilen in deine robots.txt ein:

User-agent: GPTBot
Disallow: /

Das ist bei brav funktionierenden Crawlern die gesamte Lösung. Aber sei ehrlich zu dir selbst darüber, was du gerade getan hast: robots.txt ist eine Bitte, kein Zaun. OpenAIs GPTBot ruft die Datei ab und hält sich daran. Ein Scraper, der den Standard nicht respektiert, ruft dieselbe Datei ab und ignoriert jede einzelne Zeile darin. Behalte diesen Unterschied im Kopf, bevor du einen Nachmittag mit dem Feintuning verbringst.

Wenn du die wichtigsten KI-Crawler in einem Rutsch abdecken willst, sind die gängigen User-Agent-Tokens:

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Bytespider
Disallow: /

GPTBot ist OpenAIs Trainings-Crawler, CCBot ist Common Crawl (worauf viele Modelle nachgelagert trainieren), ClaudeBot ist Anthropic, Google-Extended ist Googles KI-Trainings-Token und Bytespider gehört zu ByteDance. Beachte, dass zwei davon das Modell der höflichen Bitte bereits durchbrechen: Bytespider und PerplexityBot wurden beide öffentlich dabei dokumentiert, Seiten zu crawlen, die sie ausgesperrt hatten. Sie aufzulisten hilft trotzdem gegen die ehrlichen Bots; gegen die, die schon jetzt über ihre Identität lügen, bringt es nichts.

Wie WordPress robots.txt tatsächlich ausliefert

Genau hier laufen die Änderungen der meisten Leute stillschweigend ins Leere. Wenn keine physische robots.txt-Datei in deinem Web-Root liegt, erzeugt WordPress eine zur Laufzeit. Die Anfrage wird von do_robots() in wp-includes/functions.php verarbeitet, und die Ausgabe läuft durch den robots_txt-Filter. Das Häkchen „Suchmaschinen davon abhalten, diese Website zu indexieren” unter Einstellungen → Lesen schaltet die Option blog_public um, und genau das lässt diese virtuelle Datei Disallow: / ausgeben.

Du kannst KI-Crawler-Regeln also programmatisch anhängen:

add_filter( 'robots_txt', function ( $output, $public ) {
    $output .= "User-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10, 2 );

Und hier ist der Haken, der Stunden frisst: Sobald eine statische robots.txt-Datei im Web-Root existiert, liefert Apache oder nginx diese Datei direkt aus, und WordPress kommt gar nicht erst zum Zug. Der robots_txt-Filter, der Yoast-/Rank-Math-robots-Editor, die Lesen-Einstellung – alles wird umgangen. Wenn du robots.txt in einem Plugin bearbeitet hast und sich an der Live-Datei nie etwas geändert hat, liegt es fast immer daran. Prüfe https://yoursite.com/robots.txt in einem privaten Fenster und vergleiche das Ergebnis mit dem, was du zu setzen glaubst. Wenn eine echte Datei auf der Festplatte liegt, bearbeite diese Datei; der Filter ist dann irrelevant.

Der Reihe nach beheben

Zuerst: saubere Regeln schreiben. Bring die Syntax und die Crawler-Liste in Ordnung, damit du nicht aus Versehen den Googlebot blockierst. Unser robots.txt-Generator baut den KI-Crawler-Block für dich und zeigt dir die exakte Datei zum Einfügen – das umgeht die Verwirrung zwischen virtuell und physisch, weil du am Ende eine einzige maßgebliche Datei hast.

Zweitens: bestätigen, dass es live ist. Ruf die URL direkt ab. Vertraue nicht der Vorschau des Plugins.

Drittens: Wenn du Durchsetzung statt einer höflichen Bitte brauchst, geh eine Ebene höher im Stack. robots.txt lebt auf der Anwendungsebene und hängt vom guten Willen des Bots ab. Um eine Verbindung tatsächlich abzuweisen, blockiere per User-Agent auf dem Server. In der .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|CCBot|ClaudeBot|Bytespider) [NC]
RewriteRule .* - [F,L]
</IfModule>

Das liefert allem, was diese User-Agents sendet, ein 403 zurück. Unser .htaccess-Generator kann diese Regel zusammenbauen. Sei dir aber der Grenze bewusst: User-Agents lassen sich trivial fälschen, das stoppt also nur Bots, die ehrlich genug sind, sich zu identifizieren – und das sind genau dieselben Bots, die sich ohnehin schon an robots.txt halten. Die wirklich robuste Option ist ein CDN oder eine WAF, die anhand verifizierter Crawler-Identität oder IP-Bereich blockiert. Cloudflares Ein-Klick-Managed-Rule „Block AI Scrapers and Crawlers” ist die aufwandsärmste Variante davon und wirkt am Edge, bevor die Anfrage WordPress überhaupt erreicht.

Was du nicht tun solltest

Blockiere nicht Google-Extended in dem Glauben, das halte dich aus den AI Overviews heraus. Das ist der Irrtum, den es sich zu korrigieren lohnt. Google-Extended ist ein Produkt-Token, kein Crawler. Es steuert ausschließlich, ob deine Inhalte zum Training und zur Fundierung von Gemini-Modellen verwendet werden. Laut Googles eigener Dokumentation hat es keine Auswirkung darauf, wie deine Seiten gecrawlt, indexiert oder in der Google-Suche gerankt werden. Und AI Overviews werden aus dem regulären Suchindex gebaut, den der Googlebot crawlt – nicht aus Google-Extended. Google-Extended zu blockieren wird dich nicht aus den AI Overviews entfernen, und es wird dich keine einzige Position in der Suche kosten. Der einzige Weg, aus den AI Overviews herauszubleiben, ist, den Googlebot zu blockieren oder die Seite auf noindex zu setzen – was dich zugleich komplett aus der Suche löscht. Das ist fast nie ein Tausch, den du willst.

Behandle robots.txt nicht als Sicherheitskontrolle. Sie ist öffentlich und hat nur empfehlenden Charakter. /wp-admin/ oder einen privaten Pfad dort aufzulisten, veröffentlicht bloß eine Landkarte, wo man suchen muss. Schütze echte Endpunkte mit Authentifizierung, nicht mit einer Disallow-Zeile.

Verlass dich nicht auf noai-/noimageai-Meta-Tags. Sie wurden vorgeschlagen, nicht standardisiert, und nur eine Handvoll Plattformen respektiert sie. Sie sind kein allgemeiner Schutz.

Geh nicht davon aus, dass ein „Block AI”-Plugin mehr getan hat, als robots.txt zu schreiben. Die meisten davon schreiben dieselben Zeilen, die du auch von Hand schreiben könntest, und erben dieselbe Einschränkung. Lies nach, was das Plugin tatsächlich geändert hat, bevor du ihm vertraust.

Kommst du nicht weiter?

Wenn deine Änderungen nicht auftauchen, ist die Antwort fast immer eine verirrte physische robots.txt im Web-Root, die WordPress’ virtuelle überschreibt – ruf die URL direkt ab und prüfe das. Wenn die regelkonformen Bots weg sind, aber die Scraper weiter auf dich einprasseln, hast du die Obergrenze dessen erreicht, was robots.txt leisten kann, und der nächste Schritt ist eine WAF- oder CDN-Regel, die anhand verifizierter Identität blockiert statt durch höfliches Bitten.