robots.txt erklärt: Suchmaschinen-Crawler richtig steuern

Die Datei robots.txt gehört zu den grundlegenden Werkzeugen der technischen Suchmaschinenoptimierung. Mit ihr kannst du Suchmaschinen-Crawlern mitteilen, welche Bereiche deiner Website sie crawlen dürfen und welche nicht.

Eine falsche Konfiguration kann allerdings erhebliche Auswirkungen haben. Im ungünstigsten Fall wird Google daran gehindert, wichtige Teile oder sogar die gesamte Website zu crawlen.

Genauso wichtig ist zu verstehen, was die robots.txt nicht kann: Sie ist kein zuverlässiges Werkzeug, um Webseiten aus dem Google-Index zu entfernen.

In diesem Artikel erklären wir, wie eine robots.txt aufgebaut ist, was User-agent, Disallow und Allow bedeuten, wie du eine Sitemap einträgst und welche Fehler du unbedingt vermeiden solltest.

Kurz erklärt: Die robots.txt steuert in erster Linie, welche URLs Suchmaschinen-Crawler abrufen dürfen. Sie steuert damit das Crawling. Ob eine Webseite indexiert werden soll, ist eine andere Frage.

Was ist eine robots.txt? #

Die robots.txt ist eine einfache Textdatei, die im Stammverzeichnis eines Hosts liegt.

Bei einer Website unter:

https://example.com

befindet sich die Datei unter:

https://example.com/robots.txt

Suchmaschinen-Crawler rufen diese Datei ab und prüfen, welche Crawling-Regeln für sie gelten.

Wo muss die robots.txt liegen? #

Die Datei muss direkt im Stammverzeichnis des jeweiligen Hosts liegen.

Richtig:

https://example.com/robots.txt

Eine Datei unter:

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

ist nicht die robots.txt für die gesamte Website.

Der Dateiname muss robots.txt lauten.

robots.txt gilt immer für den jeweiligen Host #

Eine wichtige technische Besonderheit ist der Geltungsbereich.

Die Datei unter:

https://example.com/robots.txt

gilt für URLs unter diesem Host und Protokoll.

Sie gilt nicht automatisch für:

https://shop.example.com

Wenn eine Subdomain eigene Crawling-Regeln benötigt, benötigt sie entsprechend eine eigene robots.txt unter ihrem Host.

Auch unterschiedliche Protokolle und Ports werden technisch getrennt betrachtet.

Wie ist eine robots.txt aufgebaut? #

Eine einfache Datei kann beispielsweise so aussehen:

User-agent: *
Disallow: /intern/

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

Die wichtigsten Elemente sind:

Anweisung	Bedeutung
User-agent	Bestimmt, für welchen Crawler die folgenden Regeln gelten
Disallow	Verhindert das Crawling passender URL-Pfade
Allow	Erlaubt das Crawling passender URL-Pfade innerhalb entsprechender Regelgruppen
Sitemap	Gibt die vollständige Adresse einer Sitemap an

Was bedeutet User-agent? #

Mit User-agent wird festgelegt, für welchen Crawler eine Gruppe von Regeln bestimmt ist.

Das Sternchen steht dabei für alle Crawler, auf die diese allgemeine Gruppe zutrifft:

User-agent: *

Eine Regel kann auch gezielt für einen bestimmten Crawler geschrieben werden.

Beispielsweise:

User-agent: Googlebot
Disallow: /beispiel/

Damit richtet sich diese Regelgruppe gezielt an Googlebot.

Was bedeutet Disallow? #

Mit Disallow kannst du einen URL-Pfad für den jeweiligen Crawler vom Crawling ausschließen.

Beispiel:

User-agent: *
Disallow: /intern/

Damit wird den entsprechenden Crawlern mitgeteilt, dass URLs unter diesem Pfad nicht gecrawlt werden sollen.

Beispielsweise:

https://example.com/intern/

https://example.com/intern/datei.html

https://example.com/intern/unterordner/

Was bedeutet eine leere Disallow-Anweisung? #

Eine leere Disallow-Anweisung blockiert keinen Pfad.

Beispiel:

User-agent: *
Disallow:

Für diese Regelgruppe wird dadurch nichts vom Crawling ausgeschlossen.

Wenn deine Website vollständig gecrawlt werden darf, ist eine solche Regel jedoch nicht zwingend erforderlich. Eine Website kann grundsätzlich auch ohne einschränkende robots.txt-Regeln gecrawlt werden.

Die gesamte Website für Crawler sperren #

Besonders wichtig ist folgende Regel:

User-agent: *
Disallow: /

Sie weist die angesprochenen Crawler an, die gesamte Website nicht zu crawlen.

Achtung: Diese Konfiguration darf auf einer öffentlich indexierbaren Website nicht versehentlich aktiv bleiben. Besonders nach dem Wechsel von einer Entwicklungs- oder Staging-Umgebung zur produktiven Website solltest du die robots.txt kontrollieren.

Was bedeutet Allow? #

Mit Allow kann ein bestimmter Pfad innerhalb einer ansonsten gesperrten Struktur ausdrücklich für das Crawling freigegeben werden.

Ein vereinfachtes Beispiel:

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

Damit wird der Bereich grundsätzlich gesperrt, während der spezifisch freigegebene Pfad gecrawlt werden darf.

Allow und Disallow können gemeinsam verwendet werden #

Komplexere Websites können Regeln benötigen, bei denen ein größerer Bereich ausgeschlossen und eine bestimmte Ressource oder Unterstruktur wieder freigegeben wird.

Dabei sollte besonders sorgfältig gearbeitet werden, da kleine Änderungen am URL-Muster eine andere Wirkung haben können als erwartet.

Praxis-Tipp: Halte deine robots.txt möglichst einfach. Komplexe Regeln solltest du nur einsetzen, wenn es dafür einen konkreten technischen Grund gibt.

robots.txt ist keine Sicherheitsfunktion #

Eine Disallow-Regel schützt keine vertraulichen Daten.

Die Datei ist öffentlich abrufbar und ihre Regeln können von jedem eingesehen werden.

Wenn du beispielsweise Folgendes einträgst:

User-agent: *
Disallow: /geheime-dokumente/

dann ist der Pfad damit nicht vor Besuchern geschützt.

Wer die URL kennt, kann sie weiterhin direkt aufrufen, sofern kein echter Zugriffsschutz vorhanden ist.

Wichtig: Vertrauliche Inhalte müssen mit geeigneten Zugriffsmechanismen geschützt werden. Eine robots.txt ist kein Passwortschutz und keine Zugriffskontrolle.

robots.txt und noindex sind nicht dasselbe #

Das ist der wichtigste Unterschied des gesamten Artikels.

robots.txt	noindex
steuert Crawling	steuert Indexierung
liegt als zentrale Textdatei vor	wird beispielsweise als Meta-Robots-Anweisung oder HTTP-Header ausgeliefert
kann den Abruf einer URL verhindern	weist Suchmaschinen an, die Seite nicht zu indexieren
kein zuverlässiges Werkzeug zum Entfernen einer Webseite aus Google	für den Ausschluss einer zugänglichen Seite aus dem Index vorgesehen

Warum kann eine blockierte URL trotzdem bei Google erscheinen? #

Google kann eine URL auch auf anderen Wegen kennenlernen, beispielsweise durch Links von anderen Webseiten.

Wenn die URL durch robots.txt vom Crawling ausgeschlossen ist, darf Google ihren eigentlichen Inhalt nicht normal abrufen.

Die URL kann Google trotzdem bekannt sein.

Deshalb ist folgende Annahme falsch:

Disallow = garantiert nicht bei Google

Eine durch robots.txt blockierte URL kann unter bestimmten Umständen weiterhin als URL in den Suchergebnissen erscheinen.

Warum funktioniert noindex nicht, wenn Google die Seite nicht crawlen darf? #

Angenommen, eine Seite enthält:

<meta name="robots" content="noindex">

und gleichzeitig blockiert die robots.txt Google vom Abruf dieser Seite.

Dann entsteht ein Problem:

robots.txt
blockiert Crawling
        ↓
Google ruft Seite nicht ab
        ↓
Google sieht den noindex-Hinweis nicht

Damit Google eine noindex-Anweisung erkennen kann, muss der Crawler auf die betreffende Seite zugreifen dürfen.

Merke: Wenn eine öffentlich erreichbare Seite aus dem Google-Index ausgeschlossen werden soll, darfst du Google nicht gleichzeitig daran hindern, die entsprechende noindex-Anweisung zu sehen.

Kann man noindex in die robots.txt schreiben? #

Nein. Google unterstützt noindex nicht als Regel innerhalb der robots.txt.

Folgendes solltest du daher nicht verwenden:

User-agent: *
Noindex: /beispiel/

Wenn eine HTML-Seite nicht indexiert werden soll, kann beispielsweise eine Robots-Meta-Anweisung verwendet werden:

<meta name="robots" content="noindex">

Für andere Ressourcentypen kann je nach Anwendungsfall ein entsprechender HTTP-Header verwendet werden.

Wann ist robots.txt sinnvoll? #

Eine robots.txt ist insbesondere sinnvoll, wenn du das Crawling bestimmter URL-Bereiche steuern möchtest.

Das kann beispielsweise bei Websites relevant sein, die sehr viele technisch erzeugte URL-Varianten besitzen.

Mögliche Fälle sind:

bestimmte technische Bereiche

unnötige Such- oder Filter-URLs

bestimmte automatisch erzeugte URL-Muster

Crawler-Zugriff auf einzelne Ressourcen

große Mengen irrelevanter Crawl-URLs

Ob eine Sperre sinnvoll ist, muss jedoch für das konkrete System beurteilt werden.

Nicht jede technische URL muss blockiert werden #

Eine lange robots.txt ist nicht automatisch besser als eine kurze.

Bei kleineren und sauber strukturierten Websites besteht häufig kein Grund, zahlreiche Verzeichnisse vorsorglich zu sperren.

Jede zusätzliche Regel erhöht vielmehr das Risiko, versehentlich wichtige Inhalte oder Ressourcen auszuschließen.

Was ist mit WordPress? #

WordPress-Websites besitzen häufig eine automatisch beziehungsweise dynamisch bereitgestellte robots.txt.

Je nach Konfiguration und verwendeten Plugins kann sich deren Inhalt unterscheiden.

Deshalb solltest du nicht ungeprüft eine fremde „optimale WordPress robots.txt“ aus dem Internet übernehmen.

Öffne zunächst:

https://deine-domain.ch/robots.txt

und prüfe, welche Regeln deine Website tatsächlich ausliefert.

Die WordPress-Einstellung zur Sichtbarkeit für Suchmaschinen #

WordPress besitzt unter den Einstellungen eine Option, mit der Suchmaschinen davon abgehalten werden sollen, die Website zu indexieren.

Diese Einstellung ist beispielsweise während einer Entwicklungsphase relevant.

Bei einer öffentlich zugänglichen Website solltest du nach dem Livegang unbedingt kontrollieren, dass eine frühere Entwicklungs-Konfiguration nicht versehentlich bestehen bleibt.

Welche technische Ausgabe daraus entsteht, kann von WordPress-Version, Konfiguration und eingesetzten Plugins abhängen. Entscheidend ist deshalb immer die tatsächlich ausgelieferte Website.

Staging-Websites richtig behandeln #

Eine Entwicklungs- oder Staging-Website sollte normalerweise nicht öffentlich in Suchmaschinen erscheinen.

Eine reine robots.txt-Sperre ist dafür allerdings kein vollständiger Schutz.

Für nicht öffentliche Entwicklungsumgebungen ist ein echter Zugriffsschutz wesentlich zuverlässiger.

Beispielsweise:

Staging-Website
        ↓
Authentifizierung /
Passwortschutz
        ↓
nicht öffentlich zugänglich

Dadurch schützt du nicht nur vor Suchmaschinen-Crawling, sondern auch vor unerwünschtem öffentlichen Zugriff.

robots.txt nach einem Relaunch kontrollieren #

Nach einem Website-Relaunch gehört die robots.txt zu den Dateien, die du unbedingt überprüfen solltest.

Kontrolliere insbesondere:

Ist die produktive Website crawlbar?

Ist versehentlich Disallow: / aktiv?

Sind wichtige Bereiche gesperrt?

Sind wichtige CSS-/JS-Ressourcen erreichbar?

Ist die Sitemap-Adresse korrekt?

Stammen Regeln noch aus
der Entwicklungsumgebung?

Wenn gleichzeitig die URL-Struktur geändert wurde, solltest du außerdem Weiterleitungen, Sitemaps und Indexierungsstatus kontrollieren.

Wichtige CSS- und JavaScript-Dateien nicht unnötig blockieren #

Google rendert moderne Webseiten und benötigt dafür häufig CSS-, JavaScript- und andere Ressourcen.

Wenn wichtige Ressourcen durch die robots.txt blockiert werden, kann Google eine Seite möglicherweise nicht so verarbeiten und darstellen, wie ein normaler Besucher sie sieht.

Deshalb solltest du CSS- und JavaScript-Verzeichnisse nicht pauschal sperren, nur weil diese Dateien selbst nicht als normale Suchergebnisse gedacht sind.

Google soll die Seite möglichst wie ein Besucher verstehen können #

Wenn Layout, Navigation oder wesentliche Inhalte von JavaScript oder CSS abhängen, kann das Blockieren dieser Ressourcen die Verarbeitung erschweren.

Bei Problemen kannst du die URL-Prüfung der Google Search Console verwenden und untersuchen, wie Google die betreffende Seite verarbeitet.

Mehr zur URL-Prüfung findest du unter Google indexiert meine Website nicht: Ursachen prüfen.

Eine Sitemap in robots.txt angeben #

Die robots.txt kann auf eine XML-Sitemap hinweisen.

Beispiel:

User-agent: *
Disallow:

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

Die Sitemap-Adresse muss vollständig angegeben werden.

Wenn deine Website einen Sitemap-Index verwendet, kann entsprechend dieser angegeben werden:

Sitemap: https://example.com/sitemap_index.xml

Wie XML-Sitemaps funktionieren und wie du sie bei Google einreichst, erklären wir unter XML-Sitemap: Was sie macht und wie du sie bei Google einreichst.

Sitemap und robots.txt haben gegensätzliche Aufgaben #

Vereinfacht kannst du dir den Unterschied so merken:

XML-Sitemap

"Hier sind wichtige URLs,
die du kennen solltest."


robots.txt

"Diese URL-Bereiche
sollst du nicht crawlen."

Deshalb sollten beide Konfigurationen logisch zusammenpassen.

Eine URL nicht gleichzeitig empfehlen und blockieren #

Wenn eine URL als wichtige indexierbare Seite in deiner XML-Sitemap steht, sollte sie nicht gleichzeitig durch robots.txt vom Crawling ausgeschlossen werden.

Eine solche Konfiguration erzeugt widersprüchliche Signale:

Sitemap:
"Diese URL ist relevant."

robots.txt:
"Diese URL nicht abrufen."

Prüfe deshalb bei Indexierungsproblemen immer beide Seiten der Konfiguration.

Kommentare in robots.txt verwenden #

Kommentare können mit einem # eingeleitet werden.

Beispiel:

# Technischen Bereich nicht crawlen
User-agent: *
Disallow: /intern/

Alles nach dem # wird in dieser Zeile als Kommentar behandelt.

Kommentare können bei komplexeren Dateien helfen zu dokumentieren, warum eine bestimmte Regel existiert.

Groß- und Kleinschreibung bei URL-Pfaden beachten #

Bei den URL-Pfaden in Allow– und Disallow-Regeln ist die Groß- und Kleinschreibung relevant.

Beispielsweise sind:

/Bilder/

/bilder/

nicht automatisch dasselbe URL-Muster.

Schreibe Regeln deshalb passend zu den tatsächlich verwendeten URL-Pfaden.

Wildcards in robots.txt #

Google unterstützt in Pfadregeln unter anderem das Sternchen * als Platzhalter.

Ein Beispiel:

User-agent: Googlebot
Disallow: /*.pdf

Damit können URL-Pfade anhand eines Musters erfasst werden.

Solche Regeln solltest du mit Vorsicht einsetzen, weil sie wesentlich mehr URLs betreffen können als eine einfache Verzeichnisregel.

Das Dollarzeichen für das Ende einer URL #

Google unterstützt außerdem $, um das Ende eines URL-Musters zu kennzeichnen.

Beispiel:

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

Das Muster zielt auf URLs, deren Pfad entsprechend auf .pdf endet.

Eine URL mit zusätzlichen Zeichen beziehungsweise Parametern nach diesem Muster kann dadurch anders behandelt werden.

Praxis-Tipp: Wildcards sind mächtig, aber fehleranfällig. Für eine normale Unternehmenswebsite solltest du keine komplizierten Muster einsetzen, wenn einfache Regeln denselben Zweck erfüllen.

Welche Regel gewinnt bei Überschneidungen? #

Wenn mehrere Allow– und Disallow-Regeln auf eine URL passen, wertet Google die spezifischste passende Regel anhand der Länge des übereinstimmenden Pfads aus.

Ein vereinfachtes Beispiel:

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

Für eine URL unter:

https://example.com/ordner/oeffentlich/seite

ist die spezifischere Allow-Regel maßgeblich.

Gerade bei komplexen Regelwerken solltest du deshalb nicht nur die Reihenfolge der Zeilen betrachten.

Crawl-delay und Google #

Manche robots.txt-Beispiele im Internet enthalten eine Anweisung wie:

Crawl-delay: 10

Google unterstützt crawl-delay in der robots.txt nicht.

Du solltest diese Anweisung deshalb nicht als Methode verwenden, um die Crawl-Geschwindigkeit von Googlebot zu steuern.

robots.txt nicht unnötig mit fremden Regeln füllen #

Im Internet finden sich zahlreiche vorgefertigte Dateien mit langen Listen von Bots und Regeln.

Solche Vorlagen solltest du nicht blind übernehmen.

Eine fremde Konfiguration kann:

für ein anderes CMS gedacht sein

veraltete Regeln enthalten

wichtige Ressourcen blockieren

unnötige Bot-Regeln enthalten

nicht zu deiner URL-Struktur passen

zukünftige Fehler schwerer
nachvollziehbar machen

Eine kurze, verständliche und dokumentierte Datei ist häufig die bessere Lösung.

robots.txt und KI-Crawler #

Auch andere automatisierte Systeme können eigene User-Agent-Namen verwenden und das Robots Exclusion Protocol berücksichtigen.

Ob und wie ein bestimmter Dienst Crawling-Regeln interpretiert, hängt vom jeweiligen Anbieter und Crawler ab.

Du solltest deshalb nicht davon ausgehen, dass eine einzelne Regel für Googlebot automatisch sämtliche Suchmaschinen-, KI-, Analyse- und andere Crawler betrifft.

Wenn du einen bestimmten Crawler gezielt steuern möchtest, solltest du dessen aktuelle offizielle Dokumentation und User-Agent-Bezeichnung prüfen.

robots.txt öffentlich im Browser prüfen #

Die einfachste erste Kontrolle besteht darin, die Datei direkt aufzurufen:

https://deine-domain.ch/robots.txt

Prüfe anschließend:

Wird die Datei angezeigt?

Ist der Inhalt erwartungsgemäß?

Gibt es Disallow: /?

Werden wichtige Pfade blockiert?

Ist die Sitemap korrekt?

Gibt es alte Regeln?

robots.txt in Google Search Console prüfen #

Google Search Console stellt Informationen zur von Google erkannten robots.txt bereit.

Damit kannst du beispielsweise prüfen, welche Datei Google für deine Website erkannt hat und ob beim Abruf Probleme bestehen.

Bei einer konkreten URL ist außerdem die URL-Prüfung wichtig, wenn du untersuchen möchtest, ob Google die Seite crawlen kann.

Nach einer Änderung nicht nur den Browser prüfen #

Wenn du eine robots.txt-Regel geändert hast, solltest du nicht nur kontrollieren, ob die neue Datei im Browser sichtbar ist.

Prüfe zusätzlich eine oder mehrere tatsächlich betroffene URLs.

Beispielsweise:

Regel geändert
        ↓
robots.txt im Browser prüfen
        ↓
betroffene URL identifizieren
        ↓
URL-Prüfung verwenden
        ↓
Crawlbarkeit kontrollieren

Google kann robots.txt zwischenspeichern #

Google ruft die robots.txt regelmäßig ab und kann deren Inhalt zwischenspeichern.

Eine Änderung muss deshalb nicht in derselben Sekunde bei jedem Crawl berücksichtigt werden.

Wenn du eine kritische Sperre behoben hast, solltest du den aktuellen Zustand kontrollieren und Google Zeit geben, die Änderung erneut abzurufen und zu verarbeiten.

Was passiert, wenn robots.txt nicht erreichbar ist? #

Das Verhalten eines Crawlers hängt auch davon ab, welchen HTTP-Status die robots.txt liefert.

Ein dauerhaft nicht vorhandenes robots.txt-Dokument ist nicht dasselbe wie ein temporärer Serverfehler beim Abruf.

Du solltest deshalb nicht absichtlich mit Fehlerzuständen experimentieren, um Crawling zu steuern.

Für eine normale Website sollte die gewünschte Konfiguration eindeutig und zuverlässig erreichbar sein.

Die Grundlagen zu HTTP-Antworten erklären wir unter HTTP-Statuscodes erklärt: 200, 301, 404, 403 und 500.

robots.txt und 404 #

Wenn keine robots.txt existiert und der entsprechende Abruf einen normalen „nicht gefunden“-Status liefert, behandelt Google dies grundsätzlich so, als gäbe es keine Crawling-Einschränkungen durch eine robots.txt.

Das bedeutet aber nicht, dass du absichtlich eine fehlerhafte Datei erzeugen solltest.

Eine vorhandene, verständliche Konfiguration ist für Wartung und Diagnose meist einfacher.

robots.txt bei einer neuen Website prüfen #

Vor dem Livegang einer neuen Website solltest du folgende Punkte kontrollieren:

robots.txt erreichbar?
        ↓
keine versehentliche
Gesamtsperre?
        ↓
wichtige Seiten crawlbar?
        ↓
wichtige Ressourcen crawlbar?
        ↓
Sitemap-Adresse korrekt?
        ↓
noindex separat kontrollieren?
        ↓
Search Console eingerichtet?
        ↓
wichtige URLs testen?

robots.txt nach einem Domainwechsel #

Bei einem Domainwechsel solltest du die robots.txt sowohl im Zusammenhang mit der alten als auch mit der neuen Domain berücksichtigen.

Die neue Website darf Google nicht versehentlich vom Crawling abhalten.

Gleichzeitig müssen notwendige Weiterleitungen der alten URLs für Google erreichbar sein.

Blockiere deshalb nicht pauschal die alte Website, wenn Google ihre Weiterleitungen noch crawlen können soll.

robots.txt und Weiterleitungen #

Wenn Google eine alte URL wegen einer robots.txt-Regel nicht crawlen darf, kann dies verhindern, dass Google eine dort eingerichtete Weiterleitung normal abruft.

Bei einer Migration sollte Google relevante alte URLs deshalb grundsätzlich abrufen können, um ihre Weiterleitungen zu den neuen Zielen zu erkennen.

Wie du permanente Weiterleitungen korrekt einsetzt, erklären wir unter 301-Weiterleitung einrichten: URLs dauerhaft umleiten.

robots.txt und HTTP-Statuscodes gemeinsam betrachten #

Bei technischen SEO-Problemen solltest du mehrere Ebenen auseinanderhalten:

robots.txt
→ Darf Google die URL crawlen?

HTTP-Status
→ Was antwortet der Server?

noindex
→ Darf die Seite indexiert werden?

Canonical
→ Welche URL ist die bevorzugte Version?

Sitemap
→ Welche URL wird als relevant gemeldet?

Erst das Zusammenspiel dieser Signale zeigt, wie eine URL technisch konfiguriert ist.

Beispiel: öffentliche Seite soll indexiert werden #

Angenommen, folgende URL soll bei Google erscheinen:

https://example.com/ratgeber

Eine saubere Konfiguration könnte vereinfacht so aussehen:

robots.txt:
Crawling erlaubt

HTTP:
200 OK

Meta Robots:
kein noindex

Canonical:
https://example.com/ratgeber/

Sitemap:
URL enthalten

Interne Links:
vorhanden

Damit bestehen auf diesen Ebenen keine offensichtlichen technischen Widersprüche.

Beispiel: Seite soll nicht indexiert werden #

Eine öffentlich erreichbare Seite soll von Google abrufbar sein, aber nicht in den Suchergebnissen erscheinen.

Dann könnte das Prinzip lauten:

robots.txt:
Crawling erlaubt

Meta Robots:
noindex

Google kann die Seite crawlen, die noindex-Anweisung erkennen und entsprechend verarbeiten.

Beispiel: privater Bereich #

Ein wirklich vertraulicher Bereich sollte nicht lediglich durch:

Disallow: /privat/

„geschützt“ werden.

Stattdessen benötigt er einen echten Zugriffsschutz.

privater Inhalt
        ↓
Login / Authentifizierung
        ↓
nicht öffentlich abrufbar

Die Frage der Suchmaschinenindexierung ist dann nur ein Teil der eigentlichen Zugriffskontrolle.

Beispiel: komplette Website versehentlich blockiert #

Nach einem Relaunch zeigt die Datei:

User-agent: *
Disallow: /

Die Website soll aber öffentlich von Google gecrawlt werden.

Dann ist diese Regel ein kritischer Konfigurationsfehler.

Nach der Korrektur solltest du:

robots.txt erneut aufrufen
        ↓
Regel kontrollieren
        ↓
wichtige URLs mit
Search Console prüfen
        ↓
Sitemap kontrollieren
        ↓
Indexierungsentwicklung beobachten

Beispiel: URL ist in Sitemap und gleichzeitig blockiert #

Sitemap:

https://example.com/produkt/


robots.txt:

Disallow: /produkt/

Wenn die Produktseite regulär indexiert werden soll, widersprechen sich diese Signale.

Die Lösung besteht nicht darin, Google häufiger zur Indexierung aufzufordern, sondern zuerst die technische Konfiguration zu korrigieren.

Wann solltest du robots.txt überhaupt ändern? #

Ändere die Datei nur, wenn du einen konkreten Grund dafür hast.

Beispielsweise:

unnötiger Crawl-Bereich identifiziert

technisch erzeugte URL-Struktur
soll nicht gecrawlt werden

bestehende falsche Regel korrigieren

Sitemap-Adresse ergänzen

gezielten Crawler steuern

Migration / Relaunch
korrekt konfigurieren

„Ich möchte meine SEO verbessern“ ist allein noch kein Grund, zusätzliche Disallow-Regeln einzubauen.

Vor Änderungen immer die Auswirkungen prüfen #

Eine einzige kurze Regel kann tausende URLs betreffen.

Aus:

Disallow: /shop/filter/

und:

Disallow: /shop/

können völlig unterschiedliche Auswirkungen entstehen.

Kontrolliere deshalb vor dem Speichern exakt, welche URLs von einer Regel betroffen sind.

Achtung: Experimentiere nicht direkt auf einer produktiven Website mit komplexen robots.txt-Regeln, wenn du deren Auswirkungen nicht eindeutig beurteilen kannst.

Häufige Fehler bei robots.txt #

Disallow: / auf Live-Website

robots.txt als noindex verwenden

noindex-Seite gleichzeitig blockieren

vertrauliche Inhalte nur
mit robots.txt "schützen"

wichtige CSS-Dateien blockieren

wichtige JavaScript-Dateien blockieren

Sitemap-URL falsch eintragen

alte Staging-Regeln übernehmen

fremde WordPress-Vorlagen
ungeprüft kopieren

komplizierte Wildcards ohne
Notwendigkeit verwenden

Groß-/Kleinschreibung ignorieren

Crawl-delay für Google verwenden

alte Domain bei Migration blockieren,
obwohl Redirects gecrawlt werden sollen

Checkliste: robots.txt richtig prüfen #

https://deine-domain.ch/robots.txt
aufrufen
        ↓
Datei erreichbar?
        ↓
richtiger Host?
        ↓
User-agent-Regeln prüfen
        ↓
Disallow-Regeln prüfen
        ↓
Disallow: / vorhanden?
        ↓
Allow-Regeln prüfen
        ↓
Wildcards kontrollieren
        ↓
wichtige Seiten crawlbar?
        ↓
wichtige CSS-/JS-Ressourcen crawlbar?
        ↓
Sitemap-Adresse korrekt?
        ↓
noindex separat prüfen
        ↓
wichtige URLs in
Search Console testen
        ↓
nach Änderungen erneut kontrollieren

robots.txt, noindex und Sitemap im Vergleich #

Werkzeug	Hauptaufgabe	Typischer Zweck
robots.txt	Crawling steuern	Crawler von bestimmten URL-Bereichen fernhalten
noindex	Indexierung verhindern	zugängliche Seite aus Suchergebnissen ausschließen
XML-Sitemap	URLs mitteilen	Suchmaschinen auf relevante URLs hinweisen

Diese drei Mechanismen ersetzen einander nicht.

Eine technisch saubere Website verwendet sie entsprechend ihrer jeweiligen Aufgabe.

Zusammenfassung #

Die robots.txt ist eine öffentlich erreichbare Textdatei im Stammverzeichnis eines Hosts. Sie teilt Suchmaschinen-Crawlern mit, welche URL-Bereiche sie crawlen dürfen und welche nicht.

Mit User-agent bestimmst du den angesprochenen Crawler. Disallow schließt passende Pfade vom Crawling aus, während Allow spezifischere Pfade freigeben kann. Zusätzlich kann die vollständige Adresse einer XML-Sitemap angegeben werden.

Die wichtigste Unterscheidung lautet: robots.txt steuert Crawling und noindex steuert Indexierung. Eine durch robots.txt blockierte URL kann Google trotzdem bekannt sein und unter bestimmten Umständen weiterhin in den Suchergebnissen erscheinen.

Eine robots.txt ist außerdem keine Sicherheitsfunktion. Vertrauliche Inhalte benötigen einen echten Zugriffsschutz.

Besondere Vorsicht ist nach einem Relaunch, bei Domainwechseln und bei Staging-Websites erforderlich. Eine versehentliche Regel wie Disallow: / kann Google daran hindern, die gesamte produktive Website zu crawlen.

Komplexe Regeln, Wildcards und lange Listen fremder Crawler solltest du nur einsetzen, wenn dafür ein konkreter technischer Grund besteht.

Eine gute robots.txt ist deshalb nicht möglichst umfangreich. Sie ist so einfach wie möglich und so spezifisch wie nötig – und jede darin enthaltene Sperre hat einen nachvollziehbaren Zweck.