Eine Zeile in der robots.txt kann Suchmaschinen aus einem Verzeichnis fernhalten. Eine zu breite Regel kann zugleich wichtige Seiten oder Render-Ressourcen treffen. Die Datei braucht deshalb eine kontrollierte technische Pflege.
Die robots.txt gibt seriösen Crawlern Regeln für den Abruf einer Website. Sie kann Crawling lenken und auf eine Sitemap verweisen. Vertrauliche Inhalte schützt sie nicht, und eine bekannte URL kann trotz Crawling-Sperre in einem Suchergebnis erscheinen.[1][2]
Das Wichtigste in Kürze
- Fester Ort: Die Datei liegt im Stammverzeichnis des jeweiligen Hosts unter
/robots.txt.[2] - Begrenzte Wirkung: Sie steuert Crawling. Zugriffsschutz und zuverlässige Deindexierung brauchen eigene Mittel.[1][2]
- Vier Bausteine:
User-agent,Disallow,AllowundSitemapdecken die üblichen Regeln ab.[2] - Render-Ressourcen freigeben: CSS und JavaScript sollten erreichbar bleiben, wenn Google sie für die Darstellung benötigt.[2]
- Bots trennen: Suche, AI-Search, Training und Werbung sind eigenständige Zugriffsentscheidungen.
- Änderungen testen: Sichern, einzeln ändern, Datei abrufen und betroffene URLs prüfen.
Was die robots.txt steuert
Die Datei gilt für den Host, das Protokoll und den Port, unter denen sie erreichbar ist.[2] Die Fassung unter https://www.beispiel.de/robots.txt regelt daher nicht automatisch https://shop.beispiel.de/ oder eine HTTP-Variante. Jeder technische Geltungsbereich braucht seine eigene Datei.
Crawler lesen dort Gruppen aus User-agent und Regeln. Seriöse Bots berücksichtigen diese Angaben beim Abruf. Ein Angreifer oder ein einfacher Downloader muss sich daran nicht halten. Wer ein Dokument schützen will, braucht Anmeldung, Berechtigungen oder eine andere Zugriffskontrolle.
Diese Trennung ist die wichtigste Betriebsregel. Die robots.txt steht öffentlich lesbar im Web. Jeder Pfad darin verrät, dass ein Bereich existiert. Interne Dokumente, Kundendaten und Staging-Systeme gehören hinter eine technische Zugangssperre.
Welche Crawler sollen welchen Bereich abrufen dürfen? Erst diese Entscheidung rechtfertigt eine Regel in der Datei.
Crawling und Indexierung auseinanderhalten
Eine Crawling-Sperre verhindert nicht zuverlässig, dass eine URL in Suchergebnissen auftaucht. Kennt Google die Adresse über externe oder interne Links, kann die URL weiterhin ohne ausgelesenen Seiteninhalt indexiert werden.[2] Eine Disallow-Regel ist daher kein Ersatz für eine Deindexierungsentscheidung.
| Ziel | Passendes Mittel |
|---|---|
Crawler-Abruf eines unwichtigen Pfads begrenzen |
|
Seite aus dem Index entfernen | erreichbare Seite mit |
Inhalt für Unbefugte sperren | Authentifizierung oder Berechtigung |
dauerhaft entfernte URL kennzeichnen | passender HTTP-Statuscode oder Redirect |
Für noindex muss der Crawler die Seite abrufen können. Wer dieselbe URL zugleich per robots.txt sperrt, verhindert unter Umständen das Lesen der Meta-Anweisung. Legen Sie daher zuerst das gewünschte Ergebnis fest und wählen Sie anschließend das technische Mittel.
Die vier Direktiven sicher einsetzen
Eine kurze Datei mit wenigen Gruppen lässt sich leichter prüfen als eine Kette von Ausnahmen. Dieses Minimalbeispiel erlaubt allen Bots grundsätzlich den Abruf, sperrt einen internen Suchpfad und nennt die Sitemap:
1User-agent: *2Disallow: /interne-suche/3Allow: /45Sitemap: https://www.beispiel.de/sitemap.xml
User-agent eröffnet eine Gruppe und benennt den Bot. Der Stern gilt als allgemeiner Fallback. Disallow sperrt den passenden Pfad, Allow kann innerhalb einer breiteren Sperre eine Ausnahme freigeben. Sitemap enthält die vollständige URL einer Sitemap oder eines Sitemap-Index und ist keiner einzelnen User-agent-Gruppe zugeordnet.[2][3]
Kommentare beginnen mit #. Nutzen Sie sie sparsam für den Zweck einer Regel, nicht als Änderungsprotokoll. Prüfen Sie außerdem Pfadpräfixe genau: Eine Regel für /intern/ kann mehr URLs treffen als die eine Seite, die den Anlass gegeben hat.
Ist Ihre Crawler-Steuerung mit der Website-Struktur abgestimmt?
Wir prüfen mit Ihnen, welche Inhalte auffindbar sein sollen und wo Technik, Sitemap und Seitenarchitektur widersprüchliche Signale senden.
Webpräsenz besprechenWas Sie besser nicht blockieren
Render-Ressourcen und indexierbare Inhalte brauchen im Normalfall freien Crawler-Zugriff. Google weist ausdrücklich darauf hin, dass CSS- und JavaScript-Dateien für das Rendern einer Seite erforderlich sein können.[2] Eine pauschale Sperre für Asset-Verzeichnisse kann verhindern, dass der Crawler Layout und Inhalte so sieht wie ein Besucher.
Der gefährlichste Eintrag lautet:
1User-agent: *2Disallow: /
Er sperrt den gesamten Host für passende Crawler. Auf einer bewusst abgeschirmten Testumgebung kann das ergänzend sinnvoll sein. Für eine Produktionswebsite ist die Regel ein Ausfallrisiko. Auch dort ersetzt sie keinen Passwortschutz.
Weitere problematische Kandidaten sind Canonical-Seiten, indexierbare Bilder und Verzeichnisse mit gemeinsam genutzten Skripten. Setzen Sie die kleinste Regel, die den benannten Zweck erfüllt. Die Planung einer dauerhaft verständlichen Website-Struktur hilft dabei, öffentliche und interne Bereiche sauber zu trennen.
Bots nach Zweck unterscheiden
„KI-Bot“ ist keine ausreichende Kategorie für eine Zugriffsentscheidung. Such-Crawler, nutzerinitiierte Abrufe, AI-Search-Bots, Trainingscrawler und Werbeprüfer erfüllen unterschiedliche Zwecke. Eine pauschale Sperre kann deshalb zugleich unerwünschtes Training begrenzen und erwünschte Auffindbarkeit in Antwortsystemen abschneiden.
| Bot-Klasse | Zweck | Leitfrage | Regelbasis |
|---|---|---|---|
klassische Suche | Suchindex aufbauen | Soll die Seite in Suchergebnissen auffindbar sein? | offizielle Crawler-Dokumentation |
AI-Search | Inhalte für aktuelle Antworten finden | Ist Zitierbarkeit in Antwortsystemen erwünscht? | offizielle Anbieter-Dokumentation |
Training | Modelle mit Webdaten trainieren | Erlaubt die Website diese Nutzung? | dokumentierte Training-Bots |
Werbung | Anzeigenziele prüfen | Werden entsprechende Kampagnen eingesetzt? | AdsBot-Dokumentation |
Google unterstützt Regeln pro User-agent. Anthropic unterscheidet in seiner Dokumentation unter anderem ClaudeBot für Training, Claude-User für nutzerinitiierte Abrufe und Claude-SearchBot für Suchfunktionen.[2][4] Bot-Namen können sich ändern. Übernehmen Sie sie nur aus der aktuellen offiziellen Dokumentation und prüfen Sie den Stand regelmäßig.
Eine llms.txt ersetzt diese Steuerung nicht. Die verbreiteten Anbieter nutzen sie Stand 2026 nicht als verlässliche Grundlage für Sourcing oder Zitierung. Entscheidend bleiben erreichbarer, serverseitig ausgelieferter Inhalt und die passenden Regeln in der robots.txt.
Ein kleines Änderungsfenster planen
Als Daumenregel gilt: Behandeln Sie diese Datei wie produktive Konfiguration.
Für einen kleinen Änderungszyklus gilt folgende Annahme: Die Sicherung braucht 1 Tag, die Änderung und Gegenprüfung 1 Tag, das Monitoring 2 Tage. Die Rechnung lautet 1 Tag + 1 Tag + 2 Tage = 4 Tage. Das bewusst großzügige Planbeispiel richtet sich an ein Team ohne tägliche SEO-Routine; eine technische Mindestdauer gibt es dafür nicht.
Arbeiten Sie in dieser Reihenfolge:
- Ausgangsdatei sichern: Speichern Sie die abrufbare Fassung mit Datum.
- Eine Regel ändern: So bleibt die Wirkung zuordenbar.
- Datei direkt abrufen: Prüfen Sie Statuscode und sichtbaren Inhalt unter /robots.txt.
- Betroffene URL prüfen: Nutzen Sie bei Google die URL-Prüfung in der Search Console.
- Sitemap gegenlesen: Öffentlich gewünschte URLs dürfen nicht zugleich gesperrt sein.
Dokumentieren Sie Zweck, betroffene Pfade und Prüfergebnis außerhalb der Datei. Wenn die Änderung unerwartet wirkt, stellen Sie die gesicherte Fassung wieder her und untersuchen die Ursache. Eine Sitemap und die robots.txt sollten dieselbe Veröffentlichungsentscheidung ausdrücken.
Eine Änderung ist erst abgeschlossen, wenn die Datei öffentlich abrufbar ist und mindestens eine betroffene sowie eine unbetroffene URL geprüft wurden.
Wenn Crawler-Regeln Teil der Webpräsenz werden
Die Datei allein löst keinen Architekturkonflikt. Wenn Sitemap, Canonicals, interne Links und Crawler-Regeln verschiedene Ziele ausdrücken, braucht die Website eine gemeinsame Veröffentlichungsentscheidung.
Crawler-Zugriff und Seitenarchitektur gemeinsam prüfen
Wir ordnen mit Ihnen öffentliche Inhalte, technische Sperren und Auffindbarkeit zu einer überprüfbaren Webpräsenz.
Erstgespräch vereinbarenHäufige Fragen zur robots.txt
Wo liegt die robots.txt?
Sie liegt im Stammverzeichnis eines Hosts, etwa unter `https://www.beispiel.de/robots.txt`. Regeln gelten nur für den jeweiligen Host, das Protokoll und den Port.[2]
Verhindert die robots.txt eine Indexierung?
Nicht zuverlässig. Eine gesperrte URL kann weiterhin indexiert werden, wenn Google sie über andere Signale kennt.[2]
Gehört die Sitemap in die robots.txt?
Sie kann dort mit einer vollständigen `Sitemap`-URL angegeben werden. Die Zeile ist keiner bestimmten User-agent-Gruppe zugeordnet.[2][3]
Darf ich CSS und JavaScript blockieren?
Ressourcen, die zum Rendern indexierbarer Seiten benötigt werden, sollten für Google erreichbar bleiben.[2]
Schützt die robots.txt einen Staging-Bereich?
Nein. Schützen Sie Staging zusätzlich mit Authentifizierung oder einer technisch getrennten Umgebung.
