Redirect-Checker

So funktioniert es

1. Jede URL wird von unserem Server mit Chrome-User-Agent abgerufen (und, falls gewählt, noch einmal als Googlebot); Redirects werden nicht automatisch verfolgt — jeder Hop ist eine eigene Anfrage, sodass Status, Location, Cache-Control und Zeit erfasst werden
2. Bis zu 10 Hops pro Kette; eine zweimal gesehene URL ist eine Schleife; 8 s pro Anfrage und 25 s pro Kette; jeder Hop durchläuft dieselben Public-Host-Prüfungen (keine privaten, Link-local- oder localhost-Ziele)
3. Nur der Body der letzten Antwort wird gelesen, nur wenn er HTML ist, begrenzt auf 256 KB — um <meta http-equiv="refresh">, Inline-Muster wie location.href / location.replace() und das <link rel="canonical"> zu finden
4. Befunde je Kette: kein Redirect / Ziel OK / Ziel-Fehler (4xx–5xx), Schleife, Hop-Limit erreicht, mehr als 3 Hops, 302 oder 307 in der Kette, 303, relative Location, http→https→www auf zwei Hops verteilt, https→http-Downgrade, Hostwechsel, Meta-Refresh, JavaScript-Redirect, Canonical weicht von Ziel-URL ab, langsame Kette (> 3 s)
5. Mit der Googlebot-Option werden beide Ketten verglichen: eine andere Ziel-URL oder ein anderer Status wird markiert — das klassische Zeichen für User-Agent-basiertes Cloaking oder einen Bot-only-Redirect
6. Bulk: bis zu 20 URLs pro Lauf, 5 parallel; die Hop-Tabelle jeder Kette lässt sich als CSV herunterladen

Über Redirects und was der Checker meldet

Ein Redirect sagt einem Client, dass die Ressource unter einer anderen URL liegt. Für Suchmaschinen trägt der Statuscode Bedeutung: 301 und 308 sagen, der Umzug ist dauerhaft, also sollen sich Rankingsignale auf dem Ziel bündeln und die alte URL kann aus dem Index fallen; 302 und 307 sagen, der Umzug ist vorübergehend, also soll die ursprüngliche URL ihren Platz behalten. Google sagt seit Jahren, dass es lang bestehende 302 in der Praxis als dauerhaft behandelt, muss aber trotzdem raten — ein 301 nimmt das Raten weg. 303 ist ein POST-zu-GET-Idiom, das bei einem Site-Umzug nichts verloren hat. Der Checker zeigt den Code jedes Hops, sodass die Absicht der Kette sichtbar ist, nicht erschlossen.

Ketten kosten Crawl-Budget und verwässern Signale mit jedem Hop ein wenig, und Googlebot gibt nach zehn auf. Der übliche Übeltäter ist nicht eine schlechte Regel, sondern mehrere richtige, gestapelt: http zu https auf dem Webserver, nicht-www zu www im CMS, ein Trailing Slash vom Framework und eine URL-Umbenennung in der Anwendung — vier Hops, wo einer reichen würde. Der Checker benennt das Muster http→https→www ausdrücklich, weil es das häufigste ist und sich am leichtesten zu einer einzigen Regel zusammenfassen lässt, die direkt zur Ziel-URL springt.

Nicht jeder Redirect ist HTTP. Eine Seite, die 200 liefert und den Besucher dann mit <meta http-equiv="refresh"> oder einer Zeile JavaScript weiterschickt, ist für den Nutzer ein Redirect, für einen Crawler ohne Skriptausführung aber eine normale Seite — und Google, das JavaScript rendert, wertet diese Fälle als schwache Signale im Vergleich zu einem serverseitigen 301. Der Checker liest das Ziel-HTML auf beide Muster und meldet sie; er folgt ihnen nicht, denn genau das ist der Punkt: HTTP-Kette und echtes Ziel weichen voneinander ab.

Der Abruf als Googlebot neben dem Browser fängt zwei Probleme auf einmal. Bot-only-Redirects — Crawler auf eine andere Seite zu schicken als Nutzer — verstoßen gegen Googles Cloaking-Richtlinie, ob beabsichtigt oder nicht (eine fehlkonfigurierte Bot-Schutz- oder Geo-Regel genügt). Und manche Sites leiten Browser nach Sprache oder Land um, lassen Googlebot aber auf der Standardversion, was in Ordnung ist, aber bekannt sein sollte. Der Checker vergleicht Ziel-URL und Status beider Agents und sagt, ob sie übereinstimmen. Was mit einem Unterschied zu tun ist, hängt davon ab, warum er existiert; der Checker meldet ihn.

Häufige Fragen

301 oder 308?

Beide sind dauerhaft. 308 verbietet dem Client zusätzlich, die Methode zu ändern (ein POST bleibt ein POST), was für APIs und Formulare zählt, nicht für Seiten. Für Site-Umzüge wird 301 überall verstanden; 308 geht ebenfalls. Google behandelt beide für die Indexierung gleich.

Schadet ein 302 der SEO?

Nicht zwangsläufig. Google hat erklärt, dass es einen dauerhaft bestehenden 302 nach einer Weile als permanent behandelt und Signale in beiden Fällen bündelt. Das Problem ist die Mehrdeutigkeit: Ein 302 sagt „vorübergehend“, also kann die Suchmaschine bei einer Migration die alte URL länger im Index halten, als Sie möchten. Ist der Umzug dauerhaft, sagen Sie es mit einem 301 — der Checker markiert 302/307 in einer Kette, damit Sie entscheiden können.

Wie viele Hops sind zu viele?

Google folgt bis zu 10 Redirects pro Kette; darüber hinaus wird die Seite nicht gecrawlt. Jeder Hop kostet Nutzer Latenz und die Suche ein wenig Signal, also lautet die Faustregel ein Hop, höchstens zwei. Der Checker warnt ab mehr als drei. Beheben Sie Ketten, indem Sie die erste URL direkt auf die letzte leiten, nicht indem Sie Zwischenregeln entfernen, die andere URLs noch brauchen.

Warum meldet der Checker ein abweichendes Canonical auf der Zielseite?

Weil das HTML, auf dem die Kette endet, mit <link rel="canonical"> auf eine andere URL zeigt als die, auf der Sie gelandet sind. Ein Redirect auf Seite B, deren Canonical Seite C nennt, erzählt Google zwei verschiedene Geschichten. Meist ist eine von beiden nach einer Migration veraltet; der Checker meldet die Abweichung und beide URLs.

Was ist eine Redirect-Schleife, und warum stoppt der Checker früh?

Eine Schleife ist eine Kette, die zu einer bereits besuchten URL zurückkehrt — A zu B zu A. Browser zeigen einen Fehler, Crawler geben auf. Der Checker stoppt, sobald sich eine URL wiederholt, und markiert die Kette als Schleife; er stoppt außerdem bei 10 Hops, ob Schleife oder nicht, weil Googlebot das auch tut.

Warum als Googlebot abrufen?

Manche Sites — absichtlich oder durch eine fehlkonfigurierte Regel — schicken Crawler woandershin als Browser. Googlebot auf eine andere Seite als Nutzer umzuleiten ist Cloaking nach Googles Spam-Richtlinien; Browser nach Sprache umzuleiten und Bots auf der Standardversion zu lassen ist üblich und akzeptabel, aber gut zu wissen. Der Checker führt die Kette zweimal mit beiden User-Agents aus und meldet, ob Ziel-URL und Status übereinstimmen. Beachten Sie, dass manche Bot-Schutzdienste jeden blockieren, der sich von einer nicht verifizierten IP als Googlebot ausgibt — ein 403 im Bot-Lauf kann das sein, nicht eine Redirect-Regel.

Folgt der Checker Meta-Refresh- oder JavaScript-Redirects?

Nein. Er erkennt sie im Ziel-HTML und meldet das Ziel, aber die gezeigte Kette ist die HTTP-Kette — das, was ein Crawler ohne Skriptausführung sieht. Google rendert JavaScript und behandelt diese Fälle als Redirects, aber langsamer und mit weniger Sicherheit als einen serverseitigen 301. Meldet das Tool einen, liegt das echte Ziel einen Schritt weiter als die Tabelle zeigt.