Indexierbarkeit: ob deine Seite überhaupt in den Index darf

Eine Seite kann nur in den Suchergebnissen erscheinen, wenn sie im Index steht — und ob sie dort hineindarf, entscheidet nicht der Inhalt, sondern eine Handvoll technischer Angaben: Statuscode, Weiterleitungen, das Robots-Meta-Tag, der X-Robots-Tag im HTTP-Header, das Canonical-Tag und die robots.txt. Jede dieser Angaben wird an einer anderen Stelle gesetzt, oft von einem anderen Plugin oder einer anderen Person. Deshalb können sie sich widersprechen. Das Ergebnis ist der bekannte Befund: Die Seite ist online, sie sieht gut aus, sie funktioniert — und für Google existiert sie nicht.

Die Signale, die darüber entscheiden

Signal	Wo es steht	Was es sagt
Statuscode	Antwort des Servers	200 = hier ist die Seite, 301/308 = dauerhaft umgezogen, 404 = gibt es nicht
Weiterleitung	Server, selten im HTML	wohin die Adresse zeigt und ob das endgültig ist
Robots-Meta-Tag	<head> der Seite	noindex = nicht in die Suchergebnisse
X-Robots-Tag	HTTP-Header	dasselbe wie das Meta-Tag, auch für PDFs und Bilder
Canonical	<head> oder HTTP-Header	welche von mehreren Adressen die maßgebliche ist
robots.txt	Wurzel der Domain	was überhaupt abgerufen werden darf

Jedes Signal sieht für sich unauffällig aus. Interessant wird es, wenn zwei sich widersprechen — etwa ein index im Meta-Tag und ein noindex im Header. Für diesen Fall hat Google eine klare Regel: Widersprechen sich Robots-Anweisungen, gilt die strengere. Die Seite fliegt also raus.

robots.txt verhindert das Abrufen, nicht das Indexieren

Das ist der Unterschied, der die hartnäckigsten Fehler erzeugt. Google schreibt ausdrücklich, dass die robots.txt kein Mittel ist, um eine Seite aus Google herauszuhalten. Sie steuert, welche Adressen ein Crawler abrufen darf — vor allem, um den Server nicht zu überlasten.

Eine gesperrte Seite kann trotzdem im Index landen, wenn andere Websites auf sie verlinken. Sie erscheint dann mit Adresse und Linktext, aber ohne Beschreibung. In der Search Console steht sie als „Indexiert, obwohl durch robots.txt-Datei blockiert".

Schlimmer noch: Weil Google die gesperrte Seite nicht abruft, sieht Google auch das noindex darauf nicht. Google nennt das als Bedingung: Damit noindex wirkt, darf die Seite nicht durch die robots.txt gesperrt sein. Wer eine Seite loswerden will und sie deshalb sperrt, erreicht das Gegenteil.

Die Regel daraus:

• Soll eine Seite nicht in den Index: noindex setzen und den Abruf erlauben.
• Soll eine Seite gar nicht abgerufen werden, weil sie Serverlast erzeugt — etwa interne Suchergebnisse mit beliebigen Parametern: robots.txt.
• Nie beides gleichzeitig für dieselbe Seite.

Bei CSS-, JavaScript- und Bilddateien ist Google vorsichtig: Sperren ist nur dann unbedenklich, wenn die Seite ohne diese Dateien nicht wesentlich anders aussieht. Was Google zum Verstehen der Seite braucht, muss abrufbar bleiben.

noindex: der teuerste Einzelfehler

Der häufigste Befund in diesem Feld ist auch der ärgerlichste: Eine wichtige Seite steht versehentlich auf noindex. So passiert es:

• Nach einem Relaunch. Auf der Testumgebung war „Suchmaschinen davon abhalten, diese Website zu indexieren" aktiviert, und die Einstellung ist beim Umzug mitgekommen. Seit WordPress 5.3 setzt dieser Haken ein Meta-Tag noindex,nofollow auf jede Seite. Google nennt genau diesen Punkt in der Anleitung zum Website-Umzug: noindex und robots.txt-Sperren aus der Entwicklung entfernen.
• Durch ein Plugin, das für eine ganze Inhaltsart pauschal noindex setzt.
• Durch einen Header, den ein Hoster oder eine Serverregel setzt und den im HTML niemand sieht.

Wo noindex hingehört: interne Suchergebnisseiten, Login- und Kontobereiche, Warenkorb und Kasse, Dankeseiten nach dem Absenden eines Formulars, dünne Archiv- und Schlagwortseiten ohne eigenen Wert.

noindex allein genügt. Links auf der Seite zu folgen ist die Voreinstellung. Ein zusätzliches follow ändert nichts.

Dazu ein Grundsatz, der oft fehlt: Nicht jede Seite gehört in den Index. Google schreibt selbst, dass du nicht erwarten sollst, jede Adresse indexiert zu sehen. Ziel ist, dass die kanonische Fassung jeder wichtigen Seite im Index steht — nicht möglichst viele Seiten.

Canonical: welche Adresse gilt

Das Canonical-Tag sagt Google, welche Adresse die maßgebliche ist, wenn derselbe oder sehr ähnlicher Inhalt unter mehreren Adressen erreichbar ist. Doppelte Adressen entstehen schneller, als man denkt:

• durch Sortier- und Filterfunktionen und Kampagnenkennungen in der Adresse
• durch http:// und https://
• durch www. und ohne
• durch den Schrägstrich am Ende
• durch Testumgebungen, die versehentlich öffentlich erreichbar sind

Wichtig zu wissen: Das Canonical ist ein Hinweis, keine Anweisung. Google wählt die maßgebliche Adresse aus mehreren Signalen — Weiterleitungen, Canonical, Sitemap, HTTPS — und kann sich anders entscheiden, als du angegeben hast. Je mehr Signale in dieselbe Richtung zeigen, desto sicherer folgt Google dir.

Zwei Fehlerklassen

Das Ziel ist falsch. Das Canonical zeigt auf die falsche Seite. Klassisch bei mehrseitigen Inhalten: Seite 2 verweist auf Seite 1. Google rät ausdrücklich davon ab — jede Seite einer Folge bekommt ihr eigenes Canonical. Sonst verschwinden die Inhalte ab Seite 2 aus dem Index.

Die Form ist kaputt. Das Canonical ist relativ geschrieben, steht im Body statt im <head> oder ist doppelt vorhanden. Google akzeptiert es nur im <head> (oder im HTTP-Header). Stehen mehrere Canonicals mit verschiedenen Zielen auf einer Seite, ignoriert Google laut eigenem Blog alle. Ein formal kaputtes Canonical kann also auf die richtige Seite zeigen und trotzdem wirkungslos sein. Häufiger Auslöser: Theme und SEO-Plugin setzen beide eines.

Die Regeln

• Genau ein Canonical pro Seite.
• Im <head>.
• Absolut geschrieben, mit Protokoll und Domain.
• Auf sich selbst zeigend — außer die Seite ist tatsächlich eine Variante einer anderen.
• Das Ziel muss erreichbar und indexierbar sein: keine Fehlerseite, kein noindex.
• noindex ist kein Ersatz für ein Canonical. Google rät davon ab, doppelte Adressen per noindex oder robots.txt zu steuern, und ebenso davon, auf einer Seite über verschiedene Wege verschiedene Ziele anzugeben.

Weiterleitungen und Ketten

301 und 308 sind dauerhaft. Für Google ein starkes Signal, dass das Ziel die maßgebliche Adresse werden soll. Das ist der Standardfall für jede umgezogene Seite.

302, 303 und 307 sind vorübergehend. Google folgt ihnen, wertet sie aber nicht als Signal, dass das Ziel die maßgebliche Adresse ist. Sie sind nur für tatsächlich Vorübergehendes richtig.

Ketten entstehen fast von selbst: A leitet auf B, B auf C. Jedes Mal, wenn eine Adresse geändert wird, ohne die alte Regel aufzuräumen, wächst die Kette. Googlebot folgt bis zu 10 Sprüngen. Google empfiehlt trotzdem, direkt auf das Endziel zu leiten, und wo das nicht geht, die Kette kurz zu halten — idealerweise nicht mehr als 3, weniger als 5 Sprünge. Jeder Sprung kostet Besucher Ladezeit.

Die Lösung ist immer dieselbe: die Kette auf einen Sprung zusammenziehen. A zeigt direkt auf C. Schleifen — A auf B, B zurück auf A — machen die Seite für alle unerreichbar und erscheinen in der Search Console als Weiterleitungsfehler.

Und der Punkt, der bei einem Relaunch entscheidet: Interne Links sollen direkt auf die endgültige, kanonische Adresse zeigen, nicht auf eine, die weiterleitet. Google schreibt, dass einheitliches Verlinken auf die kanonische Adresse hilft, deine Absicht zu verstehen.

Weiterleitungen beim Relaunch

• Jede alte Adresse braucht ein Ziel, und zwar das thematisch nächstliegende.
• Nicht pauschal auf die Startseite leiten. Google warnt, dass viele alte Adressen auf ein einziges unpassendes Ziel als „Soft 404" gewertet werden können — also wie eine Fehlerseite.
• Weiterleitungen stehen lassen, so lange wie möglich, laut Google in der Regel mindestens ein Jahr.

Adressvarianten: Schrägstrich, www und https

/leistungen und /leistungen/ sind für Google zwei verschiedene Adressen. Nur direkt hinter dem Hostnamen ist der Schrägstrich bedeutungslos: https://example.com und https://example.com/ sind dasselbe. Überall sonst im Pfad ist er Teil der Adresse.

Dasselbe gilt für www. und ohne, http:// und https://. Bei gleichwertigen Fassungen bevorzugt Google von sich aus HTTPS — aber nur, solange keine anderen Signale widersprechen.

Die Lösung: Entscheide dich einmal für eine Variante, erzwinge sie serverseitig per 301 und zieh Canonicals, Sitemap und interne Links nach. Welche Variante du wählst, ist zweitrangig — wichtig ist, dass es nur eine gibt. Am einfachsten ist meist die, die dein System ohnehin erzeugt.

Sitemap und Canonical müssen dasselbe sagen

Die Sitemap ist ein schwaches, aber zusätzliches Signal für die maßgebliche Adresse. Deshalb gehören nur kanonische, indexierbare Adressen hinein: keine Weiterleitungen, keine Fehlerseiten, nichts mit noindex, nichts mit einem Canonical auf eine andere Seite. Eine Adresse mit noindex in der Sitemap ist ein direkter Widerspruch. Wie du die Sitemap selbst prüfst, steht im Artikel zu robots.txt und Sitemap.

Wie du das selbst prüfst

Das URL-Prüftool in der Search Console. Der direkteste Weg. Adresse oben eingeben, und du bekommst die Antwort: „URL ist auf Google" oder „URL ist nicht auf Google". Darunter stehen „Crawling erlaubt?", „Indexierung zulässig?" und zwei Canonical-Felder: „Vom Nutzer angegebene kanonische URL" und „Von Google ausgewählte kanonische URL". Weichen die beiden voneinander ab, ist Google deinem Hinweis nicht gefolgt. Nach einer Korrektur zeigt „Live-URL testen" den aktuellen Stand.

Der Bericht zur Seitenindexierung. Er listet für die ganze Website die Gründe, warum Adressen nicht indexiert sind, etwa „URL als ‚noindex' markiert", „Alternative Seite mit richtigem kanonischen Tag", „Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt", „Seite mit Weiterleitung", „Weiterleitungsfehler" oder „Gecrawlt – zurzeit nicht indexiert".

Der Quelltext-Blick. Strg+U, dann Strg+F. Such nach name="robots" und nach rel="canonical". Beide dürfen höchstens einmal vorkommen, und das Canonical gehört in den <head>.

Die HTTP-Header. Das ist der Fall, den niemand findet, der nur die Seite ansieht: Das Meta-Tag sagt index, der X-Robots-Tag im Header sagt noindex — und die strengere Anweisung gewinnt. Sichtbar in den Entwicklerwerkzeugen unter Netzwerk: Seite neu laden, erste Zeile anklicken, Antwort-Header lesen.

Weiterleitungsketten. Ebenfalls im Netzwerk-Reiter: Steht in der ersten Zeile 301 oder 302 und danach noch eine Weiterleitung, hast du eine Kette.

Der Varianten-Test. Ruf deine Startseite und eine Unterseite auf: mit www. und ohne, mit http:// und https://, mit Schrägstrich am Ende und ohne. Alle müssen auf derselben Adresse landen, in einem Sprung. Das dauert eine Minute.

Für den vollständigen Überblick braucht es ein Crawling-Werkzeug, das die ganze Website durchgeht und Indexierbarkeit, Canonicals, Weiterleitungen und Statuscodes je Adresse ausgibt. Bei 300 Seiten prüft niemand einzeln.

Was zu tun ist

1. Prüf die Startseite und die fünf wichtigsten Unterseiten mit dem URL-Prüftool. Ist dort etwas nicht indexiert, hat alles andere Vorrang.
2. Räum noindex auf. Es gehört auf wenige, klar benennbare Seiten — und nirgendwo sonst. Prüf dabei auch die Header.
3. Sorg für genau ein Canonical pro Seite, absolut, im <head>, auf eine indexierbare Adresse.
4. Führ die Adressvarianten auf eine zusammen, per 301.
5. Zieh Weiterleitungsketten zusammen und korrigier interne Links, die über eine Weiterleitung laufen.
6. Prüf die robots.txt darauf, ob dort etwas gesperrt ist, das Google zum Darstellen braucht — oder eine Seite, die eigentlich noindex bekommen sollte.
7. Nach jedem Relaunch als Allererstes: Ist die Testumgebungs-Einstellung mitgekommen? Das ist der teuerste Fehler in diesem Feld und der am leichtesten zu vermeidende.

Quellen

• Google Search Central, Einführung in robots.txt — kein Mittel gegen Indexierung, gesperrte Seiten ohne Beschreibung im Index, CSS und JavaScript: developers.google.com
• Google Search Central, Indexierung mit noindex blockieren — Meta-Tag und X-Robots-Tag, keine Sperre per robots.txt: developers.google.com
• Google Search Central, Robots-Meta-Tag und X-Robots-Tag — Voreinstellung, strengere Regel gilt bei Widerspruch: developers.google.com
• Google Search Central, Was ist Kanonisierung — Ursachen doppelter Adressen, Canonical als Hinweis: developers.google.com
• Google Search Central, Kanonische URL angeben — Signalstärke, absolute Adressen, nur im <head>, kein noindex, HTTPS, interne Links: developers.google.com
• Google Search Central Blog, 5 common mistakes with rel=canonical — mehrere Canonicals werden ignoriert, Ziel ohne noindex, Seite 2 nicht auf Seite 1: developers.google.com
• Google Search Central, Paginierung — jede Seite mit eigenem Canonical: developers.google.com
• Google Search Central, Weiterleitungen und die Google Suche — 301/308 dauerhaft, 302/303/307 vorübergehend: developers.google.com
• Google Search Central, HTTP-Statuscodes und Netzwerkfehler — bis zu 10 Weiterleitungssprünge: developers.google.com
• Google Search Central, Website-Umzug mit URL-Änderungen — Ketten kurz halten, mindestens ein Jahr, keine Massenweiterleitung auf die Startseite, noindex nach dem Umzug entfernen: developers.google.com
• Google Search Central Blog, To slash or not to slash — Schrägstrich am Ende, Ausnahme hinter dem Hostnamen: developers.google.com
• Google Search Console-Hilfe, Bericht zur Seitenindexierung — Gründe, nicht jede Adresse muss indexiert sein: support.google.com
• Google Search Console-Hilfe, URL-Prüftool — Crawling erlaubt, Indexierung zulässig, angegebene und ausgewählte kanonische URL: support.google.com
• WordPress Core, Changes to prevent search engines indexing sites — WordPress 5.3 setzt noindex,nofollow statt Disallow: /: make.wordpress.org