Robots.txt Ratgeber

Robots.txt Wildcards und Regelpriorität: *, $ und längster Treffer

Wie * und $ in robots.txt funktionieren, warum die Zeilenreihenfolge nicht entscheidet und wie Konflikte zwischen Allow und Disallow aufgelöst werden.

Von Robots.txt Tools Editorial TeamZuletzt geprüft am 2026-09-132 Min. Lesezeit
Robots.txt Wildcards und Regelpriorität: *, $ und längster Treffer

robots.txt folgt nicht dem Prinzip „die letzte Zeile gewinnt“. Passen mehrere Allow- und Disallow-Regeln, ist die spezifischste Übereinstimmung entscheidend. RFC 9309 beschreibt die spezifischste Regel als den passenden Pfad mit der größten Länge und bevorzugt bei gleichwertigem Konflikt Allow.

Google dokumentiert denselben praktischen Ansatz und unterstützt in Pfadregeln * und $.

Bedeutung von * und $

  • * steht für null oder mehr Zeichen;
  • $ markiert das Ende der URL.
User-agent: *
Disallow: /*.pdf$

Damit werden Pfade erfasst, die auf .pdf enden. Ohne $ ist das Muster breiter.

Ein * am Ende ist oft überflüssig

Disallow: /private

und

Disallow: /private*

haben bei Google praktisch einen sehr ähnlichen Bereich. Wenn wirklich ein Verzeichnis gemeint ist, macht /private/ die Absicht klarer.

Längster Treffer schlägt Zeilenreihenfolge

User-agent: *
Disallow: /products/
Allow: /products/public/

Für /products/public/widget passen beide Regeln. /products/public/ ist spezifischer und erlaubt daher die URL. Das Vertauschen der Zeilen sollte nicht als Steuerungsmethode betrachtet werden.

Gleichstand zwischen Allow und Disallow

Bei gleich spezifischen Regeln empfiehlt RFC 9309 Allow. Trotzdem sind eindeutige Regeln wartbarer als Konstruktionen, die bewusst auf einen Gleichstand setzen.

Pfade sind groß-/kleinschreibungssensitiv

Disallow: /Admin/

ist nicht zwingend dasselbe wie:

Disallow: /admin/

Teste die tatsächlich ausgelieferten Varianten.

Parameter und E-Commerce

Muster wie:

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

können bei mehreren Parametern in anderer Reihenfolge unerwartet reagieren. Bei Facettennavigation sollten URL-Architektur, interne Links und Canonicals zusammen mit robots.txt geplant werden.

Einfache Regeln sind wartbarer

Disallow: /interne-suche/

ist leichter zu verstehen als eine Sammlung cleverer Wildcard-Ausdrücke. Verwende Wildcards nur, wenn ein stabiles Präfix nicht reicht.

Reale URLs testen

Für:

User-agent: *
Disallow: /reports/
Allow: /reports/public/
Disallow: /*.csv$

solltest du mindestens prüfen:

  • /reports/private/quarterly
  • /reports/public/overview
  • /downloads/data.csv
  • /downloads/data.csv?preview=1
  • /REPORTS/private/quarterly

So werden Annahmen über Präfixe, Großschreibung, Endanker und Überschneidungen sichtbar.

Empfohlener Ablauf

  1. Policy in normaler Sprache formulieren.
  2. Einfachstes Präfix wählen.
  3. * oder $ nur bei Bedarf ergänzen.
  4. Erlaubte und blockierte Test-URLs festlegen.
  5. Syntax validieren.
  6. URLs für den richtigen User-agent testen.
  7. Live-/robots.txt nach Deployment prüfen.
  8. Logs beobachten.

Spezifität ist wichtiger als Zeilenposition. Wildcards sparsam einsetzen und Überschneidungen immer mit echten URLs testen.

Passende Anleitungen