Die robots.txt Datei

· SEO-Tutorials

Bei der robots.txt handelt es sich um eine Textdatei im Wurzelverzeichnis einer Website, die sich an Bots und Webcrawler richtet und ihnen mitteilt, welche Bereiche sie abrufen dürfen und welche nicht. Sie muss unter genau einer Adresse liegen – https://www.beispiel.de/robots.txt –, und sie gilt jeweils nur für die Kombination aus Protokoll, Host und Port, unter der sie liegt. Eine robots.txt auf der www-Variante regelt nichts für eine Subdomain wie shop.beispiel.de.

Lange war das Protokoll dahinter nur eine Konvention von 1994, an die sich alle hielten, ohne dass sie irgendwo verbindlich festgeschrieben war. Seit 2022 ist es als RFC 9309 standardisiert. Was sich dadurch praktisch geändert hat, ist überschaubar – aber die Frage, welche Direktive nun gilt und welche nicht, hat seither eine belastbare Antwort.

Aufbau und Syntax

Eine robots.txt besteht aus Gruppen. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, darunter stehen die Regeln für diesen Crawler:

User-agent: Googlebot
Disallow: /interne-suche/

User-agent: *
Disallow: /admin/
Disallow: /*?sessionid=
Allow: /admin/oeffentlich/

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

Was hier passiert, Zeile für Zeile:

Die erste Gruppe gilt nur für den Googlebot und sperrt das Verzeichnis der internen Suchergebnisse. Die zweite Gruppe gilt für alle übrigen Crawler und sperrt den Administrationsbereich sowie – über das Platzhalterzeichen * – alle URLs, die den Parameter sessionid enthalten. Die Allow-Zeile nimmt einen Unterordner von der Sperre wieder aus.

Vier Punkte, die regelmäßig für Verwirrung sorgen:

  • Erlaubt ist alles, was nicht verboten ist. Ein Allow braucht ihr nur, um eine bestehende Disallow-Regel punktuell aufzuheben.
  • Ein Crawler befolgt genau eine Gruppe – die am genauesten auf ihn passende. Wenn es eine Gruppe für Googlebot gibt, ignoriert der Googlebot die Gruppe * vollständig. Regeln, die auch für ihn gelten sollen, müssen also in seiner eigenen Gruppe wiederholt werden. Das ist die mit Abstand häufigste Fehlerquelle.
  • Bei widersprüchlichen Regeln gewinnt die spezifischere, also die mit dem längeren Pfad-Ausdruck.
  • Die Zeile heißt User-agent, nicht User Agent. Ein Leerzeichen statt des Bindestrichs macht die Zeile ungültig, und damit unter Umständen die ganze Gruppe.

Google verarbeitet die Datei bis zu einer Größe von 500 Kibibyte; alles darüber wird ignoriert. Groß- und Kleinschreibung ist bei Pfadangaben relevant, bei Direktivennamen nicht.

robots.txt sperrt das Crawling, nicht die Indexierung

Das ist der Punkt, an dem die meisten Missverständnisse anfangen. Eine per Disallow gesperrte URL wird von Google nicht abgerufen – aber sie kann trotzdem im Index landen, wenn andere Seiten darauf verlinken. Google kennt die Adresse dann, kennt aber ihren Inhalt nicht, und zeigt sie ohne Beschreibungstext an. In der Search Console taucht so etwas im Seiten-Bericht mit dem Hinweis auf, dass die URL indexiert wurde, obwohl sie durch die robots.txt blockiert ist.

Wer eine Seite zuverlässig aus dem Index halten will, braucht ein noindex im Meta-Robots-Tag oder im HTTP-Header – und die Seite muss dafür abrufbar bleiben, sonst liest niemand die Anweisung. Für alles, was wirklich niemand sehen soll, ist ohnehin weder das eine noch das andere zuständig, sondern eine Zugriffssperre mit Passwort.

Was nicht (mehr) funktioniert

Noindex: in der robots.txt. Google hat diese undokumentierte Direktive über Jahre inoffiziell ausgewertet und die Unterstützung zum 1. September 2019 eingestellt. Wenn ihr sie in einer Bestandsdatei findet, ist sie seither wirkungslos – und was schlimmer ist: Die betroffenen Seiten sind dann meist zusätzlich per Disallow gesperrt, sodass auch kein Meta-Tag greifen kann. Ein lohnender Blick beim Aufräumen alter Projekte.

Crawl-delay:. Diese Direktive war nie Teil des Protokolls, und Google hat sie nie beachtet. Bing und Yandex werten sie aus. Wenn ihr den Googlebot bremsen wollt, geht das nicht über die robots.txt; ernsthafte Lastprobleme durch Crawling löst man über die Serverkonfiguration oder, im Notfall, über einen HTTP-Statuscode 503.

Host:. Eine Yandex-Eigenheit, die nie allgemein unterstützt wurde und für die Wahl der bevorzugten Domain heute keine Rolle mehr spielt. Dafür sind Weiterleitungen und rel="canonical" zuständig.

KI-Crawler steuern

Der häufigste Anlass, eine robots.txt heute überhaupt anzufassen, hat mit klassischem SEO nichts zu tun: Es geht um Crawler, die Inhalte für das Training oder die Beantwortung von Fragen durch Sprachmodelle einsammeln. Diese Bots identifizieren sich mit eigenen Kennungen, die sich in der robots.txt ansprechen lassen.

# Crawler von OpenAI
User-agent: GPTBot
Disallow: /

# Common Crawl – Datenbasis vieler Modelle
User-agent: CCBot
Disallow: /

# Google: Nutzung der Inhalte für KI-Produkte
User-agent: Google-Extended
Disallow: /

Ein wichtiger Unterschied im letzten Block: Google-Extended ist kein Crawler. Ihr werdet die Kennung in keinem Server-Logfile finden. Es ist ein reiner Steuerungs-Token, mit dem Google die Frage abbildet, ob eure Inhalte in bestimmten KI-Produkten verwendet werden dürfen. Auf die Indexierung in der Google-Suche und auf eure Rankings hat er nach Googles Darstellung keinen Einfluss – wer nur den Googlebot sperrt, fliegt dagegen aus der Suche.

Weitere Anbieter haben eigene Kennungen, und die Liste ändert sich schneller, als eine Anleitung sie aktuell halten kann. Wer das ernsthaft steuern will, prüft die Dokumentation der jeweiligen Anbieter und gleicht sie regelmäßig mit den eigenen Server-Logfiles ab – dort steht, wer tatsächlich vorbeikommt.

Zwei Einschränkungen sollte man dabei kennen. Erstens sperrt ein Eintrag nur die Bots, die sich freiwillig daran halten; Kennungen lassen sich fälschen, und nicht jeder Betreiber ist an Kooperation interessiert. Zweitens verhindert eine Sperre nicht, dass Inhalte über Dritte in Trainingsdaten landen, etwa über Zitate oder Kopien auf anderen Websites. Wer verbindlicher steuern will, arbeitet mit Zugriffsregeln auf Server- oder CDN-Ebene statt mit einer Bitte in einer Textdatei.

Sind die Regeln verpflichtend?

Kurz gesagt: nein. Auch RFC 9309 beschreibt ein freiwilliges Protokoll. Die großen Suchmaschinen halten sich zuverlässig daran, weil sie ein Interesse an funktionierenden Absprachen haben. Für aggressive Scraper gilt das nicht. Der einzig sichere Weg bleibt ein geschützter Bereich, etwa hinter einer Anmeldung.

Und noch etwas: Die robots.txt ist öffentlich. Wer dort Disallow: /kundenportal-beta/ einträgt, hat den Pfad damit weltweit bekanntgemacht. Verzeichnisse, deren bloße Existenz vertraulich ist, gehören nicht in diese Datei.

Tipps für die Praxis

  • Prüfen statt raten. In der Search Console findet ihr unter den Einstellungen einen robots.txt-Bericht, der zeigt, welche Fassung Google zuletzt abgerufen hat und ob sie fehlerfrei verarbeitet wurde. Mit der URL-Prüfung testet ihr einzelne Adressen. Wie ihr die Search Console für ein Projekt einrichtet, beschreibt ein eigenes Tutorial.
  • Sitemap eintragen. Die Sitemap:-Zeile gehört mit absoluter URL in die Datei und ist seit dem Wegfall des Ping-Endpunkts einer von zwei Wegen, Suchmaschinen auf die XML-Sitemap hinzuweisen. Sie ist an keine User-agent-Gruppe gebunden und darf mehrfach vorkommen.
  • Nach jedem Relaunch kontrollieren. Ein Disallow: / aus der Entwicklungsumgebung, das versehentlich mit live geht, nimmt eine Website binnen Tagen aus dem Index. Das ist der teuerste Fehler, den diese Datei ermöglicht – und er passiert regelmäßig.
  • Im Zweifel weniger regeln. Sperrt gezielt, was Probleme macht: Facettennavigation, interne Suchergebnisse, endlose Kalenderseiten. Alles andere lasst offen. Welche Bereiche das im Einzelfall sind, hängt an der Struktur der Website; das Tutorial zu Indexierbarkeit und Crawlability geht darauf näher ein.

Die robots.txt ist ein grobes Werkzeug mit großer Wirkung. Sie gehört zu den Bausteinen, die wir uns bei einer Suchmaschinenoptimierung als Erstes ansehen, weil sich hier mit zwei Zeilen mehr kaputt machen lässt als mit einem halben Jahr Contentarbeit.