Robots.txt

Kurz gesagt

robots.txt ist eine öffentliche Textdatei im Root einer Website. Sie sagt Suchmaschinen-Crawlern, welche Pfade sie abrufen dürfen und welche nicht. Ihr Hauptzweck ist Crawl-Steuerung.

Der wichtigste SEO-Satz lautet: robots.txt steuert Crawling, nicht sicher Indexierung und nicht Zugriffsschutz. Wenn eine Seite nicht öffentlich erreichbar sein soll, brauchst du Passwortschutz, Login oder Serverregeln. Wenn eine Seite nicht im Index stehen soll, brauchst du in vielen Fällen noindex, und Google muss die Seite dafür crawlen können.

Bewerte mit dem technischen SEO-Audit-Leitfaden Crawler-Zugang und Indexierbarkeit gemeinsam, statt beides von robots.txt zu erwarten.

robots.txt ist also ein nützliches Werkzeug, aber ein gefährliches, wenn man es für die falsche Aufgabe einsetzt.

Einfach erklärt

Stell dir robots.txt wie ein Schild am Eingang eines Gebäudes vor. Auf dem Schild steht für Crawler: "Diesen Flur bitte nicht betreten" oder "Diese Karte findet ihr hier". Seriöse Crawler wie Googlebot lesen dieses Schild, bevor sie URLs abrufen.

Aber ein Schild ist kein Schloss. Jeder kann die Datei im Browser aufrufen. Bots, die Regeln ignorieren, können sie ignorieren. Und wenn andere Websites auf eine blockierte URL verlinken, kann Google die URL trotzdem kennen. Google kann sie unter bestimmten Umständen als URL anzeigen, obwohl der Inhalt nicht gecrawlt wurde.

Deshalb ist robots.txt gut für Fragen wie:

• Welche URL-Muster sollen Crawler nicht abrufen?
• Welche Bereiche verschwenden Crawl-Aufmerksamkeit?
• Wo soll Google eine Sitemap finden?
• Welche Ressourcen dürfen für die Seitenanalyse abgerufen werden?

Sie ist schlecht für Fragen wie:

• Wie schützen wir vertrauliche Daten?
• Wie entfernen wir sicher eine Seite aus Google?
• Wie konsolidieren wir Duplikate?

Wo robots.txt liegt

Die Datei liegt immer am Root eines konkreten Protokolls und Hosts:

~~~txt https://example.com/robots.txt ~~~

Sie gilt nicht automatisch für alle Varianten einer Domain. Diese Hosts und Protokolle können jeweils eigene Dateien haben:

~~~txt https://example.com/robots.txt https://www.example.com/robots.txt https://shop.example.com/robots.txt http://example.com/robots.txt ~~~

Das ist wichtig bei Relaunches, Subdomains, internationalen Setups, CDNs und Staging-Umgebungen. Eine perfekte robots.txt auf www.example.com hilft nicht, wenn Googlebot eigentlich shop.example.com crawlt.

Die wichtigsten Direktiven

User-agent

User-agent sagt, für welchen Crawler ein Regelblock gilt. User-agent: * richtet sich allgemein an Crawler. User-agent: Googlebot richtet sich gezielt an Googles Web-Crawler.

Disallow

Disallow sagt, welche Pfade ein Crawler nicht abrufen soll. Beispiel:

~~~txt User-agent: * Disallow: /internal-search/ ~~~

Das bedeutet: Crawler sollen Pfade unter /internal-search/ nicht abrufen.

Allow

Allow kann Ausnahmen innerhalb blockierter Bereiche definieren. Beispiel:

~~~txt User-agent: Googlebot Disallow: /downloads/ Allow: /downloads/public-guide.pdf ~~~

Das blockiert den größeren Bereich, erlaubt aber eine konkrete Datei.

Sitemap

Sitemap nennt die absolute URL einer Sitemap oder eines Sitemap-Index:

~~~txt Sitemap: https://www.example.com/sitemap.xml ~~~

Diese Zeile ist ein Hinweis. Sie ersetzt keine saubere Sitemap und keine gute interne Verlinkung.

Ein einfaches Beispiel

~~~txt User-agent: Googlebot Disallow: /test/

User-agent: * Disallow: /internal-search/

Sitemap: https://www.example.com/sitemap.xml ~~~

In diesem Beispiel soll Googlebot /test/ nicht abrufen. Alle Crawler sollen /internal-search/ meiden. Zusätzlich wird eine Sitemap genannt.

In der Praxis sollte jede Zeile eine dokumentierte Begründung haben. Wenn niemand weiß, warum ein Pfad blockiert ist, wird robots.txt schnell zur Risiko-Datei.

Was robots.txt wirklich steuert

Crawling

robots.txt sagt Crawlern, welche Pfade sie abrufen dürfen. Das ist die Kernfunktion.

Crawl-Traffic

Bei großen Websites kann robots.txt helfen, Crawler von unwichtigen, ähnlichen oder endlosen URL-Mustern fernzuhalten: interne Suche, Parameter, Filter, Sortierungen oder Testbereiche.

Ressourcenabruf

robots.txt kann auch Bilder, Skripte oder CSS blockieren. Das sollte vorsichtig passieren. Wenn Google wichtige Ressourcen nicht abrufen kann, kann es die Seite schlechter verstehen.

Sitemap-Findbarkeit

Die Sitemap-Zeile hilft Suchmaschinen, Sitemaps zu finden. Sie ist praktisch, aber nicht der Hauptgrund für robots.txt.

Was robots.txt nicht leisten kann

Keine echte Sicherheit

robots.txt ist öffentlich. Wer https://example.com/robots.txt aufruft, sieht die blockierten Pfade. Private Inhalte gehören hinter Login, Passwortschutz, VPN, IP-Regeln oder andere Zugriffskontrollen.

Keine verlässliche De-Indexierung

Wenn eine Seite per robots.txt blockiert ist, darf Google sie nicht crawlen. Dann kann Google auch kein noindex auf der Seite sehen. Wenn andere Seiten auf die URL verlinken, kann Google die URL trotzdem kennen.

Wer eine Seite aus dem Index entfernen will, muss die richtige Methode wählen: noindex, Entfernung, 404/410, Zugriffsschutz oder Kombinationen je nach Fall.

Kein noindex in robots.txt

Google unterstützt noindex in robots.txt nicht als Regel. Disallow ist nicht noindex.

Kein Canonical-Ersatz

Canonicals müssen von Google gesehen werden. Wenn du Duplikate per robots.txt blockierst, kann Google die Canonical-Signale auf diesen Seiten eventuell nicht lesen.

robots.txt, noindex und canonical unterscheiden

robots.txt

Nutze robots.txt, wenn du Crawling steuern willst: "Bitte diese Pfade nicht abrufen."

noindex

Nutze noindex, wenn eine erreichbare Seite nicht im Index erscheinen soll. Wichtig: Die Seite muss crawlbar sein, damit Google noindex sehen kann.

canonical

Nutze Canonicals, wenn mehrere URLs ähnliche Inhalte zeigen und eine bevorzugte Version kommuniziert werden soll.

Zugriffsschutz

Nutze Zugriffsschutz, wenn Inhalte privat sind. Das ist kein SEO-Trick, sondern Sicherheit.

Typische SEO-Einsatzfälle

Interne Suchergebnisse

Interne Suchseiten erzeugen oft viele dünne oder doppelte Seiten. robots.txt kann helfen, solche Muster vom Crawling auszuschließen.

Facettierte Navigation

Shops erzeugen mit Filtern oft sehr viele URL-Kombinationen. Manche Filterseiten sind wertvoll, viele andere nicht. robots.txt kann Teil der Steuerung sein, aber erst nach einer sauberen Entscheidung, welche Filterseiten Suchwert haben.

Parameter und Sortierungen

Sortierungen, Tracking-Parameter und Session-IDs können unnötig viele URL-Varianten erzeugen. robots.txt kann Muster blockieren, sollte aber nicht die einzige Lösung für schlechte URL-Logik sein.

Staging

Staging gehört nicht nur in robots.txt blockiert, sondern geschützt. Sonst ist es weiter öffentlich erreichbar und nur für brave Crawler "verboten".

Mediendateien

Für Bilder, Videos oder andere Dateien kann robots.txt je nach Ziel sinnvoll sein. Bei HTML-Seiten ist die Abgrenzung zu noindex besonders wichtig.

Praktisches Beispiel

Ein Online-Shop stellt fest, dass Googlebot sehr viele URLs wie diese abruft:

~~~txt /schuhe?farbe=schwarz&größe=42&sort=preis /schuhe?farbe=schwarz&größe=43&sort=preis /schuhe?farbe=blau&größe=42&sort=preis ~~~

Das Team blockiert zunächst grob alle Parameter-URLs. Die Crawl-Last sinkt, aber später fällt auf: Einige Filterkombinationen haben echte Nachfrage, etwa "schwarze laufschuhe herren". Diese Seiten hätten besser als kuratierte Landingpages existieren sollen.

Die bessere Lösung ist differenziert. Wertvolle Filterthemen bekommen eigene Landingpages, interne Links, indexierbare Inhalte und klare Canonicals. Endlose Sortierungen und irrelevante Parameter werden eingeschränkt. robots.txt wird dadurch Teil einer Strategie, nicht ein grober Not-Aus-Schalter.

Häufige Fehler

• Disallow: / versehentlich in Produktion ausrollen.
• robots.txt als Datenschutz oder Sicherheit verwenden.
• Erwarten, dass Disallow eine URL sicher aus dem Index entfernt.
• Eine Seite blockieren und gleichzeitig noindex erwarten.
• Wichtige CSS-, JavaScript- oder Bildressourcen blockieren.
• Regeln auf dem falschen Host, Protokoll oder Subdomain testen.
• Alle Filterseiten blockieren, ohne Nachfrage und Wert zu prüfen.
• Sitemaps mit falschen oder nicht absoluten URLs eintragen.
• robots.txt-Änderungen ohne Review deployen.
• Nach Änderungen nicht mit Search Console oder URL Inspection prüfen.

Mini-Workflow

1. Kläre die Absicht: Crawling steuern, Indexierung verhindern, Duplikate konsolidieren oder Inhalte schützen? 2. Nutze robots.txt nur für Crawl-Steuerung. 3. Prüfe Host, Protokoll und Subdomain. 4. Schreibe möglichst enge Regeln statt grober Blocks. 5. Prüfe, ob wichtige Seiten, CSS, JavaScript, Bilder oder Canonical-Signale betroffen sind. 6. Teste die Datei im Browser und mit Search Console. 7. Dokumentiere Regel, Datum, Grund und erwartete Wirkung. 8. Beobachte Crawl- und Indexierungsdaten getrennt. 9. Entferne alte Regeln, wenn ihr Zweck nicht mehr existiert.

Mit Crawl Foundry anwenden

Der Site Audit von Crawl Foundry verbindet Crawl-Ergebnisse, interne Links und technische Befunde. Prüfe betroffene URLs und priorisiere die nötigen Korrekturen.

Site Audit ansehen

Verwandte Begriffe

Diese Begriffe passen als nächste Leseschritte:

• crawling
• crawl-budget
• xml-sitemap
• noindex
• indexing
• canonical-tag

Quellen für den Review

• Google Search Central: Introduction to robots.txt
• Google Crawling Infrastructure: How Google interprets robots.txt
• Google Crawling Infrastructure: Create a robots.txt file
• Google Search Console Help: robots.txt report
• Google Search Central: Block indexing with noindex
• Google Search Central: Robots meta tag specifications
• Google Search Central: What is Googlebot
• Google Search Central: Troubleshoot crawling errors