Redirect-Chains überwachen: Weiterleitungen sauber halten

Was eine Redirect-Chain ist und wie sie entsteht

Eine Redirect-Chain ist eine Folge von mehr als einer Weiterleitung zwischen der ursprünglich angefragten URL und der finalen Zielseite. Statt direkt von /alt-url auf /ziel zu springen, durchläuft der Browser — und ebenso der Crawler — mehrere Zwischenstationen: /alt-url -> /zwischen -> /temp -> /ziel. Jede dieser Stationen antwortet mit einem HTTP-Statuscode der 3xx-Familie und einem Location-Header, der auf die nächste Adresse zeigt. Erst die letzte URL liefert einen 200 OK mit dem eigentlichen Inhalt.

Solche Ketten entstehen selten mit Absicht. Typische Auslöser sind aufeinanderfolgende Relaunches, bei denen alte Weiterleitungen nicht aufgelöst werden, der Wechsel von HTTP auf HTTPS in Kombination mit einer www-/non-www-Normalisierung, ein angehängter Trailing-Slash-Redirect oder Plugins und Server-Regeln, die unabhängig voneinander Weiterleitungen hinzufügen. Ein einzelner harmloser Umzug von 1 auf 2 kann so unbemerkt zu drei oder vier Hops anwachsen — jeder für sich korrekt, in Summe aber ein Performance- und SEO-Problem.

Der Grund, warum das relevant ist: Jeder Hop ist eine vollständige HTTP-Anfrage-Antwort-Runde. Laut Google PageSpeed Insights fügt jede Weiterleitung mindestens einen Roundtrip hinzu und im schlechtesten Fall zusätzliche Runden für DNS-Lookup, TCP-Handshake und TLS-Aushandlung (Google PageSpeed Insights). Was als kosmetisches Detail erscheint, summiert sich auf realer Mobilverbindung schnell zu spürbarer Verzögerung — und genau hier beginnt der Schaden.

301 gegen 302: permanent oder temporär richtig wählen

Der häufigste Fehler bei Weiterleitungen ist die falsche Statuswahl. Ein 301 signalisiert eine dauerhafte Verschiebung: Suchmaschinen verstehen, dass die alte URL endgültig durch die neue ersetzt wurde, und übertragen die Ranking-Signale entsprechend. Ein 302 (bzw. das HTTP/1.1-korrekte 307) signalisiert dagegen einen vorübergehenden Zustand — Google geht davon aus, dass die Original-URL zurückkehrt, und crawlt deshalb weiterhin beide Adressen. Für dauerhafte Umzüge ist das die falsche Wahl.

Wichtig für die Einordnung: Google hat bestätigt, dass 30x-Weiterleitungen heute keinen PageRank mehr verlieren — 301 und 302 werden hinsichtlich der Signalübertragung weitgehend gleich behandelt (Google/Gary Illyes 2016, via Search Engine Land). Das bedeutet aber nicht, dass die Statuswahl egal ist: Das Indexierungs- und Crawl-Verhalten unterscheidet sich weiterhin deutlich. Ein 302 auf einem dauerhaften Umzug hält die alte URL im Index und verschwendet Crawl-Ressourcen. In der Praxis sind 4,71 % aller URLs in Googles organischen Ergebnissen 302-Weiterleitungen (Web Almanac 2024) — ein Hinweis darauf, wie verbreitet das Missverständnis ist.

Latenz: Was jeder zusätzliche Hop wirklich kostet

Weiterleitungen sind nicht gratis. Jeder Hop blockiert das Rendern der Seite, bis die nächste Adresse aufgelöst ist. Google PageSpeed Insights beschreibt es präzise: Jede Weiterleitung fügt einen HTTP-Roundtrip hinzu, und wenn ein neuer Host involviert ist, kommen DNS-Lookup, TCP-Handshake und TLS-Aushandlung obendrauf (Google PageSpeed Insights). Auf einer schnellen Desktop-Verbindung fällt ein einzelner Hop kaum auf — auf Mobilfunk mit hoher Latenz wird jeder Hop dagegen schnell zur spürbaren Wartezeit.

Diese Verzögerung trifft direkt die Core Web Vitals und damit ein bestätigtes Ranking-Kriterium. Schon eine einzige Landing-Page-Weiterleitung verzögert den ersten sichtbaren Inhalt; eine Kette aus drei oder vier Hops kann das Time-to-First-Byte vervielfachen, bevor überhaupt das erste Byte der eigentlichen Seite geladen wird. Google empfiehlt deshalb ausdrücklich, Weiterleitungen zu minimieren und idealerweise ganz zu vermeiden — besonders für das HTML-Dokument selbst (Google PageSpeed Insights).

Besonders aufschlussreich ist das Zusammenspiel mehrerer Faktoren. Zeigt eine Weiterleitung auf einen anderen Host — etwa von der nackten Domain auf eine www-Variante mit eigenem Zertifikat — muss der Browser für diesen Hop eine vollständig neue Verbindung aufbauen: DNS auflösen, TCP-Handshake, TLS-Aushandlung. Genau das beschreibt Google als den teuersten Fall, in dem ein einzelner Redirect mehrere zusätzliche Roundtrips auslöst (Google PageSpeed Insights). Auf einer langsamen Mobilverbindung mit hoher Round-Trip-Time summieren sich diese versteckten Kosten zu Wartezeiten, die Nutzer als träge wahrnehmen — noch bevor ein einziges Pixel der Zielseite gerendert wurde.

SEO-Folgen: Crawl-Budget, Hop-Limit und Signalverlust

Suchmaschinen folgen Weiterleitungsketten nicht unbegrenzt. Googles John Mueller empfiehlt, für häufig gecrawlte URLs unter 5 Hops zu bleiben — Google folgt pro Crawl-Versuch nur bis zu fünf Weiterleitungen (Google / John Mueller, via Search Engine Journal). Überschreitet eine Kette dieses Limit, erreicht Googlebot die Zielseite in diesem Durchlauf nicht; sie wird in dem Versuch weder vollständig gecrawlt noch indexiert. Aus diesem Grund gilt die Faustregel: idealerweise ein einziger Hop, höchstens jedoch wenige.

Auch unterhalb des harten Limits kosten Ketten. Jeder Hop ist eine zusätzliche Anfrage, die Googlebot stellen muss — eine einzelne Weiterleitung verdoppelt die Requests bis zum Inhalt, eine Kette aus drei Hops vervierfacht sie (urllo). Bei großen Seiten mit vielen Weiterleitungen frisst das messbar Crawl-Budget, das dann für echte Inhalte fehlt. Wie sich Crawl-Budget und technische Sauberkeit insgesamt steuern lassen, beschreibt der Beitrag zu technischem SEO-Monitoring automatisieren.

In der Praxis verschärft sich der Crawl-Budget-Effekt mit der Größe der Website. Ein Online-Shop mit zehntausenden Produkt-URLs, von denen viele über historisch gewachsene Weiterleitungen erreichbar sind, kann einen erheblichen Teil seines Crawl-Budgets in 3xx-Antworten verbrennen, statt es für frische Inhalte und wichtige Kategorieseiten einzusetzen. Jede unnötige Weiterleitung ist eine Anfrage, die Googlebot stellt, ohne dafür indexierbaren Inhalt zu erhalten — und das Budget pro Domain ist endlich.

Beim Thema Signalübertragung ist eine realistische Einordnung wichtig. Google gibt an, dass 30x-Redirects keinen PageRank mehr verlieren (Google/Gary Illyes 2016, via Search Engine Land). John Mueller ergänzte jedoch, dass Redirect-Ketten in der Praxis mehr Risiko bergen als einzelne Hops, dass die Signal-Anerkennung nicht sofort erfolgt und dass die thematische Nähe zwischen Quelle und Ziel beeinflusst, wie viel historisches Signal tatsächlich übertragen wird (Google, via Search Engine Journal). Eine lange Kette mit thematisch driftenden Zwischenstationen ist damit stets riskanter als eine direkte 301.

Redirect-Loops: Wenn die Kette sich schließt

Der gefährlichste Spezialfall einer Redirect-Chain ist der Redirect-Loop: A leitet auf B, B leitet zurück auf A — oder eine längere Kette schließt sich am Ende wieder zum Anfang. Der Browser bricht nach einigen Durchläufen mit ERR_TOO_MANY_REDIRECTS ab, die Seite ist für Besucher schlicht nicht erreichbar. Für Suchmaschinen bedeutet das einen toten Pfad — die Inhalte können weder gecrawlt noch indexiert werden.

Loops entstehen typischerweise durch widersprüchliche Regeln: Eine Server-Regel erzwingt HTTPS, eine andere erzwingt www, eine dritte normalisiert den Trailing-Slash — und in einer unglücklichen Kombination zeigen zwei davon gegeneinander. Auch fehlerhafte CMS-Plugins, falsch gesetzte Canonical-Weiterleitungen oder eine versehentlich auf sich selbst zeigende Regel sind häufige Auslöser. Das Tückische: Ein Loop kann nach einem unscheinbaren Deployment plötzlich auftreten, ohne dass jemand die Weiterleitungen bewusst angefasst hat.

GET /alt-url            -> 301  Location: /zwischen
GET /zwischen           -> 302  Location: /temp
GET /temp               -> 302  Location: /ziel
GET /ziel               -> 200  OK   (4. Hop, knapp unter dem 5-Hop-Limit)

; Redirect-Loop (von Browser und Crawler abgebrochen):
GET /a                  -> 301  Location: /b
GET /b                  -> 301  Location: /a   ; ERR_TOO_MANY_REDIRECTS

Eine Sonderform sind Loops, die nur unter bestimmten Bedingungen auftreten — etwa nur für eingeloggte Nutzer, nur auf Mobilgeräten oder nur bei bestimmten Sprach- und Länderparametern in der URL. Solche bedingten Schleifen entgehen einer schnellen manuellen Sichtprüfung besonders leicht, weil die Startseite im Browser des Entwicklers völlig normal lädt. Erst eine Prüfung, die verschiedene Zugriffspfade systematisch durchgeht, deckt sie zuverlässig auf.

Weil Loops und überlange Ketten meist unbemerkt nach einem Deployment auftreten, sind sie ein Paradebeispiel für den Wert kontinuierlicher Überwachung. Eine Weiterleitung, die heute sauber ist, kann nach dem nächsten Plugin-Update oder Server-Regel-Wechsel kaputt sein — und ohne Monitoring fällt es erst auf, wenn Besucher oder Rankings einbrechen.

Canonical-Drift: Wenn Weiterleitung und Canonical auseinanderlaufen

Weiterleitungen und Canonical-Tags müssen zusammenpassen. Ein rel=canonical teilt Suchmaschinen mit, welche URL die maßgebliche Version eines Inhalts ist. Problematisch wird es, wenn eine Seite per 301 auf eine URL weiterleitet, deren Canonical-Tag jedoch wieder auf eine dritte Adresse zeigt — oder wenn die Zielseite einer Weiterleitung ein Canonical trägt, das auf die bereits weitergeleitete Quelle zurückverweist. Solche widersprüchlichen Signale nennt man Canonical-Drift.

Das Thema ist relevant, weil Canonical-Tags weit verbreitet sind: 2024 lag die Nutzung bei rund 65 % aller Seiten — erstmals gleichmäßig auf Desktop und Mobil (Web Almanac 2024). Gleichzeitig hatte eine von 50 Mobilseiten ihr Canonical-Tag während des Renderings verändert (Web Almanac 2024) — ein klassisches Drift-Risiko, das ohne Rendering-bewusste Prüfung unsichtbar bleibt. Wer Weiterleitungen ändert, sollte parallel prüfen, ob die Canonical-Angaben noch konsistent auf das endgültige Ziel zeigen.

Canonical-Konsistenz greift in dieselbe technische Schicht wie weitere SEO-Signale ein. Wie Sie Strukturdaten und Canonical zusammen sauber halten, behandelt der Beitrag zum Structured-Data-Monitoring; wie sich Index- und Crawl-Vorgaben über die XML-Sitemap steuern lassen, beschreibt der Beitrag zum Sitemap-Monitoring für SEO.

Redirect-Chains erkennen, bereinigen und konsistent halten

Bevor es an die Bereinigung geht, lohnt sich eine Bestandsaufnahme: Welche Weiterleitungen existieren überhaupt, welche stammen aus alten Relaunches, und welche werden von Plugins oder Server-Regeln automatisch erzeugt? Oft zeigt schon diese Inventur, dass mehrere Regeln dieselbe Aufgabe doppelt erledigen — der häufigste Nährboden für ungewollte Ketten. Erst auf dieser Grundlage lässt sich entscheiden, welche Hops zusammengefasst und welche Regeln entfernt werden können.

Die folgende Checkliste fasst die wichtigsten Schritte zusammen — vom Aufspüren bestehender Ketten über das Zusammenfalten auf einen Hop bis zur dauerhaften Überwachung. Sie eignet sich als Ausgangspunkt für ein Audit Ihrer Weiterleitungen.

• Ketten aufspüren — jede URL bis zur finalen Zielseite verfolgen und die Anzahl der Hops zählen; alles über einem Hop ist Optimierungspotenzial
• Auf einen Hop zusammenfalten — Zwischenstationen entfernen und die Quell-URL direkt auf die finale Zieladresse leiten
• Statuscodes prüfen — dauerhafte Umzüge auf 301 umstellen; temporäre 302 nur dort belassen, wo sie wirklich temporär sind
• Loops ausschließen — widersprüchliche Server-Regeln (HTTPS, www, Trailing-Slash) entwirren, damit sich keine Kette schließt
• Unter dem 5-Hop-Limit bleiben — Google folgt pro Crawl nur bis zu 5 Hops (Google / John Mueller, via Search Engine Journal)
• Canonical abgleichen — prüfen, ob Redirect-Ziel und rel=canonical auf dieselbe endgültige URL zeigen
• Interne Links anpassen — interne Verweise direkt auf die finale URL setzen, statt durch die Weiterleitung zu schicken
• Kontinuierlich überwachen — Weiterleitungen ändern sich bei Deployments; automatisiertes Monitoring erkennt Drift sofort

Der letzte Punkt ist der entscheidende. Eine Weiterleitung einmal sauber aufzusetzen ist einfach — sie über Relaunches, Plugin-Updates und Server-Migrationen hinweg konsistent zu halten ist die eigentliche Herausforderung. Genau dort setzt automatisiertes SEO-Monitoring an: Es verfolgt für Ihre wichtigen URLs die komplette Weiterleitungskette, zählt die Hops, unterscheidet 301 von 302, erkennt Loops und prüft, ob das Ziel mit dem Canonical zusammenpasst.

Weicht etwas vom erwarteten Zustand ab — wächst die Kette nach einem Deployment auf vier Hops, schleicht sich ein temporäres 302 ein oder schließt sich plötzlich ein Loop — erhalten Sie eine Benachrichtigung per E-Mail, Slack, Discord oder Telegram, bevor Besucher und Rankings darunter leiden. Redirect-Hygiene reiht sich damit in dieselbe Kette technischer Prüfungen ein wie die Erkennung von Mixed Content, die Überwachung des HTTP/- und QUIC-Protokolls3 oder die Kontrolle von Consent- und Tag-Drift.

Häufig gestellte Fragen zu Redirect-Chains und Weiterleitungen