robots.txt in WordPress richtig konfigurieren
Woher die robots.txt in WordPress kommt, wie Sie die Sichtbarkeit für Suchmaschinen prüfen, eigene Regeln per Filter ergänzen und warum die robots.txt keine Seite aus dem Google-Index entfernt.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Die Datei robots.txt ist die erste Adresse, die Suchmaschinen auf Ihrer Website abrufen. Sie legt fest, welche Bereiche Crawler besuchen dürfen. WordPress liefert eine solche Datei automatisch aus, obwohl im Hauptverzeichnis keine liegt. Das führt oft zu Verwirrung: Änderungen landen an der falschen Stelle, eine vergessene Einstellung aus der Entwicklungsphase sperrt Suchmaschinen aus, oder eine Regel soll eine Seite aus Google entfernen und bewirkt das Gegenteil. Diese Anleitung erklärt, woher die robots.txt in WordPress kommt, wie Sie sie sicher anpassen und was sie nicht leisten kann.
Voraussetzungen
- WordPress 7.1 mit aktivierten Permalinks (nicht „Einfach“), damit die Adresse
/robots.txtohne Umleitung erreichbar ist. - Ein Benutzerkonto mit der Rolle Administrator für die Einstellungen im Backend.
- Für eigene Regeln Zugriff per FTP, SFTP oder SSH auf das WordPress-Verzeichnis.
- Ein aktuelles Backup, bevor Sie Dateien im Hauptverzeichnis oder unter
wp-contentanlegen. - Optional ein Konto in der Google Search Console, um die Datei aus Sicht von Google zu prüfen.
Schritt 1: Die aktuelle robots.txt ansehen
Rufen Sie im Browser https://ihre-domain.de/robots.txt auf oder prüfen Sie Antwort und Inhalt auf der Kommandozeile:
curl -s -D- https://ihre-domain.de/robots.txtEine frische WordPress-Installation lieferte im Test mit Status 200 und dem Typ text/plain diesen Inhalt:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://ihre-domain.de/wp-sitemap.xmlDie Regeln bedeuten: Alle Crawler sollen den Adminbereich meiden, dürfen aber admin-ajax.php abrufen, weil manche Themes und Plugins darüber Inhalte für Besucher nachladen. Die letzte Zeile verweist auf die XML-Sitemap, die WordPress seit Version 5.5 selbst erzeugt. Eine Datei robots.txt liegt dabei nicht auf dem Server. WordPress erzeugt die Antwort über die Funktion do_robots() bei jedem Aufruf.
Waren die Permalinks im Test auf „Einfach“ gestellt, antwortete die Adresse mit einer Umleitung 301 auf /robots.txt/. Crawler rufen die Datei laut Google nur im Hauptverzeichnis ab, eine solche Umleitung vermeiden Sie besser.
Verifizieren: Die Adresse liefert Status 200, Typ text/plain und einen Inhalt, den Sie erklären können.
Schritt 2: Die Sichtbarkeit für Suchmaschinen prüfen
Öffnen Sie „Einstellungen“ und dann „Lesen“. Im Abschnitt „Sichtbarkeit für Suchmaschinen“ steht das Kontrollkästchen „Suchmaschinen davon abraten, diese Website zu indexieren“. Viele Agenturen setzen es während der Entwicklung und vergessen es beim Livegang. WordPress weist darunter selbst darauf hin, dass es Sache der Suchmaschinen ist, dieser Bitte nachzukommen.
Im Test veränderte das Häkchen zwei Dinge. Erstens fehlte der Sitemap-Verweis in der robots.txt, und die Adresse /wp-sitemap.xml lieferte 404. Zweitens erschien im Quelltext jeder Seite dieser Eintrag:
<meta name='robots' content='noindex, nofollow' />Die robots.txt selbst blieb dagegen unverändert, sie sperrte nur den Adminbereich. Die eigentliche Sperre steckt also im Meta-Tag der Seiten. Wer nur die robots.txt prüft, übersieht diese Einstellung leicht. Suchen Sie deshalb zusätzlich im Quelltext der Startseite nach name='robots'. Ohne das Häkchen stand dort im Test nur max-image-preview:large.
Verifizieren: Bei einer öffentlichen Website ist das Häkchen nicht gesetzt, die robots.txt enthält eine Zeile Sitemap:, und der Quelltext der Startseite enthält kein noindex.
Schritt 3: Entscheiden, was gesperrt werden soll
Bevor Sie Regeln ergänzen, klären Sie das Ziel. Laut Google dient die robots.txt vor allem dazu, eine Website nicht mit Anfragen zu überlasten. Sie ist ausdrücklich kein Mittel, um Seiten aus der Google-Suche herauszuhalten. Eine gesperrte Adresse kann weiter im Index erscheinen, wenn andere Seiten darauf verlinken, nur eben ohne Beschreibung. Und weil der Crawler die Seite nicht abrufen darf, sieht er auch ein noindex darin nicht.
| Ziel | Richtiges Werkzeug |
|---|---|
| Seite nicht in den Suchergebnissen | noindex per Meta-Tag oder SEO-Plugin, Seite nicht in robots.txt sperren |
| Vertraulicher Bereich | Passwortschutz oder Anmeldung |
| Crawler von endlosen Filter- oder Parameteradressen fernhalten | Disallow in der robots.txt |
| Bestimmte Bots ausschließen | eigene Gruppe mit User-agent und Disallow |
Ein Beispiel für den letzten Fall ist der von Google dokumentierte Token Google-Extended. Mit ihm steuern Sie, ob Inhalte, die Google crawlt, für das Training der Gemini-Modelle verwendet werden dürfen. Das normale Crawling für die Google-Suche bleibt davon unberührt.
WordPress sperrt bereits von sich aus einige Bereiche per Meta-Tag. Im Test trugen die Anmeldeseite noindex, noarchive und die Suchergebnisseite noindex, follow. Zusätzliche Regeln für /wp-login.php oder /?s= sind also meist unnötig. Sperren Sie außerdem nie /wp-content/ oder /wp-includes/. Google braucht CSS und JavaScript, um Ihre Seiten korrekt darzustellen.
Verifizieren: Sie haben eine kurze Liste der Pfade oder Bots, die Sie ausschließen wollen, und zu jeder Zeile einen Grund.
Schritt 4: Eigene Regeln per Filter ergänzen
Der sauberste Weg ist der Filter robots_txt. Laut Entwicklerreferenz erhält er die fertige Ausgabe und den Wert, ob die Website als öffentlich gilt. So bleiben Admin-Regel und Sitemap-Verweis erhalten, und Ihre Ergänzung überlebt Theme-Wechsel und Updates. Legen Sie die Datei wp-content/mu-plugins/robots-anpassung.php an. Plugins in diesem Ordner lädt WordPress automatisch, sie lassen sich im Backend nicht versehentlich deaktivieren:
<?php
/**
* Plugin Name: robots.txt-Anpassung
*/
add_filter( 'robots_txt', function ( $output, $public ) {
if ( $public ) {
$output .= "\nUser-agent: Google-Extended\nDisallow: /\n";
}
return $output;
}, 10, 2 );Die Bedingung $public sorgt dafür, dass die Ergänzung nur erscheint, wenn die Website für Suchmaschinen freigegeben ist. Prüfen Sie die Datei vor dem Hochladen mit php -l, falls Sie Zugriff auf die Kommandozeile haben. Ein Syntaxfehler in einem MU-Plugin betrifft die ganze Website.
Im Test hängte der Filter die neue Gruppe unter die Sitemap-Zeile an. Das ist korrekt: Laut RFC 9309 gelten Regeln je Gruppe, und eine neue Gruppe beginnt mit einer User-agent-Zeile. Die Zeile Sitemap gehört zu keiner Gruppe.
Verifizieren: Die robots.txt zeigt nach dem Neuladen die bisherigen Zeilen und darunter Ihre neue Gruppe. Leeren Sie vorher einen Seiten-Cache, falls die Adresse gecacht wird.
Schritt 5: Alternative physische Datei, mit ihren Folgen
Legen Sie eine Datei robots.txt ins WordPress-Hauptverzeichnis, liefert der Webserver diese direkt aus. WordPress kommt gar nicht mehr zum Zug. Im Test verschwanden damit Admin-Regel und Sitemap-Verweis vollständig, zu sehen war nur der Inhalt der Datei. Auch SEO-Plugins, die die robots.txt über den Filter bearbeiten, wirken dann nicht mehr.
Wenn Sie diesen Weg wählen, übernehmen Sie die Standardzeilen selbst:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://ihre-domain.de/wp-sitemap.xmlEine physische Datei hat einen Nachteil, der erst später auffällt: Sie weiß nichts von der Einstellung aus Schritt 2 und nichts von einer neuen Domain nach einem Umzug. Ein Relaunch auf neuer Domain behält dann den alten Sitemap-Verweis. Halten Sie deshalb fest, dass es diese Datei gibt, zum Beispiel in Ihrer Website-Dokumentation.
Solche Kleinigkeiten gehören zur laufenden Pflege einer Website, wie Updates, Backups und die Kontrolle nach jeder größeren Änderung. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Firewall.
Verifizieren: curl -s https://ihre-domain.de/robots.txt zeigt genau den Inhalt Ihrer Datei, einschließlich einer korrekten Sitemap-Adresse mit Ihrer Domain.
Schritt 6: Die Datei aus Sicht von Google prüfen
In der Google Search Console finden Sie unter „Einstellungen“ einen Bericht zur robots.txt. Er zeigt, wann Google die Datei zuletzt abgerufen hat und ob Fehler auftraten. Laut Google wird die Datei in der Regel bis zu 24 Stunden zwischengespeichert, Änderungen wirken also nicht sofort.
Achten Sie auf den Statuscode. Liefert die Adresse einen Fehler der Gruppe 4xx (außer 429), behandelt Google das laut Dokumentation so, als gäbe es keine robots.txt, und crawlt ohne Einschränkung. Bei Serverfehlern der Gruppe 5xx stellt Google das Crawlen zunächst ein. Eine robots.txt, die wegen eines Plugin-Fehlers mit 500 antwortet, kann die Website also vorübergehend aus dem Crawling nehmen. Nach einem Domainwechsel prüfen Sie robots.txt und Sitemap-Zeile erneut, der Ablauf steht in WordPress-Domain ändern.
Verifizieren: Die Adresse liefert Status 200, und der Bericht in der Search Console zeigt einen Abruf nach Ihrer Änderung ohne Fehler.
Typische Fehler
Die Website verschwindet nach dem Livegang nicht aus dem Staging-Zustand. Das Häkchen „Suchmaschinen davon abraten“ ist noch gesetzt. Im Dashboard steht dann in der Box „Auf einen Blick“ der Hinweis „Suchmaschinen abgewiesen“. Entfernen Sie das Häkchen und prüfen Sie den Quelltext wie in Schritt 2.
Änderungen im SEO-Plugin wirken nicht. Im Hauptverzeichnis liegt eine physische robots.txt, die WordPress übergeht. Löschen oder umbenennen Sie die Datei, nachdem Sie ihren Inhalt gesichert haben.
Seite trotz Disallow in Google. Die robots.txt verhindert das Crawlen, nicht die Aufnahme in den Index. Heben Sie die Sperre auf und setzen Sie noindex, damit Google das Meta-Tag lesen kann.
Sitemap-Zeile zeigt die alte Domain. Eine physische Datei aus der Zeit vor dem Umzug. Passen Sie die Adresse an oder wechseln Sie zum Filter aus Schritt 4.
Gesperrte Pfade verraten interne Bereiche. RFC 9309 weist darauf hin, dass jeder die robots.txt lesen kann. Tragen Sie keine geheimen Adressen ein, sondern schützen Sie diese per Anmeldung, siehe Adminbereich per IP-Freigabe und HTTP-Auth schützen.
Häufige Fragen
Brauche ich überhaupt eine eigene robots.txt?
Für die meisten Unternehmenswebsites genügt die Ausgabe von WordPress. Eigene Regeln lohnen sich bei Shops mit vielen Filteradressen oder wenn Sie bestimmte Bots ausschließen wollen.
Unterstützt Google die Angabe Crawl-delay?
Nein. Laut Google werden nur user-agent, allow, disallow und sitemap ausgewertet. Andere Crawler können Crawl-delay beachten.
Wie groß darf die Datei sein?
Google wertet höchstens 500 KiB aus, Inhalte danach werden ignoriert. Eine WordPress-Website kommt normalerweise mit wenigen Zeilen aus.
Testumfang
Wir haben alle beschriebenen Varianten der robots.txt auf einer Testinstallation mit WordPress 7.1.2 durchgespielt. Überraschend war, dass das Häkchen für Suchmaschinen die Datei kaum verändert, denn die eigentliche Sperre steckt im Meta-Tag. Eine physische robots.txt verdrängt außerdem die Sitemap-Zeile ersatzlos.
Wie echte Crawler und die Search Console reagieren, konnten wir im Labor nicht prüfen, hier verlassen wir uns auf Googles Dokumentation.
Fazit
WordPress bringt eine brauchbare robots.txt mit, und für die meisten Websites genügt es, die Sichtbarkeit unter „Einstellungen“, „Lesen“ zu kontrollieren. Eigene Regeln ergänzen Sie am besten per Filter, damit Sitemap und Admin-Sperre erhalten bleiben. Und für alles, was nicht in die Suchergebnisse soll, ist noindex das richtige Werkzeug. Wenn Sie Updates, Backups und die laufende Kontrolle Ihrer Website abgeben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.
