Eine robots.txt erstellen und richtig steuern

Eine robots.txt ist in fünf Minuten geschrieben, eine falsche Zeile nimmt ganze Bereiche aus der Suche. Die Datei steuert das Crawling, nicht die Indexierung. Dieser Leitfaden zeigt Syntax, Praxis-Rezepte und die häufigsten Fehler, sauber eingeordnet ins technische SEO.

Kaum eine Datei ist so klein und richtet so viel an. In Projekten begegnet uns immer wieder dieselbe Geschichte: Eine einzige Zeile in der robots.txt kostet über Monate Sichtbarkeit, ohne dass jemand die Ursache auf dem Schirm hat. Das Thema wirkt trivial, und genau darin liegt die Gefahr. Wir sehen bis heute schwerwiegende Fehler, die ganze Websites im Ranking zurückwerfen, oft bei Teams, die ansonsten sauber arbeiten.

Der Wissensbedarf ist real, und die Mühe lohnt sich. Wer die robots.txt beherrscht, vermeidet die teuren Unfälle und gewinnt zugleich echte Steuerung: Crawl-Kapazität landet dort, wo sie zählt, heikle Bereiche bleiben sauber geregelt, und selbst in kniffligen Konstellationen aus Parametern, Filtern und KI-Crawlern behalten Sie die Kontrolle. Der Rest ist Handwerk, und genau das zeigen die folgenden Abschnitte.

Was die robots.txt steuert, und was nicht

Die robots.txt ist eine einfache Textdatei im Stammverzeichnis einer Website. Sie ist die erste Adresse, die eine Suchmaschine beim Besuch abruft, und sie folgt dem Robots Exclusion Protocol, das seit 2022 als RFC 9309 offiziell standardisiert ist. Über wenige Zeilen legen Sie fest, welche Bereiche ein Crawler abrufen darf und welche nicht.

Der wichtigste Satz zuerst, weil an ihm die meisten Konfigurationen scheitern: Die robots.txt regelt den Zugriff, nicht die Sichtbarkeit im Index. Sie entscheidet über das Crawling, also darüber, ob eine Suchmaschine eine URL überhaupt aufruft. Ob diese URL anschließend in den Suchindex aufgenommen wird, ist ein eigener, nachgelagerter Schritt.

Der Unterschied ist keine Wortklauberei. Eine per Disallow gesperrte URL kann trotzdem in den Ergebnissen auftauchen, wenn andere Seiten auf sie verlinken. Die Suchmaschine kennt dann die Adresse, nicht aber den Inhalt, und zeigt den Treffer ohne Beschreibung. Wer eine Seite dauerhaft aus dem Index nehmen will, braucht dafür Noindex, nicht die robots.txt. Wie beide Instrumente zusammenspielen und wann welches greift, vertieft der Beitrag Indexierung richtig steuern.

Wo die robots.txt liegen muss

Die Datei gehört exakt ins Stammverzeichnis und ist immer unter https://ihre-domain.de/robots.txt erreichbar. In einem Unterordner sucht kein Crawler danach. Der Dateiname wird kleingeschrieben, das Format ist reiner Text in UTF-8, und Google verarbeitet bis zu 500 KiB pro Datei. Alles darüber wird abgeschnitten.

Entscheidend ist der Geltungsbereich: Eine robots.txt gilt nur für genau ein Protokoll, einen Host und einen Port. Jede Subdomain, jeder Wechsel von HTTP zu HTTPS und jeder abweichende Port braucht eine eigene Datei. shop.ihre-domain.de und www.ihre-domain.de sind aus Sicht der Datei zwei getrennte Welten. Pro Host existiert dabei genau eine gültige robots.txt.

Die folgende Übersicht zeigt, welche Adresse für welchen Bereich zuständig ist:

Quelle: Google Search Central, Spezifikation der robots.txt (abgerufen August 2026).

Der Aufbau: Direktiven und Steuerzeichen

Eine robots.txt besteht aus Gruppen. Jede Gruppe beginnt mit einer User-agent-Zeile und enthält darunter die Regeln für diesen Crawler. Suchmaschinen unterstützen im Kern vier Anweisungen:

• User-agent: benennt den angesprochenen Crawler, * steht für alle.
• Disallow: sperrt einen Pfad für das Crawling.
• Allow: gibt einen Pfad wieder frei, auch innerhalb eines gesperrten Verzeichnisses.
• Sitemap: verweist auf die XML-Sitemap.

Mit # beginnen Kommentare, die der Crawler bis zum Zeilenende ignoriert. Zwei ältere Anweisungen sind eine Erwähnung wert, weil sie oft noch auftauchen: crawl-delay wird von Google ignoriert (Bing und einige andere respektieren es weiterhin), und ein noindex in der robots.txt hat Google 2019 offiziell abgeschaltet. Es wirkt nicht mehr.

Ein leeres Disallow gibt alles frei

Ein häufiges Missverständnis betrifft die leere Anweisung. Disallow: ohne Pfad sperrt nichts, es gibt die gesamte Website frei. Funktional ist das identisch damit, gar keine Regeln zu hinterlegen oder eine leere Datei bereitzustellen. Wer alles erlauben will, schreibt also:

User-agent: *
Disallow:

Das genaue Gegenteil, die Komplettsperre für alle Crawler, unterscheidet sich nur durch einen Schrägstrich:

User-agent: *
Disallow: /

Disallow und Allow kombinieren

Interessant wird es, wenn beide Anweisungen zusammenkommen. Sie sperren ein ganzes Verzeichnis, geben aber einen Teil davon frei:

User-agent: *
Disallow: /intern/
Allow: /intern/oeffentlich/

Damit das verlässlich funktioniert, müssen Sie die Präzedenz kennen. Bei widersprüchlichen Regeln gewinnt der längste, spezifischste Pfad. /intern/oeffentlich/ ist länger als /intern/ und setzt sich durch, dieser Unterordner bleibt also crawlbar. Sind zwei Regeln exakt gleich lang, gewinnt die am wenigsten restriktive, also Allow. Diese Logik erlaubt feine Ausnahmen, ohne dass Sie jede einzelne URL auflisten.

Steuerzeichen: Stern und Dollar

Für Muster kennt die robots.txt genau zwei Platzhalter, und das ist die wohl häufigste Fehlerquelle: Es ist echtes Pattern-Matching, kein reguläres Regex.

• * steht für null oder mehr beliebige Zeichen.
• $ markiert das Ende der URL.

Damit lassen sich Muster präzise fassen. /*.pdf$ trifft jede URL, die auf .pdf endet. /$ trifft ausschließlich die Startseite. Ein Pfad ohne $ wirkt dagegen immer als Präfix: /fish sperrt /fish, /fish.html und /fishheads gleichermaßen.

Pfade sind relativ, die Sitemap ist es nicht

Allow- und Disallow-Werte sind immer relative Pfade und beginnen mit einem Schrägstrich. Sie beziehen sich auf den Host, unter dem die Datei liegt, eine vollständige Domain gehört hier nicht hinein. Genau umgekehrt bei der Sitemap: Der Sitemap-Verweis muss eine absolute, vollständige URL sein. Der Grund liegt in der Zuständigkeit. Eine Sitemap kann auf einem anderen Host liegen als die robots.txt, deshalb muss der Crawler die genaue Adresse inklusive Protokoll und Domain erfahren.

Ein zweiter Punkt, der in der Praxis Fehler produziert: Pfade beachten Groß- und Kleinschreibung. /Ordner/ und /ordner/ sind zwei verschiedene Ziele.

Die Schreibweise entscheidet außerdem darüber, wie weit eine Regel greift. Diese vier Varianten wirken unterschiedlich:

Quelle: Google Search Central, Spezifikation der robots.txt (abgerufen August 2026).

User-Agents gezielt ansprechen

Über die User-agent-Zeile entscheiden Sie, für wen eine Regelgruppe gilt. Ein Crawler sucht in der Datei zuerst nach der Gruppe, die exakt auf seinen Namen passt, und hält sich nur an diese. Die spezifischste Gruppe gewinnt, die Reihenfolge in der Datei spielt keine Rolle. Findet ein Crawler eine Gruppe für Googlebot-News, ignoriert er die allgemeine *-Gruppe komplett.

Für die meisten Websites reicht eine einzige *-Gruppe. Nach Crawlern zu unterscheiden lohnt sich erst, wenn ein bestimmter Bot anders behandelt werden soll als der Rest. Diese Namen begegnen Ihnen in der Praxis am häufigsten:

• Googlebot: der Haupt-Crawler für die Google-Suche. Er deckt sowohl die Desktop- als auch die Smartphone-Version ab.
• Googlebot-Image: der Bilder-Crawler von Google, sinnvoll, wenn Sie Bilder aus der Bildersuche halten wollen, den Rest aber nicht.
• Bingbot: der Crawler von Microsoft für Bing, der zugleich die Suche in vielen KI-Assistenten speist.
• AdsBot-Google: prüft die Qualität von Google-Ads-Zielseiten. Eine Besonderheit: Er hält sich nicht an die *-Gruppe, sondern muss namentlich angesprochen werden.

Der praktische Nutzen der Differenzierung: Sie können einen ressourcenhungrigen oder unerwünschten Bot aussperren, ohne die für Sie wertvollen Suchmaschinen einzuschränken. Ein typisches Muster ist, alle zu erlauben und nur einen einzelnen Crawler zu sperren:

User-agent: Storebot-Google
Disallow: /

User-agent: *
Allow: /

Ob sich ein Bot an Ihre Vorgaben hält, ist damit allerdings noch nicht gesagt. Die robots.txt ist eine Bitte, keine technische Sperre. Seriöse Suchmaschinen wie Google und Bing befolgen sie zuverlässig, Scraper und bösartige Bots ignorieren sie. Wer einen Bereich wirklich dichtmachen muss, arbeitet mit einer Zugriffssperre auf Serverebene, nicht mit einem Disallow.

Typische Anwendungsfälle mit Beispielen

In den meisten Projekten erledigt die robots.txt eine Handvoll wiederkehrender Aufgaben. Die folgenden Rezepte decken den Großteil davon ab.

Diese Seiten gehören meist nicht ins Crawling

Sinnvoll ist die Sperre für Bereiche, die keinen Wert für die Suche haben und nur Crawl-Kapazität kosten. Dazu zählen typischerweise:

• interne Suchergebnisseiten, die endlos neue URLs erzeugen
• Warenkorb, Kasse und die Danke-Seite nach einem Kauf oder Download
• Login-, Konto- und Verwaltungsbereiche
• Filter- und Sortier-URLs, die denselben Inhalt in vielen Varianten zeigen

Ein Grundgerüst dafür sieht so aus:

User-agent: *
Disallow: /suche/
Disallow: /warenkorb/
Disallow: /kasse/
Disallow: /mein-konto/

Ein wichtiger Vorbehalt: Für Seiten, die bereits im Index stehen und dort verschwinden sollen, ist die robots.txt das falsche Werkzeug (mehr dazu im Abschnitt zu den Grenzen). Zum reinen Freihalten von Crawl-Kapazität ist sie dagegen genau richtig.

Dateitypen ausschließen

Über das Muster $ sperren Sie ganze Dateiendungen. Praktisch etwa für interne PDF-Exporte oder Tabellen, die nicht in der Suche erscheinen sollen:

User-agent: *
Disallow: /*.pdf$
Disallow: /*.xls$

Parameter und Parameter-Ketten aus dem Crawl nehmen

Parameter-URLs sind auf großen Websites der häufigste Grund für verschwendetes Crawl-Budget. Sie steuern sie über den Stern. Alle URLs mit einem Fragezeichen sperren Sie übergreifend so:

User-agent: *
Disallow: /*?

Einen einzelnen Parameter fassen Sie gezielter, und dank des Sterns greift die Regel auch mitten in einer Parameter-Kette wie ?farbe=rot&sort=preis:

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

Hier lauert eine Abhängigkeit, die man leicht übersieht: Wer eine Parameter-URL per robots.txt sperrt, verhindert zugleich, dass die Suchmaschine ein Canonical oder Noindex auf dieser URL überhaupt lesen kann. Für das Bündeln von Duplikaten ist deshalb der Canonical-Tag das passende Mittel, die robots.txt taugt nur dazu, echte Crawl-Verschwendung zu stoppen.

CSS und JavaScript niemals sperren

Ein Relikt aus alten SEO-Zeiten, das immer noch auftaucht: das Blockieren von CSS- und JavaScript-Verzeichnissen. Sperren Sie diese Ressourcen nicht. Moderne Suchmaschinen rendern Seiten wie ein Browser und brauchen dafür das Stylesheet und die Skripte. Fehlt der Zugriff, sieht der Crawler eine kaputte Seite und bewertet sie entsprechend schlechter. Was früher als Aufräumen galt, schadet heute unmittelbar.

Die XML-Sitemap eintragen

Am Ende der Datei verweisen Sie auf Ihre XML-Sitemap, damit Suchmaschinen alle wichtigen URLs schnell finden. Mehrere Einträge sind erlaubt, etwa eine Sitemap-Index-Datei plus spezialisierte Sitemaps. Jeder Eintrag steht als vollständige URL und ist unabhängig von den User-agent-Gruppen:

Sitemap: https://www.ihre-domain.de/sitemap.xml
Sitemap: https://www.ihre-domain.de/sitemap-bilder.xml

Was die robots.txt nicht leisten kann

Drei Grenzen sind so wichtig, dass sie einen eigenen Abschnitt verdienen, weil ihre Missachtung teuer wird.

Erstens schützt die robots.txt keine vertraulichen Inhalte. Die Datei liegt öffentlich unter /robots.txt und muss dort liegen, jede Person kann sie lesen. Ein Disallow weist obendrein den direkten Weg zu Bereichen, die Sie eigentlich verbergen wollten. Vertrauliches gehört hinter eine Authentifizierung, niemals in ein Disallow. Die Datei selbst zu verstecken, ergibt keinen Sinn, denn dann finden die erwünschten Crawler ihre Anweisungen nicht mehr.

Zweitens entfernt die robots.txt nichts aus dem Index. Sie hält Crawler fern, aber eine bereits indexierte oder verlinkte URL kann trotzdem in den Ergebnissen bleiben, dann ohne Snippet. Zum sauberen Entfernen muss die Seite crawlbar bleiben und ein Noindex tragen. Sperren Sie sie zusätzlich per robots.txt, liest die Suchmaschine das Noindex nie und erreicht das genaue Gegenteil.

Drittens gibt es kein funktionierendes noindex in der robots.txt. Diese Anweisung wird von Google seit 2019 nicht mehr ausgewertet. Die Indexsteuerung läuft über das Meta-Robots-Tag oder den X-Robots-Tag im HTTP-Header, nicht über diese Datei.

KI-Crawler gezielt steuern

Seit generative KI-Systeme und die KI-Antworten der Suchmaschinen (AI Overviews) einen wachsenden Teil der Suche ausmachen, ist die robots.txt zum Werkzeug geworden, um den Zugriff dieser Systeme zu regeln. Viele der großen Anbieter respektieren die Datei und haben eigene, benannte Crawler. Wichtig ist die Unterscheidung zwischen zwei Aufgaben: Ein Crawler sammelt Daten für das Training von Modellen, ein anderer ruft Inhalte live ab, um eine konkrete Nutzerfrage zu beantworten. Beide lassen sich getrennt behandeln.

Quelle: Angaben der jeweiligen Anbieter zu ihren Crawlern (abgerufen August 2026).

Wer sein Google-Ranking behalten, aber nicht ins KI-Training einfließen will, sperrt gezielt die Trainings-Crawler und lässt den Googlebot unberührt:

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Disallow:

Eine ehrliche Einschränkung gehört dazu: Manche Bots halten sich nicht an die Datei. Der Crawler Bytespider von ByteDance etwa ist dafür bekannt, robots.txt-Vorgaben zu ignorieren. Solche Zugriffe stoppt nur eine Sperre auf Serverebene, zum Beispiel über die Firewall oder einen Dienst wie Cloudflare.

robots.txt testen und ausrollen

Bevor eine neue Datei live geht, prüfen Sie sie auf zwei Ebenen. Rufen Sie zuerst https://ihre-domain.de/robots.txt in einem privaten Browserfenster auf und kontrollieren Sie, dass die Datei mit Status 200 ausgeliefert wird und den erwarteten Inhalt zeigt. Der HTTP-Status ist dabei wichtiger, als er wirkt: Antwortet die Datei mit einem 5xx-Fehler, pausiert Google das Crawling der gesamten Website vorübergehend. Ein 4xx-Fehler wird dagegen so behandelt, als gäbe es keine Einschränkungen.

Für die inhaltliche Prüfung nutzen Sie den robots.txt-Bericht in der Google Search Console. Er zeigt die zuletzt abgerufene Version, meldet Syntaxfehler und lässt sich verwenden, um einzelne URLs gegen die Regeln zu testen. Nach einer Änderung greift Google nicht sofort: Die robots.txt wird bis zu 24 Stunden zwischengespeichert. Wollen Sie schneller sein, stoßen Sie im selben Bericht über die Funktion zum erneuten Crawling eine sofortige Aktualisierung an.

Ergänzend zeigt eine Log-File-Analyse, welche URLs die Crawler tatsächlich abrufen. So sehen Sie im Nachhinein, ob Ihre Sperren wie geplant wirken.

Häufige Fragen zur robots.txt

Verhindert die robots.txt, dass eine Seite bei Google erscheint?

Nein. Die Datei steuert nur das Crawling. Eine gesperrte URL kann trotzdem im Index landen, wenn andere Seiten auf sie verlinken, dann allerdings ohne Beschreibung. Um eine Seite zuverlässig aus dem Index zu halten, nutzen Sie ein Noindex und lassen die Seite dafür crawlbar.

Gilt eine robots.txt auch für Subdomains?

Nein. Jede Subdomain braucht ihre eigene robots.txt. Auch ein Wechsel des Protokolls von HTTP zu HTTPS oder ein abweichender Port erfordert jeweils eine eigene Datei, weil sie immer nur für genau eine Kombination aus Host, Protokoll und Port gilt.

Darf ich CSS- und JavaScript-Dateien sperren?

Nein. Suchmaschinen rendern Seiten und benötigen dafür Stylesheets und Skripte. Wird der Zugriff blockiert, kann die Seite falsch bewertet werden. Das Sperren dieser Ressourcen ist ein veralteter Fehler.

Wie hole ich eine bereits indexierte Seite wieder aus dem Index?

Setzen Sie ein Noindex im Meta-Robots-Tag oder im X-Robots-Tag und stellen Sie sicher, dass die Seite crawlbar bleibt, damit die Suchmaschine das Signal liest. Die URL darf dafür nicht zusätzlich in der robots.txt gesperrt sein. Über die Google Search Console lässt sich die Entfernung zusätzlich beschleunigen.

Halten sich alle Crawler an die robots.txt?

Nein. Die Datei ist eine Anweisung, keine technische Sperre. Seriöse Suchmaschinen und die meisten großen KI-Anbieter befolgen sie, Scraper und einzelne Bots ignorieren sie. Für einen echten Zugriffsschutz brauchen Sie eine serverseitige Sperre oder eine Authentifizierung.

Quellen

1. Google Search Central, Dokumentation zur robots.txt: Erstellen, Spezifikation, nützliche Regeln und Aktualisierung (abgerufen August 2026).
2. Robots Exclusion Protocol, RFC 9309 (2022).
3. Angaben der jeweiligen Anbieter zu ihren KI-Crawlern: OpenAI, Anthropic, Perplexity, Google, Common Crawl (abgerufen August 2026).

Verwandte Themen

• Indexierung richtig steuern: welche Seiten Google sieht
• Die Definition im Lexikon: robots.txt
• Der Prozess dahinter: das Crawling
• Warum große Websites das Crawl-Budget lenken müssen