Was gehört in eine WordPress robots.txt?

Vier Dinge und sonst nichts: eine User-agent-Zeile mit Platzhalter, ein Disallow für /wp-admin/, ein Allow für /wp-admin/admin-ajax.php und eine Sitemap-Anweisung mit der vollständigen URL Ihrer Sitemap. Alles darüber hinaus ist optional, und die meisten der langen Sperrlisten, die online kursieren, verursachen mehr Probleme, als sie lösen.

Legt WordPress automatisch eine robots.txt an?

Ja, aber nur eine virtuelle. WordPress erzeugt die Antwort im Arbeitsspeicher, sobald eine Anfrage an /robots.txt geht und keine echte Datei auf dem Server liegt. Sie enthält die wp-admin-Regeln und seit Version 5.5 auch eine Sitemap-Zeile für wp-sitemap.xml. Auf Ihren Server wird dabei nichts geschrieben.

Warum stimmt meine robots.txt nicht mit dem überein, was WordPress ausgeben sollte?

Fast immer, weil eine physische robots.txt in Ihrem Web-Root liegt. Der Webserver liefert diese Datei direkt aus, WordPress läuft gar nicht erst an, und damit werden sowohl die virtuelle Ausgabe als auch der robots_txt-Filter stillschweigend übergangen. Prüfen Sie auf eine echte Datei im Wurzelverzeichnis, bevor Sie irgendetwas anderes debuggen.

Sollte ich wp-content oder wp-includes in der robots.txt sperren?

Nein. In diesen Verzeichnissen liegen das CSS, das JavaScript und die Bilder, die Ihre Seiten zum Rendern brauchen. Wer sie sperrt, hindert Google daran, diese Ressourcen zu laden — bewertet wird dann eine kaputte Fassung Ihres Layouts. Das war vor Jahren ein verbreiteter Ratschlag und ist heute aktiv schädlich.

Kann robots.txt eine Seite aus Google heraushalten?

Nein. Robots.txt steuert das Crawling, nicht die Indexierung. Eine gesperrte URL kann trotzdem indexiert werden, wenn andere Seiten darauf verlinken, und erscheint dann ohne Beschreibung in den Ergebnissen. Um eine Seite aus dem Index zu halten, erlauben Sie das Crawling und liefern stattdessen ein noindex-Meta-Tag oder einen X-Robots-Tag-Header aus.

Ist robots.txt eine Sicherheitsmaßnahme?

Nein, im Gegenteil. Die Datei ist unter ihredomain.de/robots.txt öffentlich und für jeden lesbar. Wer dort ein privates Verzeichnis aufführt, weist damit auf dessen Standort hin. Anständige Crawler halten sich freiwillig daran, bösartige Scanner ignorieren sie komplett. Schützen Sie sensible Pfade mit einer Authentifizierung oder mit Serverregeln.

WordPress robots.txt 2026: Was wirklich hineingehört

Eine gute WordPress robots.txt ist ungefähr fünf Zeilen lang. /wp-admin/ sperren, admin-ajax.php erlauben, Crawler auf Ihre Sitemap zeigen — und dann aufhören. Die ausufernden 40-Zeilen-Sperrlisten aus den Foren machen meistens das Rendering kaputt oder bewirken gar nichts. Die komplette Datei:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Tauschen Sie die Domain aus, und wenn Sie ein SEO-Plugin nutzen, das die Sitemaps übernimmt, verweisen Sie die Sitemap-Zeile stattdessen auf dessen Index. Das war’s. Ist Ihre Datei länger, kosten die zusätzlichen Zeilen Sie vermutlich etwas.

WordPress erzeugt bereits eine — bis Sie eine echte Datei anlegen

WordPress liefert eine virtuelle robots.txt aus. Kommt eine Anfrage für /robots.txt herein und existiert keine echte Datei im Web-Root, fängt WordPress die Anfrage ab und gibt eine im Arbeitsspeicher erzeugte Antwort aus. Auf die Festplatte wird nichts geschrieben. Die Standardausgabe ist der wp-admin-Block von oben plus eine Sitemap:-Zeile für wp-sitemap.xml, die der Core seit WordPress 5.5 ausgibt.

Zwei Dinge verändern diese Ausgabe. Ist unter Einstellungen → Lesen → Suchmaschinen davon abhalten, diese Website zu indexieren das Häkchen gesetzt, ersetzt WordPress das Ganze durch Disallow: / und sperrt damit alles. Diese Checkbox ist mit Abstand die häufigste Ursache dafür, dass eine Website nach dem Launch aus der Suche verschwindet. Zweitens können Plugins und Themes die virtuelle Ausgabe über den robots_txt-Filter verändern — so schleusen SEO-Plugins ihre eigenen Sitemap-Zeilen und Regeln ein.

Jetzt der Teil, der ganze Nachmittage frisst. Eine physische robots.txt in Ihrem Web-Root überschreibt all das stillschweigend. Ihr Webserver findet eine echte Datei auf der Festplatte, liefert sie aus, und WordPress wird nie geladen. Der virtuelle Generator läuft nicht. Der robots_txt-Filter greift nicht. Der robots.txt-Editor Ihres SEO-Plugins zeigt Ihnen womöglich weiterhin eine schöne Oberfläche mit den richtigen Regeln darin — und nichts davon erreicht einen Crawler.

Wo die Regeln liegen	Im WordPress-Backend bearbeitbar	Gewinnt bei einem echten Aufruf
Virtuell (keine Datei auf der Festplatte)	Ja, über den `robots_txt`-Filter oder ein Plugin	Nur, wenn keine physische Datei existiert
Physische Datei im Web-Root	Nur, wenn das Plugin auf die Festplatte schreibt	Immer

Bevor Sie also irgendetwas debuggen: Öffnen Sie https://ihredomain.de/robots.txt im Browser, verbinden Sie sich dann per SFTP oder über den Dateimanager Ihres Hosters und prüfen Sie, ob neben wp-config.php und .htaccess eine echte robots.txt liegt. Wenn ja, ist das Ihre robots.txt. Bearbeiten Sie sie dort oder löschen Sie sie und überlassen Sie WordPress das Feld — aber entscheiden Sie sich. Beides parallel zu betreiben ist der Weg zu einer veralteten Sitemap-URL, die niemand findet.

Warum /wp-admin/ gesperrt, admin-ajax.php aber erlaubt ist

In /wp-admin/ liegt das Dashboard. Diese URLs sind in Suchergebnissen nutzlos, und sie zu crawlen verbrennt Crawl-Budget auf Seiten, die auf einen Login-Bildschirm weiterleiten. Das Verzeichnis zu sperren ist unstrittig.

admin-ajax.php liegt zwar in diesem Verzeichnis, ist aber keine Backend-Seite. Es ist der Endpunkt, über den Plugins und Themes AJAX-Anfragen im Frontend abwickeln — Mehr-laden-Buttons, gefilterte Produktgitter, Rechner, Formulare. Kann ein Crawler ihn nicht abrufen, sieht er die Inhalte nicht, die diese Funktionen nachladen, und Google rendert Ihre Seite so, wie ein Besucher sie mit kaputter Funktion sehen würde.

Ob Google admin-ajax.php auf Ihrer konkreten Website überhaupt abrufen muss, hängt davon ab, ob Ihr Frontend es nutzt. Ehrliche Antwort: Auf vielen modernen Websites spielt es keine Rolle, weil das Theme stattdessen die REST-API unter /wp-json/ verwendet. Die Allow-Zeile ist eine billige Versicherung gegen einen realen Ausfallweg, kein Rankingfaktor. Behalten Sie sie, weil sie nichts kostet.

Sperren Sie /wp-content/ oder /wp-includes/ nicht

Das ist der schlechteste robots.txt-Ratschlag, der immer noch kursiert, und er stammt aus einer Zeit, in der Google Seiten nicht gerendert hat.

In /wp-content/ liegen Ihre Themes, Plugins und Uploads — die Stylesheets, Skripte und Bilder, die Ihre Seiten überhaupt erst wie Seiten aussehen lassen. In /wp-includes/ liegt das Core-JavaScript, auf das Plugins angewiesen sind. Google rendert Ihre Seiten mit einem Headless-Browser, bevor es sie bewertet. Sperren Sie diese Verzeichnisse, bekommt der Renderer eine Seite ohne CSS und ohne Bilder. Google bewertet dann eine ungestylte Textwüste mit zerlegtem Layout, und das beeinflusst sowohl das Verständnis Ihrer Inhalte als auch die Bewertung der mobilen Nutzbarkeit.

Wenn Sie eine Datei mit diesen Zeilen geerbt haben, löschen Sie sie:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Den Schaden können Sie selbst nachvollziehen: im URL-Prüftool der Google Search Console. Führen Sie einen Live-Test für eine beliebige Seite aus, sehen Sie sich den gerenderten Screenshot an und prüfen Sie die Liste der Seitenressourcen auf gesperrte Einträge. Wenn Ihr CSS als gesperrt erscheint, ist das die Ursache.

Die Sitemap-Anweisung

Eine Zeile, absolute URL, und sie darf an beliebiger Stelle in der Datei stehen — sie gehört zu keiner User-agent-Gruppe.

Sitemap: https://example.com/wp-sitemap.xml

Nehmen Sie die URL, die tatsächlich funktioniert. Der WordPress-Core liefert wp-sitemap.xml aus. Die meisten SEO-Plugins schalten die Core-Sitemaps ab und liefern ihren eigenen Index unter einem anderen Pfad aus, typischerweise sitemap_index.xml. Laden Sie Ihre URL im Browser, bevor Sie sie eintragen — eine Sitemap-Zeile, die auf einen 404 zeigt, ist schlimmer als gar keine Zeile, weil sie in einem Audit korrekt aussieht.

Mehrere Sitemaps aufzuführen ist in Ordnung, eine pro Zeile. Sitemaps zusätzlich in der Search Console einzureichen lohnt sich weiterhin; die robots.txt-Anweisung ist der Weg, auf dem Crawler ohne Zugriff auf Ihre Search Console sie finden.

robots.txt ist kein noindex — und keine Sicherheit

Diese beiden Missverständnisse richten den meisten robots.txt-Schaden an.

Eine URL zu sperren entfernt sie nicht aus Google. Robots.txt regelt das Crawling. Verlinkt eine andere Website auf eine gesperrte URL, kann Google die URL selbst indexieren — Sie bekommen ein Ergebnis mit der nackten Adresse und dem Hinweis, dass keine Informationen verfügbar sind. Und es gibt eine fiesere Falle: Hat eine Seite bereits ein noindex-Meta-Tag und Sie sperren sie danach in der robots.txt, kann Google sie nicht crawlen, das noindex nicht sehen — und die Seite bleibt womöglich dauerhaft im Index. Um eine Seite zu entfernen, erlauben Sie das Crawling und liefern ein noindex-Meta-Tag im Seitenkopf oder einen X-Robots-Tag-HTTP-Header aus. Google unterstützt noindex-Anweisungen innerhalb der robots.txt seit 2019 nicht mehr.

Einen Pfad zu sperren schützt ihn nicht. Ihre robots.txt ist per Definition öffentlich. Wer dort /private-kundendateien/ aufführt, sagt jedem Besucher und jedem Scanner genau, wo er nachsehen soll, und die Einhaltung ist freiwillig — Google hält sich daran, feindselige Bots nicht. Alles, was Schutz braucht, braucht eine Authentifizierung, eine IP-Beschränkung oder Serverregeln in der .htaccess, keine Zeile in einer Textdatei, die das Ziel ausschildert.

Regeln, die sich lohnen, und Regeln, die Sie weglassen können

Zwei Ergänzungen sind auf vielen Websites wirklich sinnvoll. Den Pfad der Suchergebnisse zu sperren verhindert, dass Crawler aus Ihrer internen Suche endlos wertlose URLs erzeugen. Warenkorb- oder Kassenpfade in WooCommerce zu sperren hält URLs mit Session-Parametern aus dem Crawl heraus.

Disallow: /?s=
Disallow: /search/

Diese hier können Sie sich sparen:

Crawl-delay — Google ignoriert es vollständig. Nutzen Sie die Crawling-Frequenz-Einstellungen in der Search Console, wenn Sie ein echtes Lastproblem haben.
/feed/ oder /trackback/ sperren — harmlose URLs, und Feeds sind nützlich.
Lange Listen einzelner Bot-Namen — die meisten Bots, die man so sperren will, geben sich ohnehin nicht ehrlich zu erkennen.
/wp-json/ sperren — womöglich rendert genau darüber Ihr Theme die Inhalte.

Bauen Sie die Datei mit dem WordPress robots.txt-Generator, der die minimale korrekte Fassung erzeugt und Sie die Such- und Shop-Regeln ergänzen lässt, ohne Syntax von Hand zu tippen.

Nach der Änderung

Rufen Sie https://ihredomain.de/robots.txt direkt auf und prüfen Sie, dass die ausgelieferten Bytes dem entsprechen, was Sie erwarten — nicht dem, was der Editor Ihres Plugins anzeigt. Führen Sie danach in der Search Console eine Live-URL-Prüfung für eine normale Seite durch und kontrollieren Sie, dass keine CSS- oder JavaScript-Ressourcen als gesperrt zurückkommen. Google cacht die robots.txt etwa einen Tag lang, eine Korrektur wirkt also nicht sofort — und ein Fehler eben auch nicht. Genau diese Verzögerung ist der Grund, sorgfältig zu prüfen, statt live zu testen und abzuwarten.