Eine kleine Textdatei kann große Wirkung haben: Die robots.txt liegt im Hauptverzeichnis einer Website und gibt Suchmaschinen Regeln fürs Crawling (Abrufen von Seiten) mit. Richtig eingesetzt spart sie Ressourcen, schützt unwichtige Bereiche und reduziert technische Stolperfallen. Falsch eingesetzt blockiert sie wichtige Inhalte oder erschwert Google das Verstehen der Website.
Dieser Leitfaden erklärt robots.txt verständlich und zeigt, wie sich Regeln sauber formulieren, testen und dauerhaft pflegen lassen – ohne Mythen und ohne unnötige Komplexität.
Was die robots.txt wirklich steuert (und was nicht)
Crawling ist nicht Indexierung
Die robots.txt steuert Crawling: Ob ein Bot (z. B. Googlebot) eine URL abrufen darf. Das ist etwas anderes als Indexierung (ob eine Seite in den Suchergebnissen erscheinen kann). Eine blockierte URL kann in Einzelfällen trotzdem als „bekannte URL“ auftauchen, etwa wenn andere Seiten darauf verlinken. Nur: Google kann den Inhalt dann nicht prüfen, keine Signale aus dem Inhalt auslesen und keine Weiterleitungen auf der Seite sehen.
Für Indexierung sind in der Praxis andere Stellschrauben zuständig, zum Beispiel Meta-Robots-Angaben. Passend dazu: Robots Meta Tag: Indexierung gezielt steuern.
Was robots.txt gut kann
- Unwichtige Bereiche vom Crawling ausschließen (z. B. interne Suchergebnisse, Admin-Pfade, Test-Parameter).
- Bot-Zugriffe auf sehr große, wenig hilfreiche URL-Mengen reduzieren (oft relevant bei Shops und Filtern).
- Struktur schaffen, damit Suchmaschinen ihre Zeit auf wichtige Seiten verwenden.
Was robots.txt nicht lösen sollte
- Duplicate Content „wegblocken“: Blockierte Duplikate bleiben oft als URLs im System und können trotzdem Signale streuen.
- Vertrauliche Inhalte schützen: robots.txt ist öffentlich einsehbar und keine Zugriffskontrolle.
- Fehlerhafte URLs „reparieren“: Besser Ursachen beheben (Weiterleitungen, Canonical, saubere URL-Logik).
Aufbau: So liest sich eine robots.txt wie eine klare Anleitung
Die wichtigsten Bausteine
Eine robots.txt besteht aus Regelblöcken. Jeder Block beginnt mit User-agent (für welchen Bot gelten die Regeln?) und enthält dann Anweisungen wie Disallow (nicht crawlen) und Allow (doch crawlen, obwohl der Pfad sonst gesperrt wäre).
Typisches Muster:
- User-agent: Name des Bots (oder * für alle).
- Disallow: Pfad, der nicht abgerufen werden soll.
- Allow: Ausnahme, die wieder erlaubt ist.
- Sitemap: Hinweis, wo die XML-Sitemap liegt (hilfreich, aber nicht zwingend).
Beispiel für eine einfache Website
Das folgende Beispiel ist bewusst konservativ: Es blockiert typische Technikbereiche, lässt aber Inhalte unangetastet. Die konkrete Struktur hängt immer von CMS, Plugins und URL-System ab.
| Zeile | Beispiel | Warum das sinnvoll sein kann |
|---|---|---|
| User-agent | * | Regeln gelten für alle Bots. |
| Disallow | /wp-admin/ | Adminbereich ist nicht für Suchergebnisse gedacht. |
| Allow | /wp-admin/admin-ajax.php | Einige Systeme nutzen diese Datei für Funktionen, die Bots abrufen dürfen. |
| Disallow | /?s= | Interne Suche erzeugt oft viele dünne Seiten. |
| Sitemap | https://beispiel.de/sitemap.xml | Erleichtert das Finden der Sitemap. |
Wichtig: Nicht slicing-by-copying. Jedes Disallow sollte begründet sein, sonst werden schnell wichtige Bereiche ausgeschlossen.
Typische SEO-Fehler mit robots.txt (und wie sie sich vermeiden lassen)
Wichtige Bereiche versehentlich gesperrt
Der häufigste Unfall: ein zu grobes Disallow, das ganze Verzeichnisse blockiert. Klassisch ist das nach einem Relaunch oder beim Aufräumen von Parametern. Ein Symptom ist, dass Google in der Search Console „Blockiert durch robots.txt“ meldet und wichtige Seiten plötzlich nicht mehr gecrawlt werden.
- Vor jeder Änderung eine kurze Liste der wichtigsten Verzeichnisse/Seitentypen erstellen (Startseite, Kategorien, zentrale Ratgeber, Produkte).
- Nach jeder Änderung stichprobenartig prüfen, ob diese URLs abrufbar sind.
- Änderungen versionieren (z. B. im Git oder per Dokumentation), damit ein Rollback möglich ist.
CSS/JS blockieren und Rendering erschweren
Wenn wichtige CSS- oder JavaScript-Dateien blockiert werden, kann Google die Seite schlechter darstellen (rendern). Das muss nicht sofort Rankings kosten, kann aber die Bewertung von Layout, internen Links oder Lazy-Load-Inhalten erschweren. Bei modernen Websites ist es meist sinnvoll, Assets nicht pauschal zu sperren.
Wenn JavaScript eine große Rolle spielt, hilft eine saubere technische Einordnung: JavaScript SEO – Rendering, Crawling und Hydration erklärt.
Parameter-Chaos mit robots.txt „zukleben“
Bei Shops entstehen schnell URL-Varianten durch Filter, Sortierung oder Tracking. Viele versuchen dann, mit robots.txt alle Parameter-URLs zu blockieren. Das kann nach hinten losgehen: Google sieht die URLs weiterhin (z. B. über interne Links), darf sie aber nicht abrufen – damit fehlen Signale, Canonicals werden nicht gesehen, und das System bleibt unaufgeräumt.
Besser ist ein kombiniertes Vorgehen: interne Links auf saubere URLs, Parameter logisch begrenzen und Indexierung gezielt steuern. Für den Parameter-Teil passt: SEO für Parameter-URLs – Tracking & Filter sauber lösen.
Staging/Entwicklung blockiert – und später vergessen
Für Testumgebungen ist eine robots.txt mit „Disallow: /“ beliebt. Problematisch wird es, wenn sie unbemerkt auf die Live-Seite gelangt. Dann darf kein Bot mehr crawlen.
Besseres Sicherheitsnetz:
- Staging per Passwortschutz absichern (echte Zugriffskontrolle).
- Zusätzlich „noindex“ in der Staging-Umgebung verwenden (als zweite Barriere).
- Beim Deployment automatisiert prüfen, ob die Live-robots.txt nicht „Disallow: /“ enthält.
Praktischer Ablauf: von Analyse bis Livegang
Vorarbeit: Was soll überhaupt gecrawlt werden?
Bevor Regeln entstehen, braucht es Klarheit über Seitentypen. Eine einfache Einteilung hilft:
- Indexierbare Seiten: Inhalte, die in Google landen sollen (z. B. Ratgeber, Kategorien, Produkte).
- Hilfsseiten: nützlich für Nutzer, aber selten für Google (z. B. Warenkorb, Login, Konto).
- Technik/duplikatnah: Parameter, interne Suche, Druckansichten, Session-IDs.
Diese Einteilung vermeidet Aktionismus: robots.txt wird dann nicht „irgendwie strenger“, sondern folgt einer nachvollziehbaren Strategie.
Die kurze Schrittfolge zum sicheren Update
- URLs sammeln: wichtigste Inhalte + typische Problem-URLs (Suche, Filter, Tracking).
- Regeln in Klartext formulieren: „Welcher Pfad soll nicht gecrawlt werden – und warum?“
- robots.txt anpassen (kleine Schritte statt Komplett-Umbau).
- Testen: einzelne Beispiel-URLs gegen die neue Regel prüfen (dürfen/dürfen nicht).
- Live stellen und in den Tagen danach kontrollieren, ob unerwartete Blockaden auftreten.
Entscheidungshilfe für Shops, Blogs und große Portale
Welche Bereiche sind Kandidaten für Disallow?
Die folgenden Beispiele sind typische Kandidaten. Ob sie wirklich gesperrt werden sollten, hängt von der Website ab (und davon, ob dort Inhalte liegen, die organisch ranken sollen).
| Seitentyp | Beispiel | Typische Entscheidung |
|---|---|---|
| Interne Suche | /?s=begriff | Oft vom Crawling ausschließen, wenn viele dünne Seiten entstehen. |
| Warenkorb/Checkout | /cart/ /checkout/ | Meist nicht relevant für organische Rankings. |
| Account/Login | /my-account/ | Nicht für Suchergebnisse gedacht. |
| Sortierung/Tracking | ?sort=price ?utm_source=… | Eher über saubere interne Links und Canonicals lösen; robots.txt nur gezielt. |
| Admin-/Systempfade | /wp-admin/ | Fast immer blockieren. |
Verschachtelte Entscheidungshilfe für Parameter und Filter
- Sind Filter-/Sortierseiten ein eigenes SEO-Ziel (z. B. „Sneaker in blau Größe 43“)?
- Ja: Nicht pauschal per robots.txt blockieren. Stattdessen eindeutige, verlinkte Zielseiten definieren (z. B. Kategorien/Filterseiten) und den Rest sauber begrenzen.
- Nein: Prüfen, ob diese URLs intern stark verlinkt sind.
- Stark verlinkt: Erst interne Links entschärfen (keine indexierbaren Parameter-Links), dann über Indexierungs-Steuerung nachdenken.
- Kaum verlinkt: robots.txt kann helfen, Crawling-Rauschen zu reduzieren, aber nur mit Test-URLs und Monitoring.
- Gibt es einen klaren Canonical-Plan (Hinweis auf die Haupt-URL)?
- Ja: Canonical darf von Google gesehen werden – also diese Seiten nicht blockieren, wenn der Canonical auf der Seite liegt.
- Nein: Erst Canonicals und interne Verlinkung klären, dann robots.txt ergänzen.
Kontrolle und Pflege: So bleibt die robots.txt langfristig sauber
Warnsignale, die häufig übersehen werden
- Plötzlicher Rückgang gecrawlter Seiten oder stark sinkende Sichtbarkeit nach einem Deploy.
- Viele „Blockiert durch robots.txt“-Hinweise für eigentlich wichtige URLs.
- Wichtige Ressourcen (CSS/JS) werden nicht abgerufen, die Darstellung wirkt für Google unvollständig.
Ein sinnvoller Rhythmus für Reviews
robots.txt ist kein Einmal-Projekt. Bei jeder größeren Änderung an Navigation, Filtern, Tracking oder CMS-Plugins entstehen neue URL-Typen. Ein kurzer Review in festen Abständen (z. B. im Rahmen technischer Wartung) verhindert, dass Regeln veralten oder versehentlich zu streng werden.
Hilfreich ist außerdem ein regelmäßiger Blick auf grundlegende technische Hygiene, etwa Weiterleitungen und Fehlerseiten. Dazu passen: SEO-Redirects richtig nutzen – 301, 302 und typische Fehler und SEO für 404-Seiten – Nutzer retten, Rankings schützen.
Grenzfall: Wenn „Disallow“ nicht reicht
Wenn Seiten nicht nur nicht gecrawlt, sondern auch nicht in Suchergebnissen erscheinen sollen, braucht es meist eine Kombination aus Maßnahmen: interne Verlinkung anpassen, Meta-Robots (noindex) nutzen, Canonicals sauber setzen oder Seiten ganz entfernen. robots.txt ist dafür nur ein Teil des Werkzeugkastens.
Merksatz: robots.txt ist am besten, wenn sie klein, begründet und testbar bleibt. Je mehr sie als „Müllabfuhr“ für strukturelle Probleme herhalten muss, desto höher ist das Risiko, wichtige Inhalte zu blockieren.
