Robots.txt richtig einsetzen
Crawling gezielt steuern, wichtige Ressourcen freigeben und Indexierungsfehler vermeiden
Crawling gezielt steuern, wichtige Ressourcen freigeben und Indexierungsfehler vermeiden
Die Datei robots.txt teilt Suchmaschinen-Crawlern mit, welche Bereiche einer Website sie abrufen dürfen. Sie liegt im Stammverzeichnis eines Hosts und wird vor dem Crawling anderer URLs abgerufen. Richtig eingesetzt reduziert sie unnötige Abrufe und hält Crawler von technisch erzeugten Bereichen fern.
Die wichtigste Abgrenzung: Eine robots.txt steuert das Crawling, nicht zuverlässig die Indexierung. Eine gesperrte URL kann weiterhin als Adresse in Google erscheinen, wenn sie über externe oder interne Links bekannt ist. Vertrauliche Inhalte schützt die Datei ebenfalls nicht, denn sie ist öffentlich abrufbar und ihre Regeln sind keine Zugriffskontrolle.
Wenn alle öffentlich erreichbaren Inhalte gecrawlt werden dürfen, ist keine robots.txt erforderlich. Eine leere oder sehr kurze Datei kann sinnvoller sein als ein umfangreiches Regelwerk, dessen Auswirkungen später niemand mehr vollständig überblickt.
Die Datei muss unter dem exakten Namen robots.txt im Stammverzeichnis erreichbar sein:
https://www.example.de/robots.txtEine Datei unter /ordner/robots.txt gilt nicht für die Website. Außerdem besitzt jeder Host seinen eigenen Geltungsbereich. Für www.example.de, shop.example.de und eine weitere Subdomain werden bei Bedarf getrennte Dateien bereitgestellt. Auch Protokoll und Port gehören zum jeweiligen Ursprung.
Regeln werden zu Gruppen zusammengefasst. Eine Gruppe beginnt mit mindestens einer User-agent-Zeile. Darunter folgen die für diesen Crawler geltenden Anweisungen.
User-agent: *
Disallow: /interne-suche/
Disallow: /warenkorb/
Allow: /
Sitemap: https://www.example.de/sitemap.xmlDer Stern bei User-agent spricht alle Crawler an, die keiner spezielleren Gruppe zugeordnet sind. Ein leeres Disallow: sperrt nichts. Kommentare beginnen mit # und werden von den Crawlern nicht als Regel interpretiert.
| Anweisung | Bedeutung | Hinweis |
|---|---|---|
| User-agent | Bestimmt, für welchen Crawler die Gruppe gilt | * steht für alle nicht genauer benannten Crawler |
| Disallow | Schließt einen Pfad vom Crawling aus | Der Pfad beginnt mit / und unterscheidet Groß- und Kleinschreibung |
| Allow | Erlaubt einen Unterpfad innerhalb eines gesperrten Bereichs | Nützlich für gezielte Ausnahmen |
| Sitemap | Verweist auf eine XML-Sitemap | Absolute URL verwenden; mehrere Zeilen sind möglich |
| # Kommentar | Dokumentiert den Zweck einer Regel | Kommentare kurz und aktuell halten |
Google unterstützt in der robots.txt kein crawl-delay. Die Crawl-Aktivität sollte daher nicht über eine frei erfundene Verzögerungsregel gesteuert werden.
Pfadangaben beginnen am Stammverzeichnis und sind groß- und kleinschreibungssensitiv. /Shop/ ist daher nicht dieselbe Regel wie /shop/. Google unterstützt außerdem * als Platzhalter für beliebige Zeichenfolgen und $ zur Kennzeichnung des URL-Endes.
User-agent: *
Disallow: /produkte/
Allow: /produkte/oeffentlich/
Disallow: /*?sort=
Disallow: /*.pdf$Wenn mehrere Regeln auf eine URL passen, verwendet Google die spezifischste Übereinstimmung. Bei gleich langen gegensätzlichen Regeln wird die weniger einschränkende Regel berücksichtigt. Solche Überschneidungen sollten trotzdem sparsam eingesetzt und mit realen Beispiel-URLs getestet werden.
Parameter, Filter und Sortierungen dürfen nicht pauschal gesperrt werden. Manche Filterseiten erfüllen eine eigenständige Nachfrage und sollen indexierbar bleiben. Vor einer Regel wird deshalb geprüft, welche URL-Muster nur technische Varianten erzeugen und welche als wertvolle Landingpages ausgebaut sind.
Die passende Methode hängt vom eigentlichen Ziel ab. Crawling sparen, eine URL aus den Suchergebnissen entfernen, Duplikate zusammenführen und vertrauliche Daten schützen sind vier verschiedene Aufgaben.
| Methode | Geeigneter Einsatz | Wichtige Grenze |
|---|---|---|
| robots.txt | Crawling ausgewählter Pfade begrenzen | Verhindert die Indexierung einer bekannten URL nicht zuverlässig |
| Meta-Robots Noindex | HTML-Seite aus Suchergebnissen ausschließen | Die Seite muss crawlbar sein, damit Google die Anweisung lesen kann |
| X-Robots-Tag | PDFs, Bilder und andere Dateien per HTTP Header ausschließen | Auch die Datei muss für den Crawler erreichbar sein |
| Canonical | Ähnliche oder doppelte URLs einer bevorzugten Version zuordnen | Ist ein Konsolidierungssignal, kein Schutz und keine Crawling-Sperre |
| Login oder Serverzugriff | Vertrauliche, interne oder noch nicht veröffentlichte Inhalte schützen | Muss serverseitig eingerichtet und getestet werden |
Ein häufiger Fehler ist die Kombination aus Disallow und noindex für dieselbe Seite. Wenn Google die URL nicht crawlen darf, kann die Suchmaschine das Noindex im Dokument nicht sehen. Soll eine öffentlich erreichbare Seite aus dem Index verschwinden, muss sie für die Verarbeitung der Noindex-Anweisung zunächst crawlbar bleiben.
Google rendert moderne Seiten mit CSS und JavaScript. Werden wichtige Ressourcen blockiert, kann die Suchmaschine Layout, Navigation, Inhalte oder mobile Darstellung nicht vollständig beurteilen. Pauschale Regeln gegen Verzeichnisse wie /assets/, /scripts/ oder /wp-content/ sind deshalb riskant.
Nicht der Verzeichnisname entscheidet, sondern die Funktion der Ressource. Eine technische Prüfung zeigt, welche Dateien Google zum vollständigen Rendern einer Seite benötigt.
CMS und Shops erzeugen häufig interne Suchergebnisse, Warenkörbe, Checkout-Schritte, Session-URLs, Sortierungen und nahezu unbegrenzte Filterkombinationen. Solche Muster können unnötige Crawling-Aktivität verursachen. Eine robots.txt darf jedoch nicht blind aus einer Vorlage übernommen werden, denn Erweiterungen, Themes und Shoplogik unterscheiden sich.
User-agent: *
Disallow: /interne-suche/
Disallow: /warenkorb/
Disallow: /checkout/
Sitemap: https://www.example.de/sitemap.xmlBei WordPress sollte insbesondere geprüft werden, ob Theme, Editor und Plugins öffentlich benötigte Dateien aus /wp-content/ oder AJAX-Funktionen aus dem Administrationsbereich laden. Weitere technische Besonderheiten behandeln wir in WordPress SEO richtig umsetzen.
Entwicklungs- und Staging-Systeme werden mit Passwortschutz oder serverseitiger Zugriffskontrolle abgesichert. Ein Disallow: / allein schützt weder Inhalte noch Zugangsdaten und kann beim späteren Livegang versehentlich bestehen bleiben.
Google verarbeitet robots.txt-Dateien bis zu einer Größe von 500 KiB; darüber hinausgehender Inhalt wird ignoriert. Schon deutlich kleinere Dateien sollten vereinfacht werden, wenn viele Einzelfälle, alte Regeln oder doppelte Gruppen die Wartung erschweren.
Der HTTP-Status ist ebenfalls wichtig. Eine erfolgreich ausgelieferte Datei antwortet mit Status 200. Bei 4xx-Antworten außer bestimmten Ratenbegrenzungen geht Google in der Regel davon aus, dass keine Crawling-Einschränkungen bestehen. Serverfehler im 5xx-Bereich können das Crawling dagegen vorübergehend beeinflussen. Deshalb gehören Statuscode und Erreichbarkeit in jede technische Kontrolle.
Google speichert die robots.txt normalerweise bis zu etwa 24 Stunden zwischen. Bei technischen Problemen kann eine gespeicherte Version länger verwendet werden. Änderungen wirken daher nicht zwingend in derselben Minute auf alle Abrufe.
Disallow: / aus einem Testsystem gelangt auf die produktive Website.Vor allem bei Relaunches sollten alte und neue robots.txt gemeinsam mit Weiterleitungen, Canonicals und XML-Sitemaps geprüft werden. Unsere SEO-Relaunch-Begleitung berücksichtigt diese Signale vor und nach der Umstellung.
Disallow: / die Live-Website sperrt?Passende Artikel: Google Search Console richtig nutzen, Canonical Tag richtig einsetzen und WordPress SEO richtig umsetzen. Die Prüfung konkreter Crawling- und Indexierungsprobleme ist Bestandteil unserer SEO-Seitenanalyse.