Hauptbereich
Agency
technisches-seo

robots.txt vs. noindex vs. Canonical — drei Signale, drei Phasen, ein häufiger Fehler

Redaktion ·

robots.txt vs. noindex vs. Canonical — drei Signale, drei Phasen, ein häufiger Fehler

Drei Werkzeuge, die ständig verwechselt werden: robots.txt, noindex und rel=canonical. Auf den ersten Blick machen alle „irgendwas mit Sichtbarkeit bei Google”. Tatsächlich greifen sie in drei verschiedenen Phasen — Crawlen, Indexieren, Konsolidieren — und wer sie verwechselt, baut Setups, die genau das Gegenteil bewirken. Der bekannteste Fehler kostet regelmäßig Sichtbarkeit, weil zwei Signale sich gegenseitig blockieren. Dieser Artikel sortiert, welches Signal wann wirkt, und gibt dir einen Entscheidungsbaum für den Alltag.

Drei Phasen, drei Signale

Google verarbeitet eine URL in einer festen Reihenfolge: Erst wird sie gecrawlt (der Inhalt abgeholt), dann indexiert (in den durchsuchbaren Index aufgenommen), und Duplikate werden konsolidiert (mehrere ähnliche URLs auf eine Vorzugs-URL zusammengeführt). Jedes der drei Signale sitzt in genau einer dieser Phasen:

robots.txt → steuert das Crawlen. Ein Disallow sagt dem Crawler: Diese URL nicht abholen. Es ist eine Tür vor dem Server, kein Befehl an den Index.

noindex → steuert das Indexieren. Ein noindex (als Meta-Tag oder X-Robots-Header) sagt: Diese Seite darf gecrawlt werden, aber nicht in den Index. Es wirkt eine Phase später als robots.txt.

rel=canonical → steuert das Konsolidieren. Ein Canonical sagt: Diese Seite ist eine Variante, die eigentliche Vorzugs-URL ist jene dort. Es entfernt nichts aus dem Index, es bündelt nur Duplikate.

Wer das verinnerlicht hat, macht die meisten Fehler gar nicht erst. Die Frage ist nie „wie verstecke ich eine Seite”, sondern „in welcher Phase will ich eingreifen”.

robots.txt steuert Crawlen — nicht Indexieren

Der wichtigste und am häufigsten missverstandene Punkt: robots.txt ist kein Mechanismus, um eine Seite aus Google herauszuhalten. Google formuliert es direkt: robots.txt „is not a mechanism for keeping a web page out of Google” (Quelle: Google Search Central, abgerufen 2026-06-06).

Der Grund ist mechanisch. Eine per Disallow gesperrte URL wird nicht gecrawlt — aber sie kann trotzdem im Index landen, wenn andere Seiten auf sie verlinken. Das Ergebnis ist der charakteristische Such-Eintrag ohne Beschreibung: Google zeigt die URL (und eventuell den Ankertext der Links), aber keinen Snippet-Text, weil es den Inhalt nie gesehen hat (Quelle: Google Search Central, abgerufen 2026-06-06).

robots.txt ist also ein Crawl-Hebel, nützlich gegen Crawl-Budget-Verschwendung auf unwichtigen URL-Massen — aber das falsche Werkzeug, wenn das Ziel „nicht im Index” lautet.

noindex steuert Indexieren — muss aber crawlbar sein

Wenn eine Seite zuverlässig nicht im Index erscheinen soll, ist noindex das richtige Signal. Zwei Wege:

  • Meta-Tag im <head>: <meta name="robots" content="noindex"> — für HTML-Seiten.
  • X-Robots-Tag als HTTP-Header: X-Robots-Tag: noindex — auch für Nicht-HTML wie PDFs oder Bilder (siehe X-Robots-Tag).

Entscheidend ist die Bedingung: Damit noindex wirkt, darf die Seite nicht per robots.txt gesperrt sein und muss für den Crawler erreichbar sein. Google ist hier unmissverständlich: Ist die Seite durch robots.txt blockiert oder anderweitig unzugänglich, „the crawler will never see the noindex rule, and the page can still appear in search results” (Quelle: Google Search Central, abgerufen 2026-06-06).

Das ist der Kern des ganzen Themas — und der nächste Abschnitt zeigt, warum es so oft schiefgeht.

Der klassische Fehler: Disallow plus noindex

Die Logik scheint verlockend: „Ich will die Seite sicher draußen halten — also sperre ich sie per robots.txt und setze noindex.” Genau das funktioniert nicht.

Wenn robots.txt das Crawlen verbietet, holt Google die Seite nie ab. Damit liest Google auch den noindex-Tag im HTML nie — er steht ja in der Seite, die nicht abgerufen wird. Das noindex ist für Google unsichtbar. Folge: Die Seite kann weiter im Index auftauchen (etwa über eingehende Links), und das einzige Signal, das sie zuverlässig entfernen würde, kommt nie zur Wirkung.

Die richtige Reihenfolge bei einer Seite, die schon im Index steht und raus soll: zuerst noindex setzen, robots.txt-Disallow für diese URL entfernen (damit Google den Tag sieht), warten bis die Seite aus dem Index fällt — und erst danach optional wieder sperren, wenn man Crawl-Budget sparen will.

Entscheidungsbaum — was will ich erreichen?

Geh nicht vom Werkzeug aus, sondern vom Ziel:

  • „Diese URL soll gar nicht erst gecrawlt werden” (z. B. endlose Filter-/Sortier-Parameter, interne Suche). → robots.txt Disallow. Akzeptiere, dass die URL theoretisch ohne Snippet im Index erscheinen kann, wenn sie verlinkt ist.
  • „Diese Seite soll nicht im Index erscheinen / wieder raus” (z. B. Danke-Seiten, Test-Seiten, dünne Tag-Archive). → noindex, Seite crawlbar lassen. Kein Disallow.
  • „Es gibt mehrere URL-Varianten desselben Inhalts, eine soll die maßgebliche sein” (z. B. Tracking-Parameter, Druckansicht, Sortier-Varianten). → rel=canonical auf die Vorzugs-URL. Alle Varianten bleiben crawlbar, der Linkwert wird gebündelt.
  • „Vollständig privat, niemand außer Berechtigten” (z. B. Kundenbereiche). → Passwortschutz, nicht robots.txt — das ist die einzige harte Sperre.

Typische Konflikte und wie man sie auflöst

Disallow + noindex gleichzeitig. Der oben beschriebene Klassiker. Lösung: Disallow für diese URL entfernen, damit noindex gelesen werden kann.

Canonical auf eine per robots.txt gesperrte URL. Google kann die Ziel-URL nicht crawlen und das Canonical-Signal nicht verifizieren — die Konsolidierung wird ignoriert. Lösung: Canonical-Ziel immer crawlbar halten.

Canonical und noindex auf derselben Seite. Widersprüchlich: Canonical sagt „bündle mich mit jener Seite” (also: behandle uns als zusammengehörig im Index), noindex sagt „nimm mich raus”. Google bekommt gemischte Signale. Lösung: Entscheide dich — entweder konsolidieren (Canonical) oder entfernen (noindex), nicht beides.

FAQ

Hält robots.txt eine Seite aus dem Google-Index?

Nein. robots.txt steuert nur das Crawlen. Eine per Disallow gesperrte URL kann trotzdem indexiert werden, wenn sie verlinkt ist — sie erscheint dann ohne Beschreibung in den Ergebnissen. Um eine Seite zuverlässig aus dem Index zu halten, brauchst du noindex (und die Seite muss crawlbar sein) oder Passwortschutz.

Warum wirkt mein noindex nicht?

Mit hoher Wahrscheinlichkeit, weil die Seite gleichzeitig per robots.txt gesperrt ist. Dann kann Google die Seite nicht abrufen, liest den noindex-Tag nie und entfernt die Seite folglich nicht. Lösung: Disallow für diese URL aufheben, sodass Google den noindex sieht — danach fällt die Seite aus dem Index.

Was ist der Unterschied zwischen noindex und rel=canonical?

noindex entfernt eine Seite aus dem Index. rel=canonical entfernt nichts, es bündelt mehrere URL-Varianten desselben Inhalts auf eine Vorzugs-URL und konsolidiert deren Signale. noindex nutzt du gegen Seiten, die gar nicht erscheinen sollen; Canonical gegen Duplikate, von denen eine Variante erscheinen soll.

Kann ich Canonical und noindex zusammen setzen?

Besser nicht — die Signale widersprechen sich. Canonical behandelt die Seite als zugehörig zu einem Cluster, noindex will sie entfernen. Google erhält gemischte Anweisungen und entscheidet selbst, was nicht zuverlässig ist. Entscheide pro Seite: konsolidieren oder entfernen.

In welcher Reihenfolge schalte ich Signale, wenn eine indexierte Seite raus soll?

Zuerst noindex setzen und sicherstellen, dass die Seite nicht per robots.txt blockiert ist. Dann warten, bis Google die Seite neu crawlt, den noindex liest und sie aus dem Index entfernt. Erst danach kannst du sie optional per robots.txt sperren, um Crawl-Budget zu sparen — niemals vorher.

Themenuebersicht

Technisches SEOCrawling & Indexierung