301-Weiterleitung prüfen: jede Redirect-Kette nachverfolgen

Ein Redirect Checker zeigt, was zwischen dem Klick auf einen Link und dem Laden einer Seite wirklich passiert. Jede URL, die du eingibst, wird von Marqlys Server mit abgeschalteten automatischen Weiterleitungen abgerufen. So wird jede Antwort einzeln festgehalten: der Statuscode, derLocation-Header, auf den sie zeigt, wie lange sie gedauert hat, und die Header, die für SEO zählen. Danach folgt das Tool dieser Location und wiederholt den Vorgang, bis zu 10 Weiterleitungen, dasselbe Limit, das die Google-Crawler standardmäßig nutzen. Du bekommst die komplette Weiterleitungskette, die finale URL samt Status und verständliche Warnungen zu Schleifen, vorübergehenden Weiterleitungen, langsamen Hops, verlorenen Tracking-Parametern und Ketten, die du zusammenfassen solltest.

So prüfst du eine Weiterleitung

1. Füge eine URL in das Feld ein. Für eine Sammelprüfung fügst du bis zu 10 URLs ein, eine pro Zeile.
2. Wähle bei Bedarf einen User-Agent. Standardmäßig gibt sich das Tool als Marqly Checker zu erkennen; du kannst aber auch den User-Agent von Chrome, Safari auf dem iPhone, Googlebot Smartphone oder Googlebot Desktop senden, um Regeln zu finden, die Browser, Handys und Crawler unterschiedlich behandeln.
3. Setze das Häkchen bei Auch die Varianten mit http/https und www/ohne www prüfen, um alle vier Schreibweisen derselben Adresse auf einmal zu testen. Schneller lässt sich nicht bestätigen, dass eine Website genau einen kanonischen Hostnamen hat und jede Variante ihn mit einem einzigen Hop erreicht.
4. Klicke auf Weiterleitungen prüfen. Jede URL bekommt eine eigene Karte mit Ergebnis, Hinweisen und der Kette Hop für Hop.
5. Nutze Ergebnisse kopieren für einen Textbericht, CSV herunterladen für eine Tabelle mit einer Zeile pro Hop oder Link zum Teilen kopieren, um einen Link zu verschicken, der dieselbe Prüfung erneut ausführt.

So liest du die Ergebnisse

Jede Karte beginnt mit dem finalen Statuscode, der eingegebenen URL, der Zahl der Weiterleitungen, der Gesamtzeit und der finalen URL. Darunter markieren Hinweise, was Aufmerksamkeit verdient: von Fehlern (Schleifen, Ketten über dem Limit, eine Kette, die auf einem 404 endet) über Warnungen (vorübergehende Weiterleitungen, Meta-Refreshes, ein Wechsel von HTTPS zurück auf HTTP, verlorene Query-Parameter, einX-Robots-Tag: noindex auf der finalen Seite) bis zu neutralen Notizen (Änderungen beim abschließenden Schrägstrich oder bei www, ein Wechsel auf eine andere Domain, langsame Hops).

Die Kettentabelle listet jede Anfrage der Reihe nach. Status ist der HTTP-Statuscode, den der Server zurückgegeben hat. URL ist die angefragte Adresse und darunter das Ziel, zu dem dieser Hop den Client als Nächstes schickt, bereits in eine absolute Adresse umgewandelt, falls der Server eine relative Location gesendet hat. Zeit ist die Dauer, bis der Server die Header für diesen Hop geliefert hat. Öffne bei einer beliebigen Zeile Header, umLocation, Cache-Control, Content-Type, X-Robots-Tag,Link (hier kann ein Canonical angegeben werden), Strict-Transport-Security,X-Redirect-By (WordPress und manche Plugins nennen sich hier) und Server zu sehen. Cookie-Werte werden nie angezeigt, nur wie viele gesetzt wurden.

301, 302, 307 und 308: was die Statuscodes bedeuten

HTTP definiert die Weiterleitungs-Statuscodes in RFC 9110, Abschnitt 15.4. Zwei Fragen unterscheiden sie: Ist der Umzug dauerhaft, und darf der Client beim Folgen der Weiterleitung die Anfragemethode ändern (zum Beispiel aus einem Formular-POST ein GET machen)? GooglesDokumentation zu HTTP-Statuscodeserklärt, wie Crawler und Indexierung jeden davon behandeln.

Für normale Seiten nutzt du 301, wenn Inhalte endgültig umgezogen sind: ein geänderter Slug, zusammengelegte Artikel, ein Domainumzug, die Umstellung auf HTTPS. Nimm 302 oder307, wenn die ursprüngliche URL zurückkommt, etwa bei einer Wartungsseite, einer kurzen Kampagne oder einem Test. Greif zu 308, wenn die Methode zählt, zum Beispiel bei einem API-Endpunkt oder einem Formular, das POST-Anfragen empfängt: RFC 9110 erlaubt Clients, bei 301 und 302 aus einem weitergeleiteten POST ein GET zu machen, verbietet es aber bei 307 und 308.

Meta-Refresh und JavaScript-Weiterleitungen

Googles Leitfaden zu Weiterleitungenempfiehlt nach Möglichkeit eine dauerhafte serverseitige Weiterleitung. Ein sofortiger Meta-Refresh gilt dort als dauerhafte Weiterleitung, ein verzögerter als vorübergehende. JavaScript-Weiterleitungen rät Google nur, wenn weder serverseitige Weiterleitungen noch Meta-Refresh möglich sind, weil das Rendern fehlschlagen kann. Dieser Checker folgt Meta-Refresh-Tags und dem Refresh-Header und kennzeichnet sie, führt aber kein JavaScript aus.

Was ist eine Weiterleitungskette, und warum schadet sie?

Eine Weiterleitungskette ist jeder Pfad mit mehr als einem Hop: http://example.com/seite →https://example.com/seite → https://www.example.com/seite →https://www.example.com/seite/. Solche Ketten entstehen selten absichtlich. Sie wachsen, wenn eine Website auf HTTPS umzieht, sich für oder gegen www entscheidet, das CMS wechselt, Bereiche umbenennt und alte Weiterleitungen weiterleitet, statt sie umzuschreiben. Jede Schicht funktioniert für sich; zusammen summieren sie sich.

• Geschwindigkeit. Jeder Hop ist eine weitere vollständige Anfrage, bevor die Seite überhaupt zu laden beginnt, und ein Hop auf einen neuen Hostnamen kostet zusätzlich einen DNS-Lookup und einen TLS-Handshake. Die Zeitspalte zeigt, was jeder Hop kostet.
• Crawling. Laut Google folgen die Crawler standardmäßig bis zu 10 Weiterleitungs-Hops, und der Bericht zur Seitenindexierung führt eine zu lange Weiterleitungskette, eine Weiterleitungsschleife und eine fehlerhafte oder leere URL in der Kette als Weiterleitungsfehler. Googles Leitfaden zum Website-Umzugrät, direkt auf das endgültige Ziel weiterzuleiten, und weist darauf hin, dass Ketten die Latenz erhöhen und nicht alle User-Agents und Browser lange Ketten unterstützen.
• Andere Clients. RFC 9110 merkt an, dass eine frühere HTTP-Spezifikation höchstens fünf Weiterleitungen empfahl und manche Clients ein festes Limit dieser Art noch immer durchsetzen. Eine Kette, die Googlebot toleriert, kann also für andere Software trotzdem abbrechen.
• Fehleranfälligkeit und Datenverlust. Jeder Hop ist eine weitere Regel, die bearbeitet, gelöscht oder von einer anderen überdeckt werden kann. Ein Hop, der die URL neu zusammensetzt, kann still und leise den Query-String verlieren. Genau so verschwinden UTM-Parameter, bevor die Webanalyse sie je sieht. Der Checker warnt, wenn ein Parameter aus deiner ursprünglichen URL in der finalen fehlt.

So behebst du eine Weiterleitungskette

1. Finde die finale URL. Prüfe die alte URL mit dem Checker und kopiere die letzte URL der Kette.
2. Lass die erste Weiterleitung direkt auf die finale URL zeigen. Leitet A auf B weiter und B auf C, ändere die Regel für A so, dass sie direkt zu C führt, und behalte B → C für alle, die noch B aufrufen. In einer Redirect-Map oder einem Plugin suchst du nach Regeln, deren Ziel selbst Quelle einer anderen Regel ist.
3. Fasse Protokoll- und Hostnamen-Regeln zusammen. Die häufigste Kette ist http → https, gefolgt von ohne www → www. Schreib eine Regel, die jede Variante in einem Schritt auf die kanonische Form schickt, wie in diesem nginx-Beispiel:

# Ein Hop von jeder Variante zu https://www.example.com
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-Zeilen ausgelassen
    return 301 https://www.example.com$request_uri;
}

4. Aktualisiere Links an der Quelle. Stell interne Links, Canonical-Tags, hreflang-Angaben und XML-Sitemaps auf die finalen URLs um; auch Googles Leitfaden zum Website-Umzug verlangt, interne Links auf die neuen URLs zu aktualisieren. Weiterleitungen sollen alte Links von anderswo auffangen, nicht deine eigene Navigation tragen.
5. Behalte die Weiterleitungen. Google empfiehlt, Weiterleitungen so lange wie möglich beizubehalten, in der Regel mindestens ein Jahr. Eine Kette zusammenzufassen heißt, ihre Ziele zu ändern, nicht die alten Regeln zu löschen.
6. Teste erneut. Prüfe dieselben URLs noch einmal, am besten mit aktivierter Variantenprüfung, und bestätige, dass jede in einem Hop eine 200-Seite erreicht.

Weiterleitungsschleifen beheben

Eine Schleife ist eine Kette, die zu einer bereits besuchten URL zurückkehrt und deshalb nie endet; Browser melden dann einen Fehler wegen zu vieler Weiterleitungen. Meist streiten sich zwei Ebenen: ein CDN, das per HTTP mit dem Ursprungsserver spricht, während der Ursprungsserver HTTPS erzwingt; eine Regel für den abschließenden Schrägstrich im Webserver, die gegen die umgekehrte Regel in der Anwendung kämpft; oder www-Regeln, die sowohl in einer DNS-Weiterleitung als auch auf der Website gesetzt sind. Sieh dir den Hop an, an dem die URL zurückspringt; seine Header Server und X-Redirect-By verraten oft, welche Ebene ihn gesendet hat. Manche Schleifen treten nur ohne Cookies auf (Consent- oder Login-Weiterleitungen) und betreffen Besucher nicht, die diese Cookies schon haben; der Checker sendet keine Cookies und macht auch diese Fälle sichtbar.

Mehrere Weiterleitungen auf einmal prüfen

Füge bis zu 10 URLs ein, eine pro Zeile, um sie in einem Durchgang zu prüfen; Duplikate werden entfernt, und jede URL bekommt ein eigenes Ergebnis. Der CSV-Export enthält eine Zeile pro Hop, jeweils mit der eingegebenen URL. So kannst du nach Status filtern, nach Zahl der Hops sortieren oder die Datei an die Person weitergeben, die die Weiterleitungsregeln verwaltet. Willst du alte Lesezeichen prüfen, exportierst du sie zuerst aus dem Browser; wie das geht, steht in unserer Anleitung zumExportieren von Chrome-Lesezeichen. Für eine komplette Website findest du weitergeleitete URLs mit einem Crawler oder in deinen Server-Logs und prüfst die wichtigen dann hier stichprobenartig mit dem Googlebot-User-Agent.

HTTPS, www und abschließender Schrägstrich

Die meisten Websites sollten unter genau einer Kombination aus Protokoll und Hostname antworten, und jede andere Form sollte dauerhaft und in einem Hop dorthin weiterleiten. Die Variantenprüfung testethttp://example.com, https://example.com, http://www.example.com undhttps://www.example.com mit demselben Pfad und meldet, ob alle vier auf derselben URL enden und wie viele Hops jede braucht. Die Hinweise zeigen eine HTTPS-Umstellung, die erst spät in der Kette passiert, eine Kette, die mehr als einmal zwischen www und ohne www wechselt, und Hops, die nur einen abschließenden Schrägstrich hinzufügen oder entfernen oder die Groß- und Kleinschreibung ändern. Solche Hops lassen sich mit wenig Aufwand in die erste Weiterleitung einbauen.

Warum die Ergebnisse von deinem Browser abweichen können

Landet dein Browser woanders, merkt er sich meistens etwas. RFC 9110 erlaubt, eine 301 zu cachen; ein Browser überspringt daher womöglich eine alte Weiterleitung oder folgt weiter einer, die du längst entfernt hast. Hat ein Browser den HSTS-Header einer Website einmal gesehen (oder steht die Website auf der HSTS-Preload-Liste), stellt er http:// intern auf https:// um, bevor überhaupt eine Anfrage deinen Rechner verlässt. Cookies, deine Sprache und dein Standort können eigene Weiterleitungen auslösen. Der Checker startet jedes Mal ohne Altlasten und meldet, was der Server sendet. Genau diese Sicht zählt für Crawler und für Erstbesucher.

So funktioniert der Checker

Jeder Hop ist eine GET-Anfrage von Marqlys Server bei Cloudflare mit manueller Behandlung von Weiterleitungen; nichts wird verfolgt, bevor der Checker es festgehalten hat. Jeder Hostname wird aufgelöst und muss auf eine öffentliche Adresse zeigen; private Netze, localhost und Cloud-Metadaten-Adressen werden abgelehnt, auch wenn eine Weiterleitung mitten in der Kette auf sie zeigt. Jeder Hop hat ein Timeout von 6 Sekunden, eine ganze Kette stoppt nach 20 Sekunden oder 10 Weiterleitungen, und Seiteninhalte werden verworfen, bis auf die ersten 64 KB einer finalen HTML-Seite, die nach einem Meta-Refresh durchsucht werden. Gespeichert wird nichts: Die Ergebnisse existieren nur in deinem Browser-Tab.

Wenn du Kampagnen-Links baust, erstellt sie unser UTM-Generator, und dieser Checker bestätigt, dass die Parameter jeden Hop überleben. Arbeitest du im Marketing mit vielen Links, zeigt die Seite Marqly für Marketing, wie du Landingpages, Kampagnen-Assets und Recherche an einem Ort sammelst. Und für Entwicklerinnen und Entwickler, die Dokumentation, Issues und Referenzen ablegen wollen, gibt es Marqly für Entwickler.