Was ist robots.txt und wie schreibt man sie?

Was ist robots.txt und wo liegt sie?

robots.txt ist eine Klartextdatei, die Crawlern mitteilt, welche Teile einer Website sie abrufen dürfen. Sie gilt nur im Wurzelverzeichnis: Für example.com wird /robots.txt gelesen, example.com/blog/robots.txt bedeutet nichts. Jede Subdomain hat ihre eigene Datei — blog.example.com braucht eine eigene, und die Regeln der Hauptdomain gelten dort nicht.

Die Datei wurde 2022 mit RFC 9309 zum formalen Standard — anders als llms.txt ist sie eine von Crawlern gemeinsam akzeptierte Vereinbarung. Ein Sicherheitsinstrument ist sie dennoch nicht: Ob die Regeln befolgt werden, liegt beim Crawler, und ein bösartiger Scraper geht vorbei, ohne die Datei zu lesen. Einen geheim zu haltenden Pfad in die robots.txt zu schreiben heißt, ihn öffentlich anzukündigen.

Wie schreibt man eine robots.txt?

Die Datei besteht aus Gruppen. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, darunter stehen die Regeln für diesen Crawler. Vier Direktiven genügen:

• User-agent: benennt den Crawler, für den die Regeln gelten. Die Wildcard (*) heißt „alle ohne eigene Gruppe“ — nicht „alle“.
• Disallow: verhindert das Abrufen von Adressen, die mit dem angegebenen Pfad beginnen. Leer gelassen, blockiert sie nichts.
• Allow: öffnet einen Pfad innerhalb eines Disallow wieder; sinnvoll ist das für einen offenen Ordner unter einem gesperrten Verzeichnis.
• Sitemap: die vollständige Adresse der Sitemap. Sie ist gruppenunabhängig, darf überall stehen und wird üblicherweise zuletzt notiert.

# example.com/robots.txt

# Standard: jeder Crawler ohne eigene Gruppe.
User-agent: *
Disallow: /warenkorb/
Disallow: /konto/
Disallow: /suche
Disallow: /*?sortierung=
Allow: /

# Trainings-Crawler — eine Lizenzentscheidung.
# Die beiden Zeilen darunter zu loeschen schliesst Inhalte fuers Training.
User-agent: GPTBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: ClaudeBot
Allow: /

# Suche und Live-Abruf — daher kommt die Sichtbarkeit.
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

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

Welche Regel gilt? Gruppenzuordnung und längste Übereinstimmung

Das ist der am häufigsten missverstandene Teil der Datei, und er läuft auf zwei Regeln hinaus. Erstens die Gruppenwahl: Ein Crawler sucht die Gruppe, deren User-Agent am spezifischsten zu ihm passt, und wendet nur diese an. Googles Dokumentation ist eindeutig — eine spezifische Gruppe und die Wildcard-Gruppe werden nie kombiniert.

User-agent: *
Disallow: /intern/
Disallow: /admin/

User-agent: GPTBot
Disallow: /trainingsdaten/

# Absicht: GPTBot ueberall fernhalten und /trainingsdaten/ fuer alle sperren.
# Realitaet: Da GPTBot eine eigene Gruppe hat, gelten die zwei Zeilen oben nicht fuer ihn.
#            GPTBot darf /intern/ und /admin/ jetzt frei abrufen.

Die zweite Regel betrifft Konflikte innerhalb einer Gruppe: Das längste Pfadmuster gewinnt. Bei gleicher Länge wendet Google die weniger restriktive Regel an — Allow. Deshalb bleibt bei „Disallow: /“ zusammen mit „Allow: /blog/“ der Blog offen: Das Allow-Muster ist länger.

Praktische Folge: In einer robots.txt nach „Disallow“ zu suchen beweist nichts. Welche Regel gilt, entscheiden Gruppenzuordnung und Musterlänge — und der Schluss, den man beim bloßen Lesen zieht, ist meist falsch.

Welche KI-Crawler gibt es, und was tut jeder?

KI-Crawler erfüllen drei verschiedene Aufgaben, und die Entscheidung sollte sich dreifach teilen. Trainings-Crawler sammeln Inhalte für den Datensatz, der in die Gewichte eines Modells eingeht. Such-Crawler indexieren die Quellen, die bei einer Nutzerfrage erscheinen — davon hängt die Markensichtbarkeit unmittelbar ab. Live-Abruf-Crawler holen eine Seite in dem Moment, in dem ein Nutzer einen Link öffnet.

OpenAIs Dokumentation vermerkt für ChatGPT-User, dass „robots.txt-Regeln möglicherweise nicht gelten“ — weil die Anfrage eine Nutzerhandlung ist und kein automatisches Crawling. Wer diesen Bot blockieren will, sollte wissen, dass das Ergebnis nicht garantiert ist.

Welche Bots sollte man blockieren, welche offen lassen?

Die Entscheidung folgt dem Geschäftsmodell, eine einzige richtige Antwort gibt es nicht. Für Publisher, deren Inhalt das Produkt ist — Nachrichtenseiten, Forschungsverlage, kostenpflichtige Archive — ist das Blockieren von Trainings-Crawlern vertretbar: Verkauft wird der Inhalt selbst. Bei Unternehmen, die Leistungen und Produkte verkaufen, kehrt sich die Rechnung um: Inhalt ist nicht das Verkaufte, sondern das, was zum Verkauf führt.

In beiden Spalten ist das Blockieren von Such- und Live-Abruf-Crawlern selten richtig. Es ist das Äquivalent dazu, in der Suche nicht auffindbar sein zu wollen — und der Preis zeigt sich nicht sofort, sondern Monate später, wenn die Konkurrenz allein in den Antworten steht.

Wann wirkt eine Änderung an der robots.txt?

Nicht sofort — und das nicht zu wissen, löst viel unnötige Panik aus. Google cacht robots.txt in der Regel bis zu 24 Stunden, bei unmöglicher Aktualisierung auch länger. OpenAIs Dokumentation nennt etwa 24 Stunden, bis eine Änderung in den Systemen ankommt.

Auch die Unerreichbarkeit der Datei ist eine Entscheidung. Liefert robots.txt 5xx, stoppt Google das Crawling für 12 Stunden und versucht es erneut; schlägt der Abruf weiter fehl, nutzt Google die gecachte Fassung bis zu 30 Tage. Danach verhält es sich, wenn die Site grundsätzlich erreichbar ist, als gäbe es keine Einschränkungen. Ein Serverfehler bedeutet ab einem gewissen Punkt „alles erlaubt“.

Eine letzte Grenze: Google erzwingt ein Dateigrößenlimit von 500 Kibibyte und ignoriert Inhalte darüber hinaus. Handgeschriebene Dateien kommen selten in die Nähe, große Shops mit automatisch erzeugten Disallow-Listen schon — und die Regeln jenseits der Grenze werden stillschweigend ignoriert.

In robots.txt erlaubt, der Bot kommt trotzdem nicht durch: die Firewall-Falle

Der häufigste Grund, warum ein Crawler eine Site nicht erreicht, ist nicht robots.txt. robots.txt ist eine Bitte; die CDN- und Firewall-Ebene lässt die Anfrage gar nicht erst zum Server. Das Marketing öffnet die Datei, ein Schalter auf Infrastrukturseite verwirft den Bot am Edge — und monatelang weiß keine Seite, wo das Problem liegt.

Cloudflare ist das verbreitetste Beispiel. Der Schalter „Block AI bots“ in den Sicherheitseinstellungen blockiert verifizierte Bots, die als KI-Trainings-Crawler klassifiziert sind, sowie eine Reihe unverifizierter Bots mit ähnlichem Verhalten; laut Dokumentation nimmt er Bots mit gemischtem Zweck — Training und Suche — aus. Cloudflare stellt diesen Schalter am 15. September 2026 ein und ersetzt ihn durch Richtlinien, mit denen sich Such-, Agenten- und Trainingsverhalten getrennt steuern lassen.

• Prüfen Sie in Cloudflare den Schalter „Block AI bots“ unter Security Settings sowie den Bot Fight Mode; beide arbeiten unabhängig von robots.txt.
• Durchsuchen Sie WAF-Managed-Rule-Sets nach Blockierregeln für Bot-Kategorien — meist vor Jahren aktiviert und vergessen.
• Prüfen Sie serverseitig, ob ModSecurity, fail2ban oder Rate-Limiting-Regeln Crawler-User-Agents verwerfen.
• Ist ein „Bad Bot“- oder Sicherheits-Plugin installiert — bei WordPress häufig —, öffnen und lesen Sie dessen Liste blockierter User-Agents.
• Bei Geoblocking: Die Egress-IPs der Crawler liegen außerhalb der Türkei, länderbasierte Sperren treffen sie mit.

Wie überprüfe ich, was ich blockiert oder geöffnet habe?

Drei getrennte Prüfungen sind nötig, und jede beantwortet eine andere Frage: Was sagt die Datei, was tut die Edge-Schicht, und ist der Bot tatsächlich gekommen.

# 1) Die Datei selbst
$ curl -s https://example.com/robots.txt | head -40

# 2) Eine echte Seite mit dem User-Agent des Bots anfordern.
$ curl -s -o /dev/null -w "%{http_code}\n" \
    -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot" \
    https://example.com/

# 200 -> kommt durch
# 403 / 503 / 429 -> nicht robots.txt, sondern die Edge-Schicht blockiert

# 3) Im Server-Log pruefen, ob der Bot tatsaechlich da war.
$ grep -Ei "GPTBot|OAI-SearchBot|ClaudeBot|PerplexityBot" /var/log/nginx/access.log \
    | awk '{print $1, $12, $13}' | sort | uniq -c | sort -rn | head

Was ist der Unterschied zwischen robots.txt und noindex?

robots.txt verhindert das Crawlen, noindex das Indexieren — und beides zu verwechseln erzeugt einen der tückischsten SEO-Fehler überhaupt. Sperren Sie eine Seite in der robots.txt, kann der Crawler sie nicht abrufen; und weil er sie nicht abrufen kann, liest er das noindex auf der Seite nie. Ist die Seite extern verlinkt, kann sie weiterhin nur mit ihrer URL gelistet werden — und der Weg, sie zu entfernen, ist damit versperrt.

Die richtige Reihenfolge lautet: Soll eine Seite aus dem Index, lassen Sie sie in der robots.txt offen und setzen Sie noindex auf die Seite. Der Crawler kommt herein, liest das Tag, entfernt die Seite. Danach können Sie das Crawlen in der robots.txt zusätzlich sperren.

Was sind die häufigsten robots.txt-Fehler?

• Die Zeile „Disallow: /“ aus der Staging-Umgebung in die Produktion mitnehmen. Eine Zeile, die ganze Site. Jedes Team ohne robots.txt-Prüfung in der Release-Liste erlebt das einmal.
• Eine crawler-spezifische Gruppe eröffnen und die allgemeinen Sperren darin nicht wiederholen — die Datei lässt dann ausgerechnet den gemeinten Bot freier als alle anderen.
• CSS- und JavaScript-Verzeichnisse sperren. Ein Crawler, der nicht rendern kann, sieht unvollständige Inhalte; auf Seiten, die /wp-includes/ oder /assets/ schließen, passiert das noch immer.
• Eine vollständige Adresse in eine Disallow-Zeile schreiben. Regeln beginnen mit einem Pfad (/sepet/), nicht mit einer Domain; eine Zeile https://example.com/sepet/ bewirkt nichts.
• Die Sitemap-Zeile relativ schreiben. Die Sitemap verlangt eine absolute Adresse: nicht /sitemap.xml, sondern https://example.com/sitemap.xml.
• Groß- und Kleinschreibung übersehen. Pfade sind case-sensitiv; /Urunler und /urunler sind zwei verschiedene Pfade.