Robots.txt

Kurz gesagt

robots.txt ist eine oeffentliche Textdatei im Root einer Website. Sie sagt Suchmaschinen-Crawlern, welche Pfade sie abrufen duerfen 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 oeffentlich erreichbar sein soll, brauchst du Passwortschutz, Login oder Serverregeln. Wenn eine Seite nicht im Index stehen soll, brauchst du in vielen Faellen noindex, und Google muss die Seite dafuer crawlen koennen.

robots.txt ist also ein nuetzliches Werkzeug, aber ein gefaehrliches, wenn man es fuer die falsche Aufgabe einsetzt.

Einfach erklaert

Stell dir robots.txt wie ein Schild am Eingang eines Gebaeudes vor. Auf dem Schild steht fuer Crawler: "Diesen Flur bitte nicht betreten" oder "Diese Karte findet ihr hier". Serioese 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, koennen sie ignorieren. Und wenn andere Websites auf eine blockierte URL verlinken, kann Google die URL trotzdem kennen. Google kann sie unter bestimmten Umstaenden als URL anzeigen, obwohl der Inhalt nicht gecrawlt wurde.

Deshalb ist robots.txt gut fuer Fragen wie:

• Welche URL-Muster sollen Crawler nicht abrufen?
• Welche Bereiche verschwenden Crawl-Aufmerksamkeit?
• Wo soll Google eine Sitemap finden?
• Welche Ressourcen duerfen fuer die Seitenanalyse abgerufen werden?

Sie ist schlecht fuer Fragen wie:

• Wie schuetzen 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 fuer alle Varianten einer Domain. Diese Hosts und Protokolle koennen 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, fuer 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 groesseren 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. Zusaetzlich wird eine Sitemap genannt.

In der Praxis sollte jede Zeile eine dokumentierte Begruendung haben. Wenn niemand weiss, 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 duerfen. Das ist die Kernfunktion.

Crawl-Traffic

Bei grossen Websites kann robots.txt helfen, Crawler von unwichtigen, aehnlichen 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 fuer robots.txt.

Was robots.txt nicht leisten kann

Keine echte Sicherheit

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

Keine verlaessliche 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 waehlen: noindex, Entfernung, 404/410, Zugriffsschutz oder Kombinationen je nach Fall.

Kein noindex in robots.txt

Google unterstuetzt noindex in robots.txt nicht als Regel. Disallow ist nicht noindex.

Kein Canonical-Ersatz

Canonicals muessen 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 aehnliche 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-Einsatzfaelle

Interne Suchergebnisse

Interne Suchseiten erzeugen oft viele duenne oder doppelte Seiten. robots.txt kann helfen, solche Muster vom Crawling auszuschliessen.

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 koennen unnoetig viele URL-Varianten erzeugen. robots.txt kann Muster blockieren, sollte aber nicht die einzige Loesung fuer schlechte URL-Logik sein.

Staging

Staging gehoert nicht nur in robots.txt blockiert, sondern geschuetzt. Sonst ist es weiter oeffentlich erreichbar und nur fuer brave Crawler "verboten".

Mediendateien

Fuer 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&groesse=42&sort=preis /schuhe?farbe=schwarz&groesse=43&sort=preis /schuhe?farbe=blau&groesse=42&sort=preis ~~~

Das Team blockiert zunaechst grob alle Parameter-URLs. Die Crawl-Last sinkt, aber spaeter faellt auf: Einige Filterkombinationen haben echte Nachfrage, etwa "schwarze laufschuhe herren". Diese Seiten haetten besser als kuratierte Landingpages existieren sollen.

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

Haeufige 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 pruefen.
• Sitemaps mit falschen oder nicht absoluten URLs eintragen.
• robots.txt-Aenderungen ohne Review deployen.
• Nach Aenderungen nicht mit Search Console oder URL Inspection pruefen.

Mini-Workflow

1. Klaere die Absicht: Crawling steuern, Indexierung verhindern, Duplikate konsolidieren oder Inhalte schuetzen? 2. Nutze robots.txt nur fuer Crawl-Steuerung. 3. Pruefe Host, Protokoll und Subdomain. 4. Schreibe moeglichst enge Regeln statt grober Blocks. 5. Pruefe, 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.

Contextter-Perspektive

Fuer Contextter ist robots.txt kein isoliertes Technikdetail. Die Datei beeinflusst, welche Inhalte Suchmaschinen ueberhaupt abrufen koennen. Ein Content-Hub braucht deshalb nicht nur gute Texte, sondern auch klare technische Grenzen: Kernseiten sichtbar machen, unwichtige Varianten reduzieren, private oder unfertige Bereiche sauber schuetzen.

Gute robots.txt-Arbeit stellt immer dieselbe Frage: Hilft diese Regel Suchmaschinen, die wirklich wichtigen Inhalte besser zu verstehen, oder versteckt sie nur ein Architekturproblem?

Verwandte Begriffe

Diese Begriffe passen als naechste Leseschritte:

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

Quellen fuer 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