URL-Weiterleitungen prüfen und die Redirect-Kette verstehen

Der Link, den Sie anklicken, ist oft nicht die Seite, auf der Sie landen. Dazwischen können ein Wechsel auf HTTPS, ein Hostwechsel, ein Tracking-Dienst, ein URL-Kürzer und eine CMS-Regel liegen, die einen Trailing Slash (abschließenden Schrägstrich) anhängt – jeder Schritt eine eigene Anfrage, die Ihr Browser stillschweigend stellt.

Dieser Leitfaden zeigt, wie Sie die einzelnen Schritte mit TrueURL, curl und den DevTools Ihres Browsers sichtbar machen, was die Bestandteile einer Weiterleitungskette bedeuten und wie Sie die häufigsten Probleme beheben.

Was eine Weiterleitungskette ist

Eine Weiterleitung entsteht, wenn ein Server mit einem 3xx-Statuscode und einem Location-Header antwortet, der eine andere URL nennt. Der Client, also ein Browser oder ein Crawler, ruft daraufhin diese URL auf und wiederholt den Vorgang, bis eine Antwort eintrifft, die keine Weiterleitung ist.

Jede Anfrage bildet zusammen mit ihrer Antwort einen Hop. Die gesamte Abfolge von der ersten URL bis zur endgültigen Antwort ist die Weiterleitungskette:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Das sind drei Weiterleitungen und vier Anfragen für eine einzige Seite. Der Location-Wert in Hop 3 ist relativ: Clients lösen ihn gegen die URL auf, die sie gerade angefragt haben, wie es RFC 9110 vorschreibt. Gemeint ist also https://www.example.com/shoes/. Im Idealfall würde jede dieser Adressen die Ziel-URL mit einem einzigen Hop erreichen.

Eine Seite kann auch dann noch weiterleiten, wenn sie bereits mit 200 OK geantwortet hat, nämlich per <meta http-equiv="refresh">-Tag oder JavaScript. Diese clientseitigen Weiterleitungen gehören ebenfalls zur Kette, doch Tools, die nur HTTP-Header auswerten, etwa curl, bleiben auf dieser Seite stehen.

Warum sich die Prüfung von Weiterleitungen lohnt

SEO: Kanonisierungssignale und Crawl-Budget

Suchmaschinen verstehen eine Weiterleitung als Aussage darüber, welche URL indexiert werden soll. Google wertet permanente Weiterleitungen (301 und 308) als starkes Signal dafür, dass das Ziel die kanonische URL sein sollte, temporäre (302, 303 und 307) dagegen als schwaches Signal. Eine Seite, die dauerhaft umgezogen ist, aber per 302 weitergeleitet wird, kann deshalb mit ihrer alten URL in den Suchergebnissen bleiben.

Auch die Länge zählt. Der Googlebot folgt bis zu 10 Weiterleitungs-Hops; hat er bis dahin keinen Inhalt erhalten, meldet die Search Console einen Weiterleitungsfehler. Googles Leitfaden zum Crawl-Budget rät außerdem von langen Weiterleitungsketten ab, da sie sich laut Google negativ auf das Crawling auswirken.

Ladezeit

Die Zielseite kann erst zu laden beginnen, wenn die letzte Weiterleitung beantwortet ist. Jeder Hop kostet einen Netzwerk-Roundtrip, und ein Hop zu einem neuen Host erfordert zusätzlich eine DNS-Abfrage, eine neue Verbindung und bei HTTPS einen TLS-Handshake. Über Mobilfunkverbindungen können drei oder vier Weiterleitungen mehrere hundert Millisekunden kosten, bevor das erste Byte der eigentlichen Seite ankommt. Der Weiterleitungs-Latenztest zeigt, was jeder Hop kostet.

Sicherheit bei Kurzlinks und unbekannten Links

Kurzlinks und viele Tracking-Links in E-Mails verbergen ihr Ziel. Phishing-Kampagnen missbrauchen zudem offene Weiterleitungen (Open Redirects) auf bekannten Domains, sodass ein Link, der auf einer vertrauenswürdigen Website beginnt, ganz woanders enden kann. Der Kurzlink-Auflöser zeigt Ihnen jede Domain auf dem Weg und ob ein Hop von HTTPS auf unverschlüsseltes HTTP zurückfällt – noch bevor Sie klicken.

Affiliate- und Tracking-Links

Marketing-Links durchlaufen vor der Landingpage oft mehrere Dienste, und jeder davon muss den Query-String weiterreichen – sonst gehen UTM-Parameter, Klick-IDs und Affiliate-Tags unbemerkt verloren. An der Ziel-URL erkennen Sie, ob sie erhalten geblieben sind und ob der Link noch die gewünschte Seite erreicht.

Migrationen, HTTPS und der kanonische Host

Nach einem Relaunch, einem Domainumzug oder der Umstellung auf HTTPS sollte jede alte URL ihr neues Gegenstück mit einer einzigen permanenten Weiterleitung erreichen. Die vier Grundvarianten einer Website (http:// und https://, jeweils mit und ohne www) sollten alle auf derselben kanonischen Adresse landen. Solche Regeln gehen unbemerkt kaputt: Eine neue CDN-Regel, ein Plugin-Update oder ein Serverumzug kann einen zusätzlichen Hop oder eine Schleife einführen, ohne dass es jemandem auffällt.

Weiterleitungen mit TrueURL prüfen

TrueURL führt jede Prüfung im Edge-Netzwerk von Cloudflare aus. So können Sie Links untersuchen, denen Sie nicht trauen, ohne sie in Ihrem Browser zu öffnen. Der URL-Redirect-Checker auf der Startseite prüft eine einzelne URL; der Weiterleitungsketten-Checker und die anderen spezialisierten Tools nutzen dieselbe Engine.

Schritt 1: URL eingeben

Fügen Sie die URL ein und starten Sie die Prüfung. Ohne Protokollangabe wird https:// angenommen; geben Sie http:// ein, um unverschlüsseltes HTTP zu testen.

Schritt 2: Erweiterte Einstellungen bei Bedarf anpassen

Standardmäßig sendet der Checker eine GET-Anfrage mit dem User-Agent eines aktuellen Desktop-Chrome, ohne Cookies und mit einem Limit von 20 Weiterleitungen. Unter Erweiterte Einstellungen lässt sich das ändern:

• HTTP-Methode: GET, HEAD oder POST. HEAD ist schlanker, doch manche Server beantworten es anders, und ohne Body lassen sich clientseitige Weiterleitungen nicht erkennen. POST sendet den von Ihnen eingegebenen Anfragetext, etwa für Formular-Handler und APIs. Spätere Hops folgen den Browserregeln: Nach einem POST geht es bei 301 oder 302 mit GET weiter, bei 303 in jedem Fall, und 307 und 308 behalten Methode und Body bei.
• Max. Hops: die Anzahl der Weiterleitungen, denen gefolgt wird, von 1 bis 50. Der Standardwert 20 entspricht dem Limit im Fetch Standard sowie in Chrome und Firefox. Stellen Sie 10 ein, um zu sehen, ob eine Kette in das Limit des Googlebots passt.
• Benutzerdefinierter User-Agent: Ohne Eingabe wird Desktop-Chrome verwendet. Zu den Vorlagen gehören Safari auf dem iPhone, Chrome auf Android, Googlebot (Smartphone und Desktop), Bingbot, die Linkvorschau-Bots von Facebook und X sowie curl.
• Benutzerdefinierte Anfrage-Header: zusätzliche Header, die bei jedem Hop mitgesendet werden, zum Beispiel Accept-Language: fr-FR, um eine Sprachweiterleitung auszulösen.
• Cookies: Geben Sie name=value; other=value ein, um einen Login-, Einwilligungs- oder Regionsstatus nachzustellen. Cookies, die entlang der Kette gesetzt werden, bleiben wie im Browser für spätere Hops erhalten.
• Clientseitige Weiterleitungen: Meta-Refresh-Tags und einfachen JavaScript-Weiterleitungen folgen oder sie nur melden.
• SSL-Fehler ignorieren: Das Edge-Netzwerk von Cloudflare validiert Zertifikate immer, ein fehlerhaftes Zertifikat lässt sich damit also nicht überspringen. Ein TLS-Fehler wird bei dem Hop gemeldet, bei dem er aufgetreten ist.

Schritt 3: Ergebnis auswerten

Das Ergebnis beginnt mit der Ziel-URL und ihrem Statuscode. Die Kette darunter enthält eine Zeile pro Hop mit:

• der angefragten URL und der verwendeten HTTP-Methode;
• dem Statuscode und seinem Statustext (die Übersicht der HTTP-Statuscodes erklärt jeden einzelnen);
• der Antwortzeit vom Senden der Anfrage bis zum Eintreffen der Header, einschließlich DNS-Abfrage und Verbindungsaufbau;
• dem Ziel im Location-Header;
• den Antwort-Headern und den Namen aller Cookies, die der Hop gesetzt hat.

Jede Weiterleitung ist danach gekennzeichnet, wie sie zustande kam: per HTTP-Statuscode, Meta-Refresh (mit der Verzögerung in Sekunden) oder JavaScript. Clientseitige Weiterleitungen, die gefunden, aber nicht verfolgt wurden, werden ebenfalls gemeldet. Genauso wichtig ist, wie die Prüfung geendet hat:

Warnungen erscheinen bei einer temporären Weiterleitung in der Kette, einem Wechsel von HTTPS zurück zu HTTP, mehr als drei Weiterleitungen, einer Ziel-URL auf einer anderen Domain, clientseitigen Weiterleitungen und HEAD-Anfragen, bei denen kein Seiteninhalt gelesen werden konnte.

Eine Warnung verdient besondere Aufmerksamkeit. Manche Websites zeigen automatisiertem Traffic oder Anfragen aus Rechenzentren eine Bot-Prüfung, etwa die Cloudflare-Seite „Just a moment...“. TrueURL kennzeichnet Antworten, die danach aussehen, denn in diesem Fall hat die Prüfung die Schutzschicht der Website erreicht, nicht das eigentliche Ziel. Ein echter Besucher landet unter Umständen woanders.

Weiterleitungen auf der Kommandozeile prüfen

curl ist unter macOS, Windows 10 und 11 sowie den meisten Linux-Distributionen vorinstalliert und zeigt genau, was der Server sendet, ohne dass ein Browser-Cache dazwischenfunkt. Die Beispiele verwenden eine Unix-Shell. Geben Sie in Windows PowerShell 5.1 curl.exe ein, weil curl dort ein Alias für Invoke-WebRequest ist, und schreiben Sie NUL statt /dev/null.

Einen einzelnen Hop ansehen

curl -I https://example.com/old-page

-I sendet eine HEAD-Anfrage und gibt die Antwort-Header aus, einschließlich der Statuszeile und eines etwaigen Location-Headers. curl folgt Weiterleitungen nur, wenn Sie es ausdrücklich anweisen. Da manche Server HEAD anders behandeln, wiederholen Sie die Prüfung als GET, wenn das Ergebnis merkwürdig aussieht; -o /dev/null verwirft den Body und -D - gibt die Header aus:

curl -sS -o /dev/null -D - https://example.com/old-page

Der gesamten Kette folgen

-L folgt Weiterleitungen, und mit -I oder -D - gibt curl die Header jedes Hops aus. Ein grep-Filter sorgt für eine kompakte Ansicht:

curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

Standardmäßig folgt curl bis zu 50 Weiterleitungen; mit --max-redirs 10 gilt das Limit des Googlebots.

Nur die Ziel-URL ausgeben

Die Option -w (write-out) gibt nach der Übertragung Details aus und macht curl so zu einem kompakten URL-Expander:

curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} ist die zuletzt abgerufene URL, %{num_redirects} die Anzahl der verfolgten Weiterleitungen und %{http_code} der endgültige Statuscode. %{time_redirect} gibt an, wie viele Sekunden vor der letzten Anfrage auf Weiterleitungen entfallen sind. Ohne -L zeigt %{redirect_url}, wohin die erste Weiterleitung führen würde.

POST-Anfragen testen

-d sendet einen Body und macht die Anfrage zu einem POST. Beim Folgen von Weiterleitungen verhält sich curl dann wie ein Browser: Nach 301, 302 oder 303 wechselt es zu GET, nach 307 oder 308 sendet es den POST samt Body erneut.

curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Kombinieren Sie -X POST nicht mit -L. -X erzwingt die Methode bei jeder Anfrage, sodass curl auch nach 301, 302 oder 303 weiter POST sendet, wo ein Browser zu GET wechseln würde – Sie testen dann eine Kette, die kein echter Client erzeugt.

User-Agent, Header und Cookies ändern

# Smartphone-User-Agent
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Zusätzlicher Anfrage-Header
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Cookie senden und die entlang der Kette gesetzten Cookies behalten
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A setzt den User-Agent, -H fügt einen Header hinzu und -b sendet Cookies. -c speichert empfangene Cookies in einer Datei und aktiviert die Cookie-Engine von curl, sodass ein Cookie, das ein Hop setzt, beim nächsten mitgesendet wird.

curl führt kein JavaScript aus und reagiert nicht auf Meta-Refresh-Tags. Liefert curl als letzte Antwort eine HTML-Seite mit 200 OK, landet Ihr Browser aber woanders, findet die Weiterleitung auf der Clientseite statt.

Weiterleitungen in den Browser-DevTools prüfen

Die DevTools zeigen die Kette so, wie Ihr eigener Browser sie sieht – mit Ihren Cookies, Erweiterungen und Ihrem Standort:

1. Öffnen Sie die DevTools (F12 oder auf dem Mac Cmd+Option+I) und wählen Sie den Tab Network.
2. Aktivieren Sie in Chrome und Edge Preserve log bzw. in Firefox im Einstellungsmenü des Netzwerk-Tabs Persist Logs. Andernfalls wird die Liste bei jedem Seitenaufruf geleert, und clientseitige Weiterleitungen verschwinden aus dem Blick.
3. Aktivieren Sie Disable cache, damit eine zwischengespeicherte Weiterleitung nicht verdeckt, was der Server aktuell sendet.
4. Geben Sie die URL in die Adressleiste ein.

Jeder Hop erscheint als eigene Zeile mit seinem 3xx-Status. Wählen Sie ihn aus und öffnen Sie Headers, um den Antwort-Header location zu sehen. Steht in Chrome in der Spalte Size „(disk cache)“ oder „(memory cache)“, stammt die Weiterleitung aus dem Cache und nicht vom Server.

Manchmal listet Chrome einen 307 Internal Redirect von http:// zu https://. Diesen hat der Server nie gesendet: Der Browser hat die Anfrage selbst auf HTTPS umgestellt, meist weil er für die Website eine HSTS-Richtlinie gespeichert hat. Um zu sehen, was der Server bei unverschlüsseltem HTTP tut, verwenden Sie curl oder TrueURL.

Häufige Probleme mit Weiterleitungen und ihre Lösung

Ketten mit mehr als einem Hop

Ketten wachsen schichtweise: Eine Regel aus einer alten Migration zeigt auf eine URL, die bei einer späteren Migration erneut weitergeleitet wurde. Lassen Sie jede Regel direkt auf das endgültige Ziel zeigen, und aktualisieren Sie interne Links, Canonical-Tags, hreflang-Annotationen und Sitemaps, damit Ihre eigene Website nie eine Weiterleitung auslöst. Der Bulk-Redirect-Checker zeigt, welche alten URLs noch mehr als einen Hop brauchen.

Weiterleitungsschleifen

Chrome meldet eine Schleife als „zu oft weitergeleitet“ (ERR_TOO_MANY_REDIRECTS), Firefox als „Fehler: Umleitungsfehler“ (englisch: „The page isn’t redirecting properly“). Häufige Ursachen:

• HTTPS hinter einem Proxy oder CDN. Der Ursprungsserver leitet HTTP auf HTTPS weiter, doch der Proxy verbindet sich per unverschlüsseltem HTTP mit ihm. Der Ursprungsserver sieht also nie HTTPS und leitet endlos weiter. Bei Cloudflare ist das die klassische Folge des SSL/TLS-Modus Flexible; verwenden Sie Full (strict), oder lassen Sie den Ursprungsserver X-Forwarded-Proto auswerten.
• Zwei Ebenen, die sich widersprechen, etwa eine CDN-Regel, die www entfernt, während der Server es hinzufügt, oder ein Framework, das einen Trailing Slash anhängt, den das CDN wieder entfernt.
• Cookie-abhängige Weiterleitungen. Eine Login- oder Einwilligungsseite schickt Besucher zur ursprünglichen URL zurück, die sie erneut zur Login-Seite weiterleitet, weil das Cookie nicht gespeichert wurde.

Der Weiterleitungsschleifen-Checker zeigt, welcher Hop die Schleife schließt. Machen Sie anschließend für jede Regel genau eine Ebene zuständig.

301 und 302 gemischt in einer Kette

Eine Kette aus 301, dann 302, dann 200 ist ein dauerhafter Umzug mit einem temporären Zwischenschritt. Oft steckt ein Standardwert dahinter: res.redirect() in Express und header('Location: ...') in PHP senden beide 302, sofern nichts anderes angegeben ist. Verwenden Sie bei jedem Hop einen permanenten Code und prüfen Sie das mit dem 301-Redirect-Checker. Unser Leitfaden zu HTTP-Statuscodes für Weiterleitungen erklärt, wann welcher Code passt.

Doppelte Hops von HTTP über HTTPS zu www

Eine sehr häufige Kette ist http://example.com → https://example.com → https://www.example.com: zwei Hops, wo einer genügen würde. Leiten Sie jede nicht kanonische Variante direkt auf die endgültige HTTPS-URL weiter, und testen Sie anschließend alle vier mit dem HTTPS-Redirect-Checker.

Eine Ausnahme ist gewollt: Wenn Ihr kanonischer Host www ist und Sie die Domain in die HSTS-Preload-Liste eintragen lassen, verlangt hstspreload.org, dass http://example.com zuerst auf https://example.com weiterleitet, damit Browser die HSTS-Richtlinie für die Domain ohne www speichern.

Uneinheitlicher Trailing Slash

/pricing und /pricing/ sind unterschiedliche URLs. Liefern beide 200 OK, haben Sie Duplicate Content; leiten zwei Ebenen sie jeweils auf die andere weiter, haben Sie eine Schleife. Entscheiden Sie sich für eine Form, leiten Sie die andere mit einer einzigen 301-Weiterleitung darauf weiter, und verlinken Sie einheitlich. Der Trailing-Slash-Checker testet beide Formen gleichzeitig.

Weiterleitungen nur für Mobilgeräte

Separate Mobil-Websites, Hinweise zur App-Installation und Geräteerkennung schicken Smartphones manchmal woandershin, oft auf die mobile Startseite statt auf die entsprechende Seite. Bei der Mobile-First-Indexierung crawlt Google hauptsächlich mit seinem Smartphone-Crawler, deshalb ist für die Indexierung vor allem die mobile Kette entscheidend. Vergleichen Sie beide mit dem Tool Mobil- vs. Desktop-Weiterleitung.

Weiterleitungen in Sitemaps

Eine Sitemap sollte die kanonischen URLs enthalten, die Sie in den Suchergebnissen sehen möchten – und diese liefern 200 OK. Weiterleitende Einträge verschwenden Crawl-Anfragen und senden widersprüchliche Kanonisierungssignale. Lassen Sie nach jeder Migration den Sitemap-Redirect-Checker laufen, und ersetzen Sie jeden weiterleitenden Eintrag durch seine Ziel-URL.

JavaScript- und Meta-Refresh-Weiterleitungen

Google behandelt einen sofortigen Meta-Refresh als permanente Weiterleitung, einen verzögerten als temporäre. JavaScript-Weiterleitungen erkennt Google erst, nachdem die Seite gerendert wurde – ein Schritt, der nach dem Crawling erfolgt und fehlschlagen kann. Viele andere Crawler, Linkvorschau-Bots und Kommandozeilen-Tools führen überhaupt kein JavaScript aus, und manche ignorieren auch den Meta-Refresh. Setzen Sie überall dort serverseitige Weiterleitungen ein, wo Sie den Server kontrollieren, und spüren Sie clientseitige mit dem Meta-Refresh-Checker auf.

Checkliste für Weiterleitungen

Gehen Sie diese Liste nach einer Migration, nach einer CDN-Änderung oder vor dem Start einer Kampagne durch:

1. Jede alte URL erreicht ihr endgültiges Ziel mit einem einzigen Hop.
2. Dauerhafte Umzüge verwenden bei jedem Hop 301 oder 308.
3. Alle vier Protokoll- und Host-Varianten enden auf der kanonischen HTTPS-URL.
4. Kein Hop wechselt von HTTPS zu HTTP.
5. Query-Strings einschließlich UTM-Parametern und Affiliate-IDs bleiben über die gesamte Kette erhalten.
6. Jede URL existiert nur in einer Form (mit oder ohne Trailing Slash), und die andere Form leitet darauf weiter.
7. Anfragen von Desktop, Smartphone und Googlebot enden auf gleichwertigen Seiten.
8. Serverseitige Weiterleitungen ersetzen Meta-Refresh und JavaScript, wo immer es möglich ist.
9. Interne Links, Canonical-Tags, hreflang und Sitemaps verweisen auf die Ziel-URLs.
10. Entfernte Seiten ohne Ersatz liefern 404 oder 410, statt auf die Startseite weiterzuleiten.
11. Weiterleitungen aus einem Website-Umzug bleiben bestehen; Google empfiehlt mindestens ein Jahr.