Weitergeleitet, aber nicht sauber: Was Redirect-Ketten nach einem Relaunch kosten

Ein Relaunch ist abgeschlossen, alle alten URLs werden weitergeleitet und im Browser landet man am richtigen Ziel. Klingt sauber.

Aber was, wenn eine alte Produktseite erst von HTTP auf HTTPS, dann von www auf die Hauptdomain, anschließend auf eine neue Kategorie und von dort noch einmal auf die endgültige Detailseite springt?

Für Nutzer ist das eine kurze Verzögerung. Für Suchmaschinen, Analytics, Bots, APIs und den laufenden Betrieb ist es eine Kette aus zusätzlichen Requests, mehr Fehlerquellen und schlechter nachvollziehbaren Signalen.

Die entscheidende Frage lautet deshalb nicht nur: Gibt es einen Redirect?

Sondern: Führt jede wichtige alte URL direkt, dauerhaft und fachlich passend zum endgültigen Ziel?

Warum Redirect-Ketten entstehen

Redirect-Ketten sind selten geplant. Sie wachsen über Jahre:

• HTTP wurde später auf HTTPS umgestellt.
• www und non-www wurden vereinheitlicht.
• Ein CMS-Relaunch änderte die Pfade.
• Kategorien wurden umbenannt.
• Produkte oder Leistungen wurden zusammengelegt.
• Sprachversionen erhielten neue URL-Strukturen.
• Ein CDN, Reverse Proxy und die Anwendung setzen jeweils eigene Regeln.
• Alte Agenturregeln blieben aktiv, obwohl die neue Plattform längst andere Ziele nutzt.

Jede einzelne Regel kann einmal richtig gewesen sein. Zusammen ergeben sie jedoch einen Umweg.

Beispiel:

http://example.de/leistung-alt → https://www.example.de/leistung-alt → https://example.de/services/leistung-alt → https://example.de/leistungen/neuer-name

Das Endziel ist korrekt. Der Weg dorthin ist unnötig lang.

Was daran praktisch problematisch ist

1. Jeder Sprung kostet Zeit

Ein Redirect erzeugt einen zusätzlichen Request-Response-Zyklus. Auf schnellen Desktop-Verbindungen fällt das kaum auf. Auf Mobilfunk, bei hoher Latenz oder in internationalen Zielmärkten summiert sich jeder Sprung.

Besonders teuer sind Ketten vor kritischen Ressourcen oder Landingpages, etwa bei Anzeigen-URLs, QR-Codes, E-Mail-Kampagnen, Login- und Passwort-Links, Tracking-Links, Dokumenten, API-Endpunkten sowie Canonicals und hreflang-Zielen.

2. Fehler verstecken sich hinter scheinbarem Erfolg

Ein Browser folgt Redirects automatisch. Deshalb wirkt eine URL oft funktionierend, obwohl unterwegs ein temporärer statt permanenter Statuscode, ein falscher Host, eine Schleife, ein totes Zwischenziel oder der Verlust von Query-Parametern steckt. Wer nur die finale Seite ansieht, übersieht die Kette.

3. Migrationen werden schwerer nachvollziehbar

Google empfiehlt für Site-Moves eine klare URL-Zuordnung von alten zu neuen Adressen, passende permanente Redirects und direkte Tests der Regeln. Viele alte URLs pauschal auf die Startseite umzuleiten, kann Nutzer verwirren und als Soft-404 behandelt werden.

Je mehr Zwischenschritte bestehen, desto schwieriger wird es zu erkennen, welche Regel noch notwendig ist, welche nur ein Überrest früherer Migrationen darstellt und welche externen Links auf veraltete Zwischenziele zeigen.

4. Analytics und Attribution werden unklar

Ketten können Kampagnenparameter, Referrer oder interne Tracking-Informationen verändern oder verlieren, insbesondere wenn Regeln Query-Strings nicht sauber übernehmen. Marketing sieht dann möglicherweise Besuche, aber nicht mehr zuverlässig, woher sie kamen.

5. Formulare und Methoden können betroffen sein

HTTP unterscheidet zwischen permanenten und temporären Redirects sowie zwischen Statuscodes, die Methoden erhalten oder verändern können. 307 und 308 erhalten Methode und Request-Body. Bei anderen Redirects können Clients unter bestimmten Umständen aus einem POST einen GET machen. Für Formulare, Uploads, Webhooks und APIs ist die Wahl des Statuscodes deshalb eine echte Funktionsfrage.

Die wichtigsten Statuscodes in der Praxis

301 und 308: dauerhaft verschoben

Für dauerhaft geänderte URLs sind permanente Redirects passend. 308 erhält Methode und Body ausdrücklich. 301 wird bei gewöhnlichen GET-Seiten breit eingesetzt, kann aber bei älteren Clients methodenseitig anders behandelt werden.

302 und 307: vorübergehend verschoben

Temporäre Redirects signalisieren, dass die ursprüngliche URL weiterhin maßgeblich bleibt. 307 erhält Methode und Body. Ein dauerhaft umgezogener Inhalt sollte nicht aus Bequemlichkeit jahrelang über 302 laufen.

303: Ergebnis an anderer Stelle abrufen

303 See Other ist sinnvoll, wenn nach einer Aktion bewusst ein GET auf eine andere Ressource erfolgen soll, etwa nach einer Formularübermittlung.

Acht Red Flags in einem Redirect-Audit

1. Eine URL benötigt mehr als einen Redirect bis zum Ziel.
2. Alte Seiten werden pauschal auf die Startseite geschickt.
3. Permanente Umzüge verwenden dauerhaft 302 oder 307.
4. Interne Links zeigen weiterhin auf alte URLs.
5. Sitemap, Canonical oder hreflang enthalten Redirect-Ziele statt finaler URLs.
6. Query-Parameter gehen unterwegs verloren oder werden doppelt angehängt.
7. HTTP, HTTPS, www und non-www verhalten sich je nach Pfad unterschiedlich.
8. Alte Assets, PDFs oder Kampagnenlinks enden in 404, Schleifen oder fachlich falschen Seiten.

So prüfen Sie Redirects systematisch

1. URL-Inventar erstellen

Sammeln Sie nicht nur aktuelle Sitemap-URLs. Berücksichtigen Sie auch frühere Sitemaps, Analytics-Landingpages, Search-Console-Daten, Backlinks, Kampagnen, PDFs, QR-Codes, CMS-Exporte sowie bekannte URL-Muster früherer Systeme.

2. Jede URL bis zum Endpunkt verfolgen

Dokumentieren Sie ersten Statuscode, jede Zwischenstation, finale URL, finale Antwort, Anzahl der Sprünge, Erhalt von Query-Parametern und fachliche Passung. Das Ziel ist nicht irgendwann 200, sondern möglichst ein direkter permanenter Sprung auf eine passende 200-Seite.

3. Interne Signale aktualisieren

Auch wenn Redirects funktionieren, sollten interne Links, Sitemap, Canonicals, hreflang, strukturierte Daten und Kampagnen direkt auf finale URLs zeigen. Redirects sind ein Sicherheitsnetz für alte Verweise, kein Ersatz für saubere aktuelle Verlinkung.

4. Regeln konsolidieren

Wenn CDN, Load Balancer, Reverse Proxy, Hosting, Framework, CMS und Anwendung Redirects setzen können, muss klar dokumentiert sein, welche Ebene wofür verantwortlich ist. Doppelte Verantwortung erzeugt widersprüchliche Regeln und schwer reproduzierbare Fehler.

5. Nach Deployments erneut testen

Redirects brechen häufig Monate nach dem Relaunch: Eine Route wird entfernt, Sprachlogik ändert sich, ein Proxy wird ersetzt oder ein Hosting-Wechsel übernimmt nur einen Teil der Konfiguration. Wichtige Alt-URLs gehören deshalb in automatisierte Regressionstests.

Was Website-Pflichtencheck prüfen würde

Ein Redirect- und Migrationscheck kann alte und aktuelle URL-Muster, Ketten und Schleifen, Statuscodes, Query-Strings, Host-Konsistenz, fachliche Zielpassung, interne Links, Sitemap, Canonicals, hreflang, PDFs, Kampagnenziele, Infrastrukturregeln sowie 404- und Soft-404-Risiken untersuchen.

Das Ergebnis sollte priorisieren, welche Ketten Reichweite oder Ladezeit kosten, welche Kampagnendaten verlieren und welche echte Funktionen beschädigen können.

Ein guter Redirect ist unspektakulär. Er führt eine alte Adresse direkt, dauerhaft und nachvollziehbar zum passenden neuen Inhalt.

Wenn Ihre Migration nur deshalb funktioniert, weil Browser geduldig mehrere historische Entscheidungen hintereinander abarbeiten, ist sie noch nicht aufgeräumt.