Was ist Robots.txt?

Die robots.txt ist eine einfache Textdatei im Stammverzeichnis einer Website, die Crawlern mitteilt, welche Bereiche sie abrufen dürfen und welche nicht. Sie liegt immer unter https://ihre-domain.de/robots.txt und folgt dem Robots Exclusion Protocol, das seit 2022 als RFC 9309 formell beschrieben ist.

Ein Satz, der viel Ärger erspart: Die robots.txt ist eine Bitte, kein Schloss. Seriöse Crawler halten sich daran, andere nicht. Und sie regelt das Abrufen, nicht das Anzeigen in den Suchergebnissen — der Unterschied steht weiter unten.

Wofür die robots.txt da ist

• Crawl-Budget lenken: Große Websites mit Filtern, Sortierungen und Suchergebnisseiten erzeugen endlos viele Adressen. Wer sie sperrt, sorgt dafür, dass die wichtigen Seiten häufiger abgerufen werden.
• Server entlasten: Aufwendige Skripte, Exportfunktionen oder interne Suchen müssen nicht von jedem Bot gestartet werden.
• Auf die Sitemap verweisen: Eine Zeile in der Datei zeigt jedem Crawler den Weg zur XML-Sitemap.
• Einzelne Bots steuern: Ein aggressiver Crawler kann eigene Regeln bekommen, ohne die Suchmaschinen einzuschränken.

Wofür sie nicht da ist: Seiten aus dem Index zu entfernen, Inhalte zu schützen oder Zugriffe zu verhindern. Sensible Daten gehören hinter eine Anmeldung, nicht in ein Disallow — die robots.txt ist öffentlich und verrät genau, welche Pfade Sie verstecken wollten.

Aufbau einer robots.txt

Eine minimale, für die meisten Firmenwebsites passende Datei sieht so aus:

User-agent: *
Disallow:

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

Das bedeutet: Alle Crawler dürfen alles abrufen, die Sitemap liegt an der angegebenen Stelle. Wer nichts zu sperren hat, braucht nicht mehr. Ganz ohne Datei geht es auch — dann sollte der Server allerdings sauber einen 404 liefern und keine Fehlerseite mit Statuscode 200.

Regeln richtig schreiben

• Pfade beginnen mit einem Schrägstrich und werden als Präfix verstanden: Disallow: /intern sperrt auch /internes-handbuch. Wer nur den Ordner meint, schreibt /intern/.
• Groß- und Kleinschreibung zählt beim Pfad. /Admin/ und /admin/ sind zwei verschiedene Regeln.
• Platzhalter: * steht für beliebige Zeichen, $ markiert das Zeilenende. Disallow: /*.pdf$ sperrt alle PDF-Dateien.
• Nicht die Reihenfolge entscheidet, sondern die Länge: Bei widersprüchlichen Regeln gewinnt die spezifischere, also die längere. Bei exakt gleicher Länge gewinnt Allow.
• Jeder Crawler folgt nur einem Block. Steht ein eigener Block für Googlebot in der Datei, ignoriert Googlebot den Block für * vollständig — auch die dort gesperrten Pfade.
• Pro Host eine Datei. www und die Variante ohne www, HTTP und HTTPS sowie jede Subdomain brauchen jeweils eine eigene robots.txt.
• Nicht zu groß werden lassen: Google berücksichtigt die Datei laut eigener Dokumentation bis 500 Kibibyte, alles darüber wird ignoriert.

Fertige Beispiele für gängige Systeme

WordPress. WordPress liefert selbst eine virtuelle Datei aus, solange keine echte im Stammverzeichnis liegt. Für die meisten Installationen reicht:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /suche/

Sitemap: https://ihre-domain.de/wp-sitemap.xml

Die Ausnahme für admin-ajax.php ist wichtig, weil viele Themes darüber Inhalte nachladen. /wp-content/ und /wp-includes/ sollten Sie nicht sperren: Dort liegen CSS- und JavaScript-Dateien, ohne die Google die Seite nicht korrekt darstellen kann.

Onlineshop mit Filtern und Warenkorb. Das Muster gilt für Shopware, WooCommerce und die meisten anderen Systeme; die Pfade heißen je nach Shop anders:

User-agent: *
Disallow: /warenkorb
Disallow: /checkout
Disallow: /kundenkonto
Disallow: /*?sSort=
Disallow: /*?p=
Disallow: /*filter=

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

Shopify. Shopify erzeugt die Datei selbst; anpassen lässt sie sich über die Vorlage robots.txt.liquid im Theme. Greifen Sie dort nur ein, wenn Sie einen konkreten Grund haben — die Standardregeln sind für Shops sinnvoll gesetzt.

TYPO3 und andere Systeme mit Backend. Gesperrt wird der Verwaltungsbereich, alles Übrige bleibt offen:

User-agent: *
Disallow: /typo3/
Disallow: /typo3temp/

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

Testumgebung. Auf einem Entwicklungssystem ist die vollständige Sperre richtig — zusätzlich zu einer Anmeldung, nicht statt ihr:

User-agent: *
Disallow: /

Genau diese vier Zeilen sind der häufigste teure Fehler beim Livegang: Sie wandern mit auf die Produktivseite und nehmen die Website aus der Suche. Der Abgleich der robots.txt gehört deshalb in jede Livegang-Checkliste und in jedes SEO-Audit.

robots.txt oder noindex?

Der entscheidende Punkt: Beides zusammen funktioniert nicht. Eine per Disallow gesperrte Seite wird nicht abgerufen — also liest Google das noindex auf dieser Seite nie. Sie kann dann trotzdem im Index landen, wenn andere Websites auf sie verlinken, und erscheint dort ohne Textausschnitt.

Die richtige Reihenfolge lautet deshalb: Erst noindex setzen, warten, bis die Seite aus dem Index verschwunden ist, und erst danach — falls überhaupt nötig — per robots.txt sperren. Eine noindex-Zeile direkt in der robots.txt wertet Google nicht aus.

Häufige Fehler

• Die Sperre aus der Testumgebung geht live. Der Klassiker, oft erst nach Wochen bemerkt.
• CSS und JavaScript sind gesperrt. Google rendert die Seite dann unvollständig und bewertet die Mobildarstellung falsch.
• Die Datei liegt im falschen Verzeichnis. Sie muss im Stammverzeichnis des Hosts liegen; in einem Unterordner ist sie wirkungslos.
• Die Datei wird nicht als Text ausgeliefert oder antwortet mit einem Serverfehler. Antwortet sie mit 5xx, behandeln Crawler die Website unter Umständen zeitweise als vollständig gesperrt.
• Sperren, um Duplicate Content zu lösen. Dafür sind Canonical-Angaben zuständig. Eine gesperrte Seite kann keinen Canonical übermitteln.
• Ein eigener Block für Googlebot, der den Sammelblock aushebelt. Wer User-agent: Googlebot ergänzt, muss dort alle Regeln wiederholen.
• Umlaute und Sonderzeichen unkodiert. Pfade gehören prozentkodiert in die Datei.
• Die Sitemap-Zeile fehlt oder verweist auf eine alte Adresse.

robots.txt prüfen

Drei Wege, in dieser Reihenfolge:

1. Selbst aufrufen. Öffnen Sie https://ihre-domain.de/robots.txt im Browser. Erscheint etwas anderes als reiner Text, ist die Datei schon falsch ausgeliefert.
2. Search Console, Bericht „robots.txt“. Er zeigt, welche Datei Google zuletzt abgerufen hat, wann das geschah und ob es Fehler gab. Der frühere robots.txt-Tester wurde abgeschaltet.
3. URL-Prüfung in der Search Console. Für eine einzelne Adresse sagt sie eindeutig, ob sie blockiert ist und aus welchem Grund. Das ist die verlässlichste Antwort bei einem konkreten Verdacht.

Nach jeder Änderung lohnt ein zweiter Blick in den Indexierungsbericht: Taucht dort die Meldung „Durch robots.txt blockiert“ für Seiten auf, die Kunden finden sollen, hat die Regel zu weit gegriffen.

robots.txt und KI-Crawler

Seit Sprachmodelle Texte aus dem Web lesen, steuern viele Betreiber über die robots.txt nicht mehr nur Suchmaschinen. Eigene User-Agents haben unter anderem GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, CCBot (Common Crawl), Applebot-Extended und Google-Extended.

Wer den Zugriff für Trainingszwecke einschränken will, ergänzt eigene Blöcke:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Zwei Hinweise dazu. Erstens steuert Google-Extended nur die Nutzung für Googles KI-Produkte, nicht die normale Indexierung — wer ihn sperrt, bleibt in der Suche sichtbar. Zweitens lohnt vor dem Sperren die Gegenfrage, ob Sie in KI-Antworten überhaupt nicht vorkommen wollen. Für die meisten B2B-Anbieter ist das Gegenteil das Ziel; wie man dort als Quelle auftaucht, beschreibt unsere Leistung KI-Sichtbarkeit.

robots.txt und SEO

Für kleine und mittlere Websites ist die robots.txt selten ein Hebel — dort genügt eine schlanke Datei mit Sitemap-Verweis. Wichtig wird sie ab dem Moment, in dem ein System viele Adressen erzeugt: Filter, Sortierungen, interne Suchergebnisse, Kalenderansichten, Druckversionen. Solche Adressen binden Abrufe, die den eigentlichen Inhalten fehlen.

Der häufigste tatsächliche SEO-Schaden durch die Datei ist aber nicht das fehlende Feintuning, sondern eine Regel, die zu viel sperrt. Deshalb gilt: sparsam sperren, nach jeder Änderung prüfen, und bei Unsicherheit lieber offen lassen. robots.txt, Sitemap und Indexierungsregeln richten wir bei Kundenprojekten ein und kontrollieren sie regelmäßig — Teil der technischen SEO-Betreuung.

Häufige Fragen zur robots.txt

Braucht jede Website eine robots.txt?

Zwingend nein. Fehlt sie, dürfen Crawler alles abrufen. Sinnvoll ist sie trotzdem: schon wegen der Sitemap-Zeile und weil jeder Crawler die Datei ohnehin anfragt. Wichtig ist nur, dass der Server bei fehlender Datei sauber einen 404 liefert.

Wo muss die robots.txt liegen?

Im Stammverzeichnis des jeweiligen Hosts, also unter /robots.txt. Jede Subdomain und jedes Protokoll braucht eine eigene Datei; eine Datei in einem Unterordner hat keine Wirkung.

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

Nein. Sie verhindert nur den Abruf. Eine gesperrte Seite kann trotzdem in den Ergebnissen auftauchen, wenn andere Websites auf sie verlinken — dann meist ohne Beschreibung. Zum Ausschluss aus dem Index gehört noindex auf die Seite selbst.

Wie schnell wirkt eine Änderung?

Crawler rufen die Datei regelmäßig neu ab, üblicherweise innerhalb eines Tages. Dass eine gesperrte Seite aus den Ergebnissen verschwindet, kann länger dauern; wenn es schnell gehen muss, ist noindex plus Entfernungsantrag in der Search Console der richtige Weg.

Wird Crawl-delay von Google beachtet?

Nein. Google wertet die Anweisung nicht aus und regelt die Abrufgeschwindigkeit selbst anhand der Serverantwortzeiten. Bing und Yandex beachten sie. Wenn ein Crawler Ihren Server überlastet, ist eine Begrenzung auf Serverebene das wirksamere Mittel.

Kann ich einzelne Dateitypen sperren?

Ja, über den Platzhalter am Zeilenende: Disallow: /*.pdf$ sperrt alle PDF-Dateien für den Abruf. Sollen die PDFs lediglich nicht in den Ergebnissen erscheinen, ist der HTTP-Header X-Robots-Tag: noindex das passendere Mittel.

Muss ich fremde Crawler sperren?

In der Regel nicht. Sperren Sie gezielt, wenn ein bestimmter Bot Ihren Server spürbar belastet oder Sie Inhalte ausdrücklich nicht für KI-Training freigeben wollen. Eine lange Sperrliste nach Gefühl bringt nichts — wer sich nicht an die Datei hält, liest sie ohnehin nicht.

Zusammenfassung

Die robots.txt ist ein kleines Werkzeug mit großer Wirkung in beide Richtungen. Sie lenkt Abrufe, verweist auf die Sitemap und hält Crawler von Bereichen fern, die niemandem nützen. Sie schützt nichts, entfernt nichts aus dem Index und ersetzt kein noindex.

Für die meisten Firmenwebsites ist die beste Datei die kurze: Sitemap eintragen, den Verwaltungsbereich sperren, alles andere offen lassen und nach jeder Änderung an der Website kontrollieren. Verwandte Themen: Crawlability, Sitemap, Canonical-Tag.