Jeder Hop einer Weiterleitungskette zwischen Beitrag und Seite

Was ist eine Weiterleitungskette?

Zwei oder mehr HTTP-3xx-Antworten, die zwischen dem angetippten Link und der Seite stehen, die am Ende rendert, ergeben eine Weiterleitungskette, und jeder Hop darin kostet einen DNS-Lookup, eine TCP-Verbindung und einen TLS-Handshake, bevor ein einziges Byte Ihrer Seite ankommt.

Eine einzelne Weiterleitung ist keine Kette. Wenn http://example.com/sale mit 301 und Location: https://example.com/sale antwortet, ist das ein einzelner Hop, und das ist der Preis dafür, HTTPS zu betreiben. Eine Kette entsteht, wenn der Kürzungsdienst auf den Tracker weiterleitet, der Tracker auf die www-Variante, die www-Variante auf die Variante mit abschließendem Schrägstrich und diese endlich HTML ausliefert. Vier Hops, eine Seite.

RFC 9110 definiert die 3xx-Klasse und listet die Codes auf, die einen Location-Header tragen: 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect und 308 Permanent Redirect. Die Spezifikation fordert Clients auf, „detect and intervene in cyclical redirections“, setzt aber kein Maximum und merkt an, dass eine frühere Fassung der Spezifikation „recommended a maximum of five redirections“ und dass „some clients might implement such a fixed limitation.“

Was kostet jeder Hop einer Weiterleitungskette?

Jeder Hop kostet einen vollen Roundtrip zu einem Server, der keinen Inhalt zurückgibt, dazu einen neuen DNS-Lookup und TLS-Handshake, sobald der Hop auf einen Hostnamen wechselt, mit dem der Browser noch nicht verbunden ist. Ein Kürzungsdienst, ein Link-Shim und Ihre eigene Seite sind drei verschiedene Hostnamen, eine Kette aus drei Hops bedeutet also meist drei Handshakes.

Header fliegen ebenfalls weg. RFC 9110 weist einen User Agent, der einer Weiterleitung automatisch folgt, an, „resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie“ zu entfernen. Der User Agent ersetzt sie durch Werte, die zur neuen Anfrage passen, es braucht also eine Referrer-Policy oder einen Schritt von HTTPS zu HTTP in der Kette, damit ein Klick im Direct Traffic landet, statt dem Netzwerk gutgeschrieben zu werden, das ihn geschickt hat.

Crawler zahlen eine andere Rechnung. Die Crawling-Dokumentation von Google hält fest, dass „any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead“, jeder Zwischen-Hop ist also ein Abruf, der nichts Indexierbares liefert und trotzdem von dem abgeht, was Google auf Ihrer Seite zu crawlen bereit ist.

Wie vielen Weiterleitungen folgt ein Browser oder ein Crawler?

Browser stoppen bei 20 und die Crawler von Google stoppen bei 10. Die Zahlen stammen aus zwei verschiedenen Spezifikationen, und keine davon ist ein Zielwert.

Der eigene Rat von Google liegt weit unter dem eigenen Limit. Die Anleitung zum Seitenumzug sagt, man solle „keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5“, weil „chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains.“

Warum fügen Social-Links Hops hinzu, die Sie nie angelegt haben?

Plattformen schieben eigene Hops vor Ihren ersten, und in den meisten Netzwerken können Sie das nicht ablehnen. Das ist der Teil der Kette, den Sie einplanen statt reparieren müssen.

X ist der deutlichste Fall. Der Hilfebereich hält fest, dass auf X geteilte Links „will automatically be processed and shortened to an http://t.co link“, und beantwortet die Frage nach dem Opt-out direkt: „You cannot opt out of link shortening.“ Jeder Beitrag startet damit bei einem Hop, bevor Ihr Server überhaupt kontaktiert wird, und der t.co-Wrapper zählt immer als 23 Zeichen, egal wie kurz die ursprüngliche URL war.

Facebook und Pinterest machen dasselbe mit anderer Mechanik. Geprüft am 12. September 2026:

Beides sind Hops, die komplett innerhalb der Plattform passieren. Der Facebook-Shim leitet bei der ersten Antwort nicht einmal auf Ihre Seite weiter, sondern auf eine zweite Facebook-URL, die dann weiterleitet. Die Kurzdomain von Pinterest gibt an einen API-Host ab, bevor das Ziel aufgelöst wird. Keiner dieser Hops gehört Ihnen zum Kürzen, und genau das ist das Argument dagegen, obendrauf noch ein bit.ly zu stapeln.

Dazu kommen die Hops, die Sie sehr wohl steuern: ein eigener Kürzungsdienst, ein Klick-Tracker aus der Marketing-Automation, ein Affiliate-Redirector, ein Upgrade von http auf https, eine www-Kanonisierung und eine Regel für den abschließenden Schrägstrich. Stapeln Sie einen Kürzungsdienst und einen Tracker hinter einen Plattform-Shim, und Sie sind bei fünf Hops, bevor Ihr CDN die Anfrage sieht.

Was überlebt vom Query-String die Weiterleitungskette?

Das Fragment überlebt laut Spezifikation, der Query-String nicht. RFC 9110 ist eindeutig: Wenn ein Location-Wert kein eigenes Fragment hat, „a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the target URI.“ Für den Query gibt es keine entsprechende Regel, ?utm_source=linkedin überlebt einen Hop also nur, wenn der weiterleitende Server ihn selbst in Location schreibt.

Ob er das tut, ist eine Frage der Serverkonfiguration, und die beiden verbreiteten Webserver verhalten sich unterschiedlich genug, um Leute kalt zu erwischen:

• Redirect aus Apaches mod_alias nimmt ihn mit. Die Dokumentation sagt, eine Anfrage an http://example.com/service/foo.pl?q=23&a=42 „will be redirected to http://foo2.example.com/service/foo.pl?q=23&a=42.“
• Das rewrite von nginx nimmt ihn mit, solange Sie es nicht unterbinden. Die Dokumentation sagt, „if a replacement string includes the new request arguments, the previous request arguments are appended after them“, und dass „putting a question mark at the end of a replacement string avoids having them appended.“
• Für das return von nginx gilt diese Regel nicht. Die Dokumentation beschreibt das Anhängen von Argumenten nur für rewrite, return 301 https://example.com/new; schickt also genau das, was Sie geschrieben haben, und return 301 https://example.com$request_uri; schickt Pfad und Query, die eingegangen sind.
• Ein Location-Header, der im Anwendungscode von Hand zusammengebaut wird, trägt nur die Teile der URL, die Ihr Code hineinkopiert.

Dieses eine Detail erklärt die meisten kaputten Kampagnen-Reports. Ihre UTM-Parameter hängen an der URL, die Sie gepostet haben, der Plattform-Shim reicht sie als undurchsichtigen Block in seinem eigenen u=-Parameter weiter, und dann schreibt Ihre eigene Aufräum-Weiterleitung den Pfad um und verwirft den Query stillschweigend. Analytics verzeichnet eine Sitzung ohne Kampagne, und niemand kann den Social-Media-Traffic zurückverfolgen bis zu dem Beitrag, der ihn verdient hat.

Parameter, die die Plattform anhängt, verhalten sich genauso. Meta hängt an Werbeziele eine Klick-Kennung an, dokumentiert als ClickID: „a Meta-generated parameter that is passed with the URL of an advertiser's website when a user clicks an ad on Facebook and/or Instagram“, in der Form ?fbclid=IwAR2F4.... Eine Weiterleitungsregel, die den Query verwirft, verwirft fbclid gleich mit, und der Conversions API fehlt die Verknüpfung, die sie gebraucht hätte.

Wie finden und verkürzen Sie eine Weiterleitungskette?

Verfolgen Sie sie mit einem Befehl, bevor Sie darüber diskutieren. curl -sIL -w '%{http_code} %{url_effective}\n' -o /dev/null <url> läuft die Kette ab und gibt aus, was es gefunden hat, und curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' <url> zeigt einen Hop nach dem anderen, wenn Sie genau sehen wollen, welcher Server an welchen abgibt.

Das Verkürzen ist vor allem Buchhaltung. Richten Sie jede Weiterleitungsregel auf die endgültige URL statt auf die nächste Regel, damit ein altes /blog/post in einer einzigen 301 direkt auf https://www.example.com/blog/post/ geht, statt durch drei zu laufen. Behalten Sie den Query-String im Location-Wert bei jeder Regel, die einen tragen kann. Lassen Sie Ihren eigenen Kürzungsdienst in Netzwerken weg, die Links ohnehin einpacken, denn ein t.co, das auf ein bit.ly zeigt, das auf einen Tracker zeigt, sind drei Hops, die alle auf derselben Seite landen.

Häufig gestellte Fragen

Ist eine Weiterleitungskette schlecht für SEO?

Lange Ketten schaden dem Crawling mehr als dem Ranking. Die Dokumentation von Google sagt, dass seine Crawler standardmäßig bis zu 10 Weiterleitungs-Hops folgen und dass Inhalte der weiterleitenden URLs ignoriert werden, Hops jenseits davon werden also nie erreicht und Hops darunter verbrauchen Crawl-Kapazität. Die Anleitung zum Seitenumzug bittet um höchstens drei.

Wie viele Weiterleitungen sind zu viele?

Mehr als drei ist mehr, als Google empfiehlt. Die harten Obergrenzen sind 20 Hops für Browser, die den Fetch Standard umsetzen, und 10 für die Crawler von Google, doch die Empfehlung in Googles Dokumentation zum Seitenumzug lautet „ideally no more than 3 and fewer than 5.“

Überträgt eine 301 in einer Kette mehr Wert als eine 302?

Google behandelt beide als Kanonisierungssignale unterschiedlich. Die Dokumentation beschreibt 301 als starkes Signal dafür, dass das Weiterleitungsziel kanonisch sein soll, und 302 als schwaches, wobei 308 einer 301 entspricht und 307 einer 302. Der Hop kostet in beiden Fällen denselben Roundtrip.

Überleben UTM-Parameter eine Weiterleitung?

Nur wenn das Weiterleitungsziel sie enthält. HTTP verlangt von einem User Agent, das ursprüngliche Fragment zu erben, wenn Location keines hat, kennt aber keine solche Regel für den Query-String, eine Weiterleitung auf einen nackten Pfad wirft also jeden UTM-Parameter der eingehenden URL weg.

Kann ich X, Facebook oder Pinterest davon abhalten, einen Hop hinzuzufügen?

Nein. Der Hilfebereich von X sagt klar, dass Sie sich vom Kürzen der t.co-Links nicht abmelden können, und die Shims von Facebook und Pinterest sind serverseitiges Verhalten auf deren eigenen Domains. Entfernen können Sie nur die Hops auf Ihrer Seite der Übergabe.

Was ist der Unterschied zwischen einer Weiterleitungskette und einer Weiterleitungsschleife?

Eine Kette endet bei einer echten Seite, eine Schleife nie. RFC 9110 weist Clients an, „detect and intervene in cyclical redirections (i.e., 'infinite' redirection loops)“, weshalb eine Schleife als Browserfehler auftaucht und nicht als langsame Seite.

Was zählt als ein Hop in einer Weiterleitungskette?

Ein Hop ist eine einzelne HTTP-3xx-Antwort mit einem Location-Header, wie sie RFC 9110 als 301, 302, 303, 307 und 308 auflistet. Eine 301 von http://example.com/sale zu https://example.com/sale ist ein Hop, keine Kette. Eine Kette beginnt erst, wenn eine zweite 3xx-Antwort folgt.

Übersteht ein URL-Fragment eine Weiterleitungskette?

Das Fragment übersteht die Kette, wenn der Location-Header selbst kein Fragment enthält. RFC 9110 verlangt von einem User-Agent, in diesem Fall das Fragment aus der ursprünglichen URL zu übernehmen. Für den Query-String gilt keine solche Garantie, weshalb sich Fragment und UTM-Parameter in derselben Kette unterschiedlich verhalten.

Warum taucht Traffic aus einer Weiterleitungskette in Analytics als Direct auf?

Weil der Referrer unterwegs verloren gehen kann, nicht weil eine Kette ihn von sich aus entfernt. RFC 9110 lässt den User-Agent den Referer bei jedem Hop entfernen und durch einen Wert ersetzen, der zur neuen Anfrage passt, der Header übersteht eine Weiterleitung also, solange ihn nicht etwas anderes verwirft. Erst eine restriktive Referrer-Policy oder ein Schritt von HTTPS zu HTTP lässt die letzte Anfrage ohne Referrer ankommen, und Analytics verbucht den Besuch dann als Direct, statt ihn der Plattform zuzuschreiben, die den Klick gesendet hat.

Behält nginx' return-Direktive den Query-String bei?

Nicht von allein. Nginx dokumentiert das Anhängen von Query-Parametern nur für die rewrite-Direktive, weshalb return 301 https://example.com/new; genau das sendet, was dort steht, und alles verwirft, was die URL des Besuchers mitbrachte. Erst $request_uri im Ziel, wie in return 301 https://example.com$request_uri;, leitet Pfad und Query weiter.