Zuletzt aktualisiert: 02.05.2026
Die robots.txt ist eine einfache Textdatei im Root einer Domain, die Suchmaschinen-Crawlern mitteilt, welche URLs sie nicht abrufen dürfen. Sie steuert Crawling, nicht Indexierung – und ist eine der häufigsten Ursachen für SEO-Pannen, wenn sie versehentlich produktive Pfade blockiert.
Die robots.txt ist eine Textdatei nach dem Robots-Exclusion-Protocol, die im Root-Verzeichnis einer Domain liegt und Crawlern Regeln vorgibt, welche URL-Pfade sie abrufen oder vermeiden sollen.
Eine fehlerhafte robots.txt ist einer der Klassiker des technischen SEO: Eine einzige Zeile kann eine ganze Website aus dem Google-Index entfernen. Wir zeigen die Syntax, die häufigsten Fehler und Live-Beispiele aus großen Setups – inklusive des Unterschieds, den Anfänger zwischen Disallow und noindex regelmäßig falsch machen.
Wofür ist die robots.txt zuständig?
Die robots.txt steuert ausschließlich, ob ein Crawler eine URL abrufen darf. Sie steuert nicht, ob diese URL im Index landet. Wenn eine per Disallow gesperrte URL über externe Links bekannt wird, kann Google sie ohne den eigentlichen Inhalt indexieren – mit dem Hinweis „Für diese Seite sind keine Informationen verfügbar“.
Sinnvolle Einsatzfälle sind: interne Suchergebnis-Seiten ausschließen, Filter-URL-Parameter blockieren, Test-/Staging-Bereiche aussperren, große Mediendateien außerhalb des Webauftritts (PDF-Archive) sparsam crawlen lassen. Sensible Inhalte gehören nicht in robots.txt – sie wären über die Datei prinzipiell auffindbar.
Für Indexierungssteuerung ist der Meta-Robots-Tag (noindex) oder der HTTP-Header X-Robots-Tag zuständig. Wer beides verwechselt, riskiert paradoxe Effekte: Eine per Disallow gesperrte URL bekommt das noindex-Tag nie zu sehen, weil Google den Body gar nicht erst abruft.
Wie ist die robots.txt syntaktisch aufgebaut?
Die Syntax ist einfach: Pro Block ein User-agent, gefolgt von einer Liste an Disallow– und Allow-Direktiven. Pfade werden absolut ab dem Domain-Root angegeben. Wildcards (*) und Zeilenende-Anker ($) werden von Google unterstützt, von anderen Crawlern teilweise nicht.
Die Datei muss zwingend als https://example.com/robots.txt erreichbar sein, mit HTTP-Status 200 und MIME-Type text/plain. Jeder andere Statuscode (403, 404, 500) wird unterschiedlich interpretiert: 404 heißt für Google „keine Restriktionen“, 5xx wird als „temporär nicht crawlen“ gewertet.
Eine Sitemap-Direktive (Sitemap: https://example.com/sitemap.xml) ist optional, aber sinnvoll. Sie hilft Crawlern, die Sitemap unabhängig von der Search-Console-Anmeldung zu finden.
| Direktive | Bedeutung | Beispiel |
|---|---|---|
| User-agent | Welcher Crawler ist gemeint | User-agent: Googlebot |
| Disallow | Pfad nicht crawlen | Disallow: /admin/ |
| Allow | Ausnahme zur Disallow-Regel | Allow: /admin/preview |
| Sitemap | Hinweis auf Sitemap-URL | Sitemap: https://example.com/sitemap.xml |
| Crawl-delay | Pause zwischen Requests (von Google ignoriert) | Crawl-delay: 5 |
Welche Fehler in der robots.txt sind besonders häufig?
Fehler 1: Pauschales Disallow: / aus der Staging-Phase nicht entfernt. Das Ergebnis: nach Live-Schaltung crawlt Google die Site nicht, der Index leert sich. Wir haben das schon bei sechsstelligen Sites gesehen – inklusive Sichtbarkeitsverlust von 80 Prozent in 14 Tagen.
Fehler 2: Disallow für Pfade, die noindex-Tags tragen. Google sieht das noindex nie, weil die URL nicht abgerufen wird. Die richtige Reihenfolge ist: erst noindex setzen, warten bis Google die Seite aus dem Index nimmt, dann (optional) per Disallow blockieren.
Fehler 3: Verwendung der robots.txt als Sicherheits-Tool. Sensible Pfade in der robots.txt zu listen ist ein Hinweis für Angreifer. Authentifizierung gehört auf Server-Ebene, nicht in eine öffentlich lesbare Textdatei.
Wie teste ich Änderungen an der robots.txt sicher?
Vor dem Live-Push: Die Datei lokal mit dem robots.txt-Tester der alten Search Console oder einem Open-Source-Tool wie robotstxt-spec-validator prüfen. Beide melden Syntaxfehler und unzulässige Direktiven sofort.
Nach dem Push: In der GSC im URL-Inspection-Tool eine Ziel-URL eintragen und prüfen, ob „Crawling erlaubt: Ja“ angezeigt wird. Stichprobenweise mehrere URLs testen (Startseite, Kategorie, Produkt, Filter).
Empfohlener Workflow: Änderungen an der robots.txt versionieren (z. B. via Git im Theme-Repo) und nur über einen Pull Request mit Code-Review live nehmen. So vermeidet man Solo-Edits direkt im Production-Filesystem, die niemand mehr nachvollziehen kann.
Häufige Mythen über das Thema
Die folgenden Missverständnisse begegnen uns in fast jedem Audit-Workshop. Wer sie kennt, vermeidet typische Fehler.
Realität: Disallow steuert Crawling, nicht Indexierung. Eine Disallow-URL kann weiter im Index erscheinen, wenn andere Seiten auf sie verlinken.
Realität: Googlebot ignoriert Crawl-delay seit 2019 vollständig. Die Crawl-Frequenz wird stattdessen über die GSC-Einstellungen gesteuert.
Realität: Sie ist öffentlich lesbar. Sensible Pfade in robots.txt zu listen, gibt Angreifern eine Karte – Authentifizierung gehört auf Server-Ebene.
Realität: Nein – das ist eine valide Konfiguration. Google behandelt das Fehlen wie „keine Restriktionen“ und crawlt normal.
Realität: Beliebig viele User-agent-Blöcke sind erlaubt. Spezifische Crawler erhalten ihre eigenen Regeln, der Rest fällt unter
User-agent: *.Welche Best Practices haben sich für komplexe Sites bewährt?
Bei großen E-Commerce- oder Marktplatz-Sites empfehlen wir eine modulare robots.txt: Pro Seitentyp ein eigener Block mit klar dokumentierter Begründung. Filter-URLs (etwa /produkte?farbe=rot) gehören in einen Disallow-Block, paginierte Listen-URLs nur dann, wenn ein sauberer Canonical existiert. Ein Kommentar pro Block hilft im Re-Audit, alte Entscheidungen nachzuvollziehen, statt sie durch Reverse Engineering zu rekonstruieren.
Bei Multi-Brand- oder Multi-Domain-Setups empfiehlt sich die Versionierung der robots.txt im Repository. Jede Änderung läuft als Commit durch das übliche Code-Review. Für Staging-Umgebungen separate robots.txt-Files mit pauschalem Disallow nutzen – und vor dem Live-Push automatisiert prüfen, dass die Production-Variante aktiv ist. Wir nutzen dafür einen einfachen Pre-Deploy-Check, der die ersten 200 Bytes der Datei mit einer Whitelist vergleicht.
Bei mehrsprachigen Sites mit eigenen Hostnames pro Land (z. B. example.de, example.fr) liegt jede robots.txt unabhängig im jeweiligen Domain-Root. Vermeintliche zentrale Verwaltung über includes oder symbolische Links sind eine Fehlerquelle, weil sie Änderungen unsichtbar machen. Lieber redundant pflegen als zentralisiert verlieren – die wenigen Minuten zusätzlicher Arbeit sparen tagelange Diagnose nach unerklärlichen Index-Verlusten.
Wie verhalte ich mich bei Konflikten zwischen Stakeholdern?
Konflikte um die robots.txt entstehen typischerweise zwischen Marketing (will Sichtbarkeit), Entwicklung (will Kontrolle) und Datenschutz (will keine Indexierung sensibler Pfade). Eine pragmatische Lösung ist die Trennung: produktiv relevante Pfade wandern nach Marketing-Vorgabe, technische Backend-Pfade nach Engineering-Vorgabe, sensible Pfade fallen unter Datenschutz – jede Gruppe verwaltet ihren Block.
Schwieriger sind Pfade mit überlappendem Interesse: ein Produktfilter könnte Sichtbarkeit bringen, aber auch Crawl-Budget verbrennen. Hier hilft ein einfaches Entscheidungsmodell: liefert die URL eindeutigen, aggregierten Mehrwert (z. B. eine Kategorie nach Marke), darf sie indexiert werden. Liefert sie nur eine Permutation bestehender Listings, gehört sie blockiert.
Im Zweifel gilt: lieber Disallow + Beobachten als Allow + Risiko. Eine spätere Lockerung ist trivial, ein nachträgliches Aufräumen indexierter Schrott-URLs kann Wochen dauern. Wir dokumentieren jede Stakeholder-Entscheidung als Kommentar in der robots.txt – so bleibt der Kontext bei späteren Reviews erhalten.
Eine letzte Komponente ist das Eskalations-Pfad-Schema: wer entscheidet bei Konflikt? Üblich ist ein dreistufiges Modell – SEO-Lead trifft Vorschlag, Engineering-Lead validiert technische Machbarkeit, Datenschutzbeauftragter erteilt Veto bei Compliance-Risiko. Diese Reihenfolge dokumentiert man einmal und referenziert sie bei künftigen Diskussionen. Ohne diesen klaren Pfad versickern robots.txt-Änderungen oft monatelang in E-Mail-Threads, während die Sichtbarkeit weiter durch Müll-URLs verwässert wird.
Weiterführende Artikel auf Digital Ultras
Folgende Beiträge vertiefen einzelne Aspekte und passen direkt in dein nächstes Audit:
- Wie ein vollständiges SEO Audit abläuft
- Strukturierte SEO Analyse Schritt für Schritt
- Local SEO Grundlagen für lokale Sichtbarkeit
- E-E-A-T und seine technische Umsetzung
Häufige Fragen
Wo muss die robots.txt liegen?
Im Root-Verzeichnis der Domain unter https://example.com/robots.txt. Subdomains und Subdirectories haben keine Wirkung – pro Hostname genau eine Datei.
Was passiert, wenn keine robots.txt vorhanden ist?
Google interpretiert das als „keine Einschränkungen“ und crawlt normal. Eine fehlende Datei ist kein SEO-Problem.
Wie groß darf die robots.txt sein?
Google liest maximal 500 KiB. Größere Dateien werden bis zu dieser Grenze ausgewertet, der Rest ignoriert. Praxisrelevant ist diese Grenze fast nie.
Kann ich Bilder per robots.txt blockieren?
Ja, indem du den Bild-Crawler (Googlebot-Image) gezielt aussperrst oder Bildverzeichnisse ausschließt. Das verhindert die Image-Search-Anzeige.
Wie unterscheidet sich die robots.txt von noindex?
robots.txt steuert Crawling. noindex steuert Indexierung. Beides darf nicht gleichzeitig auf dieselbe URL angewendet werden, sonst sieht Google das noindex nie.
Wie oft schaut Google in die robots.txt?
Typischerweise alle 24 Stunden, bei großen Sites häufiger. Es gibt keinen Push-Mechanismus – Änderungen wirken nach dem nächsten Abruf.
Kann ich verschiedene Crawler unterschiedlich behandeln?
Ja. Pro User-agent ein eigener Block, am Ende ein User-agent: * für den Rest. Reihenfolge zählt – spezifischer Block schlägt allgemeinen.
Was bedeutet die Wildcard * in der robots.txt?
Sie steht für eine beliebige Zeichenfolge. Disallow: /*?utm_ sperrt zum Beispiel alle URLs mit utm-Parameter.
Fazit
Die robots.txt ist klein, aber wirkungsvoll. Eine einzige falsche Zeile kann eine Website wochenlang aus dem Index nehmen, eine saubere Konfiguration spart Crawl-Budget und schützt das Frontend vor Filter-Müll im Index. Wer den Unterschied zwischen Crawling- und Indexierungssteuerung versteht und Änderungen versioniert ausrollt, vermeidet die teuersten SEO-Pannen.
