HTTP-Weiterleitungen: Schleifen, Ketten und verdaechtige Links erkennen

Von CaptainDNS
Veröffentlicht am 20. März 2026

Schema einer HTTP-Weiterleitungsschleife mit Erkennung und Loesung

TL;DR

Weiterleitungsschleifen (ERR_TOO_MANY_REDIRECTS) entstehen durch zirkuläre Konfigurationen zwischen Servern, CDNs oder CMS.
Übermäßige Weiterleitungsketten (mehr als 3 Hops) verwässern die SEO und fügen pro Hop 100 bis 500 ms Latenz hinzu.
Kurzlinks (bit.ly, t.co) verbergen das tatsächliche Ziel und können auf Phishing-Seiten führen.
Der Redirect Checker von CaptainDNS erkennt alle drei Probleme automatisch in einer einzigen Analyse.
Google folgt maximal 10 Weiterleitungen. Darüber hinaus wird die Seite nicht indexiert.

Du klickst auf einen Link und dein Browser zeigt ERR_TOO_MANY_REDIRECTS. Oder die Seite lädt schließlich, aber erst nach einer verdächtigen Verzögerung von mehreren Sekunden. Oder ein Kollege schickt dir einen bit.ly-Kurzlink und du zögerst, bevor du klickst. Diese drei Situationen haben eines gemeinsam: Sie beinhalten HTTP-Weiterleitungen, die niemand sieht, die aber schwerwiegende Probleme verbergen können.

Weiterleitungen sind ein grundlegender Mechanismus des Webs. Sie ermöglichen das Verschieben von Seiten, das Erzwingen von HTTPS und die Verwaltung von Vanity-URLs. Aber wenn sie falsch konfiguriert sind, entstehen drei verschiedene Kategorien von Problemen. Schleifen verhindern den Zugriff auf die Seite vollständig. Übermäßige Ketten verschlechtern SEO und Performance, ohne dass der Besucher es bemerkt. Kurzlinks verbergen das tatsächliche Ziel und dienen laut Untersuchungen von Palo Alto Networks zu kürzlich registrierten Domains (NRD) in 1 von 10 Fällen als Phishing-Vektor.

Dieser Leitfaden behandelt die Diagnose und Behebung dieser drei Probleme. Jeder Abschnitt erklärt den technischen Mechanismus, die beobachtbaren Symptome und die konkreten Schritte zur Lösung. Ziel ist es, dich in die Lage zu versetzen, jedes Weiterleitungsproblem selbstständig zu erkennen und zu beheben, egal ob du Systemadministrator, Entwickler oder SEO-Verantwortlicher bist.

Analysiere deine URLs jetzt

Mit dem Redirect Checker testen Verdächtigen Link prüfen

Was ist eine Weiterleitungsschleife?

Eine Weiterleitungsschleife entsteht, wenn URL A auf URL B weiterleitet, die wiederum auf URL A zurückleitet. Der Browser folgt den Weiterleitungen im Kreis, ohne jemals eine Inhaltsseite zu erreichen. Nach einer bestimmten Anzahl von Versuchen gibt er auf und zeigt eine Fehlermeldung an.

Der einfachste Fall ist ein Zyklus mit zwei Elementen: A leitet auf B weiter, B leitet auf A weiter. Aber Schleifen können drei, vier oder fünf Zwischen-URLs umfassen, bevor sie zum Ausgangspunkt zurückkehren.

Wie reagiert der Browser auf eine Schleife?

Jeder Browser hat ein Limit für die Anzahl der Weiterleitungen, denen er folgt, bevor er aufgibt. Wenn dieses Limit erreicht ist, zeigt der Browser eine spezifische Fehlermeldung an.

Browser	Weiterleitungslimit	Fehlermeldung
Chrome	20	`ERR_TOO_MANY_REDIRECTS`
Firefox	20	"Die Seite wird nicht richtig weitergeleitet"
Safari	16	"Safari kann die Seite nicht öffnen"
Edge	20	`ERR_TOO_MANY_REDIRECTS`

Der Browser unterscheidet nicht zwischen einer Schleife (Zyklus) und einer sehr langen Kette (lineare Sequenz). In beiden Fällen wird die Anzeige blockiert, wenn das Limit erreicht ist. Der Unterschied: Eine lange Kette würde zum Ziel führen, wenn man das Limit erhöht, während eine Schleife niemals endet.

Aus der Sicht von Googlebot ist eine Schleife fatal für die Indexierung. Google erkennt den Zyklus, markiert die Seite als nicht erreichbar, und alle Backlinks, die darauf verweisen, verlieren ihren SEO-Wert.

Anatomie einer Schleife: der HTTP-Zyklus im Detail

Hier ist der detaillierte Ablauf einer Schleife mit drei Elementen auf Netzwerkebene.

1. GET https://captaindns.com/page-a
   → 301, Location: https://captaindns.com/page-b

2. GET https://captaindns.com/page-b
   → 302, Location: https://captaindns.com/page-c

3. GET https://captaindns.com/page-c
   → 301, Location: https://captaindns.com/page-a

4. GET https://captaindns.com/page-a   (zurück zum Ausgangspunkt)
   → 301, Location: https://captaindns.com/page-b

... (der Zyklus wiederholt sich)

Jede Iteration verbraucht eine Netzwerkanfrage. Chrome und Firefox brechen nach 20 Anfragen ab, also nach 6 bis 7 vollständigen Durchläufen in einer 3-Elemente-Schleife. Der Location-Header ist der rote Faden: Durch sein Verfolgen rekonstruieren Diagnosetools die Kette und erkennen den Rückkehrpunkt.

Schema einer Weiterleitungsschleife mit 3 Elementen, die den Zyklus A nach B nach C nach A mit der Anzahl der Anfragen bis zum Browserfehler zeigt

Die 7 häufigsten Ursachen für ERR_TOO_MANY_REDIRECTS

Weiterleitungsschleifen sind fast nie beabsichtigt. Sie entstehen durch Konflikte zwischen mehreren Komponenten, die jeweils versuchen, eine Weiterleitung zu erzwingen. Hier sind die 7 häufigsten Ursachen, sortiert nach Häufigkeit.

1. Konflikt HTTP/HTTPS zwischen CMS und Server

Symptom: Die Website zeigt ERR_TOO_MANY_REDIRECTS bereits auf der Startseite.

Mechanismus: Das CMS (WordPress, Joomla) ist so konfiguriert, dass es HTTPS in seinen internen Einstellungen erzwingt. Gleichzeitig enthält die .htaccess-Datei oder die Nginx-Konfiguration eine Regel, die HTTP auf HTTPS umleitet. Wenn das CMS auf HTTPS umleitet und der Server diese Anfrage auf HTTP umleitet (oder umgekehrt wegen eines Zwischenproxys), entsteht eine Schleife.

Diagnose: Überprüfe die Website-URL in den CMS-Einstellungen (siteurl und home in WordPress). Vergleiche sie mit den Weiterleitungsregeln des Webservers. Wenn beide das Protokoll in entgegengesetzte Richtungen erzwingen, hast du die Ursache gefunden.

Korrektur: Wähle einen einzigen Kontrollpunkt für die HTTP-zu-HTTPS-Weiterleitung. Best Practice ist, diese Weiterleitung auf Ebene des Webservers (Nginx, Apache) oder des Reverse Proxys zu verwalten und das CMS so zu konfigurieren, dass es HTTPS in seiner URL verwendet, ohne die Weiterleitung selbst zu erzwingen.

2. Zirkuläre www/non-www-Weiterleitung

Symptom: ERR_TOO_MANY_REDIRECTS nur bei der www- oder der non-www-Variante der Domain.

Mechanismus: Der DNS-Eintrag verweist www.captaindns.com auf Server A und captaindns.com auf Server B. Server A leitet auf die non-www-Version um, Server B leitet auf die www-Version um. Der Browser springt endlos zwischen beiden hin und her.

Diagnose: Teste beide Varianten separat mit curl -I http://www.captaindns.com und curl -I http://captaindns.com. Wenn jede auf die andere umleitet, ist die Schleife bestätigt.

Korrektur: Richte die Konfiguration beider Server auf eine einzige kanonische Version aus. Wenn du captaindns.com als kanonische Version wählst, konfiguriere www.captaindns.com für eine 301-Weiterleitung auf captaindns.com und stelle sicher, dass captaindns.com nicht auf www umleitet.

3. WordPress-Cache- oder Sicherheitsplugin

Symptom: ERR_TOO_MANY_REDIRECTS nach der Installation oder Aktualisierung eines Plugins.

Mechanismus: Bestimmte Sicherheitsplugins (Really Simple SSL, Wordfence) oder Cache-Plugins (W3 Total Cache, WP Super Cache) fügen eigene Weiterleitungsregeln in der .htaccess oder über PHP-Filter hinzu. Diese Regeln können mit bestehenden Weiterleitungen des Themes, des CMS oder des Servers in Konflikt geraten.

Diagnose: Deaktiviere die Plugins einzeln per FTP (benenne den Plugin-Ordner in wp-content/plugins/ um). Wenn die Website wieder erreichbar ist, ist das zuletzt deaktivierte Plugin der Verursacher.

Korrektur: Reaktiviere das Plugin und passe seine Einstellungen an, um den Konflikt zu vermeiden. Wenn das Plugin HTTPS erzwingt und dein Server das bereits tut, deaktiviere diese Funktion im Plugin. Wenn das Plugin .htaccess-Regeln hinzufügt, überprüfe, ob sie bestehende Regeln nicht duplizieren.

4. Cloudflare Flexible SSL kombiniert mit erzwungenem HTTPS auf dem Server

Symptom: ERR_TOO_MANY_REDIRECTS nach der Aktivierung von Cloudflare.

Mechanismus: Der Modus "Flexible SSL" von Cloudflare bedeutet, dass die Verbindung zwischen Besucher und Cloudflare HTTPS ist, aber die Verbindung zwischen Cloudflare und deinem Server HTTP ist. Wenn dein Server so konfiguriert ist, HTTP auf HTTPS umzuleiten, leitet er die Anfrage von Cloudflare auf HTTPS um. Cloudflare empfängt diese Weiterleitung, sendet die Anfrage aber im HTTP-Modus (Flexible) zurück. Der Server leitet wieder auf HTTPS um, und so weiter.

Diagnose: Überprüfe den SSL/TLS-Modus im Cloudflare-Dashboard. Wenn er auf "Flexible" steht und dein Server HTTPS erzwingt, hast du die Ursache gefunden.

Korrektur: Stelle den SSL/TLS-Modus von Cloudflare auf "Full" oder "Full (Strict)". Im Full-Modus kommuniziert Cloudflare über HTTPS mit deinem Server, was den Konflikt beseitigt. Stelle sicher, dass dein Server ein gültiges TLS-Zertifikat besitzt (Let's Encrypt reicht aus).

5. Beschädigte Cookies oder Authentifizierungsschleife

Symptom: ERR_TOO_MANY_REDIRECTS nur für bestimmte Benutzer oder nur im eingeloggten Zustand.

Mechanismus: Die Anwendung leitet nicht eingeloggte Benutzer zur Login-Seite weiter. Die Login-Seite prüft ein Session-Cookie, erkennt, dass der Benutzer nicht eingeloggt ist (Cookie beschädigt, abgelaufen oder falsch formatiert), und leitet zur Login-Seite selbst weiter. Oder nach dem Login leitet die Anwendung auf eine geschützte Seite weiter, die das Cookie nicht erkennt und zurück zum Login verweist.

Diagnose: Teste die Website im privaten Browsermodus (ohne Cookies). Wenn das Problem verschwindet, sind die Cookies die Ursache. Bitte den betroffenen Benutzer, die Cookies für die Domain zu löschen.

Korrektur: Wenn das Problem weit verbreitet ist, überprüfe die Konfiguration der Session-Cookies (Domain, Pfad, Secure-Attribut, SameSite-Attribut). Ein Cookie mit Secure=true wird bei einer HTTP-Verbindung nicht gesendet. Ein Cookie mit falscher Domain (.www.captaindns.com statt .captaindns.com) wird auf der Variante ohne www nicht gelesen.

6. .htaccess-Datei mit widersprüchlichen Regeln

Symptom: ERR_TOO_MANY_REDIRECTS auf einem Apache-Server, oft nach einer manuellen Änderung der .htaccess.

Mechanismus: Die .htaccess-Datei enthält mehrere RewriteRule-Blöcke, die sich widersprechen. Zum Beispiel leitet eine Regel /page auf /page/ um, und eine andere leitet /page/ auf /page um. Oder eine generische Regel (Catch-all) erfasst URLs, die eigentlich durch eine vorherige Regel ausgeschlossen sein sollten, aber die Reihenfolge der Regeln ist falsch.

Diagnose: Untersuche die .htaccess-Datei im Stammverzeichnis der Website und in allen Unterverzeichnissen. Suche nach RewriteRule-Blöcken, die auf ähnliche Patterns abzielen.

Korrektur: Vereinfache die .htaccess. Fasse alle Weiterleitungen in einem einzigen Block zusammen, ordne von der spezifischsten zur allgemeinsten Regel und füge das Flag [L] (last) zu den abschließenden Regeln hinzu.

Beispiel einer sauberen .htaccess, die HTTP zu HTTPS und www zu non-www ohne Konflikt behandelt:

RewriteEngine On
# HTTPS erzwingen
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# non-www erzwingen
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Die Reihenfolge ist wichtig: Zuerst HTTPS erzwingen, dann www behandeln. Das Flag [L] stellt sicher, dass jede Regel abschließend ist: Einmal ausgelöst, fährt Apache nicht mit den folgenden Regeln fort.

7. Falsch konfigurierter CDN oder Reverse Proxy

Symptom: ERR_TOO_MANY_REDIRECTS nach der Einrichtung eines CDN (Cloudflare, Fastly, AWS CloudFront) oder eines Reverse Proxys (Nginx, HAProxy).

Mechanismus: Der CDN oder der Reverse Proxy ändert die Header der Anfrage (Protokoll, Host, Pfad), bevor er sie an den Ursprungsserver weiterleitet. Der Ursprungsserver trifft eine Weiterleitungsentscheidung basierend auf diesen geänderten Headern und gibt eine Antwort zurück, die eine erneute Weiterleitung auf CDN-Ebene auslöst. Der Zyklus wiederholt sich.

Der klassische Fall: Der CDN beendet die TLS-Verbindung und leitet die Anfrage per HTTP an den Ursprungsserver weiter. Der Server sieht HTTP und leitet auf HTTPS um. Der CDN fängt diese Weiterleitung ab, sendet aber erneut per HTTP.

Diagnose: Teste die Website unter Umgehung des CDN (greife direkt auf die IP des Servers zu). Wenn die Website ohne CDN funktioniert, aber nicht mit, liegt das Problem in der Proxy-Konfiguration.

Korrektur: Konfiguriere den Ursprungsserver so, dass er Proxy-Header erkennt (X-Forwarded-Proto). Unter Nginx verwende $http_x_forwarded_proto statt $scheme. Unter Apache überprüfe %{HTTP:X-Forwarded-Proto} in den RewriteCond.

Beispiel Nginx mit Proxy-Unterstützung:

server {
    listen 80;
    server_name captaindns.com;

    # Nur auf HTTPS umleiten, wenn die Anfrage nicht bereits ueber HTTPS am CDN ankommt
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

Wie diagnostiziert man eine Weiterleitungsschleife?

Sobald du weißt, dass eine Schleife existiert (der Browser zeigt den Fehler), musst du sie genau lokalisieren. Drei ergänzende Methoden ermöglichen es, die Weiterleitungskette zu rekonstruieren und den Rückkehrpunkt zu identifizieren.

Methode 1: der Redirect Checker von CaptainDNS

Die schnellste Methode. Gib die URL in den Redirect Checker ein und starte die Analyse. Das Tool folgt jeder Weiterleitung, erfasst den HTTP-Code, die Ziel-URL, die Antwort-Header und die Antwortzeit jedes Hops. Wenn es erkennt, dass eine URL zweimal in der Kette vorkommt, meldet es die Schleife und gibt genau an, bei welchem Hop sie beginnt.

Der Vorteil: Das Tool folgt bis zu 30 Hops (gegenüber 20 bei Browsern), was die Erkennung langer Schleifen ermöglicht. Es zeigt auch die vollständigen HTTP-Header, die für die Diagnose von Protokollkonflikten und X-Forwarded-Proto-Problemen unerlässlich sind.

Methode 2: curl in der Kommandozeile

Für Administratoren, die das Terminal bevorzugen, zeigt curl mit der Option -v (verbose) und -L (follow redirects) jeden Schritt der Kette:

curl -v -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -E "^(< HTTP|< Location|> GET)"

Dieser Befehl zeigt den HTTP-Code und den Location-Header jeder Antwort sowie die bei jedem Schritt gesendete GET-Anfrage. Wenn die URL der GET-Anfrage einer bereits weiter oben in der Ausgabe gesehenen URL entspricht, hast du die Schleife gefunden.

Die Option --max-redirs 25 erhöht das Standardlimit von curl (50) auf ein ausreichendes Niveau, um die meisten Schleifen zu erkennen, ohne eine zu lange Ausgabe zu erzeugen.

Für eine kompaktere Ausgabe beschränke dich auf die Header:

curl -sI -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -iE "^(HTTP/|Location:)"

Methode 3: die DevTools des Browsers

Öffne die Entwicklertools (F12), gehe zum Tab "Network" (Netzwerk) und lade die problematische URL. Der Browser zeigt jede HTTP-Anfrage in chronologischer Reihenfolge an. Du siehst eine Reihe von Anfragen mit den Codes 301 oder 302, jeweils mit einer anderen URL, bis der Browser sein Limit erreicht und den Fehler anzeigt.

Der Vorteil der DevTools: Sie zeigen die bei jeder Anfrage gesendeten und empfangenen Cookies, unverzichtbar für die Diagnose von Authentifizierungsschleifen (Ursache 5). Die Einschränkung: Der Browser zeigt nur die ersten 20 Anfragen (16 bei Safari).

Vergleich der drei Methoden

Kriterium	Redirect Checker	curl	DevTools
Benutzerfreundlichkeit	Hoch (Weboberfläche)	Mittel (Terminal)	Mittel (Browser)
Maximale Hops	30	Konfigurierbar	16 bis 20
Automatische Schleifenerkennung	Ja	Nein (manuelle Analyse)	Nein (manuelle Analyse)
Cookie-Anzeige	Nein	Ja (mit `-v`)	Ja
Antwortzeiten anzeigen	Ja (pro Hop)	Ja (mit `-w`)	Ja
Installation erforderlich	Nein	Ja (auf Linux/macOS vorhanden)	Nein
Ergebnisse teilen	Ja (Bericht-URL)	Nein	Nein (Screenshot)

Für eine schnelle Diagnose beginne mit dem Redirect Checker. Ergänze mit den DevTools, wenn das Problem Cookies betrifft, oder mit curl für die Automatisierung in CI/CD-Pipelines.

Weiterleitungsketten: Auswirkungen auf SEO und Performance

Eine Weiterleitungskette ist eine lineare Sequenz aufeinanderfolgender Weiterleitungen. Im Gegensatz zur Schleife führt die Kette zu einer Inhaltsseite, durchläuft aber eine oder mehrere Zwischen-URLs, bevor sie dort ankommt. Das Problem ist nicht die Unerreichbarkeit (die Seite lädt schließlich), sondern die schrittweise Verschlechterung von SEO und Performance.

Ab wie vielen Hops wird es problematisch?

Ein einzelner Weiterleitungs-Hop ist völlig normal. Das ist der Standardfall eines alten Links, der auf die neue URL umleitet. Das Problem beginnt, wenn sich Hops ansammeln.

Anzahl Hops	Bewertung	Auswirkung
1	Normal	Keine messbare Auswirkung
2	Akzeptabel	Minimale Auswirkung, keine Maßnahme erforderlich
3	Warnung	Spürbare Latenz, mögliche SEO-Verwässerung
4 bis 5	Problem	400 bis 2.500 ms zusätzliche Latenz, wahrscheinlicher SEO-Verlust
6 und mehr	Kritisch	Google kann das Verfolgen abbrechen, Seite möglicherweise nicht indexiert

Google folgt offiziell bis zu 10 Weiterleitungen in einer Kette. Allerdings hat John Mueller vom Google-Search-Team präzisiert, dass die Übertragung des SEO-Signals sich deutlich vor Erreichen dieses Limits verschlechtern kann. Die praktische Empfehlung: Nie mehr als 2 Hops zwischen Quell-URL und Endziel.

SEO-Auswirkung: PageRank-Verwässerung und Indexierungsverlust

Jede Zwischenweiterleitung in einer Kette schafft eine Gelegenheit für den Verlust von SEO-Signal. Obwohl Google behauptet, dass eine einzelne 301-Weiterleitung 100 % des PageRanks überträgt, ist das Verhalten bei mehrfachen Ketten weniger dokumentiert und weniger zuverlässig.

Das konkrete Problem: Wenn Googlebot auf eine Kette von 5 Weiterleitungen trifft, führt er 6 HTTP-Anfragen durch. Jede verbraucht Crawl-Budget. Bei großen Websites mit Tausenden von Ketten verbringt Google Zeit damit, Weiterleitungen zu folgen, statt neuen Inhalt zu crawlen.

Zudem wird die PageRank-Übertragung unterbrochen, wenn eine Zwischenweiterleitung eine 302 statt einer 301 ist. Eine einzige 302 in einer Kette von 301-Weiterleitungen reicht aus, um die Autoritätsübertragung zu blockieren.

Performance-Auswirkung: Latenz addiert sich

Jeder Weiterleitungs-Hop fügt einen vollständigen Netzwerk-Roundtrip zwischen Browser und Server hinzu. In der Praxis bedeutet das 100 bis 500 ms pro Hop, abhängig von der Netzwerklatenz und dem geografischen Standort des Besuchers.

Für einen Besucher in Europa, der auf einen Server in Nordamerika zugreift, fügt jeder Hop 150 bis 200 ms hinzu. Eine Kette von 4 Hops fügt 600 bis 800 ms hinzu, bevor der Inhalt zu laden beginnt.

Diese Auswirkung konzentriert sich auf den LCP (Largest Contentful Paint), die Core-Web-Vitals-Metrik, die die Ladezeit des Hauptinhalts misst. Ein LCP über 2,5 Sekunden wird von Google als "schlecht" eingestuft. Wenn deine Seite normalerweise in 1,8 Sekunden lädt, aber eine Kette von 3 Weiterleitungen 600 ms hinzufügt, landest du im roten Bereich.

Gute Nachricht: 301-Weiterleitungen, die vom Browser gecacht werden, haben nach dem ersten Besuch keine Auswirkung mehr. Das ist ein weiteres Argument dafür, 301 gegenüber 302 in Ketten zu bevorzugen.

Wie Ketten entstehen: der Fall der mehrstufigen Migration

Weiterleitungsketten werden selten absichtlich erstellt. Sie sammeln sich im Laufe der Zeit an, bei jeder Migration, jedem Redesign oder jeder Strukturänderung.

Typisches Szenario:

2022: Die Website ist unter http://captaindns.com. Umstellung auf HTTPS. 301-Weiterleitung von http:// auf https://.
2023: Website-Redesign. Änderung der URL-Struktur. 301-Weiterleitung von /tools/dns-check auf /de/tools/dns/test-propagation.
2025: Konsolidierung der Subdomain. 301-Weiterleitung von https://outils.captaindns.com/dns-check auf https://captaindns.com/tools/dns-check.

Ein 2022 veröffentlichter Backlink, der auf http://outils.captaindns.com/dns-check verweist, durchläuft jetzt 3 Weiterleitungen:

http://outils.captaindns.com/dns-check
→ 301 → https://outils.captaindns.com/dns-check
→ 301 → https://captaindns.com/tools/dns-check
→ 301 → https://captaindns.com/de/tools/dns/test-propagation

Jede einzelne Migration war korrekt. Aber die Anhäufung erzeugt eine Kette von 3 Hops, die Crawl-Budget verbraucht und Latenz hinzufügt.

Die Lösung: Nach jeder Migration die alten Weiterleitungen aktualisieren, damit sie direkt auf das endgültige Ziel verweisen. In diesem Beispiel sollte die erste Weiterleitung auf https://captaindns.com/de/tools/dns/test-propagation aktualisiert werden, um die beiden Zwischenschritte zu eliminieren.

Schema einer 4-Weiterleitungskette mit kumulierter Latenz und der Korrektur zu einem einzigen direkten Hop

Wie erkennt man Ketten auf der eigenen Website?

Die effektivste Methode ist, deine kritischen URLs (Seiten mit viel Traffic, Seiten mit den meisten Backlinks) mit dem Redirect Checker zu testen. Das Tool zeigt die Anzahl der Hops für jede URL an und meldet Ketten mit mehr als 2 Hops.

Für ein umfassendes Audit exportiere die Liste deiner URLs aus der Google Search Console (Bericht "Seiten") und teste sie stapelweise. Priorisiere URLs mit dem meisten organischen Traffic und den meisten Backlinks.

Du kannst auch den Page Crawl Checker verwenden, um Weiterleitungsketten im Kontext eines vollständigen Seitencrawls zu analysieren, einschließlich geladener Ressourcen (CSS, JavaScript, Bilder), die ebenfalls Ketten durchlaufen können.

Kurzlinks: wohin führen sie wirklich?

URL-Verkürzungsdienste (bit.ly, t.co, tinyurl.com, ow.ly, goo.gl) ersetzen eine lange URL durch eine kurze URL, die zum Ziel weiterleitet. Dieser Vorgang ist für den legitimen Nutzer transparent: Er klickt, der Dienst leitet um, die Seite lädt. Aber genau diese Transparenz ist auch ein bedeutender Angriffsvektor.

Das Sicherheitsproblem der Kurzlinks

Ein Kurzlink verbirgt das Ziel vollständig. Der Nutzer kann vor dem Klicken nicht wissen, ob der Link zu einem legitimen Google-Dokument oder zu einer Phishing-Seite führt, die die Anmeldeseite seiner Bank nachahmt.

Angreifer nutzen diese Intransparenz systematisch aus. Eine Phishing-E-Mail mit https://bit.ly/3xYz123 ist viel schwieriger zu erkennen als eine E-Mail mit einer offensichtlich verdächtigen URL im Klartext. Anti-Phishing-Filter haben Schwierigkeiten, Kurzlinks zu analysieren, da die sichtbare Domain (bit.ly) legitim ist. Nur das endgültige Ziel ist bösartig.

Laut Untersuchungen von Palo Alto Networks (Unit 42) wurden über 70 % der bösartigen Domains innerhalb der letzten 32 Tage registriert (Newly Registered Domains). Kurzlinks sind der Hauptvektor für die Verbreitung dieser kürzlich registrierten Domains.

Fortgeschrittene Verschleierungstechniken

Angreifer beschränken sich nicht darauf, einen bösartigen Link zu verkürzen. Sie kombinieren mehrere Techniken, um die Erkennung noch schwieriger zu machen.

Ketten von Verkürzern: Ein bit.ly-Link leitet auf tinyurl weiter, das auf ow.ly weiterleitet, das zur Phishing-Seite führt. Jede Schicht fügt eine Barriere für Erkennungstools hinzu. Der Redirect Checker folgt der gesamten Kette und enthüllt das endgültige Ziel.

Bedingte Weiterleitungen: Der Dienst leitet je nach Land, Browser oder Tageszeit auf eine andere Website um. Zielbenutzer sehen die Phishing-Seite, alle anderen werden auf eine legitime Website umgeleitet.

Wiederverwendete abgelaufene Domains: Der Angreifer kauft eine Domain mit gutem Ruf, installiert bösartigen Inhalt und verbreitet Kurzlinks zu dieser Domain. Der historische Ruf täuscht die Sicherheitsfilter.

Wie der Redirect Checker Kurzlinks entlarvt

Wenn du einen Kurzlink in den Redirect Checker eingibst, folgt das Tool jeder Weiterleitung bis zum endgültigen Ziel und erfasst den HTTP-Code, die Ziel-URL, die Header und die Antwortzeit jedes Hops. Es meldet automatisch mehrere Risikoindikatoren:

Kürzlich registrierte Domains (NRD): Wenn das endgültige Ziel eine Domain ist, die vor weniger als 30 Tagen registriert wurde, gibt das Tool eine Warnung aus. NRD-Domains sind statistisch deutlich häufiger bösartig als etablierte Domains.

Übermäßige Anzahl von Weiterleitungen: Ein legitimer Kurzlink umfasst in der Regel 1 oder 2 Weiterleitungen (vom Verkürzer zum Ziel). Wenn die Kette 4 oder mehr Weiterleitungen enthält, ist das ein Warnsignal.

Verdächtiger Protokollwechsel: Wenn eine Weiterleitung in der Kette von HTTPS auf HTTP wechselt, ist das ein Risikoindikator. Legitime Websites verwenden HTTPS. Ein Rückfall auf HTTP mitten in der Kette kann auf einen Downgrade-Versuch zum Abfangen des Datenverkehrs hindeuten.

IDN-Homographen: wenn die Domain einer anderen zum Verwechseln ähnlich sieht

IDN-Homograph-Angriffe (Internationalized Domain Name) nutzen Unicode-Zeichen, die lateinischen Buchstaben visuell ähneln. Zum Beispiel ist das kyrillische "a" (U+0430) visuell identisch mit dem lateinischen "a" (U+0061), aber es handelt sich um ein anderes Zeichen.

Ein Angreifer kann cаptaindns.com (mit kyrillischem "a") registrieren, das in der Adressleiste exakt wie captaindns.com aussieht. Hinter einem Kurzlink ist dieser Unterschied völlig unsichtbar.

Der Redirect Checker zeigt die Ziel-URL in ASCII-Punycode an, wenn sie IDN-Zeichen enthält. Die URL cаptaindns.com erscheint dann in ihrer technischen Form xn--cptaindns-r6a.com, was sofort offenbart, dass es sich nicht um die erwartete Domain handelt.

Um deine Marke zu schützen, überprüfe regelmäßig, ob homographe Varianten deiner Domain nicht von Dritten registriert wurden. Der Phishing URL Checker analysiert speziell Homographie- und Typosquatting-Risiken für die URLs, die du eingibst.

Wie behebt man Weiterleitungsprobleme?

Die Diagnose ist gestellt, das Problem identifiziert. Hier sind die Korrekturschritte für jeden Problemtyp.

Eine Weiterleitungsschleife beheben

Schritt 1: Einstiegspunkt und Rückkehrpunkt identifizieren. Verwende den Redirect Checker, um die vollständige Kette zu rekonstruieren. Notiere, bei welchem Hop die URL erneut erscheint.

Schritt 2: Die für den Rückkehr verantwortliche Komponente identifizieren. Das ist der Server, CDN, das CMS oder Plugin, das die Weiterleitung zur bereits gesehenen URL erzeugt. Konsultiere den Abschnitt "Die 7 Ursachen" oben, um das Muster zu identifizieren.

Schritt 3: Den Zyklus durchbrechen. Ändere die Konfiguration der verantwortlichen Komponente, damit sie die zirkuläre Weiterleitung nicht mehr erzeugt. In den meisten Fällen bedeutet das, eine Weiterleitungsregel in einer der beteiligten Komponenten zu entfernen oder zu ändern.

Schritt 4: Sofort testen. Leere nach der Korrektur den Browser-Cache (301-Weiterleitungen können gecacht werden) und teste mit dem Redirect Checker. Überprüfe, dass die Kette mit einem Code 200 endet und nicht mit einem Zyklus.

Konkretes Beispiel: Schleife zwischen Cloudflare (Flexible SSL) und einem Apache-Server, der HTTPS erzwingt.

Vor der Korrektur:
https://captaindns.com → Cloudflare (HTTP zum Server) → Apache (leitet auf HTTPS um)
→ Cloudflare (HTTP zum Server) → Apache (leitet auf HTTPS um) → Schleife

Korrektur: Cloudflare auf Modus "Full (Strict)" umstellen

Nach der Korrektur:
https://captaindns.com → Cloudflare (HTTPS zum Server) → Apache (keine Weiterleitung, Code 200)

Eine Weiterleitungskette beheben

Prinzip: Die Kette auf 1 einzigen Hop verkürzen. Jede Quell-URL muss direkt auf das Endziel verweisen, ohne Zwischenschritte.

Schritt 1: Alle Weiterleitungen der Kette auflisten. Verwende den Redirect Checker, um die vollständige Sequenz zu erhalten.

Schritt 2: Das endgültige Ziel identifizieren. Das ist die letzte URL der Kette, die einen Code 200 zurückgibt.

Schritt 3: Jede Zwischenweiterleitung aktualisieren. Ändere die Konfiguration jedes beteiligten Servers oder Dienstes, damit die Zwischen-URLs direkt auf das Endziel umleiten.

Beispiel:

Vor der Korrektur:
http://captaindns.com/old-page
→ 301 → https://captaindns.com/old-page
→ 301 → https://captaindns.com/de/old-page
→ 301 → https://captaindns.com/de/tools/new-page

Nach der Korrektur:
http://captaindns.com/old-page → 301 → https://captaindns.com/de/tools/new-page
https://captaindns.com/old-page → 301 → https://captaindns.com/de/tools/new-page
https://captaindns.com/de/old-page → 301 → https://captaindns.com/de/tools/new-page

Jede Quell-URL verweist jetzt direkt auf das Endziel mit einem einzigen Hop. Browser und Googlebot müssen nur noch einer einzigen Weiterleitung folgen.

Überprüfung nach der Korrektur

Nach jeder Korrektur systematisch mit dem Redirect Checker testen:

Überprüfe, dass die Kette mit einem Code 200 endet.
Überprüfe, dass die Anzahl der Hops kleiner oder gleich 2 ist.
Überprüfe, dass alle Zwischenweiterleitungen den Code 301 verwenden (außer bei spezifischen temporären Weiterleitungen).
Überprüfe, dass das endgültige Protokoll HTTPS ist.
Teste die 4 Varianten der URL: http://, https://, http://www., https://www..

Wenn du mehrere Ketten korrigiert hast, warte 48 bis 72 Stunden und überprüfe dann in der Google Search Console, ob die Weiterleitungsfehler im Bericht "Seiten" verschwunden sind.

Best Practices, um zukünftige Probleme zu vermeiden

Einen einzigen Kontrollpunkt für Weiterleitungen verwenden. Konfiguriere nicht dieselbe Weiterleitung an zwei verschiedenen Stellen (Webserver und CDN, CMS und .htaccess). Wähle eine einzige Komponente für die Verwaltung jedes Weiterleitungstyps.

Für permanente Weiterleitungen immer 301 verwenden. 302-Weiterleitungen übertragen keinen PageRank und werden vom Browser nicht gecacht. Außer in speziellen Fällen (bedingte Weiterleitung, A/B-Test) ist 301 die Standardwahl.

Alte Weiterleitungen nach jeder Migration aktualisieren. Lass Ketten sich nicht ansammeln. Überarbeite nach jeder Änderung der URL-Struktur die alten Weiterleitungen, damit sie direkt auf das Endziel verweisen.

Alle bestehenden Weiterleitungen dokumentieren. Pflege eine Übersichtstabelle aller aktiven Weiterleitungsregeln mit Quelle, Ziel, HTTP-Code und Erstellungsdatum. Diese Tabelle ist unverzichtbar, um Konflikte bei zukünftigen Änderungen zu vermeiden.

Vor dem Deployment testen. Bevor du eine neue Weiterleitungsregel in Produktion nimmst, teste sie in einer Staging-Umgebung oder mit curl -I. Überprüfe, dass die Weiterleitung funktioniert und keinen Konflikt mit bestehenden Regeln erzeugt.

Empfohlener Aktionsplan

Hier ist eine 5-Schritte-Checkliste zum Auditieren und Beheben von Weiterleitungsproblemen auf deiner Website.

Schritt 1: Kritische URLs scannen

Identifiziere deine 20 bis 50 wichtigsten URLs: Startseiten, Produktseiten, Blog-Artikel mit viel Traffic, Conversion-Seiten. Teste jede mit dem Redirect Checker.

Notiere für jede URL:

Die Anzahl der Hops
Das eventuelle Vorhandensein einer Schleife
Den HTTP-Code des Endziels (muss 200 sein)
Das Protokoll des Endziels (muss HTTPS sein)

Schritt 2: Schleifen und Ketten mit mehr als 3 Hops identifizieren

Filtere unter den getesteten URLs diejenigen mit einem Problem:

Schleife erkannt: Höchste Priorität, die Seite ist nicht erreichbar
5 Hops oder mehr: Hohe Priorität, signifikante SEO- und Performance-Auswirkung
3 bis 4 Hops: Mittlere Priorität, im nächsten Wartungszyklus zu korrigieren
1 bis 2 Hops: Keine Maßnahme erforderlich

Schritt 3: Serverkonfigurationen korrigieren

Wende für jedes identifizierte Problem die passende Korrektur an:

Schleife: Identifiziere die verantwortliche Komponente (siehe die 7 Ursachen) und durchbrich den Zyklus
Kette: Aktualisiere jede Zwischenweiterleitung, damit sie auf das Endziel verweist
CDN/Server-Konflikt: Gleiche die SSL/TLS-Konfiguration zwischen CDN und Ursprungsserver ab
Konflikt in der .htaccess: Vereinfache die Regeln, füge [L]-Flags hinzu, ordne von der spezifischsten zur allgemeinsten Regel

Schritt 4: Kurzlinks in E-Mails und Newslettern überprüfen

Überprüfe die Kurzlinks in deinen Newsletter-Vorlagen, E-Mail-Signaturen und aktiven Marketing-Kampagnen. Für jeden Kurzlink:

Teste das Ziel mit dem Redirect Checker
Überprüfe, dass das Ziel deine Website ist (und keine Drittanbieter-Domain)
Ersetze Kurzlinks durch Direktlinks, wenn möglich
Wenn der Kurzlink notwendig ist (Tracking, QR-Code), überprüfe, dass die Kette nicht mehr als 2 Hops umfasst

Schritt 5: Nach der Korrektur erneut testen

Überprüfe nach jeder Korrektur die korrigierten URLs und stelle sicher, dass:

Die Schleife behoben ist (Code 200 am Ende der Kette)
Die Kette verkürzt ist (maximal 2 Hops)
Alle 4 URL-Varianten (HTTP/HTTPS, www/non-www) korrekt funktionieren
Keine neuen Probleme eingeführt wurden

Plane ein Follow-up-Audit nach 30 Tagen, um zu überprüfen, ob die Korrekturen halten und keine neuen Ketten entstanden sind.

Praxisbeispiele: Häufige Diagnosen und Lösungen

Fall 1: WordPress-Website nach Aktivierung von Really Simple SSL nicht erreichbar

Symptom: ERR_TOO_MANY_REDIRECTS unmittelbar nach Aktivierung des Plugins.

Diagnose mit dem Redirect Checker:

Hop 1: https://captaindns.com → 301 → http://captaindns.com (Plugin erzwingt HTTP?)
Hop 2: http://captaindns.com → 301 → https://captaindns.com (Server erzwingt HTTPS)
Hop 3: https://captaindns.com → 301 → http://captaindns.com
→ Schleife erkannt bei Hop 3

Ursache: Die Datei wp-config.php enthält define('FORCE_SSL_ADMIN', false) oder die Website-URL in der Datenbank ist HTTP, was mit dem Plugin in Konflikt gerät, das HTTPS erzwingen will.

Lösung: Deaktiviere das Plugin per FTP (benenne seinen Ordner um), aktualisiere die Optionen siteurl und home in wp_options auf HTTPS, füge define('FORCE_SSL_ADMIN', true) in wp-config.php hinzu und reaktiviere dann das Plugin.

Fall 2: Kurzlink in einer E-Mail, der auf eine Phishing-Seite führt

Symptom: Ein Mitarbeiter erhält eine E-Mail mit einem Link https://bit.ly/3Ab4Cd5, der angeblich zu einem geteilten Dokument führt.

Diagnose mit dem Redirect Checker:

Hop 1: https://bit.ly/3Ab4Cd5 → 301 → https://tinyurl.com/y7x8z9
Hop 2: https://tinyurl.com/y7x8z9 → 301 → https://docs-google-verification.com/login
→ Endziel: https://docs-google-verification.com/login
→ WARNUNG: Domain vor 3 Tagen registriert (NRD)
→ WARNUNG: Domain ahmt "docs.google.com" nach (mögliche Homographie)

Risikoindikatoren: Zwei Verkürzer in einer Kette (Verschleierungstechnik), Ziel-Domain vor 3 Tagen registriert (NRD), Domainname, der einen legitimen Dienst nachahmt (Google Docs), URL enthält "/login" (Versuch des Identitätsdiebstahls).

Maßnahme: Nicht klicken. Die E-Mail als Phishing melden. Das Sicherheitsteam informieren. Falls der Link angeklickt wurde, sofort das Passwort des imitierten Dienstes ändern und die Zwei-Faktor-Authentifizierung aktivieren.

Weiterleitungen und Sicherheit: Angriffe auf Basis von Weiterleitungen

Weiterleitungen sind nicht nur ein Konfigurationsproblem. Sie sind auch ein Angriffsvektor, der aktiv von Cyberkriminellen ausgenutzt wird.

Open Redirect: wenn deine eigene Website zum Angriffsvektor wird

Eine "Open Redirect"-Schwachstelle besteht, wenn deine Website einen URL-Parameter akzeptiert, der das Weiterleitungsziel steuert, ohne diesen Parameter zu validieren. Beispiel: https://captaindns.com/login?redirect=https://boesartige-website.com. Wenn deine Anwendung blind auf den Wert des redirect-Parameters umleitet, kann ein Angreifer deine legitime Domain als ersten Schritt einer Phishing-Kette nutzen.

Schutz: Validiere Weiterleitungs-URLs immer serverseitig. Akzeptiere nur Weiterleitungen auf deine eigene Domain oder auf eine Whitelist autorisierter Domains.

Angriff über Weiterleitungsketten

Ein Angreifer kann legitime Weiterleitungen nutzen, um Ketten zu konstruieren, die Sicherheitsfilter umgehen. Die typische Kette: Eine E-Mail enthält einen Link zu einem legitimen Verkürzer (bit.ly), der Verkürzer leitet auf eine seriöse Website mit einer Open-Redirect-Schwachstelle weiter, der Open Redirect schickt zur Phishing-Seite. Jeder Schritt passiert die Filter einzeln. Nur die Kombination ist bösartig. Nur ein Tool, das der gesamten Kette bis zum Endziel folgt, kann den Angriff erkennen.

Best Practices für die Sicherheit von Weiterleitungen

Nie auf einen Kurzlink klicken, ohne ihn zu überprüfen. Verwende den Redirect Checker, um das Ziel vor dem Klicken zu enthüllen.
Die eigene Website auf Open Redirects auditieren. Suche alle Endpunkte, die einen URL-Parameter als Weiterleitungsziel akzeptieren.
NRD-Domains in E-Mails überprüfen. Eine Domain, die weniger als 30 Tage alt ist und in einem E-Mail-Link vorkommt, ist ein starkes Warnsignal.
Die Teams sensibilisieren. Kurzlinks in internen E-Mails sollten immer von der vollständigen Ziel-URL im Klartext begleitet werden.

FAQ

Was bedeutet ERR_TOO_MANY_REDIRECTS?

Diese Fehlermeldung bedeutet, dass der Browser sein Limit an aufeinanderfolgenden Weiterleitungen erreicht hat (20 für Chrome und Firefox, 16 für Safari), ohne eine Inhaltsseite zu erreichen. Die Ursache ist entweder eine Weiterleitungsschleife (zwei oder mehr URLs, die sich gegenseitig umleiten) oder eine übermäßig lange Weiterleitungskette. Um die genaue Ursache zu identifizieren, teste die URL mit dem Redirect Checker, der der gesamten Kette folgt und Schleifen automatisch erkennt.

Wie behebt man eine Weiterleitungsschleife bei WordPress?

WordPress-Schleifen werden in der Regel durch einen Konflikt zwischen einem Plugin (Really Simple SSL, Wordfence, W3 Total Cache) und der Serverkonfiguration verursacht. Die Korrektur in 4 Schritten: 1) Deaktiviere die Plugins einzeln per FTP (benenne den Ordner in wp-content/plugins/ um), um den Verursacher zu identifizieren; 2) Überprüfe, ob die URLs siteurl und home in der Tabelle wp_options das richtige Protokoll (HTTPS) verwenden; 3) Bereinige die .htaccess-Datei von doppelten Weiterleitungsregeln; 4) Reaktiviere das Plugin und passe seine Einstellungen an, damit die Serverweiterleitungen nicht dupliziert werden.

Wie vielen Weiterleitungen kann Google folgen?

Google folgt offiziell bis zu 10 Weiterleitungen in einer Kette. Darüber hinaus gibt Googlebot auf und die Zielseite wird weder gecrawlt noch indexiert. In der Praxis empfiehlt John Mueller, nie mehr als 2 Hops zu verwenden. Jede Weiterleitung verbraucht Crawl-Budget und kann das SEO-Signal verwässern, besonders wenn sich eine 302 in eine Kette von 301-Weiterleitungen einschleicht.

Sind Kurzlinks gefährlich?

Kurzlinks sind nicht grundsätzlich gefährlich, aber sie verbergen das tatsächliche Ziel, was sie zu einem bevorzugten Vektor für Phishing und Malware-Verbreitung macht. Laut Untersuchungen von Palo Alto Networks wurden über 70 % der bösartigen Domains innerhalb der letzten 32 Tage registriert, und Kurzlinks sind das wichtigste Mittel, um diese Domains per E-Mail zu verbreiten. Best Practice ist, das Ziel eines Kurzlinks immer vor dem Klicken zu überprüfen, indem du ein Tool verwendest, das der Weiterleitungskette bis zum Ende folgt.

Wie findet man heraus, wohin ein bit.ly-Link führt?

Es gibt mehrere Methoden. Die zuverlässigste ist die Verwendung des Redirect Checkers von CaptainDNS: Gib den bit.ly-Link ein und das Tool folgt allen Weiterleitungen bis zum Endziel, wobei jeder Zwischenhop angezeigt wird. Du kannst auch ein "+" an das Ende der bit.ly-URL anhängen (zum Beispiel https://bit.ly/3xYz123+), um auf die bit.ly-Statistikseite zuzugreifen, die das Ziel anzeigt, aber diese Methode funktioniert nicht mit allen Verkürzern und folgt keinen mehrfachen Weiterleitungen.

Was ist der Unterschied zwischen einer Schleife und einer Weiterleitungskette?

Eine Schleife ist ein Zyklus: URL A leitet auf B weiter, B leitet auf C weiter, C leitet wieder auf A weiter. Der Browser dreht sich im Kreis und erreicht nie eine Inhaltsseite. Das Ergebnis ist ein Fehler ERR_TOO_MANY_REDIRECTS. Eine Kette ist eine lineare Sequenz: A leitet auf B weiter, B leitet auf C weiter, C gibt einen Code 200 zurück (Inhaltsseite). Die Kette führt zum Ziel, aber jeder Zwischenhop fügt Latenz hinzu und kann das SEO-Signal verwässern. Schleifen sind blockierend (die Seite ist nicht erreichbar), Ketten sind leistungsmindernd (die Seite lädt, aber schlechter).

Funktioniert der Redirect Checker mit Kurzlinks?

Ja. Der Redirect Checker folgt allen HTTP-Weiterleitungen, unabhängig von der Quell-Domain. Wenn du einen bit.ly-, tinyurl.com-, t.co- oder anderen Kurzlink eingibst, folgt das Tool der gesamten Kette bis zum Endziel. Es zeigt jeden Zwischenhop mit HTTP-Code, Ziel-URL und Antwortzeit an. Es meldet auch kürzlich registrierte Domains (NRD) und ungewöhnlich lange Ketten, die auf einen Verschleierungsversuch hindeuten können.

Wie erkennt man einen maskierten Phishing-Link?

Mehrere Hinweise helfen, einen Phishing-Link hinter einem Verkürzer zu erkennen. Überprüfe das Ziel mit dem Redirect Checker und suche nach folgenden Warnsignalen: 1) Die Ziel-Domain wurde vor weniger als 30 Tagen registriert (NRD); 2) die Kette enthält mehr als 2 Weiterleitungen (Verschleierungstechnik); 3) die Domain ahmt einen bekannten Dienst nach (IDN-Homograph oder Typosquatting); 4) die endgültige URL enthält Wörter wie "login", "verify", "secure" oder "update"; 5) das Protokoll wechselt während der Kette von HTTPS auf HTTP. Das Vorhandensein von 2 oder mehr dieser Indikatoren deutet stark auf einen bösartigen Link hin.

Können Meta-Refresh-Weiterleitungen Schleifen erzeugen?

Ja, Meta-Refresh-Weiterleitungen können genauso wie HTTP-Weiterleitungen Schleifen erzeugen. Seite A enthält ein <meta http-equiv="refresh">-Tag, das auf Seite B weiterleitet, und Seite B enthält ein ähnliches Tag, das auf A weiterleitet. Der Unterschied: Meta-Refresh ist langsamer (der Browser muss das HTML herunterladen und parsen, bevor er weiterleitet) und schwieriger zu diagnostizieren, da sie in den HTTP-Headern nicht sichtbar sind. Kommandozeilen-Tools wie curl erkennen sie ohne spezielle Optionen nicht.

Wie verhindert man, dass sich Weiterleitungsketten im Laufe der Zeit ansammeln?

Best Practice ist, alte Weiterleitungen nach jeder Migration zu aktualisieren. Wenn du eine neue Weiterleitungsebene hinzufügst (Domainwechsel, Änderung der URL-Struktur, HTTPS-Umstellung), gehe zu den vorherigen Weiterleitungen zurück und aktualisiere sie, damit sie direkt auf das Endziel verweisen. Dokumentiere alle aktiven Weiterleitungen in einer zentralen Tabelle mit Quelle, Ziel, HTTP-Code und Datum. Plane ein vierteljährliches Audit deiner wichtigsten URLs mit dem Redirect Checker, um Ketten zu erkennen, bevor sie problematisch werden.

Glossar

Weiterleitungsschleife: Zyklus, bei dem sich zwei oder mehr URLs gegenseitig umleiten. Der Browser zeigt ERR_TOO_MANY_REDIRECTS nach 16 bis 20 Versuchen.
Weiterleitungskette: Lineare Sequenz aufeinanderfolgender Weiterleitungen. Die Kette führt zum Ziel, verschlechtert aber SEO und Performance.
ERR_TOO_MANY_REDIRECTS: Fehlermeldung der Chromium-Browser, wenn das Weiterleitungslimit erreicht ist. Entspricht "Die Seite wird nicht richtig weitergeleitet" bei Firefox.
NRD (Newly Registered Domain): Domain, die vor weniger als 32 Tagen registriert wurde. Statistisch häufiger bösartig.
IDN-Homograph: Internationalisierte Domain, die Unicode-Zeichen verwendet, die lateinischen Buchstaben visuell ähneln, um eine legitime Domain nachzuahmen.
Meta-Refresh: HTML-Tag <meta http-equiv="refresh">, das eine clientseitige Weiterleitung auslöst. Von Google für SEO nicht empfohlen.
Kurzlink: Kurze URL (bit.ly, t.co, tinyurl.com), die auf ein längeres Ziel weiterleitet und die tatsächliche URL verbirgt.
Open Redirect: Schwachstelle, bei der eine Anwendung einen URL-Parameter als Weiterleitungsziel ohne Validierung akzeptiert, was Phishing ermöglicht.

Quellen

RFC 7231, Abschnitt 6.4: HTTP Redirection: Offizielle Definition der HTTP-Weiterleitungscodes 301, 302, 303 und 307
Google Search Central: URL redirections: Offizielle Google-Dokumentation zur Behandlung von Weiterleitungen durch die Suchmaschine
Palo Alto Networks Unit 42: Newly Registered Domains: Forschung zur bösartigen Nutzung kürzlich registrierter Domains