robots.txt: Der vollständige Leitfaden zur Crawler-Zugriffskontrolle

Die robots.txt-Datei ist eines der ältesten und mächtigsten Werkzeuge im Arsenal eines Webmasters. Am Root jeder Domain platziert, teilt diese Klartextdatei Crawlern mit, welche Teile deiner Website sie besuchen dürfen und welche sie meiden sollen. Trotz ihrer Einfachheit ist die robots.txt auch eine der am häufigsten fehlkonfigurierten Dateien im Web. Eine einzige falsch platzierte Regel kann eine gesamte Website vor Suchmaschinen verbergen oder Bereiche offenlegen, die du privat halten wolltest.

Dieser Leitfaden deckt alles ab — von grundlegender Syntax bis zu fortgeschrittenen Mustern —, damit du robots.txt-Regeln mit Sicherheit schreiben kannst.

Wo robots.txt liegt und wie Crawler sie finden

Jeder konforme Crawler ruft vor jeder anderen URL auf einer Domain die /robots.txt am Root ab:

https://example.com/robots.txt

Wichtige Regeln zur Datei selbst:

  • Sie muss unter dem exakten Pfad /robots.txt ausgeliefert werden — nicht /Robots.txt, nicht in einem Unterverzeichnis.
  • Sie muss einen 200-Statuscode mit dem Content-Type text/plain zurückgeben. Gibt der Server einen 404 zurück, gehen Crawler davon aus, dass alles erlaubt ist. Ein 5xx-Fehler veranlasst die meisten Crawler, das Crawling zu pausieren, bis die Datei wieder verfügbar ist.
  • Die Datei gilt pro Origin (Schema + Host + Port). Eine Regel auf https://example.com/robots.txt regelt nicht https://blog.example.com oder http://example.com.
  • Die von Google beachtete maximale Dateigröße beträgt 500 KiB. Alles darüber hinaus wird ignoriert.

Grundlegende Syntax

Eine robots.txt-Datei besteht aus einer oder mehreren Regelgruppen. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, gefolgt von Disallow- und/oder Allow-Direktiven:

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

Die User-agent-Zeile gibt an, für welchen Crawler die folgenden Regeln gelten. Der Platzhalter * passt auf jeden Crawler, der keinen eigenen spezifischen Block hat. Crawler ordnen sich dem spezifischsten verfügbaren User-agent-Block zu. Existieren sowohl User-agent: * als auch User-agent: Googlebot, nutzt Googlebot ausschließlich den Googlebot-spezifischen Block und ignoriert den Platzhalter-Block vollständig.

Disallow

Disallow: /path/ weist den zugeordneten Crawler an, keine URL aufzurufen, die mit /path/ beginnt. Ein leeres Disallow: (ohne Pfad) bedeutet, dass nichts verboten ist — gleichbedeutend mit vollem Zugriff.

Allow

Allow: /path/ erlaubt explizit den Zugriff auf URLs, die dem Muster entsprechen, selbst wenn ein breiteres Disallow sie andernfalls blockieren würde. Dies ist essenziell für Ausnahmen.

Wildcards und Pattern Matching

Die ursprüngliche robots.txt-Spezifikation von 1994 enthielt keine Wildcards, aber Google, Bing und die meisten modernen Crawler unterstützen zwei wichtige Pattern-Matching-Zeichen:

Das Sternchen: *

Passt auf jede Zeichenfolge (einschließlich einer leeren Zeichenfolge). Beispiele:

  • Disallow: /*.pdf — blockiert alle URLs, die .pdf irgendwo im Pfad enthalten.
  • Disallow: /directory/*/page — blockiert URLs wie /directory/anything/page.

Das Dollarzeichen: $

Verankert die Übereinstimmung am Ende der URL. Ohne $ passen Muster als Präfixe. Beispiele:

  • Disallow: /*.pdf$ — blockiert URLs, die mit .pdf enden, erlaubt aber /file.pdf?view=1 (da die URL nicht bei .pdf endet).
  • Allow: /page$ — erlaubt genau /page, aber nicht /page/subpage oder /page?q=1.

Allow vs. Disallow: Was gewinnt?

Wenn eine URL sowohl einer Allow- als auch einer Disallow-Regel entspricht, hängt die Auflösung von der Spezifität (Pfadlänge) ab. Googles Implementierung folgt dieser Logik:

  1. Die Regel mit dem längeren übereinstimmenden Pfad gewinnt.
  2. Haben beide Regeln die gleiche Länge, hat Allow Vorrang.

Beispiel:

User-agent: *
Disallow: /directory/
Allow: /directory/public/

Hier ist /directory/public/page.html erlaubt, weil /directory/public/ (20 Zeichen) länger ist als /directory/ (11 Zeichen). Aber /directory/secret.html bleibt blockiert.

Dies ist eine häufige Quelle der Verwirrung. Teste deine Regeln immer mit einem robots.txt-Tester, um das Ergebnis für bestimmte URLs zu bestätigen.

Die Crawl-delay-Direktive

Crawl-delay fordert den Crawler auf, eine bestimmte Anzahl von Sekunden zwischen aufeinanderfolgenden Anfragen zu warten:

User-agent: Bingbot
Crawl-delay: 10

Wichtige Hinweise:

  • Google ignoriert Crawl-delay vollständig. Um Googlebots Crawling-Rate zu steuern, nutze die Einstellung Crawling-Rate in der Google Search Console.
  • Bing respektiert es. Ein Wert von 10 bedeutet, dass Bingbot 10 Sekunden zwischen Anfragen wartet.
  • Yandex, Baidu und einige andere Crawler beachten es ebenfalls, obwohl die Implementierungen variieren.
  • Ein übermäßig hoher Wert (z. B. 60) stoppt das Crawling praktisch. Verwende es sparsam und nur, wenn dein Server die Last tatsächlich nicht bewältigen kann.

Die Sitemap-Direktive

Du kannst Sitemaps direkt in der robots.txt deklarieren:

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

Wichtige Punkte:

  • Die Sitemap-Direktive ist nicht an einen User-agent-Block gebunden. Platziere sie am Anfang oder Ende der Datei — sie gilt global.
  • Die URL muss vollständig qualifiziert sein (absolute URL mit Schema).
  • Du kannst mehrere Sitemaps auflisten.
  • Es ist ein Entdeckungshinweis, keine Garantie. Das Einreichen von Sitemaps über die Search Console oder Bing Webmaster Tools ist zuverlässiger.

Häufige Fehler, die das Crawling sabotieren

1. CSS und JavaScript blockieren

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

Moderne Suchmaschinen rendern Seiten, um Inhalt und Layout zu bewerten. Wenn du die für das Rendering benötigten Ressourcen blockierst, sieht der Crawler eine defekte Seite — und stuft sie möglicherweise herab oder überspringt sie. Blockiere nur Ressourcen, die für das Rendering öffentlicher Inhalte wirklich irrelevant sind.

2. Disallow verwenden, um Seiten aus dem Index fernzuhalten

Disallow verhindert das Crawling, nicht die Indexierung. Wenn andere Seiten auf eine blockierte URL verlinken, kann Google sie trotzdem indexieren — nur ohne Inhalt, was zu einem kryptischen Eintrag führt. Um eine Seite wirklich aus dem Index zu entfernen, verwende ein noindex-Meta-Tag oder den X-Robots-Tag-Header und erlaube dem Crawler, die Seite zu sehen.

3. Den abschließenden Schrägstrich vergessen

Disallow: /private   # blockiert /private, /private.html, /privately usw.
Disallow: /private/  # blockiert nur Pfade innerhalb des /private/-Verzeichnisses

Das erste Muster ist breiter als die meisten beabsichtigen. Überlege immer, ob du den abschließenden Schrägstrich brauchst.

4. Widersprüchliche Wildcard- und spezifische Blöcke

Einen User-agent: *-Block und einen bot-spezifischen Block zu haben, bei dem der spezifische Block leer ist, gibt diesem Bot effektiv vollen Zugriff — selbst wenn der Wildcard-Block restriktiv ist. Das ist beabsichtigt, überrascht aber Menschen, die annehmen, dass sich Regeln kumulieren.

5. robots.txt hinter einem Redirect ausliefern

Wenn /robots.txt einen 301 oder 302 zurückgibt, folgen die meisten Crawler dem Redirect. Allerdings führen Redirect-Ketten, Redirect-Schleifen oder Weiterleitungen auf eine nicht-text/plain-Antwort dazu, dass Crawler die Datei als nicht verfügbar behandeln. Halte es einfach: Liefere die Datei direkt am Root mit einer 200-Antwort aus.

6. KI-Crawler nicht berücksichtigen

Wenn deine robots.txt nur einen User-agent: *-Block hat, hat jeder KI-Crawler, den du nicht explizit blockiert hast, den gleichen Zugang wie Googlebot. Erwäge, spezifische Regeln für Bots wie GPTBot, ClaudeBot, PerplexityBot und Bytespider hinzuzufügen.

Deine robots.txt testen

Deploye niemals Änderungen an der robots.txt, ohne sie zu testen. Verfügbare Tools:

  • Google Search Console — der robots.txt-Tester zeigt, wie Google deine Regeln für bestimmte URLs interpretiert.
  • Bing Webmaster Tools — ähnliche Testfunktionalität für Bingbot.
  • Spider.es — prüfe, welche Crawler (Suchmaschinen, KI-Bots, SEO-Tools) auf jede URL deiner Domain zugreifen können, mit der spezifischen Regel, die jedes Ergebnis steuert.
  • Kommandozeilen-Tools — Bibliotheken wie Pythons urllib.robotparser ermöglichen die Automatisierung von Tests in CI/CD-Pipelines.

Eine solide Ausgangsvorlage

# Suchmaschinen: voller Zugriff
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /
Crawl-delay: 5

# KI-Crawler: selektiv
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# Standard: erlauben mit Einschränkungen
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

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

Passe dies an deine Bedürfnisse an. Das Prinzip ist einfach: Sei explizit bei dem, was du erlaubst, bewusst bei dem, was du blockierst, und teste vor dem Deployment.

Fazit

Die robots.txt ist trügerisch einfach. Wenige Textzeilen steuern, ob Millionen von Menschen deine Inhalte über Suchmaschinen und KI-Tools entdecken können. Behandle sie mit der gleichen Sorgfalt wie die Sicherheitskonfiguration deiner Website. Überprüfe sie regelmäßig — besonders wenn neue KI-Crawler auftauchen — und nutze Tools wie Spider.es, um sicherzustellen, dass deine beabsichtigte Policy mit der Realität übereinstimmt.

Zurück zum Blog