Weiterleitungsketten: Wie sie entstehen, was sie kosten, wie man sie flacht

Eine Weiterleitungs-Kette ist der seltene technische Defekt, der sich hinter einer grünen Ampel versteckt. Tippen Sie die URL, holen Sie die Seite, Status 200 — jeder gewöhnliche Test besteht, weil jeder gewöhnliche HTTP-Client die ganze Kette stillschweigend folgt und nur berichtet, wo er gelandet ist. Die Hops dazwischen existieren, sie werden bei jedem Abruf abgerechnet, und nichts in einem Browser sagt Ihnen, wie viele es gab.

Eine nützliche Weiterleitungsfindung zeigt den Einstiegspunkt URL, Zwischenziele und die Endseite. Dieses Protokoll lässt das verantwortliche Team entscheiden, welche Regel die ursprüngliche Anfrage direkt zum vorgesehenen Ziel senden soll. Die Beobachtung lässt sich auch nach einer Reparatur leicht verifizieren: untersuchen Sie die Sequenz erneut und vergleichen Sie sie mit dem gespeicherten Pfad.

Eine 4-Hop-Kette setzt sich aus 4 getrennten korrekten Entscheidungen zusammen

Ketten akkumulieren eine Schicht nach der anderen, und jede Schicht verdient ihren Platz, wenn sie landet:

1. TLS landet. Jemand fügt eine Edge-Regel hinzu, die http:// zu https:// sendet. Das beabsichtigte Ziel verwendet jetzt HTTPS.
2. Ein kanonischer Host wird gewählt. Das Team standardisiert auf www, sodass der Apex darauf umleitet. Der Geschwister-Hostname sollte zum gleichen beabsichtigten Ziel führen.
3. Abschließende Schrägstriche werden normalisiert. Ein Framework oder CDN-Default fügt eine Regel hinzu, die den abschließenden Schrägstrich anhängt oder entfernt. Veröffentlichten Links und Sitemap-Einträgen sollte der beabsichtigte Stil konsequent verwendet werden.
4. Internationalisierung wird ausgeliefert. Root-Pfade beginnen, zu einem Locale-Präfix zu routen, /blog/ zu /en/blog/. Lokalisierte Seiten benötigen eindeutige stabile URLs, obwohl eine Weiterleitung vom Root eine site-design-Entscheidung ist.

Das sind 4 korrekte Regeln, und jetzt erreicht http://example.com/blog sein Ziel durch 4 Weiterleitungen. Eine CMS-Migration, die /blog/* zu /articles/* umschreibt, fügt eine 5. hinzu, ohne die ersten 4 zu berühren, weil sie in der Anwendung implementiert ist, während die anderen im Edge, im Webserver und im Router leben. Die Regeln feuern in der Reihenfolge, in der die Anfrage den Stack durchläuft, nicht in der Reihenfolge, die die URL am schnellsten lösen würde. Niemand besitzt die Zusammensetzung.

Dies ist auch der Grund, warum das http‑zu‑https‑Ergebnis in unseren eigenen Daten sorgfältig gelesen werden muss. Zwischen dem 23. Mai und dem 31. August 2026 wurde die HTTP‑zu‑HTTPS‑Normalisierung bei 44 % von 171 Bewertungen als problematisch gekennzeichnet, jedoch nur bei 8 % von 48 unterschiedlichen Sites. Die Site‑Level‑8% ist die Prävalenzzahl; die Bewertungszahl beschreibt unsere Beobachtungen, nicht das Web. Eine Prüfung wird jedes Mal bewertet, wenn ein Audit ausgeführt wird, sodass einige Sites, die wiederholt auditiert wurden, während das Defekt weiterhin bestand, viele fehlerhafte Bewertungen beitragen, und sie ziehen die Bewertungsrate weit über den Anteil der betroffenen Sites. Die 44% als "44% der Sites" zu zitieren, würde die Prävalenz um mehr als einen Faktor von 5 überschätzen.

Google folgt bis zu 10 Hops und rät Ihnen, unter 5 zu bleiben

Das Hop‑Budget ist dokumentiert, kein Mythos. Die Crawling‑Dokumentation von Google besagt, dass seine Crawler standardmäßig bis zu 10 Redirect‑Hops folgen, und weist darauf hin, dass einzelne Produkte unterschiedlich sind — die eigenen Inspection Tools von Google folgen überhaupt nicht den Redirects. Die Site‑Migration‑Anleitung ist gezielter: Googlebot kann bis zu 10 Hops folgen, aber "wir empfehlen, direkt zum endgültigen Ziel umzuleiten. Wenn dies nicht möglich ist, halten Sie die Anzahl der Redirects in der Kette niedrig, idealerweise nicht mehr als 3 und weniger als 5." Die Crawl‑Budget‑Dokumentation reduziert es auf eine Zeile: vermeiden Sie lange Redirect‑Ketten, die negative Auswirkungen auf das Crawlen haben.

Die Kosten teilen sich in 3 Teile, und sie tragen ungleiche Gewichtung:

Crawl‑Effizienz. Jeder Hop ist eine Anfrage, die der Crawler von Google ohne Empfang von Inhalt ausgibt — die Dokumentation ist ausdrücklich, dass Inhalte, die von einem Redirecting URL zurückgegeben werden, ignoriert werden und nur der Inhalt des endgültigen Ziels verarbeitet wird. Auf einer Seite mit ein paar hundert URLs ist das Rauschen. Auf einer Seite, auf der die Kette im URL Muster sitzt, verwendet jeder interne Link, es vervielfacht sich über die gesamte Crawl und konkurriert mit der Crawl-Kapazitätsgrenze, der derselbe Host bereits unterliegt.

Latenz, bei jedem nicht zwischengespeicherten Abruf. Ein Sprung ist ein vollständiger Hin- und Rückweg: DNS kann bereits warm sein, aber die Wiederverwendung der Verbindung endet im Moment, wenn ein Sprung den Host ändert, was der Schritt von example.com zu www.example.com per Definition tut. Benutzer spüren dies einmal und hören dann auf, es zu spüren, weil Browser permanente Weiterleitungen zwischenspeichern. Maschinen, die kalt abrufen, ohne einen warmen Cache, spüren es jedes Mal.

Signalzusammenführung, wo das Volksglauben lebt. Die alte Behauptung ist, dass jeder Sprung einen Prozentsatz des Link-Equity verliert. Google widersprach ihm öffentlich im Juli 2016, als Gary Illyes eindeutig erklärte, dass 30x Weiterleitungen kein PageRank verlieren, und klärte damit, was John Mueller bereits zu http‑zu‑https‑Übergängen früher im selben Jahr gesagt hatte. Die dauerhafte Version der Sorge ist enger und immer noch real: ein 301 ist das stärkste verfügbare Canonicalisierungssignal, und der Wert einer Weiterleitung besteht darin, dass sie ein Ziel eindeutig benennt. Eine Kette benennt immer noch ein Ziel, daher ist das Equity-Argument das schwächste der 3 Gründe, um zu flachen. Crawl-Effizienz und Latenz tragen den Fall.

AI‑Fetcher und Agenten behandeln Ketten weniger nachsichtig als Browser

Browser sind die permissivsten Weiterleitungsclients, mit denen eine Seite jemals getestet wird. Sie folgen langen Ketten ohne Kommentar, speichern permanente Weiterleitungen aggressiv und präsentieren das Ziel, als wäre es das URL angefordert. Programmatische Clients — die Schicht, durch die AI‑Assistenten, Retrieval‑Pipelines und Agenten tatsächlich abrufen — variieren auf Weisen, die ein Browser-Test nicht aufdecken kann.

curl folgt überhaupt nichts ohne -L; eine Kette liefert einen reinen 301 und einen leeren Körper. Library HTTP Clients wählen jeweils ihr eigenes Sprunglimit und ihre eigene Vorgabe dafür, ob überhaupt gefolgt wird, und diese Vorgaben werden von demjenigen gesetzt, der den Abrufcode geschrieben hat, nicht von der Seite. Spezifikationskonforme Clients geben Anmeldeinformationen weg, wenn eine Weiterleitung Quellgrenzen überschreitet, was genau das ist, was ein apex‑zu‑www Sprung tut. Methodensemantik verschiebt sich ebenfalls: 301 und 302 haben eine lange Geschichte, einen POST in einen GET umzuschreiben, während 307 und 308 die ursprüngliche Methode beibehalten — ein Unterschied, der zählt, sobald ein Agent statt zu lesen, ein Submittet.

Füge die Budgetbeschränkung hinzu. Ein Summarizer oder Agent, der eine Seite unter einer Zeitbegrenzung bearbeitet, verbringt einen Teil davon mit Sprüngen, die keinen Inhalt zurückliefern, und ein Abruf, der ein internes Sprunglimit überschreitet, sieht aus wie eine Seite, die ausfällt. Die Kette meldet sich nicht als Kette; sie meldet sich als leeres Ergebnis. Das ist die gleiche Fehlermuster wie die Direktive-Konflikte in unseren Indexierbarkeit-Daten — die Seite funktioniert für Menschen und lehnt stillschweigend ab, für Maschinen zu funktionieren.

Flache in 4 Schritten: Inventar, zusammenfassen, neu verlinken, die Karte behalten

1. Inventarisiere die echten Sprungzahlen. Messe, nicht über die Konfiguration nachdenken. Für ein einzelnes URL:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

Die erste Zeile gibt die Anzahl an, die zweite den Pfad. Führen Sie es gegen die Formen http:// und https:// aus, Apex und www, mit und ohne abschließenden Schrägstrich, und gegen ein repräsentatives URL aus jeder Vorlage – die Kette lebt normalerweise in einem Muster, nicht auf einer Seite. Ein Audit führt dieselbe Durchlaufung auf der Startseite, dem kanonischen Ziel und dem alternativen Host in einem Durchgang durch und meldet den nachverfolgten Pfad als Beweis.

2. Falten Sie jede Kette zu einer einzigen 301. Nehmen Sie die Eintrag URL und das Endziel aus dem Inventar und schreiben Sie eine Regel, die das Erste direkt zum Letzten abbildet, auf der äußersten Schicht, die beide sehen kann – normalerweise die Grenze oder CDN. Dann treten Sie die Zwischenregeln, aus denen die Kette zusammengesetzt war, zurück, anstatt sie hinter der neuen zu belassen. Verwenden Sie 301 für einen dauerhaften Umzug und 308, wenn die Methode erhalten bleiben muss. Das Ziel muss ein 200 sein, das sich selbst als kanonisch erklärt; ein Weiterleitungsziel auf einer Seite, deren kanonisches Ziel woanders liegt, startet die Mehrdeutigkeit in einem anderen Vokabular neu, was die Interaktion ist, durch die unsere kanonischen Tags führen arbeitet.

3. Lenken Sie interne Links auf die endgültigen URLs. Eine abgeflachte Regel kostet immer noch einen Sprung bei jedem internen Link, der das alte URL nennt. Sitemaps, Navigation, hreflang‑Annotationen, kanonische Tags und Links im Text sollten alle direkt auf das Ziel verweisen, sodass die Weiterleitung nur für externe eingehende Links und alte Lesezeichen existiert. Dieser Schritt ist das, was eine Konfigurationskorrektur in einen Gewinn an Crawl‑Effizienz verwandelt.

4. Behalten Sie die Kettendiagramm bei. Protokollieren Sie jede zurückgezogene Regel, ihren Eintrag URL und ihr endgültiges Ziel in einer Datei, die mit der Infrastrukturkonfiguration zusammenhängt. Ketten bilden sich neu, weil die nächste Person, die ein Sprachpräfix hinzufügt oder ein Pfadschema migriert, keine Möglichkeit hat, die bereits vorhandenen 4 Regeln im Anforderungs­pfad zu sehen. Die Karte ist das, was die Zusammensetzung für jeden sichtbar macht, der die Schicht 5 verschickt, und sie ist die Eingabe für das nächste Inventar. Die vollständige Check‑by‑Check‑Behandlung befindet sich in unserem Redirects‑ und URL‑Normalisierungs­leitfaden.

Eine abgeflachte Weiterleitungsschicht ist eine der wenigen technischen Verbesserungen ohne Inhaltsabhängigkeit, ohne Ranking‑Verzögerung, und ein Verifizierungsschritt, der einen einzigen Befehl erfordert. Sie bleibt auf so vielen Seiten fehlerhaft, weil kein Test, den jemand von Hand durchführt, die Sprünge meldet. Sobald ein Trace Teil des Audits ist, wird die Naht zwischen den korrekten Entscheidungen der 4‑Teams zu einem Befund mit einem Pfad, einem Status pro Sprung und einer Regel, die geschrieben werden muss.