Die vier Werkzeuge lösen vier verschiedene Probleme. Wer sie verwechselt, erzeugt Effekte, die dem Ziel genau entgegenlaufen — am häufigsten den Klassiker: eine Seite per robots.txt sperren, damit sie nicht in den Index kommt, und sie damit erst recht dort belassen.
Was welches Werkzeug tut
- robots.txt: Steuert das Crawling. Sie sagt: Diese Bereiche bitte nicht abrufen. Sie sagt nicht: Diese Bereiche nicht indexieren.
- noindex: Steuert die Indexierung. Die Seite darf abgerufen werden, soll aber nicht in den Suchergebnissen erscheinen.
- Canonical: Steuert die Zusammenführung. Bei mehreren sehr ähnlichen Seiten benennt es die maßgebliche Fassung, auf die Signale konsolidiert werden.
- Sitemap: Ist ein Vorschlag. Sie zeigt, welche Seiten es gibt und wann sie sich geändert haben. Sie erzwingt keine Aufnahme.
Der häufigste Fehler: Eine Seite wird in der robots.txt gesperrt und trägt gleichzeitig ein noindex. Da die Seite nicht abgerufen werden darf, wird das noindex nie gelesen — die Seite kann trotzdem im Index landen, dann ohne Beschreibung. Wer etwas aus dem Index halten will, muss das Crawling erlauben.
Was nicht in den Index gehört
- Interne Suchergebnisseiten — sie erzeugen beliebig viele Varianten ohne eigenständigen Wert.
- Filter- und Sortierkombinationen, sofern sie nur bestehende Inhalte neu anordnen.
- Dankeseiten und Bestätigungsseiten nach Formularen.
- Druck- und Exportansichten.
- Login-, Konto- und Warenkorbbereiche.
- Reine Paginierungsseiten ohne eigenen Text.
Nicht auf diese Liste gehören Seiten, die einfach schwach sind. Die Antwort darauf ist bessere Inhalte oder Zusammenlegung, nicht Ausschluss.
Canonical richtig setzen
Jede Seite sollte ein selbstreferenzierendes Canonical tragen — also auf sich selbst zeigen, in der bevorzugten Schreibweise: mit oder ohne abschließenden Schrägstrich, mit oder ohne www, immer über verschlüsselte Verbindung. Damit werden Varianten, die durch angehängte Parameter entstehen, automatisch zusammengeführt.
Zwei Regeln, die häufig verletzt werden: Ein Canonical ist ein Hinweis, keine Anweisung — bei stark abweichenden Inhalten wird er ignoriert. Und ein Canonical darf niemals auf eine Seite zeigen, die selbst weiterleitet oder ein noindex trägt; solche Ketten führen zu unvorhersehbaren Ergebnissen.
Die Sitemap sauber halten
Eine Sitemap ist nur so nützlich wie ihre Genauigkeit. Sie sollte ausschließlich Seiten enthalten, die tatsächlich indexiert werden sollen: keine Weiterleitungen, keine Fehlerseiten, keine noindex-Seiten, keine Seiten, deren Canonical woanders hinzeigt. Jeder dieser Widersprüche kostet Vertrauen in die gesamte Datei.
Das Änderungsdatum sollte den tatsächlichen inhaltlichen Stand abbilden. Wird es bei jedem Systemlauf pauschal auf heute gesetzt, verliert es seinen Informationswert vollständig. Verweisen sollte die Sitemap außerdem aus der robots.txt heraus — das ist der zuverlässigste Weg, sie auffindbar zu machen.
Crawl-Budget realistisch einschätzen
Für kleine und mittlere Websites ist Crawl-Budget selten das Problem. Relevant wird es bei sehr großen Seiten oder wenn Filterkombinationen praktisch unendlich viele Adressen erzeugen. Dann ist die Sperre per robots.txt tatsächlich das richtige Mittel — nicht um die Indexierung zu verhindern, sondern um Abrufe auf die Bereiche zu lenken, die zählen.
In der Praxis wirkt die interne Verlinkung stärker als jede Konfigurationsdatei: Seiten, die von wichtigen Stellen aus verlinkt sind, werden häufiger abgerufen. Deshalb gehört die Indexsteuerung immer zusammen mit der internen Verlinkung gedacht, nicht als isolierte technische Einstellung.
Nach der Umstellung kontrollieren
Änderungen an der Indexsteuerung wirken nicht sofort und nicht immer wie erwartet. Nach jeder Umstellung gehören deshalb drei Kontrollen: Stimmt die Zahl der indexierten Seiten grob mit der Zahl der Seiten überein, die indexiert sein sollen? Tauchen Seiten auf, die ausgeschlossen sein sollten? Und melden die Berichte Seiten als ausgeschlossen, die eigentlich hineingehören?
Besonders aufmerksam sollte man bei der Meldung sein, eine Seite sei zwar gefunden, aber nicht indexiert worden. Sie deutet meist nicht auf ein technisches Problem hin, sondern darauf, dass der Inhalt als zu dünn oder zu ähnlich zu anderen Seiten bewertet wurde — ein Hinweis auf die Inhaltsebene, nicht auf die Konfiguration.
Der häufigste Unfall beim Relaunch
Auf Entwicklungs- und Testumgebungen steht üblicherweise eine vollständige Sperre. Geht die Seite live und wird diese Sperre nicht entfernt, verschwindet die gesamte Website innerhalb weniger Tage aus dem Index. Der umgekehrte Fall ist ebenso verbreitet: Die Testumgebung ist öffentlich erreichbar und wird indexiert, was zu doppelten Inhalten unter zwei Adressen führt. Beide Fehler kosten Rankings und beide sind mit einer einzigen Prüfung am Tag des Umzugs vermeidbar.