Redirect-/Canonical-/Indexierbarkeitsprüfung
Stellt Statuskette, finale URL, Canonical, Robots-Regeln, Hreflang und Sitemap-Indizien einer öffentlichen URL in einem Bericht zusammen.
Web / SEORedirects, Canonicals und Indexierbarkeit als ein System
Crawler bewerten Redirects, Canonicals und Robots-Anweisungen nicht einzeln. Sie bauen aus jeder Antwort, jedem Link und jeder wiederholten Beobachtung ein Gesamtbild — und wenn deine Signale einander widersprechen, ist die Wunsch-URL nur eine Meinung unter mehreren.
Eine URL, viele voneinander unabhängige Signale
Indexierbarkeit steckt nicht in einem einzelnen Tag. Eine URL hat einen HTTP-Status, einen Response-Body, Header-Anweisungen, eine Robots-Meta-Angabe, ein Canonical-Ziel, interne Links, einen Platz in der Sitemap und möglicherweise Sprachreferenzen. Am Ziel beginnt dasselbe Spiel von vorn. Suchmaschinen setzen diese Indizien über wiederholte Crawls zusammen und beantworten damit zwei verschiedene Fragen: Darf das Dokument in den Index, und welche URL soll es dort vertreten? Die zweite Entscheidung heißt Kanonisierung. Wer beide Fragen vermischt, sucht später am falschen Ende.
Denk das Gebilde als gerichteten Graphen. Redirects sind starke Kanten: Sie bewegen Crawler und Nutzer. Canonicals sind Hinweise auf einen Repräsentanten, ohne jemanden umzuleiten. noindex verbietet die Anzeige einer abgerufenen Ressource, benennt aber keinen Ersatz. Hreflang verbindet regionale oder sprachliche Varianten, überschreibt deren Canonical-Entscheidung jedoch nicht. Sitemaps und interne Links verstärken die URLs, die du selbst als maßgeblich betreibst. Die betriebliche Forderung ist unspektakulär und streng: Jede Schicht muss dieselbe Geschichte erzählen. Der Redirect-/Canonical-/Indexierbarkeitsprüfung hilft, weil er die tatsächlich ausgelieferten Indizien einer öffentlichen URL nebeneinanderstellt.
301 und 302 sind betriebliche Versprechen
Ein 301 erklärt den Umzug für dauerhaft: Clients sollen künftig das Ziel verwenden, Caches dürfen die Zuordnung halten, Suchmaschinen sollen Signale dorthin konsolidieren. Ein 302 sagt dagegen, dass die Quell-URL die dauerhafte Identität bleibt und nur vorübergehend woandershin führt. Suchmaschinen können nach langer Zeit trotz falschem Status Dauerhaftigkeit vermuten. Darauf zu bauen ist trotzdem schlampig. Dauerhafte Domainwechsel, Host- und Scheme-Normalisierung, stabile Slash-Regeln sowie ausgemusterte Pfade mit echtem Nachfolger gehören auf einen permanenten Redirect. Wartungsfenster und kurzlebige Ausweichziele gehören auf einen temporären.
Bei Nicht-GET-Requests kommt die Methodensemantik dazu: 301 und 302 wurden historisch oft in GET umgeschrieben; 307 und 308 erhalten Methode und Body, temporär beziehungsweise permanent. Für APIs ist das entscheidend. Bei normalen Dokumenten richtet den größeren Schaden meist die gewachsene Kette an: http nach https, Apex nach www, Groß- nach Kleinschreibung und schließlich ohne Slash zum Slash. Ein Hop ist Alltag. Vier Hops kosten Latenz und Crawl-Arbeit und geben jeder späteren Migration eine weitere Sollbruchstelle. Jede bekannte Altform sollte direkt auf die endgültige kanonische URL zeigen.
Das Canonical ist ein Indiz, keine Weisung
<link rel="canonical" href="…" > ist für doppelte oder weitgehend gleiche Dokumente gedacht, die erreichbar bleiben müssen. Es schlägt eine URL für die Konsolidierung vor; es erzwingt sie nicht. Ein selbstreferenzierendes Canonical auf der finalen 200-Seite ist ein sauberer Standard, weil es die beabsichtigte Identität explizit macht. Zeigt es dagegen auf einen Redirect, einen 404, eine noindex-Seite, eine inhaltlich andere Sprache oder eine URL, die intern nirgends verlinkt wird, steht deine eigene Website gegen diesen Vorschlag.
Canonical-Ketten und -Schleifen sind vermeidbare Konfigurationsschulden. Wenn A auf B kanonisiert und B auf C, muss A direkt C nennen. Wenn A nach B umleitet und B per Canonical zurück auf A zeigt, hast du einen Widerspruch gebaut, den kein Crawler wörtlich erfüllen kann. Domainübergreifende Canonicals sind für syndizierte Kopien legitim, aber kein Ersatz für Redirects bei einem Site-Umzug: Nutzer, Referrer, Caches und andere Clients bleiben sonst auf dem alten Host. Prüfe außerdem das ausgelieferte HTML und nicht nur deine Framework-Komponente. Per JavaScript nachgeschobene Tags kommen spät, crawlerabhängig und für reine Response-Prüfer gar nicht.
Der restriktive Header, an den niemand mehr denkt
Das Robots-Meta-Tag gilt für das HTML-Dokument, in dem es steht. X-Robots-Tag transportiert vergleichbare Regeln im HTTP-Header und funktioniert deshalb auch für PDFs, Bilder und andere Nicht-HTML-Ressourcen. Ein optimistisches index,follow im Markup hebt ein noindex im Header nicht zuverlässig auf; restriktive Regeln werden kombiniert. Der Header stammt häufig aus CDN-Regeln, Reverse Proxies, Security-Plugins oder einer übernommenen Staging-Konfiguration. Genau deshalb bleibt er bei Template-Reviews unsichtbar. Untersuche die reale Antwort mit dem HTTP-Header-Analyzer — einschließlich der einzelnen Redirect-Hops.
Ein noindex muss gecrawlt werden, damit es wirken kann. Sperrst du dieselbe URL gleichzeitig in robots.txt, kann ein regelkonformer Crawler die Anweisung nicht abrufen. Die URL kann dann aufgrund externer Links und anderer Indizien im Index verbleiben, oft ohne Snippet. Lass den Abruf zu, solange noindex verarbeitet wird, und entferne die URL zusätzlich aus Sitemap und Navigation. Verwechsle auch nofollow nicht mit noindex: Es betrifft das Folgen der Links auf der Seite, nicht deren eigene Indexierbarkeit. Pauschale X-Robots-Regeln auf Dateiendungen oder ganze CDN-Routen verdienen besondere Skepsis — ihr Radius ist weit größer als der eines sichtbaren Templates.
Hreflang muss sich in denselben Konsens einfügen
Jedes Hreflang-Ziel sollte eine finale, indexierbare, kanonische 200-Seite sein. Das Set enthält die Seite selbst und gegenseitige Rückverweise; ein optionales x-default bezeichnet den sprachneutralen Selektor oder Fallback. Zeigt Hreflang auf Redirects, muss der Crawler erst einer Umleitung folgen, bevor er die Annotation nutzen kann. Verweist die englische Seite auf Deutsch, während die deutsche Seite per Canonical Englisch auswählt, behauptet dein Setup zugleich, es gebe zwei Sprachvarianten und nur eine dürfe beide vertreten. Die Suchmaschine kann Hreflang, Canonical oder beides verwerfen.
Kanonisiere deshalb innerhalb jeder Sprache, solange es sich wirklich um Übersetzungen und nicht um Duplikate handelt. Englisch wählt Englisch als Canonical und annotiert Deutsch; Deutsch wählt Deutsch und annotiert Englisch. Halte die URL-Form in HTML, Sitemap, Redirects und internen Links exakt gleich — inklusive Scheme, Hostname, Escaping, Großschreibung und Slash. Defektes Hreflang deindexiert eine Seite nicht unmittelbar. Es verhindert aber, dass die richtige indexierte Seite beim richtigen Publikum landet. Von außen wird daraus schnell „Google indexiert Deutsch nicht“, obwohl in Wahrheit der Sprachcluster keine schlüssige Aussage abgibt.
Am Draht beginnen, Widersprüche an der Quelle beseitigen
Starte mit einer exakten URL, nicht mit einer vagen Aussage über die Domain. Protokolliere jeden Status und jeden Location-Wert bis zur finalen Antwort. Dort vergleichst du Canonical, Robots-Meta, X-Robots-Tag, Hreflang-Ziele, Sitemap-Eintrag und wichtige interne Links. Wiederhole das für Varianten, die normalisiert werden sollen: HTTP, alternativer Host, alter Pfad, Parameter und Slash-Form. Das richtige Ergebnis ist langweilig — höchstens ein beabsichtigter Hop, danach nennen alle verbleibenden Signale dieselbe URL.
Prüfe anschließend die Policy-Grenzen. Ein in robots.txt gesperrter Crawler kann weder Canonical noch noindex im Body bestätigen; der KI-Crawler-robots.txt-Prüfer zeigt für einen konkreten Pfad die gewinnende Gruppe, Direktive und Quellzeile. Suche dabei getrennt nach Such-, Trainings- und nutzerangestoßenen Bots — das sind verschiedene Entscheidungen. Und dann repariere die verursachende Schicht: entferne den alten Proxy-Header, korrigiere Redirect-Map und Canonical-Generator, erzeuge die Sitemap neu. Suchmaschinen gewichten Signale, weil das Web widersprüchlich ist. Deine Aufgabe ist nicht, deren Formel zu erraten, sondern den Streit zu beenden, den der eigene Stack produziert.