Eine Kanzlei in Essen hatte eine alte Landingpage für eine Leistung, die sie nicht mehr anbietet. Der Auftrag an die Agentur: die Seite soll aus Google raus. Die Agentur setzte ein Disallow in die robots.txt, meldete „erledigt" und ging. Drei Wochen später stand die URL noch in den Suchergebnissen, jetzt ohne Beschreibung, dafür mit einer neuen Meldung in der Search Console: „Indexiert, obwohl durch robots.txt-Datei blockiert".
Das ist der Normalfall, nicht die Ausnahme. Die robots.txt steuert das Crawlen, noindex steuert das Indexieren. Die robots.txt ist ein Türsteher: Sie entscheidet, ob ein Bot eine URL abrufen darf, und sagt nichts darüber, ob die URL in den Ergebnissen erscheinen darf. noindex ist ein Schild in der Seite selbst: du darfst rein, aber trag das nicht ins Verzeichnis ein. Lässt der Türsteher niemanden herein, liest keiner das Schild.
Dieser Text gibt dir eine Entscheidungstabelle für die fünf häufigsten Ziele, zeigt beide Wege, ein noindex zu setzen, und geht danach jede Falle durch, jeweils mit dem Symptom, an dem du sie erkennst.
Welches Werkzeug erreicht welches Ziel
| Was du erreichen willst | Richtiges Werkzeug | Der übliche Fehlgriff |
|---|---|---|
| Eine Seite soll nicht in Google auftauchen | noindex, Crawlen erlauben | Disallow in der robots.txt |
| Crawl-Kapazität für tausende Filter-URLs sparen | Disallow in der robots.txt | noindex auf jeder einzelnen URL |
| Inhalte vor Menschen verbergen | Passwortschutz oder Login | Disallow in der robots.txt |
| Eine Seite jetzt sofort aus den Ergebnissen holen | Entfernungen-Tool, danach noindex | nur Disallow, dann warten |
| Ein PDF oder Bild aus dem Index nehmen | X-Robots-Tag: noindex im HTTP-Header | ein Meta-Tag, das es dort nicht gibt |
Zeile eins ist der Fall von oben. Zeile zwei ist der einzige, in dem die robots.txt wirklich passt: Ein Onlineshop mit 400 Produkten erzeugt über Filterkombinationen leicht 80.000 URLs. Die willst du nicht per noindex behandeln, denn dafür müsste Google jede einzelne abrufen. Hier sperrst du das Muster.
Zeile drei ist die peinlichste Verwechslung, weil sie in die falsche Richtung wirkt (dazu unten mehr). Zeile vier braucht beides, weil das schnelle Werkzeug befristet ist. Zeile fünf kennt kaum jemand: Ein PDF hat keinen <head> für ein Meta-Tag.
Die robots.txt: wo sie liegt, was sie kann, was Google ignoriert
Die Datei muss exakt unter /robots.txt im Wurzelverzeichnis liegen und gilt nur für den Host, das Protokoll und den Port, unter dem sie liegt. Diese Regel kippt bei Subdomains am häufigsten: https://example.de/robots.txt gilt nicht für https://shop.example.de/. Der Shop braucht seine eigene Datei.
Google wertet genau vier Felder aus:
User-agent: *
Disallow: /warenkorb
Disallow: /*?filter=
Disallow: /suche
Allow: /suche/beliebte-anfragen
Sitemap: https://example.de/sitemap.xml
User-agent benennt den Bot, * gilt für alle ohne eigenen Block. Disallow sperrt einen Pfad, Allow schneidet eine Ausnahme heraus, Sitemap nennt deine Sitemap. Zwei Platzhalter versteht Google: * steht für beliebig viele Zeichen, $ markiert das Ende der URL, weshalb Disallow: /*.pdf$ alle PDF-Dateien sperrt. Ein Stern am Ende eines Pfads ist überflüssig, /suche* und /suche bedeuten dasselbe.
Bei widersprüchlichen Regeln gewinnt die spezifischere, gemessen an der Länge des Pfads. Oben ist /suche/beliebte-anfragen länger als /suche, also ist diese eine Seite erlaubt und der Rest gesperrt. Bei gleicher Länge gewinnt die weniger restriktive, also Allow. Bei Ausnahmen musst du nicht raten: Schreib den vollständigen Pfad hin, dann ist er automatisch spezifischer. Zwei Kleinigkeiten: Die Datei ist öffentlich lesbar, und Google beachtet nur die ersten 500 KiB.
Und nun die Liste, um die es eigentlich geht, denn hier ist viel veraltetes Halbwissen im Umlauf. Google wertet diese Anweisungen nicht aus:
Crawl-delay: Bing und Yandex halten sich daran, Googlebot nicht. Das Werkzeug zur Crawling-Frequenz in der Search Console hat Google Anfang 2024 abgeschaltet. Wenn Googlebot deinen Server überlastet, ist die dokumentierte Notbremse ein zeitweiliger Status503oder429.Noindex: /pfadundNofollow: /pfad: Google hat den Code dafür am 1. September 2019 abgeschaltet. Vorher hat es inoffiziell funktioniert, deshalb stehen die Zeilen heute noch in Anleitungen. Sie tun nichts.Host: eine Yandex-Erfindung für die Wahl der Hauptdomain. Dafür nimmst du Canonical-Tags.
Findest du eine dieser Zeilen in deiner Datei, lösch sie. Sie wirkt nicht.
noindex setzen: als Meta-Tag und als HTTP-Header
Weg eins gehört in den <head> der Seite:
<meta name="robots" content="noindex">
Damit sprichst du alle Suchmaschinen an, die die Anweisung unterstützen. Nur Google ausschließen und bei Bing drinbleiben geht mit <meta name="googlebot" content="noindex">. Das Tag muss im <head> stehen und die Seite abrufbar sein. Ein noindex, das erst per JavaScript nachgeladen wird, ist ein Glücksspiel.
Weg zwei ist der HTTP-Header X-Robots-Tag: noindex. Er wirkt auf jede Datei, auch auf solche ohne <head>, und deshalb kennt ihn kaum jemand. Für Apache in der .htaccess, hier für alle PDF-Dateien:
<FilesMatch "\.pdf$">
Header set X-Robots-Tag "noindex"
</FilesMatch>
Und für nginx:
location ~* \.pdf$ {
add_header X-Robots-Tag "noindex";
}
Willst du die alte Preisliste als PDF aus Google nehmen, ist das der Weg. Ein Disallow: /*.pdf$ macht die Datei nur unlesbar, nicht unsichtbar. Ob der Header sitzt, prüfst du mit curl -I https://example.de/preisliste.pdf.
„Indexiert, obwohl durch robots.txt-Datei blockiert" und der Weg heraus
Diese Meldung ist kein Fehler von Google, sondern die logische Folge einer Sperre. Google erfährt die URL aus einem Link, aus einer Sitemap oder aus der eigenen Historie, versucht sie abzurufen, und die robots.txt sagt nein. Google hat eine Adresse, aber keinen Inhalt. Und weil eine verlinkte URL für irgendwen relevant sein könnte, behält Google sie im Index. Ohne Snippet.
Der Weg heraus hat eine Reihenfolge, die sich nicht abkürzen lässt:
- Die Sperre in der robots.txt aufheben. Ja, wirklich. Das fühlt sich falsch an und ist der einzige Weg.
noindexauf der Seite setzen, per Meta-Tag oder Header.- Die URL über die URL-Prüfung abrufen und die Indexierung beantragen. Das beschleunigt den Besuch, garantiert ihn nicht.
- Warten, bis der Status auf
URL als „noindex" markiertwechselt. Google nennt für diesen Übergang keine Frist; in der Praxis sind es Tage bis Wochen. - Erst danach die Sperre wieder setzen, falls du sie wirklich brauchst. Meistens brauchst du sie nicht.
Stehen im selben Bericht andere Statusmeldungen, die du nicht deuten kannst, sortiert Seite wird nicht indexiert sie durch. Nur ein Teil davon ist ein Problem.
Die Fallen, die die üblichen Ratgeber übersehen
CSS und JavaScript sperren. Vor zehn Jahren war Disallow: /wp-content/ ein verbreiteter Tipp. Heute rendert Google Seiten wie ein Browser, und eine Seite ohne Stylesheet ist für Google eine Textwüste. Symptom: In der URL-Prüfung zeigt der gerenderte Screenshot eine unformatierte Seite. Bei einer JavaScript-Anwendung sperrst du im Extremfall den ganzen Text.
Die robots.txt als Versteck. Jeder kann deine Datei aufrufen. Wer dort Disallow: /backup-2024/ oder Disallow: /interne-preise/ hineinschreibt, veröffentlicht eine Landkarte seiner Geheimnisse, und gesperrt ist nichts: Wer die URL kennt, ruft sie ab. Symptom: keins, und das ist das Gefährliche. Hier hilft ein Passwort. Dahinter kann Google weder crawlen noch indexieren, und niemand sieht in einer Textdatei, dass die Seite existiert.
Das noindex aus der Testumgebung. Auf der Staging-Domain gehört ein noindex hin. Falsch wird es, wenn beim Deploy die Konfiguration mitwandert. Symptom: Der Traffic bricht ein bis drei Wochen nach dem Relaunch ein, und die Zahl der Seiten mit dem Status URL als „noindex" markiert wächst. Nimm es als festen Punkt in die Deploy-Prüfung auf: einmal curl -I auf die Startseite, einmal in den Quelltext sehen.
Eine robots.txt, die einen Serverfehler liefert. Eine fehlende Datei mit Status 404 ist harmlos: Google nimmt an, es gibt keine Regeln, und crawlt alles. Ein Serverfehler mit 5xx ist das Gegenteil: In den ersten zwölf Stunden stellt Google das Crawlen der Website ein, danach greift für bis zu 30 Tage die letzte gecachte Fassung, und erst danach wird die Datei wie eine fehlende behandelt. Ein Server, der auf /robots.txt einen Fehler 500 wirft, ist also schlimmer als gar keine robots.txt. Umgekehrt nutzbar: Ein bewusster 503 ist die dokumentierte Notbremse für ein Wartungsfenster.
nofollow mit noindex verwechseln. nofollow sagt: folge den Links auf dieser Seite nicht weiter. Über die Indexierung sagt es nichts. Ein <meta name="robots" content="nofollow"> allein lässt die Seite fröhlich in den Suchergebnissen stehen. Wer beides will, schreibt content="noindex, nofollow", wobei das nofollow meist unnötig ist.
Wenn etwas Falsches sofort raus muss, und wie du prüfst, was gilt
Steht öffentlich etwas, das nicht öffentlich sein darf, ein falscher Preis, ein Name, ein interner Entwurf, dann ist noindex zu langsam: Es wirkt erst beim nächsten Crawl. Dafür gibt es in der Search Console den Bericht „Entfernungen", Tab „Vorübergehende Entfernungen", Knopf „Neue Anfrage". Die URL verschwindet innerhalb von Stunden aus den Ergebnissen.
Das Entscheidende steht im Namen: vorübergehend. Die Entfernung hält rund sechs Monate. Danach kommt die URL zurück, wenn die Seite erreichbar ist und kein noindex trägt. Der richtige Ablauf: erst entfernen, damit es sofort weg ist, dann in derselben Stunde noindex setzen, ein Passwort davorschieben oder die Seite mit 404 beziehungsweise 410 löschen. Wer nur den ersten Schritt macht, hat das Problem in einem halben Jahr wieder, und dann erinnert sich niemand, warum.
Was tatsächlich gilt, siehst du an zwei Stellen. Unter Einstellungen → robots.txt liegt der robots.txt-Bericht: Hosts deiner Property, Status des letzten Abrufs („Abgerufen" oder „Nicht abgerufen"), Datum und die Zeilen, die Google nicht verstanden hat. Er zeigt die Abrufe der letzten 30 Tage, und du kannst dort ein erneutes Crawling anfordern. Die zweite Stelle ist die URL-Prüfung oben in der Suchleiste: Sie sagt dir für eine einzelne URL, ob Crawlen und Indexierung zulässig sind und welche Regel greift. Beides ohne externe Werkzeuge. Wie du die Property aufsetzt, steht in Google Search Console einrichten.
KI-Crawler: dieselbe Datei, andere Abwägung
Für GPTBot, ClaudeBot, PerplexityBot und Verwandte gilt dieselbe robots.txt mit denselben vier Feldern. Die Abwägung ist eine andere, weil es nicht um Suchergebnisse geht, sondern um Trainingsdaten und Zitate in Antworten. Ein noindex hilft dabei nicht: Es ist eine Anweisung an Suchmaschinen, kein Opt-out aus KI-Systemen. Welcher Bot welche Aufgabe hat und welche Sperre Sichtbarkeit kostet, steht in KI-Crawler steuern. Wenn du diesen Systemen zeigen willst, wo deine besten Inhalte liegen, ist eine llms.txt die halbe Stunde Arbeit dafür.
Womit du anfängst
- Ruf
https://deine-domain.de/robots.txtim Browser auf und lies die Datei Zeile für Zeile. Bei jedemDisallowfragst du: soll diese Seite nur nicht gecrawlt werden, oder soll sie nicht in Google stehen? Beim zweiten Fall ist die Zeile falsch. - Lösch alles, was Google nicht auswertet:
Crawl-delay,Noindex,Nofollow,Host. - Prüf, ob dort Pfade stehen, die niemand kennen sollte. Falls ja: raus aus der Datei, rein hinter ein Passwort.
- Öffne den Bericht zur Seitenindexierung und such nach „Indexiert, obwohl durch robots.txt-Datei blockiert". Jede URL dort bekommt die Fünf-Schritt-Behandlung von oben.
- Betreibst du Subdomains oder einen separaten Shop, ruf deren robots.txt einzeln auf.
Das ist an einem Nachmittag erledigt und beseitigt mehr Sichtbarkeitsprobleme als die meisten Optimierungsprojekte. Fehlt dir dabei der systematische Blick, fängt die Arbeit eine Stufe früher an: bei SEO-Probleme finden.
Häufige Fragen
Was ist der Unterschied zwischen robots.txt und noindex?
Die robots.txt steuert das Crawlen: Sie sagt einem Bot, welche URLs er abrufen darf. noindex steuert das Indexieren: Es sagt der Suchmaschine, dass diese Seite nicht in den Ergebnissen erscheinen soll. Eine per robots.txt gesperrte Seite kann trotzdem im Index landen, eine Seite mit noindex nicht.
Der Merksatz: Die robots.txt ist ein Türsteher, noindex ein Schild im Inneren. Lässt der Türsteher niemanden herein, liest niemand das Schild. Die beiden Werkzeuge schließen sich aus, statt sich zu ergänzen.
Wie schließe ich eine einzelne Seite von Google aus?
Du setzt noindex auf die Seite, als Meta-Tag im Kopfbereich oder als HTTP-Header X-Robots-Tag, und stellst sicher, dass die robots.txt dieselbe Seite nicht sperrt. Google muss sie abrufen können, um die Anweisung zu sehen. Bis die Seite verschwindet, dauert es meist Tage bis Wochen; eine verbindliche Frist nennt Google nicht.
Warum ist meine Seite trotz robots.txt bei Google?
Weil die robots.txt nur das Abrufen verhindert, nicht das Auflisten. Google kennt die URL aus Links, aus deiner Sitemap oder aus früheren Crawls und darf sie nicht mehr besuchen. Also bleibt sie im Index, aber ohne Inhalt. Der Weg heraus führt über das Crawlen: Sperre aufheben, noindex setzen, Google die Seite besuchen lassen.
Brauche ich überhaupt eine robots.txt?
Zwingend nicht. Fehlt die Datei und liefert der Server einen 404, nimmt Google an, dass keine Regeln gelten, und crawlt normal weiter. Kleine Websites mit ein paar Dutzend Seiten kommen ohne aus.
Sinnvoll wird sie, wenn du viele URLs hast, die Crawler nur Zeit kosten: Filterparameter, interne Suchergebnisse, Warenkorb, Konto. Wichtig ist, dass eine vorhandene Datei sauber ausgeliefert wird, denn ein Serverfehler auf /robots.txt ist schlimmer als keine Datei.
Wie sperre ich eine PDF-Datei für Google?
Über den HTTP-Header X-Robots-Tag: noindex, den dein Webserver für die Datei mitschickt. Ein PDF hat keinen Kopfbereich für ein Meta-Tag, deshalb ist der Header der einzige Weg. Ein Disallow hilft nicht: Die Datei bleibt in den Ergebnissen stehen, Google kann sie nur nicht mehr lesen.
Was bedeutet „Indexiert, obwohl durch robots.txt-Datei blockiert"?
Google hat die URL in den Index aufgenommen, darf sie aber wegen deiner robots.txt nicht abrufen: Google kennt die Adresse, nicht den Inhalt, und zeigt die Seite ohne Beschreibung. Ob das ein Problem ist, entscheidet deine Absicht. Wolltest du die Seite aus Google haben, hebst du die Sperre auf und setzt noindex. Wolltest du nur Crawl-Kapazität sparen, ignorier die Meldung.
Darf ich CSS und JavaScript in der robots.txt sperren?
Besser nicht. Google rendert Seiten wie ein Browser und braucht dafür Stylesheets und Skripte. Sind sie gesperrt, sieht Google eine unformatierte oder halb leere Seite, und bei Inhalten, die erst per JavaScript entstehen, kann der komplette Text verschwinden. Der Rat, Ordner wie wp-content zu sperren, stammt aus einer Zeit, in der Suchmaschinen nur HTML gelesen haben.
Wie schnell wirkt eine Änderung an der robots.txt?
Google speichert die Datei in der Regel bis zu 24 Stunden zwischen, bei Serverproblemen länger. Beschleunigen kannst du das im robots.txt-Bericht. Etwas anderes ist die Wirkung auf die Ergebnisse: Eine neue Sperre entfernt nichts aus dem Index, und eine gelöste Sperre führt nicht sofort zu einem Besuch.
Wie entferne ich eine Seite sofort aus Google?
Über den Bericht „Entfernungen" in der Search Console, Tab „Vorübergehende Entfernungen", Knopf „Neue Anfrage". Die URL verschwindet innerhalb von Stunden. Die Entfernung hält rund sechs Monate, danach kommt die URL zurück. Nutz die Zeit für die dauerhafte Lösung: noindex, ein Passwort oder Status 404 beziehungsweise 410.