Die Datei robots.txt gehört zu den ältesten und gleichzeitig am häufigsten missverstandenen Steuerungsmöglichkeiten einer Website.
Auf den ersten Blick wirkt sie simpel.
Ein paar Textzeilen können einem Suchmaschinen-Crawler mitteilen:
Diesen Bereich darfst du crawlen.
oder:
Diesen Bereich sollst du nicht abrufen.
Gerade diese Einfachheit verführt jedoch zu einem gefährlichen Missverständnis: Viele Website-Betreiber betrachten die robots.txt als Werkzeug, mit dem sich Seiten aus Google entfernen oder private Inhalte verstecken lassen.
Genau dafür ist sie nicht gedacht.
Google beschreibt die robots.txt in erster Linie als Werkzeug zur Steuerung des Crawling-Zugriffs auf URLs. Eine durch robots.txt gesperrte Webadresse kann unter Umständen trotzdem in den Suchergebnissen auftauchen, wenn Google sie beispielsweise über externe Links kennt. Wer eine Seite zuverlässig nicht in Google haben möchte, braucht dafür andere Mechanismen wie noindex; private Inhalte benötigen echten Zugriffsschutz. (Google for Developers)
Die wichtigste Grundlage lautet deshalb:
robots.txt steuert Crawling. Sie steuert nicht zuverlässig die Indexierung.
Crawling und Indexierung sind zwei verschiedene Vorgänge
Diesen Unterschied haben wir bereits in Wie Suchmaschinen Websites finden kennengelernt.
Beim Crawling ruft ein Suchmaschinenbot eine URL ab.
Bei der Indexierung entscheidet die Suchmaschine, ob und wie Informationen über diese URL in ihren Suchindex aufgenommen werden.
Vereinfacht:
URL bekannt
↓
Crawler darf sie abrufen?
↓
robots.txt
↓
Seite wird gecrawlt
↓
Inhalt und Signale werden verarbeitet
↓
mögliche Indexierung
Die robots.txt greift also sehr früh im Prozess ein. Sie beantwortet im Kern die Frage, ob ein bestimmter Crawler eine bestimmte URL anfordern darf. Google beschreibt genau diese Funktion als Zweck der Datei. (Google for Developers)
Eine Crawling-Sperre löscht keine bekannte URL
Angenommen, wir besitzen:
und schreiben in die robots.txt:
User-agent: *
Disallow: /intern/
Googlebot soll den Bereich nun nicht crawlen.
Das bedeutet aber nicht automatisch:
Google vergisst, dass
/intern/existiert.
Wenn andere Websites oder Seiten auf die URL verlinken, kann Google die Adresse weiterhin kennen. Google weist ausdrücklich darauf hin, dass eine durch robots.txt blockierte URL unter Umständen trotzdem ohne gecrawlten Seiteninhalt in den Suchergebnissen erscheinen kann. (Google for Developers)
Das klingt zunächst widersprüchlich.
Ist es aber nicht.
Google kennt in diesem Fall die Adresse, darf aber den Inhalt nicht abrufen.
robots.txt ist deshalb kein Datenschutzwerkzeug
Stell dir vor, unter:
/geheime-vertraege/
liegen vertrauliche PDFs.
Nun wird geschrieben:
User-agent: *
Disallow: /geheime-vertraege/
Damit sind die Dateien nicht geschützt.
Ein Mensch, der die URL kennt, kann sie weiterhin aufrufen.
Auch die robots.txt selbst ist öffentlich abrufbar und würde sogar verraten, dass dieser Pfad existiert.
Google empfiehlt deshalb ausdrücklich, robots.txt nicht zum Schutz privater Informationen zu verwenden. Für wirklich private Inhalte braucht es Zugriffsschutz, etwa Authentifizierung. (Google for Developers)
Eine gute Merkhilfe lautet:
robots.txt ist eine Anweisung an kooperative Crawler – keine Tür mit Schloss.
Wo befindet sich die robots.txt?
Die robots.txt liegt im Stamm des jeweiligen Hosts.
Für:
lautet die Adresse:
https://example.de/robots.txt
Eine Datei unter:
https://example.de/ordner/robots.txt
ist keine robots.txt für die gesamte Website.
Google prüft die Datei auf der obersten Ebene des jeweiligen Hosts. Außerdem gelten die Regeln nur für genau die Kombination aus Host, Protokoll und Port, unter der die robots.txt bereitgestellt wird. (Google for Developers)
Das ist technisch wichtiger, als es zunächst aussieht.
www und non-www besitzen nicht automatisch dieselbe robots.txt
Diese beiden Adressen sind technisch unterschiedliche Hosts:
https://example.de/
https://www.example.de/
Eine robots.txt unter:
https://www.example.de/robots.txt
gilt nach Googles Spezifikation nicht automatisch für:
https://example.de/
Dasselbe gilt für Subdomains wie:
https://shop.example.de/
Sie besitzen ihren eigenen Geltungsbereich. (Google for Developers)
In einer sauber konfigurierten Website wird meist ohnehin eine bevorzugte Hauptvariante verwendet und andere Varianten werden weitergeleitet. Trotzdem sollte man verstehen, dass robots.txt-Regeln technisch an ihren konkreten Host gebunden sind.
HTTP und HTTPS sind ebenfalls unterschiedliche Geltungsbereiche
Auch:
http://example.de/
und:
https://example.de/
sind für robots.txt unterschiedliche Bereiche.
Eine unter HTTPS bereitgestellte robots.txt gilt nicht einfach automatisch für dieselbe Domain über HTTP. Google definiert den Geltungsbereich anhand von Protokoll, Host und Port. (Google for Developers)
Für moderne Websites sollte die Hauptversion ohnehin konsequent über HTTPS laufen. Den Zusammenhang behandeln wir unter SSL und HTTPS verständlich erklärt.
Wie sieht eine einfache robots.txt aus?
Eine sehr einfache Datei könnte so aussehen:
User-agent: *
Disallow: /intern/
Die erste Zeile legt fest, auf welche Crawler sich die folgenden Regeln beziehen.
Die zweite Zeile sperrt einen URL-Pfad für diese Crawler.
Google unterstützt im robots.txt-Format insbesondere die Felder user-agent, allow, disallow und sitemap. (Google for Developers)
Damit lassen sich bereits die meisten normalen Anwendungsfälle abdecken.
Was bedeutet User-agent?
Crawler identifizieren sich normalerweise mit einem User-Agent.
Google verwendet verschiedene Crawler für unterschiedliche Aufgaben. Für die normale Websuche ist vor allem Googlebot relevant. In robots.txt können Regeln entweder für einen bestimmten Crawler oder mit * allgemein formuliert werden. (Google for Developers)
Beispielsweise:
User-agent: Googlebot
Disallow: /test/
Diese Gruppe richtet sich an Googlebot.
Dagegen:
User-agent: *
Disallow: /test/
richtet sich grundsätzlich an alle Crawler, die diese allgemeine Gruppe beachten.
Der Stern bedeutet „alle“
Das Sternchen in:
User-agent: *
steht für alle User-Agents, für die keine spezifischere passende Gruppe gilt.
Eine typische einfache robots.txt beginnt daher mit:
User-agent: *
wenn für alle normalen Suchcrawler dieselben Regeln gelten sollen.
Google wählt bei mehreren Gruppen die spezifischste passende User-Agent-Gruppe. Eine speziell definierte Googlebot-Gruppe wird deshalb nicht einfach mit der allgemeinen *-Gruppe zusammengemischt. (Google for Developers)
Das ist wichtig, sobald komplexere Dateien entstehen.
Spezifische Gruppen können allgemeine Regeln ersetzen
Betrachten wir:
User-agent: *
Disallow: /intern/
User-agent: Googlebot
Allow: /
Für Googlebot ist die spezifische Googlebot-Gruppe maßgeblich; die allgemeine Gruppe wird dabei nicht zusätzlich als Regelpaket herangezogen. Google dokumentiert ausdrücklich, dass spezifische User-Agent-Gruppen Vorrang vor globalen Gruppen haben. (Google for Developers)
Wer komplexe robots.txt-Dateien bearbeitet, sollte deshalb nicht davon ausgehen, dass sämtliche Regeln einfach von oben nach unten addiert werden.
Googlebot Smartphone und Desktop werden nicht getrennt gesteuert
Google verwendet derzeit unter anderem Smartphone- und Desktop-Varianten von Googlebot. Beide verwenden für robots.txt jedoch denselben Produkt-Token Googlebot. Man kann sie deshalb dort nicht separat mit unterschiedlichen Regeln behandeln. (Google for Developers)
Für normale Websites ist das ohnehin selten notwendig.
Es zeigt aber, dass User-Agent-Strings und robots.txt-Produkt-Tokens nicht dasselbe Detailniveau besitzen müssen.
Was bedeutet Disallow?
Disallow sagt einem passenden Crawler, welche URL-Pfade er nicht abrufen soll.
Beispiel:
User-agent: *
Disallow: /privater-bereich/
Damit wird der entsprechende Pfad für diese Crawler gesperrt.
Der Pfad wird relativ zum Stamm des Hosts angegeben und beginnt normalerweise mit /. Die Pfadwerte sind bei Google groß-/kleinschreibungssensitiv. (Google for Developers)
Das bedeutet:
Disallow: /Test/
ist nicht automatisch dasselbe wie:
Disallow: /test/
wenn der Server diese URLs ebenfalls unterscheidet.
Ein Verzeichnis wird mit dem abschließenden Slash klarer abgegrenzt
Angenommen, wir möchten den kompletten Bereich:
/intern/
blockieren.
Dann schreiben wir:
Disallow: /intern/
Das passt beispielsweise zu:
/intern/
/intern/datei/
/intern/beispiel.html
Eine Regel:
Disallow: /intern
ist breiter und kann auch andere Pfade erfassen, die mit dieser Zeichenfolge beginnen. Google vergleicht robots.txt-Pfade mit dem tatsächlichen URL-Pfad und dokumentiert beispielsweise, dass /fish auch /fishheads trifft, während /fish/ gezielter einen Ordnerbereich abgrenzt. (Google for Developers)
Bei robots.txt lohnt sich deshalb präzise Schreibweise.
Die gesamte Website lässt sich mit einem Slash sperren
Diese Datei:
User-agent: *
Disallow: /
verbietet passenden Crawlern den Zugriff auf die gesamte Website.
Google führt genau diese Regel als Beispiel für das vollständige Blockieren des Crawlings auf. Die URLs könnten trotzdem unter bestimmten Umständen bekannt bleiben und sogar ohne gecrawlten Inhalt in Suchergebnissen erscheinen. (Google for Developers)
Diese zwei Zeichen:
/
können also enorme Auswirkungen haben.
Gerade nach Staging-Phasen oder Relaunches sollte deshalb geprüft werden, ob eine solche Sperre versehentlich produktiv geblieben ist.
Ein leeres Disallow sperrt nichts
Folgendes:
User-agent: *
Disallow:
erlaubt Crawling grundsätzlich.
Google betrachtet eine leere Disallow-Regel funktional wie keine entsprechende Sperre. (Google for Developers)
Man braucht diese Konstruktion nicht zwingend.
Eine Website ohne robots.txt-Regeln ist hinsichtlich des Crawlings ebenfalls grundsätzlich nicht durch robots.txt eingeschränkt.
Was bedeutet Allow?
Allow kann innerhalb eines ansonsten gesperrten Bereichs gezielte Ausnahmen definieren.
Beispielsweise:
User-agent: *
Disallow: /intern/
Allow: /intern/oeffentlich/
Damit wird /intern/ grundsätzlich blockiert, während der speziellere Pfad /intern/oeffentlich/ erlaubt werden kann.
Google unterstützt Allow ausdrücklich als robots.txt-Regel und entscheidet bei passenden Konflikten anhand der spezifischeren Pfadregel. (Google for Developers)
Damit lassen sich differenziertere Strukturen aufbauen.
Die spezifischere Regel gewinnt
Angenommen:
Allow: /ordner/seite/
Disallow: /ordner/
Für:
/ordner/seite/
ist die Allow-Regel spezifischer.
Google entscheidet bei der URL-Zuordnung anhand der Länge beziehungsweise Spezifität des passenden Regelpfades. Sind zwei kollidierende Regeln gleich spezifisch, verwendet Google die weniger restriktive Regel. (Google for Developers)
Das ist wesentlich zuverlässiger als die Vorstellung:
Die unterste Zeile gewinnt.
Die Reihenfolge der Allow– und Disallow-Zeilen ist nicht das zentrale Entscheidungskriterium.
Ein typisches WordPress-Beispiel verwendet genau dieses Prinzip
WordPress erzeugt standardmäßig eine robots.txt-Ausgabe mit:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Damit wird der Administrationsbereich grundsätzlich vom Crawling ausgeschlossen, während admin-ajax.php ausdrücklich erreichbar bleibt. Genau diese Ausgabe befindet sich aktuell in der WordPress-Core-Funktion do_robots(). (WordPress Developer Resources)
Das ist ein sehr anschauliches Beispiel dafür, wozu Allow gedacht ist.
Was bedeutet Sitemap in robots.txt?
Eine robots.txt kann zusätzlich den Standort einer XML-Sitemap nennen.
Beispielsweise:
Sitemap: https://example.de/wp-sitemap.xml
Anders als Allow und Disallow gehört diese Zeile nicht zur Zugriffskontrolle eines einzelnen User-Agents. Google unterstützt vollständige absolute Sitemap-URLs in robots.txt und erlaubt auch mehrere Sitemap:-Angaben. (Google for Developers)
Die robots.txt kann damit zwei völlig unterschiedliche Aufgaben enthalten:
Crawling-Regeln
+
Hinweis auf Sitemaps
Die Funktionsweise der Sitemap behandeln wir ausführlich unter XML-Sitemap erklärt.
Eine Sitemap-Zeile braucht die vollständige URL
Richtig:
Sitemap: https://example.de/wp-sitemap.xml
Nicht nur:
Sitemap: /wp-sitemap.xml
Google verlangt für das sitemap-Feld eine vollständige URL einschließlich Protokoll und Host. (Google for Developers)
Das unterscheidet sich von Allow und Disallow, bei denen URL-Pfade relativ zum jeweiligen Host angegeben werden.
Kommentare beginnen mit einer Raute
Eine robots.txt kann Kommentare enthalten.
Beispielsweise:
# WordPress-Backend
User-agent: *
Disallow: /wp-admin/
Alles hinter # wird von Google als Kommentar behandelt und für die Regeln ignoriert. Google akzeptiert eine einfache Textsyntax aus Feld, Doppelpunkt und Wert. (Google for Developers)
Kommentare können bei komplexeren Dateien sehr hilfreich sein.
Besonders wenn mehrere Personen später verstehen müssen, warum eine bestimmte Regel existiert.
Eine robots.txt ist eine normale Textdatei
Google erwartet robots.txt als UTF-8-kodierte Textdatei. Sie sollte kein HTML-Dokument sein. Google ignoriert ungültige Zeilen soweit möglich und verarbeitet gültige Regeln, setzt aber auch eine maximale Dateigröße von 500 KiB durch; darüberliegende Inhalte werden ignoriert. (Google for Developers)
Eine normale WordPress-Website wird diese Größenbegrenzung niemals annähernd erreichen.
Wenn eine robots.txt hunderte Kilobyte benötigt, ist wahrscheinlich ohnehin eine unnötig komplizierte Strategie entstanden.
Wildcards ermöglichen Muster
Google unterstützt für Pfadregeln eine begrenzte Form von Wildcards.
Das Sternchen:
*
kann für beliebig viele Zeichen stehen.
Das Dollarzeichen:
$
markiert das Ende einer URL. (Google for Developers)
Damit lassen sich beispielsweise bestimmte Dateitypen oder URL-Muster adressieren.
Ein Beispiel mit Dateiendungen
Google dokumentiert beispielsweise eine Regel dieser Art:
User-agent: Googlebot
Disallow: /*.gif$
Damit werden Pfade blockiert, die auf .gif enden. (Google for Developers)
Das $ ist hier entscheidend.
Ohne Endmarkierung kann eine Zeichenfolge auch mitten in einer längeren URL passen.
Wildcards sind leistungsfähig – aber genau deshalb sollte man sie nicht ungetestet in komplexe produktive Dateien schreiben.
Query-Parameter können ebenfalls Teil des Pfadabgleichs werden
Google gleicht Regeln gegen den Pfad der angeforderten URL einschließlich relevanter weiterer URL-Zeichenfolgen ab. So kann beispielsweise eine Regel mit einem Dateiende anders reagieren, wenn hinter der Endung noch URL-Parameter folgen. Die Google-Dokumentation zeigt ausdrücklich, dass /*.xls$ eine URL mit zusätzlichem ?parameter=... nicht mehr trifft, weil .xls dann nicht am Ende der URL steht. (Google for Developers)
Das ist ein gutes Beispiel dafür, warum scheinbar einfache robots.txt-Muster unerwartete Lücken erzeugen können.
crawl-delay gehört bei Google nicht zu den unterstützten Regeln
Manche robots.txt-Beispiele im Web enthalten:
Crawl-delay: 10
Google unterstützt dieses Feld in seiner robots.txt-Auswertung derzeit nicht. Google dokumentiert als unterstützte Felder user-agent, allow, disallow und sitemap und nennt crawl-delay ausdrücklich als nicht unterstützt. (Google for Developers)
Wer Probleme mit übermäßigem Googlebot-Crawling vermutet, sollte deshalb nicht einfach eine crawl-delay-Zeile in die robots.txt schreiben und davon ausgehen, Google werde sie beachten.
robots.txt ist heute meist kein Instrument gegen Serverüberlastung kleiner Websites
Google beschreibt die Steuerung des Crawlertraffics zwar als zentralen Zweck der robots.txt. Bei den meisten normalen Websites ist Googlebot allerdings nicht die Ursache für grundsätzliche Serverprobleme. Google gibt selbst an, dass Googlebot bei den meisten Websites im Durchschnitt nicht häufiger als etwa einmal alle paar Sekunden zugreift, wobei kurzfristige Schwankungen möglich sind. (Google for Developers)
Wenn eine kleine WordPress-Seite bereits bei normalem Crawling zusammenbricht, sollte deshalb auch WordPress-Performance beziehungsweise die Serverkonfiguration untersucht werden.
CSS und JavaScript sollte man nicht leichtfertig blockieren
Frühere robots.txt-Dateien sperrten gelegentlich pauschal technische Verzeichnisse mit CSS- und JavaScript-Dateien.
Das kann problematisch sein.
Google rendert Webseiten und benötigt dafür unter Umständen genau diese Ressourcen. Selbst Googles aktuelle robots.txt-Dokumentation verwendet als Beispiel ein technisch gesperrtes Verzeichnis, in dem CSS und JavaScript liegen, und erlaubt Googlebot dort ausdrücklich den Zugriff, weil die Ressourcen fürs Rendering benötigt werden. (Google for Developers)
Eine Regel wie:
Disallow: /wp-content/
sollte daher nicht gedankenlos eingesetzt werden.
Dort liegen bei WordPress unter anderem Themes, Plugins und Mediendateien, die für die Darstellung relevant sein können.
Crawler sollten die öffentliche Seite möglichst ähnlich verstehen können wie Besucher
Wenn ein Besucher CSS und JavaScript laden kann, Googlebot aber nicht, erhält Google möglicherweise eine andere technische Sicht auf die Seite.
Das bedeutet nicht, dass jede beliebige Ressource zwingend crawlbar sein muss.
Aber zentrale öffentliche Ressourcen ohne konkreten Grund zu blockieren, erschwert die Verarbeitung.
Für normale WordPress-Websites ist eine minimalistische robots.txt daher häufig besser als ein riesiger Katalog scheinbarer SEO-Sperren.
Muss ich wp-admin sperren?
WordPress selbst liefert standardmäßig:
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
über seine virtuelle robots.txt aus. (WordPress Developer Resources)
Das ist vernünftig, weil normale Suchmaschinen den Administrationsbereich nicht crawlen müssen.
Dabei darf man aber nicht verwechseln:
Disallow: /wp-admin/
schützt /wp-admin/ nicht vor Angreifern.
Jeder kennt diese Standardadresse trotzdem.
Die Sicherheit des WordPress-Backends muss über Authentifizierung, Updates, Rechte und weitere Sicherheitsmaßnahmen gewährleistet werden.
robots.txt ist auch hier keine Zugangskontrolle.
Was ist eine virtuelle robots.txt in WordPress?
Bei WordPress muss nicht zwingend eine physische Datei namens robots.txt im Webverzeichnis liegen.
WordPress kann die Antwort für /robots.txt dynamisch erzeugen.
Die aktuelle Core-Funktion do_robots() liefert die robots.txt als text/plain aus und erzeugt standardmäßig die Regeln für /wp-admin/ und admin-ajax.php. WordPress stellt außerdem den Filter robots_txt bereit, über den diese Ausgabe verändert werden kann. (WordPress Developer Resources)
Das erklärt eine typische Situation:
Du suchst per FTP nach robots.txt.
Keine Datei vorhanden.
Im Browser funktioniert:
https://example.de/robots.txt
trotzdem.
WordPress erzeugt die Antwort dynamisch.
Eine physische robots.txt kann diese virtuelle Ausgabe ersetzen
Wenn im Webroot eine echte Datei robots.txt liegt und der Webserver sie direkt ausliefert, erreicht die Anfrage möglicherweise gar nicht mehr die dynamische WordPress-Funktion.
Welche Variante tatsächlich aktiv ist, lässt sich am einfachsten überprüfen:
https://deine-domain.de/robots.txt
im Browser aufrufen und die tatsächliche Antwort ansehen.
Für die Suchmaschine zählt nicht, was irgendwo im WordPress-Backend konfiguriert sein sollte.
Sie sieht die HTTP-Antwort, die unter dieser Adresse tatsächlich ausgeliefert wird.
Plugins können die WordPress-Ausgabe verändern
WordPress stellt den Filter:
robots_txt
für Änderungen an der robots.txt-Ausgabe bereit. (WordPress Developer Resources)
SEO- oder Sicherheitsplugins können deshalb zusätzliche Regeln oder Sitemap-Hinweise ergänzen.
Das ist grundsätzlich praktisch.
Es bedeutet aber auch, dass bei einer ungewöhnlichen robots.txt mehrere Ebenen beteiligt sein können:
WordPress Core,
Plugin,
physische Datei,
Webserver,
Hostingplattform
oder vorgeschalteter Proxy.
Wie bei Caching gilt auch hier:
Zuerst herausfinden, welche Ebene tatsächlich die Antwort erzeugt.
Die WordPress-Einstellung „Suchmaschinen davon abhalten“ ist besonders wichtig
Unter:
Einstellungen → Lesen
besitzt WordPress die Option sinngemäß:
Suchmaschinen davon abhalten, diese Website zu indexieren.
Wird die Website als nicht öffentlich markiert, verwendet der aktuelle WordPress-Core dafür unter anderem Robots-Meta-Direktiven wie noindex; seit WordPress 5.3 wird dafür nicht mehr einfach Disallow: / als Standardausgabe der robots.txt verwendet. (WordPress.org)
Das ist eine wichtige Änderung gegenüber sehr alten WordPress-Anleitungen.
Deshalb sollte man nach einem Staging-Relaunch diese Einstellung kontrollieren
Ein typischer Ablauf:
Die neue Website wird auf einer Testdomain aufgebaut.
Suchmaschinen sollen sie dort nicht indexieren.
Die entsprechende WordPress-Einstellung wird aktiviert.
Später wird die Installation auf die echte Domain verschoben.
Alles sieht perfekt aus.
Nur die Option bleibt aktiviert.
WordPress kann dann weiterhin noindex ausgeben. Die WordPress-Core-Funktion wp_robots_noindex() orientiert sich ausdrücklich an der Site-Konfiguration beziehungsweise blog_public. (WordPress Developer Resources)
Das kann wesentlich gravierender sein als eine bloße robots.txt-Sperre, weil noindex tatsächlich die Indexierung betrifft.
Die Einstellung ist trotzdem kein Schutz für eine Staging-Site
Auch WordPress formuliert die Option als Bitte an Suchmaschinen beziehungsweise als Indexierungssteuerung.
Eine Staging-Website mit vertraulichen Inhalten sollte nicht ausschließlich darauf vertrauen.
Wenn niemand außer berechtigten Personen Zugriff haben soll, gehört die Testumgebung hinter einen echten Zugriffsschutz.
Das entspricht auch Googles Empfehlung: Für private Inhalte ist Passwortschutz beziehungsweise Authentifizierung das geeignete Mittel, nicht robots.txt. (Google for Developers)
robots.txt und noindex dürfen nicht verwechselt werden
Das ist der zentrale Unterschied dieses gesamten Artikels.
robots.txt:
User-agent: *
Disallow: /seite/
bedeutet für den passenden Crawler:
Rufe diese URL nicht ab.
noindex:
<meta name="robots" content="noindex">
bedeutet:
Diese Seite soll nicht im Suchindex erscheinen.
Google dokumentiert noindex ausdrücklich als Indexierungsregel und robots.txt als Crawling-Steuerung. (Google for Developers)
Das sind zwei verschiedene Ebenen.
Die Kombination „Disallow + noindex“ kann sich selbst sabotieren
Angenommen, eine Seite besitzt:
<meta name="robots" content="noindex">
Gleichzeitig steht in robots.txt:
Disallow: /seite/
Googlebot darf die Seite nun nicht crawlen.
Damit kann Google möglicherweise das noindex im HTML überhaupt nicht lesen.
Google warnt ausdrücklich vor genau diesem Konflikt: Robots-Meta-Direktiven und X-Robots-Tag können nur verarbeitet werden, wenn der Crawler die betreffende URL abrufen darf. (Google for Developers)
Wenn das Ziel lautet:
Diese öffentlich erreichbare Seite soll nicht in Google erscheinen, dann muss Google sie im Regelfall crawlen dürfen, damit noindex erkannt werden kann.
Eine alte robots.txt-Sperre kann deshalb das Entfernen erschweren
Stell dir vor, eine URL ist bereits in Google.
Nun fügen wir noindex hinzu.
Gleichzeitig blockieren wir sie in robots.txt.
Google kann das neue noindex nicht zuverlässig sehen.
Die Adresse könnte dadurch länger als erwartet in Suchergebnissen verbleiben.
Google nennt genau dieses Szenario als möglichen Grund, weshalb ein noindex nicht verarbeitet wird. (Google for Developers)
Das klingt paradox:
Manchmal muss man Google erlauben, eine Seite zu crawlen, damit Google versteht, dass sie nicht indexiert werden soll.
noindex gehört nicht in die robots.txt
Im Internet findet man gelegentlich ältere Beispiele wie:
Noindex: /irgendwas/
Google unterstützt noindex in robots.txt nicht. noindex muss für Google als Robots-Meta-Tag oder als X-Robots-Tag im HTTP-Header ausgeliefert werden. (Google for Developers)
Eine Zeile Noindex: in robots.txt sollte deshalb nicht als funktionierende Google-Indexierungssteuerung betrachtet werden.
Was ist der X-Robots-Tag?
Bei einer normalen HTML-Seite lässt sich noindex im HTML-Head angeben.
Bei Dateien wie PDFs gibt es keinen klassischen HTML-Head.
Dafür kann ein HTTP-Header verwendet werden:
X-Robots-Tag: noindex
Google unterstützt den X-Robots-Tag für entsprechende Indexierungs- und Darstellungsregeln und nennt ihn insbesondere als Möglichkeit für nicht-HTML-Ressourcen. (Google for Developers)
Auch hier gilt:
Wenn die URL per robots.txt für Googlebot gesperrt ist, kann Google diesen HTTP-Header nicht zuverlässig abrufen und auswerten. (Google for Developers)
robots.txt und Canonical lösen ebenfalls unterschiedliche Probleme
Ein Canonical-Tag sagt sinngemäß:
Von mehreren ähnlichen URLs ist diese Version meine bevorzugte.
robots.txt sagt:
Diese URL darfst du nicht crawlen.
Wer doppelte Inhalte ausschließlich per robots.txt blockiert, verhindert möglicherweise sogar, dass Google die Canonical-Signale auf diesen Seiten sieht.
Canonicalisierung behandeln wir deshalb später separat unter:
/wissen/canonical-tag/
Auch hier lautet die Grundregel:
Für jedes Problem das Werkzeug verwenden, das tatsächlich dafür vorgesehen ist.
Parameterseiten sind ein typischer robots.txt-Anwendungsfall – aber mit Vorsicht
Große Websites können sehr viele URL-Varianten erzeugen.
Zum Beispiel:
/shop/?farbe=rot
/shop/?farbe=blau
/shop/?sortierung=preis
/shop/?sortierung=name
Bei tausenden Filterkombinationen kann Crawling unnötig Ressourcen binden.
robots.txt kann theoretisch bestimmte URL-Muster vom Crawling ausschließen. Google nennt das Vermeiden des Crawlings unwichtiger oder ähnlicher URLs als einen möglichen Anwendungsfall. (Google for Developers)
Ob das sinnvoll ist, muss aber anhand der konkreten Website entschieden werden.
Manche Parameterseiten sollen indexiert werden.
Andere besitzen Canonicals.
Andere sind per noindex gesteuert.
Eine pauschale Regel:
Disallow: /*?
kann deshalb viel zu aggressiv sein.
WordPress-Suchseiten gehören eher auf die Indexierungs- als auf die Crawling-Ebene
Interne Suchergebnisse einer Website sollen häufig nicht als eigenständige Suchmaschinen-Ergebnisse erscheinen.
WordPress besitzt dafür im Core eine wp_robots_noindex_search()-Funktion, die bei WordPress-Suchergebnissen noindex in die Robots-Direktiven einfügt. (WordPress Developer Resources)
Das ist konzeptionell sinnvoll:
Die Suchseite kann weiterhin gecrawlt werden.
Die Indexierungsregel sagt aber:
Diese Seite soll nicht als Suchergebnis aufgenommen werden.
Damit ist das ein gutes Beispiel für die richtige Trennung von Crawling und Indexierung.
Eine robots.txt kann andere Crawler anders behandeln
Nicht jeder Crawler ist Googlebot.
Die Datei kann unterschiedliche Gruppen enthalten:
User-agent: Bot-A
Disallow: /
User-agent: *
Allow: /
Damit kann ein bestimmter Bot anders behandelt werden als andere.
Google unterstützt diese gruppenbasierte Logik gemäß Robots Exclusion Protocol und verwendet die spezifischste passende User-Agent-Gruppe. (Google for Developers)
In der Praxis sollte man trotzdem vorsichtig mit riesigen Bot-Listen umgehen.
User-Agent-Bezeichnungen können sich ändern, und nicht jeder aggressive Bot hält sich überhaupt an robots.txt.
Ein bösartiger Bot muss robots.txt nicht beachten
Das Robots Exclusion Protocol lebt davon, dass der Crawler die Regeln freiwillig respektiert.
Ein Scraper oder Angreifer kann die Datei einfach ignorieren.
Deshalb ist robots.txt kein Sicherheitsmechanismus gegen:
Scraping,
Brute Force,
Spam,
Angriffe.
Dafür braucht es technische Schutzmaßnahmen wie Rate Limiting, Firewallregeln, Authentifizierung oder andere Sicherheitsmechanismen.
robots.txt ist für kooperative Crawler gedacht.
Googlebot-User-Agents können gefälscht werden
Wenn im Serverlog ein Request mit:
Googlebot
auftaucht, beweist dieser Text allein nicht, dass die Anfrage wirklich von Google stammt.
Google weist ausdrücklich darauf hin, dass User-Agent-Angaben gefälscht werden können und empfiehlt bei Bedarf eine Überprüfung über Reverse DNS beziehungsweise die veröffentlichten Googlebot-IP-Bereiche. (Google for Developers)
Das ist besonders wichtig, wenn ein vermeintlicher „Googlebot“ massenhaft ungewöhnliche Requests erzeugt.
Nicht sofort die Suchmaschine beschuldigen.
Zuerst prüfen, ob es tatsächlich Google ist.
Kann robots.txt die Crawl-Last reduzieren?
Ja, genau dafür kann sie eingesetzt werden.
Google nennt das Management des Crawlertraffics als Hauptzweck der robots.txt. (Google for Developers)
Auf sehr großen Websites kann es sinnvoll sein, wertlose oder endlos erzeugte URL-Bereiche vom Crawling auszunehmen.
Beispiele können sein:
bestimmte Filterkombinationen,
technische Ergebnislisten,
unendliche Kalenderstrukturen,
automatisch erzeugte URL-Varianten.
Die Voraussetzung ist allerdings, dass man vorher verstanden hat, welche Inhalte dadurch für Google nicht mehr abrufbar sind.
Crawl Budget ist bei kleinen Websites selten das erste SEO-Problem
Eine Website mit 80 Artikeln muss normalerweise nicht anfangen, jeden einzelnen Googlebot-Aufruf strategisch zu rationieren.
Wenn wichtige Seiten schlecht indexiert werden, liegen häufig wesentlich grundlegendere Fragen näher:
Sind die Seiten intern verlinkt?
Sind sie technisch erreichbar?
Besitzen sie noindex?
Sind Canonicals korrekt?
Sind die Inhalte eigenständig?
Ist die Sitemap sauber?
Eine komplizierte robots.txt ist für einen kleinen Wissensblog selten der entscheidende SEO-Hebel.
Eine minimalistische robots.txt ist häufig die beste robots.txt
Für eine normale WordPress-Wissenswebsite kann eine sehr überschaubare Datei völlig ausreichen.
WordPress selbst erzeugt bereits seine Standardregeln für /wp-admin/. (WordPress Developer Resources)
Je nach Sitemap-System kann zusätzlich ein Sitemap-Hinweis erscheinen.
Mehr braucht eine einfache öffentliche Website möglicherweise gar nicht.
Jede zusätzliche Regel sollte eine Frage beantworten können:
Welches konkrete Crawlingproblem löst sie?
Wenn darauf keine klare Antwort existiert, braucht man die Regel wahrscheinlich nicht.
Mehr robots.txt-Regeln bedeuten nicht mehr SEO
Das ist ein typisches Muster technischer Optimierung.
Eine Datei mit:
3 Zeilen
wirkt simpel.
Eine Datei mit:
137 Zeilen
wirkt professionell.
Das sagt nichts über ihre Qualität aus.
Eine lange robots.txt kann notwendig sein.
Sie kann aber ebenso das Ergebnis jahrelanger SEO-Experimente, Pluginreste und kopierter Internetregeln sein.
Technik wird nicht besser, nur weil sie komplizierter aussieht.
Regeln aus fremden Websites sollte man nicht kopieren
Du öffnest die robots.txt eines riesigen internationalen Shops.
Dort stehen fünfzig Disallow-Regeln.
Dann kopierst du sie in einen WordPress-Blog.
Das kann katastrophal enden.
Der Shop besitzt völlig andere:
URL-Strukturen,
Filter,
Anwendungen,
Crawlerprobleme.
Eine robots.txt ist Teil der konkreten Websitearchitektur.
Sie sollte nicht als allgemeine SEO-Vorlage betrachtet werden.
Besonders gefährlich sind Regeln aus alten SEO-Tutorials
Suchmaschinen und CMS entwickeln sich weiter.
So verwendet WordPress beispielsweise seit Jahren nicht mehr einfach Disallow: / als Standardreaktion auf die Einstellung „Suchmaschinen davon abhalten“, sondern setzt entsprechende Robots-Meta-Direktiven. (WordPress.org)
Google wiederum dokumentiert aktuelle robots.txt-Unterstützung und nicht unterstützte Felder ausdrücklich. (Google for Developers)
Eine zehn Jahre alte robots.txt-Anleitung kann deshalb technisch nachvollziehbar sein und trotzdem nicht mehr den heutigen Stand widerspiegeln.
Wie behandelt Google eine fehlende robots.txt?
Wenn keine robots.txt vorhanden ist beziehungsweise Google bei normalen 4xx-Antworten außer 429 keine gültige Datei erhält, behandelt Google das grundsätzlich so, als gäbe es keine Crawlingbeschränkung. (Google for Developers)
Das bedeutet:
Eine Website braucht nicht zwingend eine robots.txt, um von Google gecrawlt werden zu können.
Die Datei ist ein Steuerungsinstrument.
Keine Voraussetzung für Suchmaschinenzugriff.
Serverfehler bei robots.txt sind dagegen kritischer
Interessant wird es, wenn Google die robots.txt wegen eines Serverfehlers nicht abrufen kann.
Bei 5xx-Fehlern stoppt Google nach aktueller Dokumentation zunächst das Crawling für einen Zeitraum und versucht weiterhin, die robots.txt abzurufen. Existiert eine ältere gültige gecachte Version, kann diese für längere Zeit weiterverwendet werden. (Google for Developers)
Eine kaputte /robots.txt, die ständig Serverfehler erzeugt, ist deshalb keine Kleinigkeit.
Sie kann das Crawling der gesamten Website beeinflussen.
robots.txt wird von Google gecacht
Google gibt an, die robots.txt normalerweise bis zu etwa 24 Stunden zu cachen. Bei Problemen mit dem erneuten Abruf kann die alte Version länger verwendet werden. (Google for Developers)
Damit erklärt sich ein typischer Effekt:
Du änderst die Datei.
Google reagiert nicht zwangsläufig innerhalb derselben Sekunde.
Die Änderung muss erst erneut abgerufen und verarbeitet werden.
Das ist bei Fehlerbehebungen wichtig zu berücksichtigen.
Die robots.txt muss selbst erreichbar bleiben
Eine absurde, aber technisch denkbare Konfiguration wäre, den Zugriff auf die robots.txt durch zusätzliche Servermechanismen zu blockieren.
Crawler müssen die Datei jedoch abrufen können, um die Regeln zu kennen.
Deshalb sollte:
/robots.txt
öffentlich und zuverlässig erreichbar sein.
Das bedeutet wiederum nicht, dass sie sensible Informationen enthalten sollte.
Jeder kann sie ansehen.
robots.txt kann Informationen über die Website verraten
Stell dir folgende Datei vor:
User-agent: *
Disallow: /geheimer-admin/
Disallow: /kunden-backups/
Disallow: /interne-dokumente/
Disallow: /nicht-oeffentliche-vertraege/
Für einen Angreifer ist das fast eine kleine Schatzkarte.
Genau deshalb warnt Google davor, robots.txt als Schutz privater Bereiche zu verwenden; die Datei selbst ist öffentlich. (Google for Developers)
Wenn ein Ordner wirklich geheim bleiben soll, braucht er technischen Zugangsschutz.
Die Tatsache, dass sein Pfad nicht in robots.txt steht, ist allerdings ebenso wenig ein Sicherheitskonzept.
Sollte man /wp-login.php in robots.txt sperren?
Für SEO bringt es normalerweise wenig.
Crawler brauchen die Loginseite nicht als Suchergebnis.
Aber eine robots.txt-Regel verhindert weder Bot-Angriffe noch Loginversuche.
Ein bösartiger Bot kann die Regel ignorieren und /wp-login.php direkt aufrufen.
Wenn der Zweck lautet:
WordPress-Login schützen, dann sind andere Maßnahmen zuständig.
Wenn der Zweck lautet:
Crawlerressourcen sparen, sollte zunächst geprüft werden, ob überhaupt ein reales Crawlingproblem besteht.
Die Regel sollte immer aus dem tatsächlichen Problem entstehen.
Sollte man /wp-content/ sperren?
Pauschal normalerweise nicht.
In /wp-content/ liegen typischerweise Themes, Plugins und Uploads.
Darunter können CSS-, JavaScript- und Bildressourcen liegen, die für das Rendering und Verständnis öffentlicher Seiten relevant sind.
Da Google für die Verarbeitung von Seiten benötigte Ressourcen crawlen können sollte, kann eine pauschale Sperre unnötige Probleme erzeugen. Googles eigene robots.txt-Dokumentation illustriert ausdrücklich, dass CSS- und JavaScript-Ressourcen trotz eines allgemeinen Verzeichnisblocks für Googlebot zugänglich gemacht werden können, damit Rendering funktioniert. (Google for Developers)
Auch hier gilt:
Nicht alte WordPress-SEO-Vorlagen blind übernehmen.
Sollte man /wp-includes/ sperren?
Auch dafür gibt es bei einer modernen normalen WordPress-Seite keine universelle Pflicht.
Entscheidend ist, ob öffentlich benötigte Ressourcen darin liegen und welche URLs Google tatsächlich crawlt.
Eine Blockliste mit sämtlichen technischen WordPress-Verzeichnissen erzeugt nicht automatisch bessere SEO.
Suchmaschinen müssen nicht vor der Tatsache geschützt werden, dass die Website WordPress verwendet.
Sollte man interne Suchergebnisse per robots.txt sperren?
Das hängt von der Strategie ab, aber robots.txt ist nicht automatisch das beste Werkzeug.
Wenn die Suchergebnisse nicht im Google-Index erscheinen sollen, ist eine Indexierungsregel konzeptionell passender. WordPress Core unterstützt für interne Suchergebnisse bereits noindex über seine Robots-Meta-Infrastruktur. (WordPress Developer Resources)
Bei sehr großen Websites kann zusätzlich die Crawl-Last solcher Seiten relevant werden.
Dann muss aber bewusst zwischen:
nicht crawlen
und
nicht indexieren
unterschieden werden.
Sollte man Tag- und Kategoriearchive in robots.txt sperren?
Nein, nicht pauschal.
Eine gut aufgebaute Kategorie kann eine wertvolle Hub-Seite sein.
Ein belangloses Tagarchiv soll vielleicht nicht indexiert werden.
Das sind Entscheidungen der Informationsarchitektur und Indexierungsstrategie.
robots.txt wäre erst dann das richtige Werkzeug, wenn es tatsächlich um Crawlingzugriff geht.
Für Casiopeya sollen zentrale Themencontainer sogar ausdrücklich crawl- und indexierbar sein, weil sie den Wissensbereich strukturieren.
robots.txt sollte zur Sitemap passen
Nehmen wir an, die XML-Sitemap enthält:
/wissen/caching/
robots.txt blockiert gleichzeitig:
Disallow: /wissen/
Nun sagt die Website in einem System:
Diese Wissens-URL ist wichtig.
und im anderen:
Du darfst sie nicht abrufen.
Das ist offensichtlich widersprüchlich.
Eine saubere technische Architektur sollte deshalb regelmäßig prüfen, ob wichtige Sitemap-URLs überhaupt crawlbar sind.
Sitemap, interne Links, Canonical und robots.txt sollten möglichst dieselbe Seitenstrategie widerspiegeln.
robots.txt sollte auch zur internen Verlinkung passen
Wenn eine Seite von zahlreichen zentralen Wissensartikeln prominent verlinkt wird, aber gleichzeitig für Googlebot per robots.txt blockiert ist, sollte es dafür einen sehr guten Grund geben.
Andernfalls sendet die Website wieder widersprüchliche Signale.
Die interne Verlinkung sagt:
Das ist ein relevanter Teil unseres Wissensnetzes.
robots.txt sagt:
Diesen Inhalt darfst du nicht abrufen.
Technische SEO wird einfacher, wenn solche Konflikte vermieden werden.
So kann eine typische einfache WordPress-robots.txt aussehen
Für eine normale öffentliche WordPress-Installation kann eine sehr schlichte Struktur beispielsweise in diese Richtung gehen:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.de/wp-sitemap.xml
Die ersten drei Zeilen entsprechen der aktuellen WordPress-Core-Logik für den Administrationsbereich. WordPress stellt standardmäßig einen Sitemap-Index unter /wp-sitemap.xml bereit, sofern das Core-Sitemap-System aktiv ist. (WordPress Developer Resources)
Ob tatsächlich genau diese Sitemap-URL verwendet wird, hängt allerdings davon ab, ob beispielsweise ein SEO-Plugin ein eigenes Sitemap-System bereitstellt.
Deshalb sollte die reale Website kontrolliert und nicht eine Vorlage blind kopiert werden.
Wenn ein SEO-Plugin eine andere Sitemap erzeugt
Angenommen, das Plugin verwendet:
https://example.de/sitemap_index.xml
Dann sollte die robots.txt natürlich diese tatsächliche Sitemap nennen, wenn dort ein Sitemap-Hinweis verwendet wird.
Es ist wenig sinnvoll, parallel auf eine alte oder deaktivierte Sitemap zu verweisen.
Die Prüfung ist einfach:
Sitemap-Adresse im Browser öffnen.
Funktioniert sie?
Enthält sie die gewünschten URL-Gruppen?
Dann kann sie entsprechend referenziert werden.
Wie prüfe ich meine robots.txt praktisch?
Die wichtigste Prüfung braucht kein Spezialwerkzeug.
Rufe auf:
https://deine-domain.de/robots.txt
und lies die Datei.
Frage anschließend:
Steht dort Disallow: /?
Sind wichtige Bereiche blockiert?
Sind CSS-, JavaScript- oder Upload-Verzeichnisse pauschal gesperrt?
Ist eine Sitemap eingetragen und erreichbar?
Gibt es Regeln aus alten Plugins oder früheren Websiteversionen?
Stimmt die Datei überhaupt mit der aktuellen Seitenarchitektur überein?
Bereits diese manuelle Kontrolle entdeckt viele Probleme.
Danach sollte eine konkrete URL geprüft werden
Eine robots.txt lässt sich nicht sinnvoll beurteilen, indem man nur die Datei betrachtet.
Man braucht eine Frage wie:
Darf Googlebot
/wissen/caching/crawlen?
Dann werden die relevanten User-Agent- und Pfadregeln auf genau diese URL angewendet.
Gerade bei Wildcards und mehreren Allow-/Disallow-Regeln kann das Ergebnis anders sein als erwartet, weil Google jeweils die spezifischste passende Regel verwendet. (Google for Developers)
Das ist die richtige Denkweise:
Regeln nicht abstrakt lesen – reale URLs testen.
Die URL-Prüfung in Search Console ergänzt die Diagnose
Für einzelne Seiten kann die Google Search Console helfen, Crawling- und Indexierungsprobleme zu untersuchen.
Wenn Google eine wichtige Seite wegen robots.txt nicht abrufen kann, ist das für die technische Diagnose relevant.
Gleichzeitig muss immer geprüft werden, ob die robots.txt wirklich die Ursache oder lediglich ein sichtbares Symptom einer bewusst gewählten Strategie ist.
Nicht jede blockierte URL ist ein Fehler.
Nur jede unbeabsichtigt blockierte wichtige URL ist problematisch.
Nach Änderungen sollte nicht hektisch alles andere umgebaut werden
Angenommen, wir entdecken:
Disallow: /wissen/
obwohl der komplette Wissensbereich indexiert werden soll.
Dann entfernen wir die falsche Regel.
Danach sollte der Suchmaschine Zeit gegeben werden, die robots.txt erneut abzurufen. Google cached die Datei üblicherweise und aktualisiert sie nicht zwingend in Echtzeit. (Google for Developers)
Es wäre wenig sinnvoll, gleichzeitig:
Canonicals ändern,
Sitemap umbauen,
Permalinks ändern
und Texte neu schreiben.
Eine Ursache nach der anderen.
Genau denselben Ansatz verwenden wir auch bei Performanceproblemen.
robots.txt-Fehler können siteweit wirken
Eine falsche Meta-Description betrifft vielleicht eine Seite.
Eine falsche robots.txt-Regel kann einen kompletten Ordner oder sogar die gesamte Website betreffen.
Das macht Änderungen an dieser Datei vergleichsweise riskant.
Vor allem:
Disallow: /
sollte auf einer produktiven öffentlichen Website sofort Aufmerksamkeit auslösen, sofern die Vollsperre nicht ausdrücklich beabsichtigt ist. (Google for Developers)
Je größer eine Website, desto sinnvoller sind Tests und dokumentierte Änderungen.
Bei einem Relaunch gehört robots.txt auf die Checkliste
Vor dem Livegang sollte kontrolliert werden:
Welche robots.txt wird auf der neuen Domain ausgeliefert?
Existieren alte Staging-Sperren?
Ist WordPress weiterhin auf „Suchmaschinen abhalten“ gestellt?
Ist die richtige Sitemap angegeben?
Sind öffentliche Ressourcen erreichbar?
Sind alte technische Verzeichnisse unnötig blockiert?
Besonders wichtig ist die WordPress-Sichtbarkeitseinstellung, da WordPress bei nicht öffentlicher Konfiguration entsprechende noindex-Direktiven erzeugen kann. (WordPress Developer Resources)
Das ist eine kleine Prüfung mit potenziell großer Wirkung.
Bei einem Domainumzug gelten wieder eigene robots.txt-Dateien
Die neue Domain besitzt ihren eigenen Host und damit ihren eigenen robots.txt-Geltungsbereich. (Google for Developers)
Bei einem Umzug sollte die neue Website Googlebot natürlich nicht versehentlich blockieren.
Die alte Domain wiederum muss für die notwendigen Weiterleitungen erreichbar bleiben.
Ein häufiger Fehler wäre, die komplette alte Domain über robots.txt zu sperren und gleichzeitig zu erwarten, dass Google sämtliche Umzugsinformationen problemlos verarbeitet.
Weiterleitungen gehören später in unseren eigenen Artikel zu 301-Weiterleitungen.
robots.txt ist kein Ersatz für 404 oder 410
Wenn eine Seite dauerhaft gelöscht wurde, braucht sie nicht einfach in robots.txt blockiert zu werden.
Damit verhindert man lediglich den Abruf.
Die Suchmaschine erhält dadurch nicht die klare Serverinformation:
Diese Ressource existiert nicht mehr.
Für tatsächlich entfernte Inhalte sind korrekte HTTP-Statuscodes beziehungsweise gegebenenfalls passende Weiterleitungen die sinnvolleren Werkzeuge.
Jede Ebene sollte ihre eigene Information liefern.
robots.txt ist kein Ersatz für Canonical
Bei doppelten Seitenvarianten geht es meist nicht darum, Google blind am Crawling zu hindern.
Es geht darum, eine bevorzugte URL festzulegen beziehungsweise unnötige Varianten strukturell zu vermeiden.
Dafür existieren Canonical-Signale und Weiterleitungen.
Wer eine Dublette lediglich in robots.txt sperrt, verhindert gegebenenfalls sogar, dass Google die dort vorhandenen Seitensignale vollständig sieht.
Auch dieses Problem behandeln wir deshalb getrennt.
robots.txt ist kein Ersatz für gute Informationsarchitektur
Eine Website mit tausenden nutzlosen URL-Varianten sollte nicht ausschließlich durch immer umfangreichere Disallow-Muster „repariert“ werden.
Vielleicht liegt die bessere Lösung tiefer:
Filter erzeugen zu viele URLs.
Interne Links führen auf Parameterseiten.
Plugins produzieren unnötige Archive.
Canonical-Signale sind inkonsistent.
Die Sitemap enthält falsche URLs.
robots.txt kann Symptome kontrollieren.
Sie ersetzt keine saubere URL- und Seitenarchitektur.
Eine gute robots.txt ist dokumentierbar
Bei einer professionell betriebenen Website sollte jede ungewöhnliche Sperre einen nachvollziehbaren Grund besitzen.
Beispiel:
# Endlose Kalendernavigation erzeugt unbegrenzt neue URLs
Disallow: /kalender/
Dann weiß ein Administrator zwei Jahre später noch:
Warum existiert diese Regel?
Ohne Dokumentation entsteht dagegen schnell das typische Szenario:
Keine Ahnung, warum das blockiert ist. Das stand schon immer so drin.
Solche historischen Regeln gehören zu den gefährlichsten technischen Altlasten.
Regeln sollten regelmäßig auf ihre Berechtigung geprüft werden
Eine Website entwickelt sich.
Ein früher unwichtiger Ordner kann später öffentliche Inhalte enthalten.
Ein Plugin verschwindet.
URL-Strukturen ändern sich.
Was 2022 sinnvoll blockiert wurde, kann 2026 längst irrelevant oder sogar schädlich sein.
robots.txt gehört deshalb bei größeren technischen Audits mit auf die Prüfliste.
Nicht weil sie ständig verändert werden sollte.
Sondern weil alte Regeln dauerhaft wirksam bleiben können.
Die Datei sollte so kurz wie möglich und so lang wie nötig sein
Das fasst die beste Strategie ziemlich gut zusammen.
Eine robots.txt sollte nicht zeigen, wie viel SEO-Wissen der Betreiber besitzt.
Sie sollte konkrete Crawlingprobleme lösen.
Eine einfache WordPress-Seite kann mit wenigen Zeilen auskommen.
Ein riesiger Shop braucht vielleicht deutlich komplexere Regeln.
Beides kann vollkommen richtig sein.
Komplexität ist keine Qualitätsmetrik.
Was du dir über robots.txt merken solltest
Eine robots.txt steuert, welche URLs bestimmte kooperative Crawler abrufen dürfen. Google beschreibt sie primär als Werkzeug zur Verwaltung des Crawlingzugriffs und der Crawlerlast. (Google for Developers)
Sie liegt im Stamm des jeweiligen Hosts unter:
/robots.txt
und gilt nur für den entsprechenden Host, das Protokoll und den Port. (Google for Developers)
User-agent bestimmt, für welchen Crawler eine Regelgruppe gilt.
Disallow sperrt Pfade.
Allow kann gezielte Ausnahmen ermöglichen.
Sitemap nennt eine oder mehrere Sitemap-Adressen. (Google for Developers)
Google unterstützt außerdem * und $ für bestimmte Pfadmuster; crawl-delay wird von Google dagegen nicht als robots.txt-Feld unterstützt. (Google for Developers)
WordPress erzeugt standardmäßig eine virtuelle robots.txt, in der /wp-admin/ gesperrt und /wp-admin/admin-ajax.php erlaubt wird. Die Ausgabe kann über WordPress-Filter verändert werden. (WordPress Developer Resources)
Vor allem aber gilt:
robots.txt
= Crawling steuern
und:
noindex
= Indexierung verhindern
Wer eine URL in robots.txt blockiert, verhindert damit nicht zuverlässig, dass die Adresse jemals in Google auftaucht. Und wer gleichzeitig Disallow und noindex einsetzt, kann verhindern, dass Google das noindex überhaupt sieht. (Google for Developers)
Die wichtigste Regel ist deshalb nicht irgendeine bestimmte Zeile.
Sie lautet:
Bevor du eine URL per robots.txt sperrst, musst du wissen, warum Google sie nicht crawlen soll.
Wenn die eigentliche Antwort lautet:
Weil sie nicht in den Suchergebnissen erscheinen soll,
dann beschäftigen wir uns bereits mit dem nächsten Thema.