Disallow vs. Allow in der robots.txt richtig einsetzen

Disallow und Allow sind die beiden zentralen Direktiven der robots.txt – und gleichzeitig die häufigste Fehlerquelle. Dieser Artikel erklärt, wie beide zusammenspielen und welche Regel bei einem Konflikt tatsächlich gewinnt.

Warum diese beiden Direktiven ständig verwechselt werden

Auf den ersten Blick wirken Disallow und Allow wie simple Gegensätze – in der praktischen Anwendung entstehen die meisten Fehler aber genau an den Stellen, an denen beide Regeln gleichzeitig auf dieselbe URL zutreffen könnten. Wer beide Direktiven nur isoliert betrachtet, statt ihr Zusammenspiel bei sich überschneidenden Pfad-Mustern zu verstehen, konfiguriert leicht eine robots.txt, die sich anders verhält als beabsichtigt.

Diese Verwechslung betrifft nicht nur Einsteiger: Auch erfahrene Entwickler unterschätzen gelegentlich, wie genau die Auswertungslogik zwischen mehreren zutreffenden Regeln tatsächlich funktioniert, weil sie sich in der täglichen Praxis nur selten mit mehrdeutigen Regelkombinationen auseinandersetzen müssen.

Die Grundregel: Spezifischer gewinnt

Wenn sowohl eine Allow- als auch eine Disallow-Regel auf denselben Pfad zutreffen, gewinnt bei den meisten modernen Crawlern (u. a. Googlebot) die spezifischere Regel – also die mit dem längeren, genaueren Pfad-Präfix. Das ist ein häufiges Missverständnis: Es geht nicht um die Reihenfolge der Zeilen in der Datei, sondern um die Länge bzw. Genauigkeit des passenden Pfad-Musters.

Warum „spezifischer" nicht dasselbe ist wie „länger"

Die genaue Definition von „spezifischer" bezieht sich auf die Länge des tatsächlich passenden Pfad-Präfixes vor Berücksichtigung von Wildcards, nicht auf die reine Zeichenanzahl der geschriebenen Regel. Ein kurzer, aber präziser Pfad ohne Wildcard kann daher spezifischer sein als eine lange Regel mit mehreren Sternchen, die zwar mehr Zeichen enthält, aber durch die Wildcards tatsächlich einen breiteren URL-Bereich abdeckt. Im Zweifel hilft ein Blick in die offizielle Dokumentation der jeweiligen Suchmaschine oder ein praktischer Test mit konkreten Beispiel-URLs.

Beispiel: Ausnahme innerhalb eines gesperrten Bereichs

User-agent: *
Disallow: /downloads/
Allow: /downloads/whitepaper.pdf

Hier ist grundsätzlich der gesamte Ordner /downloads/ gesperrt, aber eine einzelne Datei darin ausdrücklich freigegeben. Da /downloads/whitepaper.pdf die spezifischere Regel ist, gewinnt sie gegenüber dem allgemeineren Disallow: /downloads/ – die Datei bleibt crawlbar.

Was „Disallow: /" wirklich bedeutet

Die wohl folgenreichste Zeile in der gesamten robots.txt ist Disallow: / unter User-agent: *. Sie blockiert die komplette Website für alle nicht explizit genannten Crawler. Diese Zeile findet sich überraschend häufig versehentlich in produktiven robots.txt-Dateien – meist als Überbleibsel aus einer Staging- oder Entwicklungsumgebung, das beim Go-Live vergessen wurde, zu entfernen.

Ein leeres Disallow ist keine Sperre

Ein oft übersehenes Detail: Disallow: ohne jeden Wert bedeutet nicht "alles sperren", sondern das genaue Gegenteil – "nichts sperren". Wer versehentlich ein / vergisst, öffnet also unbeabsichtigt alles, was eigentlich geschlossen werden sollte.

Reihenfolge der Zeilen spielt (meist) keine Rolle

Anders als man intuitiv annehmen könnte, kommt es bei den meisten modernen Crawler-Implementierungen nicht darauf an, ob Allow vor oder nach Disallow steht – ausschlaggebend ist die Pfad-Spezifität. Ältere oder weniger standardkonforme Crawler werten die Regeln allerdings teils schlicht in Zeilenreihenfolge aus. Wer maximale Kompatibilität möchte, sollte spezifischere Allow-Regeln daher dennoch möglichst direkt nach der zugehörigen Disallow-Regel platzieren.

Diese defensive Reihenfolge kostet nichts und schafft zusätzliche Sicherheit gegenüber weniger verbreiteten Bots, deren genaue Auswertungslogik nicht immer öffentlich dokumentiert ist.

Praxisbeispiel: Nachrichtenportal „Regio Nachrichten"

Ein fiktives, lokales Nachrichtenportal wollte verhindern, dass die interne Druckansicht (/drucken/...) sowie kommentierte Beitrags-Duplikate (/beitrag/*/kommentare) gecrawlt werden, gleichzeitig aber sicherstellen, dass ein wichtiges PDF-Dossier innerhalb eines ansonsten gesperrten Archivordners weiterhin auffindbar bleibt:

User-agent: *
Disallow: /drucken/
Disallow: /archiv/
Allow: /archiv/dossier-wahl-2024.pdf
Allow: /

Ergebnis: Druckansichten und das allgemeine Archiv wurden vom Crawling ausgeschlossen, während das einzelne, weiterhin relevante PDF-Dossier gezielt erreichbar blieb.

Groß- und Kleinschreibung nicht vergessen

Sowohl Disallow- als auch Allow-Pfade werden case-sensitive ausgewertet. Disallow: /Warenkorb/ blockiert nicht dieselbe URL wie /warenkorb/. Wer seine URL-Struktur nicht konsistent in Kleinbuchstaben hält, sollte hier besonders genau prüfen, welche Schreibweise tatsächlich in der Live-Umgebung verwendet wird.

Disallow für Parameter-URLs

Ein häufiger praktischer Anwendungsfall ist das Ausschließen von Filter- und Sortierparametern, die technisch endlos viele, inhaltlich fast identische URLs erzeugen können – etwa bei Online-Shops mit Facettensuche:

User-agent: *
Disallow: /*?sort=
Disallow: /*?farbe=
Disallow: /*&farbe=

Wichtig dabei: Da Wildcards und das Verhalten bei mehreren Parametern in einer URL nicht von allen Crawlern identisch interpretiert werden, lohnt sich nach dem Einrichten ein Test mit tatsächlichen, produktiven Beispiel-URLs, um sicherzustellen, dass die Regel wie beabsichtigt greift.

Disallow für Session-IDs und Tracking-Parameter

Neben Filter- und Sortierparametern erzeugen auch Session-IDs oder Marketing-Tracking-Parameter (z. B. ?utm_source=...) technisch unzählige, inhaltlich identische URL-Varianten derselben Seite. Diese lassen sich grundsätzlich ebenfalls per Disallow ausschließen, allerdings mit Vorsicht: Da Tracking-Parameter oft für Kampagnen-Auswertungen relevant sind und die zugehörigen Landingpages weiterhin normal crawlbar bleiben sollen, ist hier ein kombinierter Ansatz aus Canonical-Tag (statt Disallow) meist die robustere Lösung, um sowohl Tracking-Daten zu erhalten als auch Duplicate Content zu vermeiden.

Kombination mit Canonical-Tags

Disallow-Regeln für Parameter-URLs ersetzen keine rel="canonical"-Angabe. Während Disallow das Crawlen verhindert, signalisiert ein Canonical-Tag zusätzlich, welche URL-Variante als die „echte", zu indexierende Version gelten soll. Beide Mechanismen ergänzen sich sinnvoll: Canonical für Varianten, die weiterhin gecrawlt werden dürfen, Disallow für Varianten, die überhaupt nicht mehr besucht werden sollen, weil sie z. B. reine technische Duplikate ohne eigenen Mehrwert sind.

In der Praxis führt die Verwechslung beider Konzepte häufig zu unnötigem Aufwand: Wer versucht, jede einzelne Duplicate-Content-Variante über eine eigene Disallow-Regel zu unterbinden, statt konsequent Canonical-Tags einzusetzen, pflegt schnell eine unübersichtlich lange und fehleranfällige robots.txt, obwohl das eigentliche Problem mit einem einzigen, konsistent gesetzten Tag pro Seite gelöst wäre.

Praktische Kombinationsmuster

In der Praxis bewährt sich oft ein Grundmuster: zunächst ein grobes Disallow für einen gesamten technischen Bereich, danach gezielte Allow-Ausnahmen für einzelne, weiterhin relevante Unterseiten. Dieses Muster ist wartungsfreundlicher als der umgekehrte Ansatz (alles einzeln auflisten), weil neue, standardmäßig unkritische Unterseiten innerhalb des gesperrten Bereichs automatisch mit gesperrt bleiben, statt vergessen zu werden.

Testen einzelner URLs gegen die Regeln

Bevor eine neue Disallow/Allow-Kombination live geschaltet wird, lohnt sich ein gezielter Test gegen einige repräsentative, tatsächlich existierende URLs der eigenen Website – nicht nur gegen theoretische Beispiel-Pfade. Gerade bei verschachtelten Regeln mit mehreren Wildcards zeigt sich häufig erst im konkreten Test, dass eine Regel entweder zu weit oder zu eng gefasst ist und versehentlich auch benachbarte, eigentlich nicht gemeinte Pfade betrifft oder ausschließt.

Sinnvoll ist es, für diesen Test bewusst URLs aus unterschiedlichen Bereichen der Website auszuwählen – nicht nur aus dem Bereich, der eigentlich geändert werden soll, sondern auch aus benachbarten, eigentlich unveränderten Bereichen. So lässt sich ausschließen, dass eine neue, breiter gefasste Regel unbeabsichtigt auch dort greift, wo bislang eine andere, unabhängige Regel galt.

Auswirkungen auf das Crawling-Budget

Bei sehr großen Websites mit Millionen von URLs ist das sogenannte Crawling-Budget – die begrenzte Anzahl an Seiten, die eine Suchmaschine in einem bestimmten Zeitraum crawlt – ein relevanter Faktor. Gezielte Disallow-Regeln für technische, für Suchmaschinen irrelevante Bereiche (interne Suche, Sortier-Parameter, Session-IDs in der URL) sorgen dafür, dass dieses begrenzte Budget stattdessen für tatsächlich relevante, indexierungswürdige Inhalte verwendet wird, statt in technischen Duplikaten zu versickern.

Für kleinere und mittlere Websites mit wenigen Tausend Seiten spielt das Crawling-Budget in der Praxis kaum eine Rolle – Google verfügt hier in aller Regel über ausreichend Kapazität, um sämtliche relevanten Seiten regelmäßig zu erfassen. Die gezielte Steuerung über Disallow-Regeln gewinnt daher vor allem bei sehr großen, dynamisch generierten Websites an praktischer Bedeutung.

Häufig gestellte Fragen

Was passiert, wenn Allow und Disallow exakt gleich spezifisch sind?

In diesem seltenen Fall gewinnt bei Google die Allow-Regel. Andere Crawler können sich abweichend verhalten, weshalb Mehrdeutigkeiten möglichst vermieden werden sollten.

Sollte ich lieber zu restriktiv oder zu offen konfigurieren?

Im Zweifel eher zu offen: Eine zu restriktive robots.txt kann wichtige Inhalte dauerhaft von der Sichtbarkeit ausschließen, während eine zu offene Konfiguration meist nur unnötiges Crawling-Budget kostet – ein deutlich geringeres Risiko.

Kann ich mit Disallow auch Dateitypen sperren?

Ja, mit Wildcards, z. B. Disallow: /*.pdf$ für alle PDF-Dateien unabhängig vom Verzeichnis.

Wirkt Disallow rückwirkend auf bereits indexierte Seiten?

Nein. Disallow verhindert nur zukünftiges Crawling. Bereits indexierte Seiten können weiterhin in der Suche erscheinen, bis Google sie regulär erneut prüft oder sie anderweitig entfernt werden.

Sollte ich lieber viele kleine oder wenige große Disallow-Regeln verwenden?

Wenige, klar strukturierte Regeln sind in der Regel wartungsfreundlicher und weniger fehleranfällig als viele einzelne, sehr spezifische Zeilen, die bei jeder URL-Struktur-Änderung angepasst werden müssen.

Fazit

Wer die Priorisierungslogik zwischen Disallow und Allow versteht, kann gezielt Ausnahmen definieren, ohne ganze Bereiche pauschal freizugeben oder zu sperren. Im Zweifel hilft ein Blick in die konkrete Regel-Auswertung, um Überraschungen zu vermeiden.