Die robots.txt gehört zu den ältesten und gleichzeitig meistunterschätzten Dateien einer Website. Sie steuert, welche Bereiche einer Domain von Suchmaschinen-Crawlern besucht werden dürfen – und welche nicht. Dieser Artikel erklärt Aufbau, Syntax und die wichtigsten Direktiven verständlich und mit Beispielen.

Warum dieser Artikel für jede Website relevant ist

Egal ob privater Blog, Firmenwebsite oder großer Online-Shop – jede öffentlich erreichbare Domain kann von einer bewusst konfigurierten robots.txt profitieren. Selbst wer keine besonderen Crawling-Einschränkungen benötigt, sollte zumindest wissen, was passiert, wenn die Datei fehlt oder versehentlich falsch konfiguriert ist, da genau diese beiden Szenarien in der Praxis die häufigsten unbeabsichtigten Auswirkungen auf die Sichtbarkeit in Suchmaschinen haben.

Was ist eine robots.txt überhaupt?

Die robots.txt ist eine einfache Textdatei, die im Stammverzeichnis einer Domain liegt, etwa unter https://beispiel.de/robots.txt. Sie folgt dem sogenannten „Robots Exclusion Protocol", einem seit den 1990er-Jahren etablierten, informellen Standard. Suchmaschinen wie Google, Bing oder Yandex rufen diese Datei ab, bevor sie eine Website crawlen, und richten sich – zumindest bei seriösen Suchmaschinen – nach den dort hinterlegten Regeln.

Wichtig: Keine Zugriffskontrolle

Ein häufiges Missverständnis: Die robots.txt ist keine Sicherheitsfunktion. Sie verhindert nicht den Zugriff auf eine Seite, sondern äußert lediglich eine Empfehlung an kooperative Crawler. Wer vertrauliche Inhalte tatsächlich schützen möchte, benötigt eine echte Zugriffskontrolle (Passwortschutz, Login, IP-Sperre) – nicht nur einen Eintrag in der robots.txt, den ohnehin jeder öffentlich einsehen kann.

🧰 Ist Ihre robots.txt korrekt aufgebaut?

Der Checker ruft Ihre robots.txt automatisch ab und zeigt verständlich, was sie bewirkt. Jetzt kostenlos prüfen →

Der grundlegende Aufbau

Eine robots.txt besteht aus einer oder mehreren „Gruppen". Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, gefolgt von Regeln, die für diese Crawler gelten:

User-agent: *
Disallow: /admin/
Disallow: /warenkorb/
Allow: /

Sitemap: https://beispiel.de/sitemap.xml

Diese Beispiel-Datei sagt: Alle Crawler (User-agent: *) dürfen grundsätzlich alles besuchen (Allow: /), außer den Admin-Bereich und den Warenkorb. Zusätzlich wird auf die Sitemap verwiesen, damit Suchmaschinen alle relevanten URLs zuverlässig finden.

Die wichtigsten Direktiven im Überblick

User-agent

Legt fest, für welchen Crawler die nachfolgenden Regeln gelten. Der Platzhalter * steht für „alle Crawler, die nicht explizit anders genannt sind". Einzelne Suchmaschinen lassen sich auch gezielt ansprechen, z. B. User-agent: Googlebot.

Disallow

Verbietet das Crawlen eines Pfads. Disallow: /admin/ blockiert alle URLs, die mit /admin/ beginnen. Ein leeres Disallow: bedeutet paradoxerweise „nichts blockieren".

Allow

Erlaubt explizit einen Pfad, meist um eine Ausnahme innerhalb eines blockierten Bereichs zu definieren, z. B. eine öffentliche Unterseite innerhalb eines ansonsten gesperrten Verzeichnisses.

Sitemap

Verweist auf die XML-Sitemap der Website. Im Gegensatz zu den anderen Direktiven gilt dieser Eintrag global, unabhängig von der User-agent-Gruppe, in der er steht.

Crawl-delay

Bittet den Crawler, zwischen zwei Anfragen eine bestimmte Anzahl Sekunden zu warten. Google ignoriert diese Direktive komplett, andere Suchmaschinen wie Bing berücksichtigen sie teilweise.

Wildcards und Sonderzeichen

Viele Crawler unterstützen zusätzlich zwei Sonderzeichen in Pfadangaben: * als Platzhalter für eine beliebige Zeichenfolge und $ als Markierung für das Ende einer URL. Damit lässt sich z. B. Disallow: /*.pdf$ formulieren, um sämtliche PDF-Dateien vom Crawling auszuschließen, unabhängig davon, in welchem Verzeichnis sie liegen. Ohne das abschließende $ würde die Regel auch URLs erfassen, die zwar mit .pdf im Pfad enthalten, aber danach noch weitere Zeichen aufweisen, etwa Parameter – ein Detail, das bei der Fehlersuche leicht übersehen wird.

Praxisbeispiel: Online-Shop „Gartenwelt Fischer"

Ein fiktiver Online-Shop für Gartenbedarf wollte verhindern, dass Suchmaschinen den internen Warenkorb- und Checkout-Prozess sowie interne Filterkombinationen crawlen, die zu tausenden ähnlichen URLs mit Duplicate Content führten. Die Lösung:

User-agent: *
Disallow: /warenkorb/
Disallow: /checkout/
Disallow: /*?filter=
Allow: /

Sitemap: https://gartenwelt-fischer-beispiel.de/sitemap.xml

Damit blieb der eigentliche Produktkatalog vollständig crawlbar, während technische und duplicate-content-anfällige Bereiche gezielt ausgeschlossen wurden. Ergebnis nach einigen Wochen: deutlich weniger vom Crawler „verschwendete" Anfragen auf irrelevante URLs, laut Google Search Console.

Häufige Struktur-Fehler

  • Regeln ohne vorherigen User-agent: Eine Disallow-Zeile ohne vorangehende User-agent-Zeile wird von den meisten Crawlern ignoriert oder falsch zugeordnet.
  • Groß-/Kleinschreibung: Pfade in Disallow/Allow sind case-sensitive – /Admin/ ist nicht dasselbe wie /admin/.
  • Falscher Speicherort: Die Datei muss exakt im Stammverzeichnis liegen (/robots.txt), nicht in einem Unterordner.
  • Falsches Encoding: Die Datei sollte als reines UTF-8-Textdokument ohne Byte-Order-Mark gespeichert werden.

Unterschiede zwischen den großen Suchmaschinen

Nicht jeder Crawler interpretiert die robots.txt identisch. Googlebot unterstützt Wildcards (*, $) vollständig und priorisiert bei Konflikten die spezifischere Regel. Bingbot verhält sich in den meisten Punkten ähnlich, berücksichtigt zusätzlich aber die Crawl-delay-Direktive, die Google komplett ignoriert. Yandex, die in Russland verbreitete Suchmaschine, unterstützt historisch eine eigene, inzwischen aber auch von Google übernommene Clean-param-Direktive zur Behandlung von URL-Parametern. Wer international ausgerichtete Websites betreibt, sollte diese Unterschiede im Hinterkopf behalten, statt sich blind auf ein einziges, Google-zentriertes Verhalten zu verlassen.

Historischer Hintergrund: Warum gibt es die robots.txt überhaupt?

Das Robots Exclusion Protocol entstand 1994, nachdem ein aggressiver Crawler den Server des Web-Pioniers Martijn Koster wiederholt überlastet hatte. Aus dieser praktischen Notwendigkeit heraus einigten sich damals mehrere Suchmaschinenbetreiber informell auf einen gemeinsamen Standard, wie Website-Betreiber Crawlern Empfehlungen mitgeben können. Erst 2019 wurde der Standard von Google offiziell bei der IETF als RFC 9309 eingereicht und damit erstmals formal spezifiziert – bis dahin galt er jahrzehntelang als reine Branchenkonvention ohne offiziellen Standardisierungsstatus.

Kommentare in der robots.txt

Innerhalb der Datei lassen sich mit einer Raute (#) Kommentare einfügen, die von Crawlern ignoriert werden:

# Interner Adminbereich, nicht für Suchmaschinen relevant
User-agent: *
Disallow: /admin/

Das ist besonders bei größeren, über Jahre gewachsenen robots.txt-Dateien hilfreich, um für spätere Bearbeiter nachvollziehbar zu dokumentieren, warum eine bestimmte Regel existiert – ohne dass diese Dokumentation die Funktion der Datei beeinträchtigt.

Robots.txt für Nicht-Suchmaschinen-Bots

Neben klassischen Suchmaschinen-Crawlern lesen auch andere automatisierte Bots die robots.txt aus – etwa SEO-Analyse-Tools, Preisvergleichsportale oder in den letzten Jahren zunehmend auch Crawler, die Trainingsdaten für KI-Sprachmodelle sammeln. Viele dieser neueren Bots (z. B. „GPTBot" von OpenAI oder „CCBot" von Common Crawl) lassen sich über eigene, namentlich benannte User-agent-Gruppen gezielt ansprechen, unabhängig von der allgemeinen „User-agent: *"-Gruppe. Wer nicht möchte, dass eigene Inhalte für das Training von KI-Modellen verwendet werden, kann diese Bots gezielt per Disallow ausschließen – eine Kontrollmöglichkeit, die in den letzten Jahren stark an Bedeutung gewonnen hat.

Robots.txt in Verbindung mit einem CDN oder Reverse Proxy

Wird eine Website über ein Content Delivery Network oder einen Reverse Proxy ausgeliefert, kann es vorkommen, dass die robots.txt auf CDN-Ebene zusätzlich zwischengespeichert wird. Nach einer Änderung an der Datei sollte in diesem Fall geprüft werden, ob der CDN-Cache diese Änderung auch tatsächlich an Suchmaschinen-Crawler weitergibt, oder ob eine manuelle Cache-Invalidierung nötig ist – sonst sehen Crawler unter Umständen noch tagelang die alte Version.

Robots.txt bei mehrsprachigen Websites

Bei international ausgerichteten Websites mit mehreren Sprachversionen (z. B. über Unterverzeichnisse wie /de/, /en/, /fr/) gilt weiterhin nur eine einzige robots.txt pro Domain. Regeln müssen daher so formuliert werden, dass sie – sofern gewünscht – sprachübergreifend konsistent greifen, etwa Disallow: /*/warenkorb/ statt separater Regeln für jede einzelne Sprachversion. Wird stattdessen mit länderspezifischen Subdomains gearbeitet (z. B. de.beispiel.de, fr.beispiel.de), benötigt hingegen jede Subdomain ihre eigene, unabhängige robots.txt-Datei.

Versionierung und Änderungsnachvollziehbarkeit

Da die robots.txt weitreichende Auswirkungen auf die Sichtbarkeit einer gesamten Website haben kann, empfiehlt es sich, Änderungen an dieser Datei wie an regulärem Quellcode zu versionieren – etwa über ein Versionskontrollsystem. So lässt sich im Nachhinein nachvollziehen, wer wann welche Regel geändert hat, und im Zweifel schnell auf eine frühere, funktionierende Version zurückgesetzt werden, statt die fehlerhafte Konfiguration mühsam manuell zu rekonstruieren.

Häufig gestellte Fragen

Muss jede Website eine robots.txt haben?

Nein. Fehlt die Datei, dürfen Crawler standardmäßig alles crawlen. Eine explizite robots.txt mit Sitemap-Verweis ist aber empfehlenswert.

Kann ich mit robots.txt einzelne Seiten aus Google entfernen?

Nicht zuverlässig. Für das Entfernen aus dem Index ist ein „noindex"-Meta-Tag oder HTTP-Header geeigneter – robots.txt verhindert nur das Crawlen, nicht zwingend die Indexierung bereits bekannter URLs.

Gilt robots.txt für Subdomains mit?

Nein. Jede Subdomain benötigt ihre eigene robots.txt unter ihrem jeweiligen Stammverzeichnis, z. B. https://shop.beispiel.de/robots.txt separat von https://beispiel.de/robots.txt.

Wie oft rufen Suchmaschinen die robots.txt ab?

Die meisten großen Suchmaschinen cachen die Datei für eine gewisse Zeit (oft rund 24 Stunden), rufen sie danach aber regelmäßig erneut ab, um Änderungen zu erkennen.

Wie groß darf eine robots.txt maximal sein?

Google verarbeitet Dateien bis etwa 500 Kibibyte, danach wird der Inhalt abgeschnitten. Für die überwältigende Mehrheit der Websites ist diese Grenze in der Praxis irrelevant.

Fazit

Eine robots.txt ist schnell geschrieben, aber leicht falsch konfiguriert. Wer die Grundstruktur und die wichtigsten Direktiven versteht, kann gezielt steuern, welche Bereiche seiner Website gecrawlt werden – und vermeidet die häufigsten, oft erst spät bemerkten Fehler.