Robots.txt: Alles, was du für SEO wissen musst

Was die robots.txt wirklich steuert

Die robots.txt ist eine einfache Textdatei im Wurzelverzeichnis einer Domain, die Suchmaschinen-Crawlern mitteilt, welche Bereiche sie aufrufen dürfen und welche nicht. Sie liegt immer unter einer festen Adresse wie example.de/robots.txt und ist die allererste Datei, die ein Bot wie der Googlebot abruft, bevor er auch nur eine einzige andere URL besucht. Wer hier einen Fehler einbaut, beeinflusst damit das gesamte Crawling-Verhalten für die komplette Domain – oft ohne es sofort zu merken.

Ein häufiges Missverständnis vorweg: Die robots.txt steuert das Crawlen, nicht das Indexieren. Eine per Disallow gesperrte URL kann trotzdem im Google-Index landen, wenn sie von außen verlinkt wird. Google zeigt sie dann ohne Snippet mit dem Hinweis an, dass keine Informationen verfügbar seien. Wer eine Seite wirklich aus dem Index halten möchte, braucht stattdessen ein noindex-Meta-Tag – und damit muss die Seite ironischerweise crawlbar bleiben, sonst sieht Google das noindex nie.

In der Praxis nutzt man die robots.txt vor allem, um Ressourcen zu sparen und Crawler von unwichtigen oder doppelten Bereichen fernzuhalten. Typische Kandidaten sind interne Suchergebnisseiten, Filter- und Sortier-URLs mit endlosen Parameterkombinationen, Warenkorb- und Checkout-Pfade oder Admin-Bereiche. Ein Onlineshop mit 5.000 Produkten kann durch Filterparameter schnell auf mehrere Hunderttausend crawlbare URL-Varianten kommen – hier trennt die robots.txt Spreu vom Weizen.

Wichtig ist außerdem das Grundprinzip der Freiwilligkeit: Die robots.txt ist eine Bitte, kein technischer Riegel. Seriöse Crawler wie Googlebot oder Bingbot halten sich daran, viele aggressive Scraper und Bots ignorieren die Datei jedoch komplett. Wer sensible Inhalte schützen will, kommt um eine echte Zugriffskontrolle per Passwort oder Serverkonfiguration nicht herum – die robots.txt ist dafür das falsche Werkzeug.

Die Syntax im Detail – Direktiven richtig schreiben

Eine robots.txt besteht aus Blöcken, die jeweils mit einer User-agent-Zeile beginnen. Diese legt fest, für welchen Crawler die folgenden Regeln gelten. Ein Stern als Wert (User-agent: *) adressiert alle Bots, während ein konkreter Name wie User-agent: Googlebot nur diesen einen Crawler anspricht. Unter jeder User-agent-Zeile folgen die eigentlichen Anweisungen, meist Disallow und Allow, jeweils gefolgt von einem Pfad.

Ein einfaches Beispiel: User-agent: * / Disallow: /warenkorb/ / Allow: /warenkorb/info/. Hier wird der gesamte Warenkorb-Ordner gesperrt, eine einzelne Unterseite aber wieder freigegeben. Google wertet bei Konflikten grundsätzlich die spezifischere, also längere Regel aus – nicht die Reihenfolge im Dokument. Eine Allow-Regel mit längerem Pfad schlägt also eine kürzere Disallow-Regel, was gezielte Ausnahmen erst möglich macht. Diese Logik überrascht viele, die ein zeilenweises Abarbeiten erwarten.

Für komplexere Muster stehen zwei Wildcards bereit: Der Stern (*) steht für eine beliebige Zeichenkette, das Dollarzeichen ($) markiert das Ende einer URL. So sperrt Disallow: /*? alle URLs mit Parametern, während Disallow: /*.pdf$ ausschließlich Adressen ausschließt, die exakt auf .pdf enden. Diese Mustererkennung ist mächtig, aber auch fehleranfällig – ein vergessenes Dollarzeichen kann ungewollt ganze URL-Gruppen erfassen, weil der Stern am Zeilenende implizit weiterwirkt.

Ergänzend gehört in jede robots.txt ein Verweis auf die XML-Sitemap, etwa Sitemap: https://example.de/sitemap.xml. Diese Zeile steht unabhängig von den User-agent-Blöcken und darf mehrfach vorkommen. Sie hilft Crawlern, alle wichtigen URLs schnell zu finden, und ist gerade bei großen oder schlecht intern verlinkten Seiten ein sinnvoller Wegweiser. Die früher übliche Crawl-delay-Direktive ignoriert Google dagegen vollständig; die Crawl-Geschwindigkeit regelt der Konzern intern über eigene Mechanismen.

Crawl-Steuerung in der Praxis

Kurz gesagt: Gute Crawl-Steuerung bedeutet, Suchmaschinen genau dorthin zu lenken, wo wertvolle, indexierbare Inhalte liegen – und sie von technischem Ballast fernzuhalten. Bei kleinen Websites mit ein paar Hundert Seiten ist das selten ein Thema, weil Google ohnehin alles problemlos erfasst. Ab einigen Tausend URLs aufwärts wird es jedoch relevant, weil dann die Effizienz des Crawlings über die Aktualität des Index entscheidet.

Ein konkretes Szenario: Ein Magazin mit 40.000 Artikeln erzeugt zusätzlich Tag-Seiten, Autorenarchive, Druckansichten und Paginierungsketten, sodass die Gesamtzahl crawlbarer URLs leicht auf das Drei- bis Vierfache steigt. Wenn der Googlebot einen großen Teil seines Budgets in diese Nebenpfade investiert, dauert es länger, bis neue Artikel entdeckt und aktualisierte Inhalte neu bewertet werden. Per robots.txt lassen sich solche Nebenpfade gezielt aussperren, etwa Druckansichten über Disallow: /*?print=.

Vorsicht ist bei CSS- und JavaScript-Dateien geboten. In den frühen Jahren sperrten viele Betreiber pauschal Ordner wie /assets/ oder /wp-includes/, um Crawler vermeintlich zu entlasten. Heute rendert Google Seiten jedoch wie ein echter Browser und braucht diese Ressourcen, um Layout und Inhalte korrekt zu erfassen. Werden sie blockiert, kann Google die Seite falsch interpretieren, was Rankings kostet. Solche Dateien gehören also nie in ein Disallow.

Nach jeder Änderung sollte man die Wirkung prüfen, statt blind zu vertrauen. Die Google Search Console bietet dafür einen robots.txt-Bericht, der die ausgelieferte Datei anzeigt und einzelne URLs gegen die Regeln testet. So sieht man sofort, ob eine wichtige Seite versehentlich gesperrt ist. Ein kurzer Test vor dem Livegang einer neuen Regel verhindert die meisten der teuren Unfälle, die sonst erst Wochen später in fallenden Zugriffszahlen sichtbar werden.

Typische Fehler und wie man sie vermeidet

Der folgenschwerste Fehler ist eine versehentliche Komplettsperre: Disallow: / unter User-agent: * blockiert die gesamte Website für alle Crawler. Genau diese Zeile steht oft in Staging- oder Entwicklungsumgebungen, um die Testseite vor dem Index zu schützen – und wandert beim Livegang versehentlich mit auf die Produktivseite. Wenige Tage später bricht die Sichtbarkeit ein, weil Google alle Seiten aus dem Index entfernt. Ein fester Punkt auf jeder Launch-Checkliste sollte daher die Kontrolle der robots.txt sein.

Ein zweiter Klassiker ist der Versuch, mit der robots.txt etwas aus dem Index zu entfernen. Wie eingangs erklärt, verhindert ein Disallow nur das Crawlen, nicht die Indexierung verlinkter URLs. Sperrt man eine bereits indexierte Seite zusätzlich, kann Google das noindex-Tag auf dieser Seite nicht mehr lesen – die Seite bleibt im Index hängen. Der richtige Weg lautet: erst die Seite crawlbar lassen, das noindex greifen lassen, und erst nach der De-Indexierung gegebenenfalls per robots.txt sperren.

Auch falsch gesetzte Wildcards und Groß-/Kleinschreibung sorgen regelmäßig für Ärger. Pfade in der robots.txt sind case-sensitive: Disallow: /Produkte/ sperrt nicht /produkte/. Ebenso erfasst Disallow: /suche ohne abschließendes Zeichen auch /suchergebnisse, weil es als Präfix wirkt. Wer nur einen Ordner meint, sollte mit Slash arbeiten, wer eine exakte URL meint, mit dem Dollarzeichen. Solche Feinheiten entscheiden darüber, ob eine Regel zu viel oder zu wenig erfasst.

Schließlich wird die Erreichbarkeit der Datei selbst unterschätzt. Liefert der Server bei /robots.txt einen 500er-Fehler statt eines klaren 200 oder 404, interpretieren manche Crawler das als generelles Crawling-Verbot und stellen das Crawlen vorübergehend ein. Die robots.txt muss schnell und stabil ausgeliefert werden, sauberes UTF-8 ohne BOM enthalten und unter genau einer kanonischen Adresse erreichbar sein. Redirect-Ketten oder eine in einem Unterordner abgelegte Datei funktionieren nicht zuverlässig.

robots.txt, Crawl-Budget und interne Verlinkung

Das Crawl-Budget beschreibt, wie viele URLs eine Suchmaschine in einem bestimmten Zeitraum auf einer Domain abruft. Es ergibt sich grob aus der Crawl-Kapazität, die der Server verträgt, und dem Crawl-Bedarf, den Google anhand von Wichtigkeit und Aktualität der Seiten einschätzt. Die robots.txt ist eines der wenigen direkten Werkzeuge, mit denen Betreiber dieses Budget aktiv beeinflussen können – indem sie unwichtige Bereiche aussperren und so Kapazität für relevante Seiten freimachen.

Hier greift das Zusammenspiel mit der internen Verlinkung. Crawler folgen Links, um neue URLs zu entdecken und die Bedeutung einzelner Seiten über den internen Linkfluss – eine Art interner PageRank – einzuschätzen. Sperrt man per robots.txt einen Bereich, in den viele interne Links zeigen, verpufft die dort gebündelte Linkkraft teilweise, weil der Crawler dem Pfad nicht mehr folgt. Umgekehrt entstehen verwaiste Seiten, wenn wichtige Inhalte nur über gesperrte Pfade erreichbar sind und sonst nirgends verlinkt werden.

Ein durchdachtes Setup behandelt robots.txt und interne Links deshalb als zwei Seiten derselben Medaille. Bevor man einen Bereich sperrt, sollte man prüfen, welche Links dorthin und von dort weg führen und ob dadurch indexierbare Seiten ihre Anbindung verlieren. Genau an dieser Stelle hilft LinkJuice: Das Tool analysiert die interne Verlinkung aus einem Screaming-Frog-Crawl direkt im Browser, berechnet den internen PageRank und deckt verwaiste Seiten, Weiterleitungsketten und problematische Ankertexte auf – ohne dass Daten hochgeladen werden müssen.

So lässt sich vor jeder robots.txt-Änderung abschätzen, welche Seiten von einer Sperre real betroffen wären und wo Linkkraft verloren ginge. Statt einer isolierten Disallow-Regel entsteht eine fundierte Entscheidung: Crawl-Budget für die wertvollen URLs sichern, gleichzeitig aber sicherstellen, dass diese Seiten intern stark verlinkt und für den Crawler ohne Umweg erreichbar bleiben. Beide Hebel zusammen entfalten deutlich mehr Wirkung als jeder für sich.

Eine saubere robots.txt aufbauen und pflegen

Eine gute robots.txt ist kurz, eindeutig und nachvollziehbar dokumentiert. In der Praxis hat sich ein schlanker Aufbau bewährt, der mit einem allgemeinen Block für alle Crawler beginnt, dann die wenigen wirklich nötigen Sperren auflistet und mit einem Sitemap-Verweis endet. Wer Dutzende Disallow-Zeilen sammelt, sollte misstrauisch werden – meist lassen sich viele davon durch ein sauberes URL-Konzept oder Parameter-Handling ersetzen.

• Klare Struktur: Ein Block je relevantem User-agent, sprechende Kommentare mit Raute (#) zur Begründung jeder Sperre, ein Sitemap-Eintrag am Ende und keine Direktiven, die der Zielcrawler ohnehin ignoriert.

Genauso wichtig wie das Erstellen ist die laufende Pflege. Websites wachsen, CMS-Updates erzeugen neue URL-Muster, und Relaunches ändern Pfadstrukturen – jede dieser Veränderungen kann eine bestehende Regel ins Leere laufen lassen oder neue Lücken öffnen. Es lohnt sich, die robots.txt in regelmäßige technische Audits aufzunehmen und sie als Teil des Deployment-Prozesses zu versionieren, damit jede Änderung nachvollziehbar bleibt und im Zweifel zurückgerollt werden kann.

Besondere Aufmerksamkeit verdient der Übergang zwischen Umgebungen. Staging-Server tragen sinnvollerweise ein hartes Disallow für alles, Produktivserver dagegen die freigebende Variante – diese beiden Dateien dürfen niemals verwechselt werden. Eine bewährte Praxis ist, die robots.txt umgebungsabhängig zu generieren, statt sie als statische Datei mitzudeployen. So wird auf der Live-Domain technisch sichergestellt, dass dort nie versehentlich die Sperrvariante landet.

Abschließend gilt: Die robots.txt ist ein kleines, aber kritisches Steuerinstrument. Sie ersetzt weder noindex-Tags noch eine durchdachte interne Verlinkung, entfaltet ihre Stärke aber genau im Zusammenspiel mit beiden. Wer sie bewusst einsetzt, das Crawl-Budget im Blick behält und die Folgen jeder Sperre für die interne Linkstruktur durchdenkt, holt aus dem Crawling spürbar mehr heraus – und vermeidet die teuren Unfälle, die aus einer einzigen falschen Zeile entstehen können.