robots.txt für WordPress: Crawler steuern, AI-Bots aussperren

Wenn du WordPress nutzt und Yoast SEO installiert hast, generieren beide ihre eigene robots.txt – mit Überschneidungen, doppelten User-agent-Blöcken und veralteten Einträgen. Dazu kommen seit ein paar Jahren AI-Crawler, die deine Inhalte für LLM-Training scrapen. Hier zeige ich dir, wie ich meine robots.txt komplett selbst kontrolliere und sauber halte.

Warum überhaupt eine eigene robots.txt

WordPress liefert ab Werk eine virtuelle robots.txt. Sobald du Yoast aktiviert hast, schreibt das Plugin zusätzlich seinen eigenen Block hinein. Das Ergebnis: Mehrere User-agent: *-Sektionen, Sitemap-Einträge an seltsamen Stellen und keine Kontrolle darüber, welche Bots du tatsächlich aussperrst.
Mit dem do_robots-Hook kann ich die komplette Datei dynamisch generieren – inklusive Logik für WooCommerce, Yoast-Erkennung und AI-Bot-Listen.

Yoasts robots.txt-Output abschalten

Der erste Schritt ist, Yoast davon abzuhalten, eigene Regeln einzuschleusen. Dafür gibt es einen Filter:

add_filter( 'wpseo_robots_txt_output', '__return_empty_string' );

Damit bleibt der Yoast-Block leer. Die volle Kontrolle liegt jetzt bei mir.

Standard-Crawler korrekt führen

Für alle Suchmaschinen-Bots gilt: Der Admin-Bereich, interne WordPress-Pfade und nutzlose Crawl-Ziele wie Suchergebnisseiten oder XML-RPC sollen nicht indexiert werden. Bilder im Uploads-Ordner und der AJAX-Endpunkt müssen aber erreichbar bleiben.

add_action( 'do_robots', 'ls_robots' );

function ls_robots() {

	// Standard crawlers
	echo "User-agent: *\n";
	echo "Disallow: /wp-admin/\n";
	echo "Disallow: /wp-includes/\n";
	echo "Disallow: /cgi-bin/\n";
	echo "Disallow: /?s=\n";
	echo "Disallow: /search/\n";
	echo "Disallow: /*?replytocom=\n";
	echo "Disallow: /trackback/\n";
	echo "Disallow: */trackback/\n";
	echo "Disallow: /xmlrpc.php\n";
	echo "Allow: /wp-admin/admin-ajax.php\n";
	echo "Allow: /wp-content/uploads/\n\n";
}

Die Such-Ergebnisseiten unter /?s= sind ein häufig übersehener Crawl-Budget-Killer. Jede Suchanfrage, die irgendein Bot auf der Seite testet, generiert eine eigene URL – ohne SEO-Wert, aber mit voller Server-Last.

WooCommerce-Filter abfangen

Wer einen WooCommerce-Shop betreibt, kennt das Problem: Filter-URLs wie ?filter_color=blau&orderby=price erzeugen tausende Permutationen. Bots crawlen sie alle, die Datenbank ächzt unter WP_Query-Aufrufen. Im schlimmsten Fall fällt der Shop mit 503-Fehlern aus.
Die Lösung ist, diese Parameter in der robots.txt komplett auszuschließen:

if ( class_exists( 'WooCommerce' ) ) {
	echo "Disallow: /?*filter_*\n";
	echo "Disallow: /?*orderby=*\n";
	echo "Disallow: /?*min_price=*\n";
	echo "Disallow: /?*max_price=*\n";
}

Wichtig ist die class_exists-Prüfung. Wenn der Code in einem Plugin oder Theme liegt, das auch ohne WooCommerce verwendet wird, vermeidet der Check unnötige Regeln auf Nicht-Shop-Seiten.

AI-Crawler aussperren

Hier wird es interessant. Seit 2023 kommen immer mehr Bots, die ausschließlich für LLM-Training scrapen. Wer seine Inhalte nicht in den Trainingsdaten von OpenAI, Anthropic, Google Gemini oder Apple Intelligence sehen will, muss sie explizit blockieren.

$ai_bots = array(
	'GPTBot',
	'ChatGPT-User',
	'OAI-SearchBot',
	'ClaudeBot',
	'Claude-Web',
	'anthropic-ai',
	'CCBot',
	'Google-Extended',
	'PerplexityBot',
	'Applebot-Extended',
	'Bytespider',
	'FacebookBot',
	'Amazonbot',
	'cohere-ai',
);

foreach ( $ai_bots as $bot ) {
	echo "User-agent: {$bot}\n";
	echo "Disallow: /\n\n";
}

Ein wichtiger Punkt zu Google-Extended: Das ist nicht der normale Googlebot. Google trennt seit 2023 die Such-Indexierung (Googlebot) vom Gemini-Training (Google-Extended). Du kannst also AI-Training blockieren, ohne deine Google-Rankings zu gefährden.

Sitemap-Erkennung je nach Setup

Yoast hat einen anderen Sitemap-Pfad als die WordPress-Core-Sitemap. Mit einer einfachen Abfrage erkenne ich, welche aktiv ist:

if ( defined( 'WPSEO_VERSION' ) ) {
	echo "Sitemap: " . esc_url( home_url( '/sitemap_index.xml' ) ) . "\n";
} else {
	echo "Sitemap: " . esc_url( home_url( '/wp-sitemap.xml' ) ) . "\n";
}

Die Sitemap-Zeile gehört ans Ende der robots.txt – das ist die offizielle Empfehlung des Standards.

Validieren nach dem Deployment

Nach dem Aktivieren prüfe ich drei Dinge in dieser Reihenfolge:

• Im Browser – die URL /robots.txt aufrufen und den Inhalt visuell durchgehen. Keine doppelten User-agent: *-Blöcke mehr.
• Search Console – unter Einstellungen den robots.txt-Report prüfen. Google muss die neue Version sehen, ohne Fehler.
• URL-Prüfung – eine wichtige Seite testen, etwa die Hauptlandingpage. Sie muss als crawlbar markiert sein.

Was die robots.txt nicht leistet

Drei Dinge zur Erwartungshaltung. Die robots.txt ist ein freiwilliger Standard – seriöse Bots halten sich daran, Schurken-Scraper ignorieren sie komplett. Inhalte, die bereits in Trainingsdaten geflossen sind, bleiben dort. Und die Liste der AI-Bots ändert sich ständig – ein Update-Check alle paar Monate lohnt sich.
Wer wirklich aggressive Crawler aussperren will, kommt um Server-seitige Maßnahmen wie fail2ban, Cloudflare-Regeln oder einen Bot-Blocker im Theme nicht herum. Die robots.txt ist die erste Verteidigungslinie, nicht die einzige.