Wie man eine robots.txt schreibt: Direktiven, Abgleich und was sie nicht verbergen kann

Eine Crawl-Anweisung, kein Schloss und kein Radiergummi

Google sagt es unumwunden: robots.txt ist kein Mittel, um eine Seite aus Google herauszuhalten, und eine per robots.txt gesperrte Seite kann weiterhin indexiert werden, wenn andere Seiten darauf verlinken. Der Mechanismus ist leicht zu sehen, sobald man ihn ausspricht. Disallow bittet einen wohlerzogenen Crawler, die URL nicht abzurufen. Es sagt nichts darüber, ob die Adresse in einem Index erscheinen darf, und ein Link von einer anderen Seite liefert genug — die URL selbst und den darauf zeigenden Ankertext — um die Seite aufzulisten, ohne sie je herunterzuladen. Heraus kommt der bekannte Suchtreffer mit nackter URL, ohne Titel aus der Seite und ohne Beschreibung, genau dort, wo der Betreiber sie entfernt zu haben glaubte.

Die richtigen Werkzeuge hängen davon ab, was du tatsächlich willst. Um eine Seite aus den Suchergebnissen zu halten, liefere ein noindex — entweder ein meta-robots-Tag im Kopf des Dokuments oder einen X-Robots-Tag-Antwortheader, der auch für Dateien ohne HTML-Kopf funktioniert, etwa PDFs. Um Inhalte überhaupt niemandem zugänglich zu machen, stelle sie hinter eine Authentifizierung; nichts Deklaratives in einer öffentlichen Textdatei hat je Zugriff beschränkt, und RFC 9309 sagt das unumwunden, indem sie das Protokoll als keinen Ersatz für taugliche Sicherheitsmaßnahmen bezeichnet. Und es gibt eine Reihenfolgenfalle für alle, die beides kombinieren: Sperrst du eine URL, ruft der Crawler sie nie ab, sieht folglich nie das dort hinterlegte noindex, und die Seite kann unbegrenzt im Index bleiben. Lass sie crawlen, bis sie herausfällt, und sperre sie danach, falls du noch willst.

Wie der Abgleich funktioniert: Präfixe, zwei Platzhalter und die längste Regel

Jeder Disallow- und Allow-Wert wird als Präfix des URL-Pfads abgeglichen, Disallow: /admin sperrt also /admin, /admin/, /administrator und /admin-tools gleichermaßen. Ein abschließender Schrägstrich engt auf das Verzeichnis ein. Zwei Sonderzeichen verfeinern das: * steht für null oder mehr beliebige Zeichen, und $ verankert das Ende der URL — Disallow: /*.pdf$ sperrt somit jede auf .pdf endende URL und lässt /report.pdf?download=1 erreichbar, weil der Query-String nach dem Anker kommt. Ein abschließender Platzhalter bringt nichts: /* ist dieselbe Regel wie /. Pfade unterscheiden Groß- und Kleinschreibung, /Admin und /admin sind also zwei Regeln, die Direktivnamen selbst hingegen nicht.

Treffen mehrere Regeln auf eine URL zu, gewinnt die spezifischste, und Spezifität bedeutet hier nichts Raffinierteres als die Länge des Regelpfads in Oktetten. Disallow: /reports/ und Allow: /reports/public/ passen beide auf /reports/public/q3.html; das Allow ist länger, die Datei ist also crawlbar. Kehre die Längen um, und das Disallow gewinnt. Sind zwei passende Regeln exakt gleich lang, geht der Gleichstand an die am wenigsten einschränkende, also an das Allow. Die Reihenfolge in der Datei spielt keine Rolle — ein nach einem Allow geschriebenes Disallow hebt es nicht auf, und allein das erklärt einen großen Teil der robots.txt-Dateien, die sich nicht so verhalten, wie ihr Autor sie liest. Zwei weitere Grenzen sind wissenswert: Google liest höchstens 500 Kibibyte und ignoriert alles danach, und ein leerer Disallow-Wert bedeutet, dass nichts gesperrt ist — die idiomatische Schreibweise für eine Gruppe, die alles erlaubt.

Wo die Datei liegt und warum sie bekannt macht, was du verbergen wolltest

Die Ortsregel ist absolut und lässt sich nicht konfigurieren. RFC 9309 verlangt, dass die Regeln in einer Datei namens /robots.txt, komplett kleingeschrieben, im obersten Pfad des Dienstes erreichbar sind, und Google ergänzt, dass sie nur für Host, Protokoll und Port gelten, unter denen die Datei liegt. Lies das genau, denn die Folgen bringen laufend Leute zu Fall. Eine Datei unter https://example.com/robots.txt regelt nichts auf http://example.com, nichts auf https://shop.example.com und nichts auf https://example.com:8443 — jede dieser Adressen ist ein eigener Ursprung und braucht eine eigene Datei. Eine in einem Unterverzeichnis abgelegte Datei wird gar nicht gelesen. Und eine Site hinter einem CDN oder Reverse Proxy ist nur so korrekt wie ihr Routing: Liefert die Plattform an der Wurzel ihre eigene robots.txt aus, kommt deine aus der Anwendung nie zum Zug.

Nun der unbequeme Teil. Die Datei wird jedem ausgeliefert, der sie anfordert, hat keine Authentifizierung und ist mit Abstand das Erste, was ein automatisierter Scanner liest. Disallow: /internal/backup-2019/ zu schreiben verbirgt dieses Verzeichnis nicht — es veröffentlicht seine Existenz, seinen exakten Pfad und die Tatsache, dass du es für verbergenswert hieltest, in einem Dokument, zu dessen Lektüre du das gesamte Internet eingeladen hast. Jedes je geschriebene Aufklärungswerkzeug beginnt genau deshalb dort. Darf ein Pfad nicht erreichbar sein, stelle ihn hinter eine Authentifizierung oder nimm ihn vom öffentlichen Host; soll er lediglich nicht gecrawlt werden, sperre ein breites übergeordnetes Präfix, statt das heikle Blatt zu benennen. Und behandle die Datei wie Code: unter Versionskontrolle halten, Änderungen wie jedes andere Deployment prüfen und nach jeder Plattformmigration kontrollieren — denn ein versehentlich in die Produktion gelangtes Disallow: / ist der schnellste Weg, eine ganze Site aus der Suche zu entfernen, und einer der langsamsten, sich davon zu erholen.

Häufige Fragen

Kann ich mit robots.txt eine private Seite aus Google heraushalten?

Nein, in beiderlei Hinsicht. Google sagt unumwunden, dass robots.txt kein Mittel ist, um eine Seite aus Google herauszuhalten, und eine gesperrte, von irgendeiner anderen Seite verlinkte URL kann allein anhand des Links und seines Ankertexts gelistet werden. Privat ist die Seite in keinem echten Sinn: robots.txt ist nur eine Bitte, die Suchmaschinen befolgen und alles ignoriert, was ein Interesse am Ignorieren hat, und die Datei selbst posaunt den Pfad hinaus. Für die Sichtbarkeit in der Suche nutze ein noindex, ausgeliefert als meta-robots-Tag oder X-Robots-Tag-Header. Für echte Vertraulichkeit nutze Authentifizierung. Das sind zwei getrennte Probleme, und robots.txt löst keines davon.

Teilen sich Subdomains sowie http und https eine robots.txt?

Nein. Die Regeln gelten nur für genau den Host, das Protokoll und den Port, die die Datei ausgeliefert haben; https://example.com, http://example.com, https://www.example.com und https://api.example.com sind also vier getrennte Geltungsbereiche mit vier getrennten Dateien — auch wenn sie auf denselben Server und dasselbe Dokumentenwurzelverzeichnis zeigen. Das ist die zweithäufigste Fehlkonfiguration nach der Ablage in einem Unterverzeichnis, wo die Datei gar nicht gelesen wird. Praktische Folge: Leitest du http auf https um, folgt der Crawler der Umleitung, um die Datei zu holen, faktisch regelt die https-Fassung also beides; leitest du nicht um, hat der http-Ursprung keine Regeln und wird frei gecrawlt.

Ich habe eine Seite gesperrt, sie steht aber weiter in den Ergebnissen. Was nun?

Das ist das erwartete Verhalten, und die Abhilfe besteht darin, die Reihenfolge umzudrehen. Entferne das Disallow, damit die Seite wieder crawlbar wird, füge ein noindex hinzu — meta-robots-Tag oder X-Robots-Tag-Header — und warte, bis die Seite erneut gecrawlt und entfernt wird. Der ursprüngliche Weg scheiterte an einem Zirkel: Solange die URL gesperrt ist, ruft der Crawler sie nie ab, sieht also nie das dort hinterlegte noindex, und der aus eingehenden Links gebaute Eintrag bleibt unbegrenzt bestehen. Ist die Seite aus dem Index gefallen, kannst du das Disallow wieder setzen, um Crawl-Budget zu sparen, auch wenn es zu diesem Zeitpunkt meist wenig einbringt.