Noindex vs. Canonical vs. robots.txt: Ein klarer Entscheidungsrahmen

1. Die drei Werkzeuge im Überblick

Der Canonical-Tag ist eine Empfehlung an Suchmaschinen, welche von mehreren ähnlichen oder identischen URLs als die maßgebliche Version behandelt werden soll, während alle Varianten weiterhin gecrawlt und indexiert werden können. Das Noindex-Attribut dagegen ist eine explizite Anweisung, eine bestimmte URL nicht in den Suchindex aufzunehmen, wobei die Seite für Suchmaschinen weiterhin crawlbar bleiben muss, damit die Anweisung überhaupt gelesen werden kann.

Die robots.txt-Datei schließlich steuert nicht die Indexierung, sondern das Crawling selbst, indem sie bestimmten oder allen Suchmaschinen-Bots untersagt, definierte URL-Muster überhaupt erst aufzurufen. Diese drei Ebenen, Empfehlung zur Kanonisierung, Indexierungsverbot und Crawling-Verbot, wirken an unterschiedlichen Punkten im Verarbeitungsprozess einer Suchmaschine, weshalb sie sich nicht beliebig austauschen oder kombinieren lassen.

<!-- Canonical: Empfehlung, welche Version maßgeblich ist -->
<link rel="canonical" href="https://shop.example.com/schuhe/damenschuhe" />

<!-- Noindex: explizites Indexierungsverbot, Seite bleibt crawlbar -->
<meta name="robots" content="noindex, follow" />

<!-- robots.txt: verbietet das Crawling bestimmter Muster -->
<!-- Disallow: /suche
     Disallow: /warenkorb -->

2. Wann Canonical die richtige Wahl ist

Canonical-Tags sind das richtige Werkzeug, wenn mehrere URLs inhaltlich sehr ähnlichen oder identischen Content ausliefern und alle Varianten aus technischen oder funktionalen Gründen weiterhin erreichbar bleiben müssen. Ein typisches Beispiel ist ein Produkt, das über zwei verschiedene Kategoriepfade erreichbar ist, etwa einmal über 'Damenschuhe' und einmal über 'Sale', wobei beide URLs für die Nutzerführung sinnvoll sind, aber nur eine davon in der Suche ranken soll.

Auch bei URL-Parametern wie Sortierungen, Session-IDs oder leichten Filterkombinationen ist Canonical meist die richtige Wahl, weil diese Varianten funktional gebraucht werden, aber keinen eigenständigen Suchwert haben. Wichtig ist, dass der Canonical-Tag immer auf eine tatsächlich existierende, inhaltlich passende Zielseite verweist und nicht auf eine Seite mit grundlegend anderem Inhalt, da Google eine solche Fehlkonfiguration schlicht ignoriert.

3. Wann Noindex die richtige Wahl ist

Noindex eignet sich für Seiten, die technisch und funktional existieren müssen, aber keinerlei Wert in den Suchergebnissen haben, etwa der Warenkorb, die interne Suchergebnisseite, Login- und Registrierungsseiten oder automatisch generierte, sehr dünne Inhaltsseiten. Diese Seiten sollen für Nutzer und teilweise auch für Suchmaschinen erreichbar bleiben, etwa damit interne Links funktionieren, sollen aber nicht als eigenständiges Suchergebnis erscheinen.

Anders als beim Canonical-Tag gibt es bei Noindex keine alternative Zielseite, die stattdessen indexiert werden soll, sondern die betroffene URL wird schlicht aus dem Index entfernt oder gar nicht erst aufgenommen. Noindex ist deshalb die richtige Wahl, wenn eine Seite für sich genommen keinen eigenen Suchwert hat und es auch keine sinnvolle Alternative gibt, auf die man kanonisieren könnte.

4. Wann robots.txt die richtige Wahl ist

Die robots.txt ist das richtige Werkzeug, wenn es nicht um die Indexierung einzelner Seiten geht, sondern um das Schonen des Crawling-Budgets bei sehr großen Mengen an URLs, die Suchmaschinen erst gar nicht aufrufen sollen. Typische Beispiele sind Admin-Bereiche, interne technische Endpunkte, Session-behaftete URL-Varianten oder automatisch generierte Filterkombinationen in solcher Menge, dass ihr Crawling wertvolle Crawling-Kapazität von wichtigeren Seiten abzieht.

Der zentrale Unterschied zu Noindex besteht darin, dass eine per robots.txt gesperrte Seite von Google gar nicht erst besucht wird, wohingegen Noindex voraussetzt, dass die Seite besucht und die Anweisung gelesen werden kann. Deshalb eignet sich robots.txt vor allem für Bereiche, bei denen ohnehin kein Interesse an Indexierung besteht und deren Crawling schlicht unnötige Ressourcen verbraucht, während für Seiten mit tatsächlichem Indexierungsrisiko Noindex die präzisere Wahl bleibt.

5. Die häufigste Fehlkombination: robots.txt-Sperre plus Noindex

Der wohl häufigste Fehler in der Praxis ist, eine Seite gleichzeitig per robots.txt zu sperren und mit einem Noindex-Tag zu versehen, in der Annahme, das sei besonders gründlich. Tatsächlich bewirkt diese Kombination das Gegenteil des Gewünschten, denn wenn robots.txt das Crawling verbietet, kann Google die Seite gar nicht erst besuchen und somit auch das Noindex-Tag im HTML-Head nicht lesen.

In diesem Fall kann Google die URL trotzdem indexieren, wenn ausreichend externe oder interne Links auf sie verweisen, allerdings ohne Titel und Beschreibung, weil der Seiteninhalt nicht gecrawlt werden durfte, was zu einer besonders unschönen Darstellung in den Suchergebnissen führt. Die Regel lautet daher: Wenn eine Seite per Noindex aus dem Index entfernt werden soll, darf sie nicht gleichzeitig per robots.txt gesperrt sein, sondern muss crawlbar bleiben, bis Google das Noindex-Tag verarbeitet und die Seite tatsächlich aus dem Index entfernt hat.

6. Weitere häufige Fehlkombinationen

Eine weitere verbreitete Fehlkonfiguration ist ein Canonical-Tag auf einer Seite, die gleichzeitig ein Noindex-Tag trägt, wobei die Zielseite des Canonical-Tags dann meist ebenfalls übersehen wird, weil widersprüchliche Signale für Google schwer aufzulösen sind. Auch Canonical-Ketten, bei denen Seite A auf Seite B verweist, die wiederum auf Seite C kanonisiert, führen dazu, dass Google die Kette teilweise ignoriert und selbstständig entscheidet, welche Version die maßgebliche ist.

Ebenso problematisch ist ein Canonical-Tag, das auf eine per robots.txt gesperrte Seite verweist, weil Google die Zielseite dann nicht crawlen und somit auch die dortigen Signale nicht bestätigen kann. In all diesen Fällen gilt die gleiche Grundregel: Die Zielseite jeder Anweisung muss selbst uneingeschränkt crawlbar sein, damit die Anweisung wirken kann, unabhängig davon, ob es sich um Canonical oder Noindex handelt.

7. Die praktische Entscheidungsmatrix

Um im Alltag schnell die richtige Wahl zu treffen, hilft eine einfache Leitfrage: Soll die Seite für Nutzer erreichbar bleiben und lediglich nicht in der Suche erscheinen, ist Noindex die Wahl. Gibt es eine inhaltlich passende Alternative, auf die konsolidiert werden soll, ist Canonical die Wahl. Soll die Seite von Suchmaschinen gar nicht erst besucht werden, weil sie schlicht keinen Crawling-Wert hat, ist robots.txt die Wahl.

Die folgende Tabelle fasst die typischen Anwendungsfälle zusammen und zeigt, welches Werkzeug für welches Problem vorgesehen ist, wobei sich diese Fälle in der Praxis meist eindeutig einer der drei Kategorien zuordnen lassen. Bleiben in einem Einzelfall Zweifel, lohnt sich der Blick auf die Grundfrage, ob die Seite überhaupt gecrawlt werden soll, denn daraus ergibt sich die Wahl zwischen robots.txt auf der einen und Canonical oder Noindex auf der anderen Seite fast automatisch.

8. Praxisbeispiel: Anwendung im E-Commerce-Kontext

In einem typischen Magento-Shop kommen alle drei Werkzeuge gleichzeitig zum Einsatz, aber für unterschiedliche Bereiche: Die interne Suchergebnisseite erhält ein Noindex-Tag, weil sie für Nutzer erreichbar bleiben soll, aber keinen eigenen Suchwert hat. Gefilterte Kategorieseiten mit einzelnen, sinnvollen Filterparametern erhalten einen Canonical-Tag auf die ungefilterte Kategorieseite, während der Warenkorb und der Checkout-Bereich komplett per robots.txt gesperrt werden, weil an ihrem Crawling kein Interesse besteht.

Diese Kombination sorgt dafür, dass Google seine Crawling-Kapazität auf die wirklich relevanten Produkt- und Kategorieseiten konzentriert, während funktional notwendige, aber für die Suche irrelevante Bereiche entweder konsolidiert oder komplett ausgeschlossen werden. Wichtig ist dabei, die Konfiguration regelmäßig zu prüfen, weil neue Funktionen wie ein zusätzlicher Checkout-Schritt oder eine neue Filteroption schnell vergessen werden, wenn die ursprüngliche robots.txt- oder Canonical-Konfiguration nicht mitgepflegt wird.

9. Monitoring und Audit-Prozess zur Fehlererkennung

Da Fehlkonfigurationen bei diesen drei Werkzeugen selten sofort auffallen, lohnt sich ein regelmäßiger technischer Audit, der systematisch prüft, ob Noindex- und robots.txt-Regeln jemals gleichzeitig auf dieselbe URL zutreffen. Ein einfaches Skript, das die robots.txt parst und mit den Noindex-Tags einer Stichprobe wichtiger Seiten abgleicht, deckt diese Fehlkombination zuverlässig auf, bevor sie zu einem echten Sichtbarkeitsproblem wird.

Ergänzend liefert die Google Search Console unter dem Bericht zur Indexabdeckung wertvolle Hinweise, etwa wenn Seiten als 'durch robots.txt blockiert, aber indexiert' gemeldet werden, was ein direktes Indiz für genau diese Fehlkombination ist. Ein solcher Bericht sollte fester Bestandteil eines monatlichen SEO-Reviews sein, damit Fehlkonfigurationen nicht über Monate unentdeckt bleiben und unnötig Sichtbarkeit kosten.

10. Zusammenfassung

11. FAQ: Noindex vs. Canonical vs. robots.txt: Das Wichtigste auf einen Blick