Robots.txt: der komplette Guide mit Beispielen

Die robots.txt ist eine der unscheinbarsten und zugleich folgenreichsten Dateien deiner Website. Sie ist nur wenige Zeilen lang, entscheidet aber mit darüber, welche Bereiche Suchmaschinen abrufen dürfen und welche nicht. Eine einzige falsche Zeile kann eine ganze Domain aus dem Crawl nehmen, deshalb lohnt es sich, den Aufbau wirklich zu verstehen. Dieser Leitfaden erklärt dir Schritt für Schritt, wozu die Datei dient, wie du sie korrekt schreibst, und zeigt dir die häufigsten Fehler, die der Indexierung schaden.

Was ist die robots.txt und wozu dient sie?

Die robots.txt ist eine einfache Textdatei im Stammverzeichnis deiner Domain. Sie spricht den sogenannten Robots Exclusion Standard, ein seit den 1990er-Jahren etabliertes Protokoll, mit dem Websites Crawlern mitteilen, welche Pfade sie abrufen dürfen und welche sie besser meiden sollen. Wenn ein Bot wie der Googlebot deine Seite besucht, ruft er als Erstes diese Datei ab und richtet sein Verhalten danach aus.

Wichtig ist das Wort „abrufen“. Die robots.txt steuert das Crawling, also den Zugriff auf eine Ressource, nicht die Indexierung, also die Aufnahme in den Suchindex. Dieser Unterschied klingt nach Haarspalterei, ist aber die Ursache der meisten Probleme rund um die Datei. Wer ihn verinnerlicht, vermeidet die teuersten Fehler von vornherein.

Der wichtigste Anwendungsfall ist nicht, einzelne Seiten zu verstecken, sondern das Crawl-Budget sinnvoll zu lenken. Große Websites mit Tausenden von URLs profitieren davon, dass Suchmaschinen ihre begrenzte Zeit nicht in endlosen Filterseiten, internen Suchergebnissen oder Warenkorb-Seiten verschwenden, sondern in den Inhalten, die wirklich ranken sollen. Daneben dient die Datei dazu, ganze Entwicklungs- oder Staging-Umgebungen vor dem Crawling zu schützen und auf die Sitemap zu verweisen.

Zwei Dinge solltest du dir von Anfang an merken. Erstens ist die robots.txt keine Sicherheitsmaßnahme. Die Datei ist öffentlich einsehbar, jeder kann sie unter deinedomain.de/robots.txt aufrufen, und seriöse Bots halten sich freiwillig daran, während Schadbots sie schlicht ignorieren. Vertrauliche Inhalte gehören also niemals nur per Disallow geschützt, sondern hinter ein Login oder eine Server-Zugriffssteuerung. Zweitens ist die Datei kein Werkzeug, um Seiten zuverlässig aus Google zu entfernen, dazu gleich mehr.

Wo liegt die Datei und wie ist sie aufgebaut?

Der Ort ist nicht verhandelbar. Die robots.txt muss exakt im Wurzelverzeichnis der Domain liegen und ist nur dort gültig:

https://www.deinedomain.de/robots.txt

Eine Datei in einem Unterordner wie /blog/robots.txt wird komplett ignoriert. Außerdem gilt sie immer nur für genau den Host, unter dem sie liegt. Subdomains wie shop.deinedomain.de und unterschiedliche Protokolle wie http und https brauchen jeweils eine eigene Datei. Vergisst man das, kann eine sauber konfigurierte Hauptdomain neben einer völlig ungeschützten Subdomain stehen.

Der Aufbau ist denkbar einfach. Die Datei besteht aus einem oder mehreren Blöcken, die jeweils mit einer User-agent-Zeile beginnen und danach die Regeln für genau diesen Bot auflisten. Eine leere Zeile trennt die Blöcke. Kommentare leitest du mit dem Rautezeichen ein, sie werden von Crawlern ignoriert und dienen nur deiner eigenen Übersicht.

# Regeln für alle Bots
User-agent: *
Disallow: /warenkorb/
Disallow: /suche/

Sitemap: https://www.deinedomain.de/sitemap.xml

Dieses Minimalbeispiel deckt bereits den Alltag vieler Websites ab. Es spricht alle Bots an, sperrt zwei für die Suche wertlose Bereiche und weist den Weg zur Sitemap. Mehr braucht es für viele Projekte gar nicht.

Die wichtigsten Direktiven im Detail

Auch wenn der Standard mehrere Felder kennt, reichen vier Direktiven für die allermeisten Websites völlig aus. Sie zu beherrschen ist der Kern dieses Themas.

User-agent

Die User-agent-Zeile legt fest, für welchen Crawler der nachfolgende Block gilt. Das Sternchen ist eine Platzhalter-Angabe und steht für alle Bots, die keinen eigenen, spezifischeren Block haben.

User-agent: *

Du kannst Bots aber auch gezielt ansprechen, etwa wenn du für einen bestimmten Crawler abweichende Regeln brauchst:

User-agent: Googlebot
Disallow: /nur-fuer-andere-bots/

User-agent: Bingbot
Disallow: /

Hier ist eine Eigenheit entscheidend, die in der Praxis oft missverstanden wird: Jeder Bot befolgt nur einen Block, nämlich den am genauesten passenden. Findet der Googlebot einen eigenen Googlebot-Block, ignoriert er den allgemeinen Block mit dem Sternchen vollständig. Steht eine wichtige Regel nur im allgemeinen Block, gilt sie für den Googlebot dann eben nicht. Wer spezifische Blöcke anlegt, muss dort also alle relevanten Regeln wiederholen.

Disallow

Disallow ist das Herzstück der Datei. Es nennt einen Pfad, den der Bot nicht abrufen soll. Der Pfad wird immer ab dem Stammverzeichnis interpretiert und ist case-sensitive, Groß- und Kleinschreibung müssen also exakt zur tatsächlichen URL passen.

User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /danke.html

Ein paar Sonderfälle solltest du kennen. Ein leeres Disallow ohne Pfad bedeutet „nichts sperren“ und erlaubt damit alles. Ein einzelner Schrägstrich dagegen sperrt die komplette Domain, was nur für Staging-Umgebungen sinnvoll ist:

# Alles erlauben (leeres Disallow)
User-agent: *
Disallow:

# Alles sperren (Vorsicht!)
User-agent: *
Disallow: /

Diese beiden Zeilen unterscheiden sich nur durch einen einzigen Schrägstrich, ihre Wirkung ist aber gegensätzlich. Genau diese Verwechslung ist einer der häufigsten und teuersten Fehler überhaupt.

Allow

Die Allow-Direktive ist die Ausnahme zur Regel. Mit ihr kannst du innerhalb eines gesperrten Verzeichnisses einzelne Unterpfade wieder freigeben. Sie wird von Google und Bing unterstützt und ist immer dann nützlich, wenn ein ganzer Ordner gesperrt ist, eine bestimmte Datei darin aber trotzdem zugänglich bleiben soll.

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

Bei Konflikten zwischen Allow und Disallow gewinnt bei Google die spezifischere, also die längere Regel. Da admin-ajax.php der längere und genauere Pfad ist, bleibt diese Datei im Beispiel erreichbar, obwohl der übergeordnete Ordner gesperrt ist.

Sitemap

Die Sitemap-Direktive verweist auf den vollständigen Pfad deiner XML-Sitemap und hilft Suchmaschinen, alle wichtigen URLs zu finden. Sie ist an keinen User-agent-Block gebunden und steht üblicherweise ganz oben oder ganz unten in der Datei. Die Angabe muss immer eine absolute URL inklusive Protokoll sein.

Sitemap: https://www.deinedomain.de/sitemap.xml
Sitemap: https://www.deinedomain.de/sitemap-news.xml

Du kannst mehrere Sitemaps angeben, etwa für Beiträge, Produkte und Bilder getrennt. Wie du eine saubere Sitemap aufbaust und einreichst, vertiefen wir im eigenen Guide zur Sitemap. Die beiden Dateien arbeiten Hand in Hand: Die robots.txt regelt, was nicht gecrawlt werden soll, die Sitemap zeigt aktiv, was unbedingt gecrawlt werden soll.

Wildcards und Zeilenende

Google und die meisten großen Suchmaschinen unterstützen zwei Sonderzeichen für die Mustererkennung. Das Sternchen steht für eine beliebige Zeichenfolge, das Dollarzeichen markiert das Ende einer URL. Damit lassen sich Parameter und Dateitypen elegant abfangen.

User-agent: *
# Alle URLs mit einem ?-Parameter sperren
Disallow: /*?
# Alle PDF-Dateien sperren
Disallow: /*.pdf$

Solche Muster sind mächtig, aber auch riskant. Ein zu breit gefasstes Sternchen kann unbeabsichtigt viel mehr sperren als gedacht, deshalb solltest du jedes Muster vor dem Veröffentlichen testen.

Typische Praxisbeispiele

Theorie ist gut, aber am schnellsten lernt man an fertigen Vorlagen. Hier sind drei realistische Konstellationen, die du an deine eigene Domain anpassen kannst.

Eine schlanke Standardkonfiguration für eine normale Unternehmens- oder Content-Website sieht so aus:

User-agent: *
Disallow: /warenkorb/
Disallow: /kasse/
Disallow: /suche/
Disallow: /*?

Sitemap: https://www.deinedomain.de/sitemap.xml

Eine typische WordPress-Konfiguration sperrt den Administrationsbereich, lässt aber die für das Frontend nötige Ajax-Datei zu:

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

Sitemap: https://www.deinedomain.de/sitemap_index.xml

Und so sieht eine Staging-Umgebung aus, die komplett vor allen Crawlern verborgen werden soll. Diese Variante gehört ausschließlich auf die Testumgebung und niemals auf die Live-Seite:

User-agent: *
Disallow: /

Die letzte Vorlage führt direkt zum gefährlichsten Fehler überhaupt, dem wir uns jetzt widmen.

Häufige Fehler, die die Indexierung blockieren

Die meisten Schäden durch robots.txt entstehen nicht durch fehlendes Wissen, sondern durch Flüchtigkeit. Ein vergessener Schrägstrich, eine aus der Testumgebung übernommene Datei oder ein falsch verstandenes Disallow reichen aus, um wochenlang Sichtbarkeit zu verlieren. Die folgende Tabelle fasst die Klassiker zusammen.

Fehler	Auswirkung	Lösung
Disallow: / aus dem Staging übernommen	Die gesamte Domain wird vom Crawling ausgeschlossen, Rankings brechen ein	Vor dem Livegang prüfen und auf ein leeres Disallow: umstellen
Disallow zum „Entfernen“ aus dem Index genutzt	Die Seite bleibt indexiert, weil Google den noindex-Tag nicht mehr lesen kann	Seite crawlbar lassen und stattdessen noindex setzen
Falsche Groß- und Kleinschreibung im Pfad	Disallow: /Admin/ sperrt /admin/ nicht, der Bereich bleibt offen	Pfade exakt an die echte URL anpassen
Datei liegt nicht im Stammverzeichnis	Die robots.txt wird komplett ignoriert	Datei nach deinedomain.de/robots.txt verschieben
CSS- oder JS-Ordner gesperrt	Google kann die Seite nicht korrekt rendern, das schadet der Bewertung	Ressourcen für das Rendering freigeben
Sitemap-Pfad relativ angegeben	Die Sitemap-Zeile wird nicht verarbeitet	Immer die vollständige absolute URL angeben
Subdomain ohne eigene robots.txt	Eine Subdomain bleibt ungeschützt oder umgekehrt komplett gesperrt	Für jeden Host eine eigene Datei pflegen

Drei dieser Fehler verdienen eine genauere Erklärung, weil sie besonders häufig vorkommen und teuer sind.

Crawling mit Indexierung verwechseln

Der mit Abstand verbreitetste Denkfehler: Eine Seite soll aus Google verschwinden, also wird sie per Disallow gesperrt. Das Gegenteil tritt ein. Disallow verbietet nur das Abrufen. Ist die URL irgendwo verlinkt, kann Google sie weiterhin indexieren und in den Ergebnissen anzeigen, oft mit dem Hinweis, dass keine Informationen verfügbar sind. Schlimmer noch: Wenn die Seite ein noindex-Meta-Tag trägt, du sie aber gleichzeitig per robots.txt sperrst, kann der Bot dieses noindex gar nicht mehr lesen, weil er die Seite nicht abrufen darf. Die Seite bleibt dann erst recht im Index hängen.

Die Regel lautet deshalb klar: Willst du eine Seite zuverlässig aus dem Index halten, sperre sie nicht in der robots.txt, sondern lasse sie crawlbar und setze ein noindex im Seitenkopf. Erst wenn Google die Seite über längere Zeit nicht mehr im Index zeigt, kannst du sie zusätzlich per Disallow vom Crawling ausnehmen.

Die Staging-Datei mit live schalten

Auf Entwicklungs- und Testumgebungen steht fast immer ein pauschales Disallow: / , um zu verhindern, dass die unfertige Seite indexiert wird. Das ist richtig. Gefährlich wird es beim Deployment: Wird die Testumgebung samt robots.txt auf die Live-Domain kopiert, sperrt man unbemerkt die komplette echte Website. Innerhalb weniger Tage können dann nahezu alle Seiten aus dem Crawl fallen. Dieser eine vergessene Schrägstrich ist regelmäßig die Ursache dramatischer Sichtbarkeitsverluste. Eine feste Prüfung der robots.txt direkt nach jedem Livegang sollte deshalb zum Standard gehören.

Ressourcen für das Rendering aussperren

Früher galt es als sauber, technische Ordner mit CSS- und JavaScript-Dateien zu sperren. Heute ist das schädlich. Google rendert Seiten wie ein Browser und braucht dafür Zugriff auf das Design und die Skripte. Sind diese Ressourcen blockiert, sieht der Bot eine kaputte, unvollständige Seite und bewertet sie entsprechend schlechter. Lass solche Ordner deshalb grundsätzlich crawlbar, sofern sie für die Darstellung nötig sind.

Die robots.txt richtig testen

Keine Änderung an dieser Datei sollte ungetestet live gehen. Das wichtigste Werkzeug dafür ist die Google Search Console. Dort zeigt dir der robots.txt-Bericht, welche Version Google zuletzt abgerufen hat und ob sie Fehler enthält. Mit der URL-Prüfung kannst du außerdem einzelne Adressen testen und sofort sehen, ob sie durch eine Regel blockiert werden.

Ein zweiter, schneller Check ist die einfache Suchabfrage site:deinedomain.de in Google. Sie zeigt dir grob, wie viele und welche Seiten im Index stehen. Bricht diese Zahl nach einer Änderung plötzlich ein, ist eine fehlerhafte robots.txt einer der ersten Verdächtigen. Beide Prüfungen gehören auch in jeden gründlichen SEO-Audit, bei dem die Indexierung systematisch kontrolliert wird, denn eine versehentliche Crawl-Blockade ist eines der ersten Dinge, die ein Audit aufdecken sollte.

Ein praktischer Ablauf sieht so aus: Du änderst die Datei zunächst in einer Kopie, prüfst die neuen Regeln gegen deine wichtigsten URLs, stellst die Datei dann live und kontrollierst unmittelbar danach erneut in der Search Console. So fängst du Fehler ab, bevor sie sich auf die Rankings auswirken.

So fügt sich robots.txt in deine SEO-Strategie ein

Die robots.txt ist ein technisches Fundament, kein Ranking-Booster. Sie sorgt dafür, dass Suchmaschinen die richtigen Seiten abrufen und keine Energie an wertlose URLs verschwenden. Damit gehört sie zur selben Grundschicht wie eine saubere Seitenstruktur, korrekte Statuscodes und eine gepflegte interne Verlinkung. Wie all diese Bausteine zusammenspielen, ordnet unser Überblick zur Suchmaschinenoptimierung ein.

Entscheidend ist die Reihenfolge. Erst wenn Crawling und Indexierung technisch sitzen, also Google deine wichtigen Seiten zuverlässig abrufen und in den Index aufnehmen kann, lohnt es sich, Energie in den Inhalt zu stecken. Eine perfekt optimierte Seite nützt nichts, wenn ein falsches Disallow sie unsichtbar macht. Umgekehrt verschenkt eine technisch einwandfreie, aber inhaltlich dünne Seite ihr Ranking-Potenzial. Beide Ebenen müssen stimmen.

Genau an diesem zweiten Schritt setzt ein semantisches SEO-Tool an. Sobald die technische Basis steht, geht es darum, die Inhalte deiner Schlüsselseiten so umfassend und relevant zu gestalten, dass sie die Suchintention vollständig bedienen. Ein Werkzeug wie NeuronWriter analysiert dafür die aktuell rankenden Ergebnisse zu deinem Keyword, leitet daraus das passende semantische Feld ab und zeigt dir in Echtzeit, welche Begriffe und Themen deinem Text noch fehlen. So stellst du sicher, dass die Seiten, die Google nach einer sauberen robots.txt wieder problemlos crawlt, inhaltlich auch wirklich überzeugen.

Wer das einmal selbst ausprobieren möchte, kann NeuronWriter direkt testen: Jetzt NeuronWriter ausprobieren. Eine ehrliche Einordnung aus der Praxis, mit Stärken und Schwächen, findest du außerdem in unseren NeuronWriter Erfahrungen.

Fazit

Die robots.txt ist klein, aber mächtig. Sie steuert, welche Bereiche deiner Website gecrawlt werden, und schützt damit dein Crawl-Budget vor Verschwendung. Wer die vier Kerndirektiven User-agent, Disallow, Allow und Sitemap verstanden hat und den Unterschied zwischen Crawling und Indexierung verinnerlicht, vermeidet die teuersten Fehler ganz von allein.

Drei Dinge solltest du mitnehmen. Erstens: Die Datei sperrt nur das Abrufen, nicht die Indexierung, für das Entfernen aus Google nutzt du noindex. Zweitens: Ein einziger falscher Schrägstrich kann eine ganze Domain unsichtbar machen, deshalb gehört nach jeder Änderung ein Test in der Search Console dazu. Und drittens: Die robots.txt ist nur das technische Fundament. Stehen Crawling und Indexierung, entscheidet die inhaltliche Qualität deiner Schlüsselseiten über die Rankings, und genau dort setzt ein Tool wie NeuronWriter an. Wenn deine technische Basis steht, ist der nächste logische Schritt, die Inhalte gezielt zu optimieren: Jetzt mit NeuronWriter starten.