Redirect-Ketten und SEO: Wie viele Hops sind zu viele?

Eine Redirect-Kette sind zwei oder mehr Weiterleitungen hintereinander zwischen der URL, die jemand angefordert hat, und der Seite, die schließlich mit einem 200 antwortet. Google dokumentiert, dass Googlebot bis zu 10 Hops folgt, rät dazu, direkt auf das endgültige Ziel weiterzuleiten, und führt lange Ketten als Bremse für das Crawling auf. Es sagt nicht, dass sie das Ranking zerstören, und es sagt, dass permanente Weiterleitungen keinen Verlust an PageRank verursachen. Die ehrliche Zusammenfassung ist also: Ketten sind ein Problem von Latenz und Crawl-Effizienz, das Sie günstig beheben sollten, keine SEO-Katastrophe.

Die meisten Ketten werden nicht absichtlich gebaut. Jemand fügt eine HTTPS-Regel hinzu, jemand anderes eine www-Regel, ein Marketing-Tool verpackt den Link in einen Tracker, und jeder Hop ist für sich vernünftig. Unten: wie sich die Schichten stapeln, was jeder Hop kostet, welche SEO-Behauptungen gegenüber Googles Dokumentation standhalten und wie Sie eine Kette nachverfolgen und abflachen. Für das Vokabular der Statuscodes ist zuerst Arten von URL-Weiterleitungen die Landkarte. Wenn die Kette in sich zurückläuft, wollen Sie stattdessen wie man eine Redirect-Schleife behebt.

Was eine Redirect-Kette ist

Eine Redirect-Kette entsteht, wenn URL A zu B weiterleitet und B zu C, statt dass A direkt auf C zeigt. Jeder Pfeil ist eine eigene HTTP-Antwort, und der Client stellt für jede eine neue Anfrage. Eine Weiterleitung ist normal; "Kette" beginnt bei zwei.

Mehrfache Weiterleitungen und Redirect-Hops beschreiben dasselbe aus verschiedenen Blickwinkeln: die Anzahl der Weiterleitungen zwischen Anfrage und Zielseite. Eine Redirect-Schleife ist eine Kette, die nie endet, weil sie eine URL erneut besucht. Eine Kette dagegen endet; sie braucht nur zu lange dafür.

Wie Redirect-Ketten entstehen

Ketten stapeln sich, weil jede Schicht ihre eigene Vorliebe durchsetzt. Die üblichen Schichten, in der Reihenfolge, in der eine Anfrage ihnen begegnet:

• Schema. http:// geht zu https://, meist in einer Server- oder Proxy-Regel.
• Host. Die Apex-Domain geht zu www oder umgekehrt, in einer anderen Regel, die nach der Schema-Regel greift.
• Pfad. Ein Normalisierer für den abschließenden Schrägstrich oder Kleinschreibung schreibt /Promo/ zu /promo um.
• Kampagnen- oder Tracking-Wrapper. Ein Anzeigen-Klick-Tracker, der Link-Umschreiber einer E-Mail-Plattform oder ein Kurzlink sitzt vor allem anderen.
• Altlasten-Zuordnung. Eine Weiterleitung aus einem früheren Redesign, die niemand neu gesetzt hat.

Setzt man sie zusammen, kann ein schlichtes http://example.com/Promo/ vier Hops brauchen: zu HTTPS, dann zu www, dann zum normalisierten Pfad, dann über eine alte Redesign-Regel zur Live-Seite. Kurzlinks kommen vorn dazu. Einer ist ein legitimer Hop. Der Schaden beginnt, wenn sein Ziel nicht die endgültige URL ist. Fügen Sie http://example.com/promo als Ziel ein, und Ihr Link steht am Anfang einer Kette, die die Zielseite unsichtbar gebaut hat. Schaden URL-Kürzer der SEO behandelt die Ranking-Seite dieser Frage; die kurze Antwort: Ein sauberer Hop ist in Ordnung, ein gestapelter ist Ihr Problem.

Ketten sind leicht zu übersehen, weil Browser sie verbergen: Die Adressleiste zeigt die endgültige URL und die Seite lädt, also wirkt nichts falsch. Sie tauchen außerdem nur bei der Anfragevariante auf, die jede Regel auslöst, meist der älteste http://-Link auf dem ältesten gedruckten Material.

Wie vielen Hops folgt Googlebot?

Googlebot folgt standardmäßig bis zu 10 Redirect-Hops. Das stammt direkt aus Googles Crawler-Dokumentation. Sie fügt hinzu, dass bestimmte Google-Produkte andere Limits verwenden können und dass das URL-Prüftool Weiterleitungen gar nicht folgt. Google sagt nicht ausdrücklich, was mit einer längeren Kette geschieht, nehmen Sie also an, dass das Ziel schlicht nicht erreicht wird.

Zehn ist eine Obergrenze, keine Empfehlung. Googles Leitfaden zum Website-Umzug sagt, man solle direkt auf das endgültige Ziel weiterleiten und, wenn das nicht möglich ist, die Kette kurz halten, "idealerweise nicht mehr als 3 und weniger als 5", weil Verkettung Latenz für Nutzer erzeugt und nicht alle User Agents lange Ketten unterstützen. Merken Sie sich das so: ein Hop als Ziel, ein paar als Toleranz und bei zehn ein harter Stopp.

Browser haben eigene Limits. Chrome gibt bei 20 auf und liefert ERR_TOO_MANY_REDIRECTS, das Symptom, das im Leitfaden zur Redirect-Schleife behandelt wird. Auch der HTTP-Standard legt keine Zahl fest: RFC 9110 sagt nur, Clients sollten zyklische Weiterleitungen erkennen und eingreifen.

Was jeder Hop an Latenz kostet

Jeder Hop kostet mindestens einen Netzwerk-Roundtrip. Ein Hop zu einem anderen Hostnamen kostet mehr. Der Client löst den neuen Namen auf, öffnet eine TCP-Verbindung und schließt einen TLS-Handshake ab, bevor er etwas senden kann. Lighthouses eigener Audit lässt eine Seite mit zwei oder mehr Weiterleitungen durchfallen und sagt, der zusätzliche Weg könne eine Ressource "um hunderte Millisekunden" verzögern.

Hier die Rechnung, als Veranschaulichung und nicht als Benchmark. Nehmen Sie einen Roundtrip von 100 ms an, was bei einer Mobilverbindung mit mittlerem Signal üblich ist. Ein Hop zu einem neuen Host mit DNS, TCP und einem TLS-1.3-Handshake vor der Anfrage kann leicht drei bis vier Roundtrips kosten, also 300 bis 400 ms. Ein Hop, der eine offene Verbindung zum selben Host wiederverwendet, kostet einen, also 100 ms. Eine Kette mit vier Hops und zwei neuen Verbindungen verbringt dann grob 900 ms, bevor die eigentliche Seite beginnt, gegenüber etwa 450 ms bei einer flachen Weiterleitung.

Mobil macht es aus einem schlichten Grund schlimmer: Die Einschränkung ist die Latenz, nicht die Bandbreite. Redirect-Antworten sind winzig, das Warten besteht also nur aus Roundtrips, und ein schnellerer Tarif nützt dabei nichts. Einen Hop zu streichen ist oft billiger, als ein Bild zu verkleinern. Was ein einzelner Hop auf der Serverseite kosten sollte, steht in wie Weiterleitungen unter 15 ms kommen.

Ketten verlieren auch Daten. Jeder Hop ist eine Stelle, an der eine Umschreibregel einen Query-String fallen lassen kann, und ein abgeschnittenes utm_source ist der übliche Weg, wie UTM-Parameter aus den Analytics verschwinden.

Link-Equity und Crawl-Budget: Was Google dokumentiert

Zuerst die Link-Equity. Googles Dokumentation zum Website-Umzug stellt fest, dass "301 und andere permanente Weiterleitungen keinen Verlust an PageRank verursachen". Googles Gary Illyes sagte 2016 dasselbe über 30x-Weiterleitungen, aber das war ein Social-Media-Beitrag, keine Dokumentation. Die alte Faustregel, dass jeder Redirect-Hop einen festen Prozentsatz an Equity verblutet, ist also Folklore. Keine Google-Quelle nennt einen Prozentsatz, und Zahlen wie 15 Prozent werden in SEO-Beiträgen ohne Quellenangabe wiederholt. Wenn Ihnen jemand eine nennt, fragen Sie nach der Quelle.

Ketten sind trotzdem nicht kostenlos. Zwei Effekte sind dokumentiert. Erstens die Crawl-Effizienz: Googles Crawl-Budget-Leitfaden für große Websites sagt unmissverständlich, lange Redirect-Ketten zu vermeiden, die sich negativ auf das Crawling auswirken. Zweitens die Nutzer-Latenz, oben behandelt, die in die Signale der Seitenerfahrung einfließt. Das Crawl-Budget zählt vor allem bei sehr großen oder sich schnell ändernden Websites; eine Website mit 200 Seiten wird von ein paar Ketten kaum ein Crawl-Budget-Problem spüren, wobei Besucher die Geschwindigkeitskosten trotzdem spüren.

Es gibt außerdem eine Indexierungs-Nuance. Google nutzt permanente Weiterleitungen als Canonical-Signal für das Ziel. Welche URL angezeigt wird, hängt teils davon ab, ob jede Weiterleitung temporär oder permanent war. Eine Kette, die 301- und 302-Hops mischt, macht dieses Signal unklarer, ein guter Grund, die Codes einmal festzulegen. Canonical vs. 301-Weiterleitung geht darauf ein, wie diese Signale zusammenwirken.

Meine Haltung: Geraten Sie wegen Equity nicht in Panik, beheben Sie Ketten wegen Geschwindigkeit und Crawl-Hygiene und versprechen Sie von der Abflachung keinen Ranking-Zuwachs. Niemand hat diesen Zuwachs dokumentiert. Schnellere Ladezeiten und weniger verschwendete Abrufe sind das, was Sie messen können.

Wie Sie Redirect-Ketten erkennen

Beginnen Sie mit curl, denn es gibt jeden Hop aus, den ein Browser verbirgt. Der erste Befehl zeigt die Statuszeile und Location jeder Antwort:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Ein sauberes Ergebnis ist ein 3xx, dann ein 200. Eine Kette zeigt zuerst zwei oder mehr 3xx-Zeilen. Für eine Zählung und die in Weiterleitungen verbrachte Zeit fragen Sie curl nach seinen eigenen Zahlen:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Zwei Vorbehalte. -I sendet eine HEAD-Anfrage, und manche Server beantworten HEAD anders als GET, wiederholen Sie also, wenn das Ergebnis zu sauber aussieht, ohne -I und verwerfen Sie den Body mit -o /dev/null -D -. Und testen Sie die Worst-Case-Variante, die jede Regel auslösen würde: http://, kein www, Großbuchstaben im Pfad, abschließender Schrägstrich. Nur die kanonische URL zu testen ist der Grund, warum Ketten überleben. Ich teste lieber die hässlichen Varianten zu viel, als der sauberen zu vertrauen.

Öffnen Sie im Browser die Devtools, gehen Sie zum Network-Panel, setzen Sie den Haken bei "Preserve log", damit frühere Hops die Navigation überleben, und laden Sie neu. Jede Weiterleitung erscheint als eigene 301- oder 302-Zeile. Unser Link-Checker zeigt dieselbe Kette ohne Terminal.

Um eine ganze Website zu prüfen, hat ein Desktop-Crawler wie Screaming Frog oder Sitebulb einen Bericht zu Redirect-Ketten, der jede Kette mit jedem Hop und den Statuscodes auflistet. Für langlebige Links legen Sie dieselbe Verfolgung in einen geplanten Job, wie in Link-Weiterleitungen überwachen.

Wie Sie eine Redirect-Kette abflachen

Abflachen bedeutet, dass jede Alt-URL direkt auf die endgültige URL zeigt. Die Schritte der Reihe nach:

1. Wählen Sie die kanonische Form: Schema, Host, Richtlinie zum abschließenden Schrägstrich und Schreibung. Schreiben Sie sie auf.
2. Verfolgen Sie jede alte URL und notieren Sie ihr endgültiges Ziel.
3. Schreiben Sie jede Regel so um, dass sie auf dieses endgültige Ziel zeigt, nicht auf die nächste Regel.
4. Aktualisieren Sie interne Links, Sitemaps und rel="canonical"-Tags auf die endgültige URL, damit Crawler und Nutzer die Kette gar nicht mehr betreten.
5. Führen Sie die Verfolgung erneut aus und bestätigen Sie höchstens einen Hop.

Der serverseitige Trick besteht darin, Schema und Host in einer Regel zu kombinieren. In nginx sieht das so aus, mit $request_uri, damit Pfad und Query-String erhalten bleiben:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Eine Anfrage an http://example.com/page geht nun in einem Hop zu https://www.example.com/page, wo zwei Regeln zwei erzeugt hätten. Eine Weiterleitung in .htaccess einrichten und wie man eine URL weiterleitet behandeln die Entsprechungen für Apache und auf Anwendungsebene.

Testen Sie zuerst mit 302. Browser cachen 301 aggressiv, ein Fehler bleibt also hängen. Sobald die Kette ein Hop ist, wechseln Sie zum permanenten Code. HSTS hilft ebenfalls: Nachdem ein Browser einen Strict-Transport-Security-Header gesehen hat, stellt er http:// intern auf https:// um, sodass wiederkehrende Besucher diesen Hop ganz überspringen. Für Crawler oder Erstbesucher bringt es nichts, es ergänzt die Ein-Hop-Regel also und ersetzt sie nicht.

Wenn Ketten immer wieder auftauchen, liegt die Ursache im Prozess, nicht in der Syntax; Link-Rot-Prävention beschreibt die Prüfgewohnheit, die verhindert, dass sich alte Zuordnungen anhäufen.

Wie die Weiterleitung eines gut erzogenen Kurzlinks aussieht

Ein Kurzlink sollte genau ein Hop vom Slug zur endgültigen kanonischen Seite sein, und sonst nichts. Die Anfrage erreicht die Kurz-Domain. Die Antwort ist ein 3xx mit dem Ziel in Location. Das Ziel antwortet direkt mit 200. Kein zwischengeschalteter Kürzer, kein Tracker, der erneut weiterleitet, kein Ziel, das zu www oder zu HTTPS springt, weil Sie die alte Form eingefügt haben.

Der Code hängt vom Anwendungsfall ab.

• 302 (oder 307) für getrackte, bearbeitbare Links in Kampagnen, Social-Beiträgen, E-Mail und QR-Codes. Er lässt Sie das Ziel später umleiten und sorgt dafür, dass jeder Klick die Weiterleitungsebene erreicht, sodass die Analytics vollständig bleiben.
• 301 (oder 308), wenn der Umzug dauerhaft ist und das Ziel als kanonisch behandelt werden soll, etwa bei einer Vanity-URL, die eine alte Adresse endgültig ersetzt.

301 vs. 302-Weiterleitungen führt durch die Caching-Falle, die den 302-Standard sinnvoll macht. Zwei Gewohnheiten halten die Kette bei einem Hop. Fügen Sie immer die endgültige URL als Ziel ein, nachdem Sie sie einmal geladen und die Adresse aus der Leiste kopiert haben, und führen Sie die obige curl-Zählung bei neuen Links vor dem Start aus. Wenn Sie das Ziel einmal gespeichert und ohne Neudruck bearbeitbar haben möchten, beginnen Sie mit einem kostenlosen Elido-Workspace und verfolgen Sie Ihren ersten Link mit den Befehlen aus diesem Beitrag.

Dritte können Hops hinzufügen, die Sie nicht kontrollieren. Der Klick-Tracker einer Werbeplattform oder der Link-Wrapper eines E-Mail-Anbieters sitzt vor Ihrem Kurzlink, ob Sie wollen oder nicht, und das ist das beste Argument, Ihren eigenen Teil des Pfads bei einem Hop zu halten. Eine Marken-Domain fügt keinen hinzu, wie eigene Domains für Kurzlinks erklärt.

Dieser Beitrag gehört zum Engineering-Cluster. Für die vollständige Landkarte der Statuscodes lesen Sie Arten von URL-Weiterleitungen, und für die Weiterleitungsebene hinter einem Kurzlink wie URL-Kürzer funktionieren.

Weiterführend im Blog

• Redirect-Schleife: ERR_TOO_MANY_REDIRECTS finden und beheben
• Arten von URL-Weiterleitungen: 301, 302, 307, 308 und mehr
• 301 vs. 302-Weiterleitungen: welche sollten Kurzlinks verwenden
• Schaden URL-Kürzer der SEO? Die ehrliche Antwort
• Canonical vs. 301-Weiterleitung: das richtige Signal wählen
• Wie man eine URL weiterleitet: sechs Wege und wann welcher passt