Wie lässt sich die Ursache finden, wenn eine Website nach der Einrichtung einer 301-Weiterleitung nicht mehr erreichbar ist?

Wenn eine Website nach dem Einrichten einer 301-Weiterleitung nicht mehr erreichbar ist, sollten Sie zunächst feststellen, an welcher Stelle die Anfrage hängen bleibt: Antwortet die alte URL nicht, wird wiederholt zwischen mehreren Adressen umgeleitet oder wurde bereits die neue URL aufgerufen, die Website zeigt jedoch einen Fehler an? Der in Suchanfragen häufig verwendete Begriff „301エラー“ bedeutet nicht, dass 301 selbst fehlerhaft ist. 301 steht für eine permanente Weiterleitung. Zu prüfen sind vielmehr die Weiterleitungsregeln, die Zieladresse und der Zugriffsweg.

Halten Sie zunächst den vollständigen Weiterleitungsweg fest und ändern Sie dann die entsprechende Konfiguration. Werden DNS-Auflösung, Zertifikat und Rewrite-Regeln gleichzeitig angepasst, lässt sich die Fehlerquelle schwerer bestimmen.

Zunächst feststellen, an welcher Stelle die Anfrage hängen bleibt

Öffnen Sie die Entwicklertools des Browsers, wechseln Sie zum Tab „Netzwerk“, aktivieren Sie „Protokoll beibehalten“ und rufen Sie die vollständige fehlerhafte URL erneut auf. Achten Sie besonders auf den Statuscode und den Antwortheader Location, der die Adresse der nächsten Weiterleitung angibt.

• Meldung, dass zu viele Weiterleitungen auftreten: Prüfen Sie, ob zwei Adressen sich gegenseitig weiterleiten oder dieselbe Adresse immer wieder auf sich selbst zurückleitet.
• Nach der Weiterleitung wird ein 404- oder 5xx-Fehler angezeigt: Die Anfrage hat die Zieladresse erreicht. Prüfen Sie den Seitenpfad, den Anwendungsdienst oder das Gateway.
• Meldung zu einem Zertifikatsfehler, nicht auflösbaren Domainnamen oder einer Zeitüberschreitung der Verbindung: Beheben Sie zunächst das Zertifikats-, DNS- oder Netzwerkproblem. Möglicherweise hat die Anfrage die 301-Regel noch nicht erreicht.

Wenn eine Kommandozeile verfügbar ist, können Sie mit curl -I https://old.example.com/path die Antwortheader anzeigen und mit curl -IL --max-redirs 10 https://old.example.com/path die aufeinanderfolgenden Weiterleitungen verfolgen. Manche Websites behandeln HEAD-Anfragen anders. Wenn das Ergebnis unklar ist, orientieren Sie sich an der tatsächlichen GET-Anfrage des Browsers oder prüfen Sie die Antwort mit curl -sS -D - -o /dev/null URL.

Bei Weiterleitungsschleifen zuerst Protokoll-, Domain- und Proxy-Konfiguration prüfen

Häufige Schleifen entstehen, wenn HTTP zu HTTPS und anschließend wieder zurück zu HTTP weitergeleitet wird oder wenn sich eine Domain mit und ohne www gegenseitig weiterleitet. Leitet der Server beispielsweise example.com zu www.example.com weiter, während das Website-Backend die zweite Adresse wieder auf die erste zurücksetzt, kann der Browser die Seite nicht erreichen.

Legen Sie zunächst die eindeutige kanonische Adresse fest und prüfen Sie anschließend, ob CDN, Load Balancer, Server und Website-Backend dasselbe Ziel verwenden. Regeln auf mehreren Ebenen können zusammenwirken, dürfen jedoch nicht auf unterschiedliche Domains oder Protokolle verweisen.

Wenn die Website einen Reverse-Proxy verwendet, prüfen Sie auch, wie der Origin-Server das vom Besucher verwendete Protokoll erkennt. Der Besucher greift über HTTPS auf das CDN zu, das CDN verbindet sich jedoch über HTTP mit dem Origin-Server. Wenn der Origin-Server nur seine eigene Verbindung berücksichtigt, kann er immer wieder eine Weiterleitung zu HTTPS erzwingen und so eine Schleife verursachen.

Prüfen Sie in diesem Fall das Protokoll der Verbindung zum Origin-Server und ob die Anwendung die von einem vertrauenswürdigen Proxy übermittelten Protokollinformationen korrekt erkennt, zum Beispiel X-Forwarded-Proto. Vertrauen Sie diesem Request-Header nicht pauschal, sondern beschränken Sie den Zugriff auf vertrauenswürdige Proxys.

Auch wenn die Regeln keine gegenseitigen Weiterleitungen verursachen, müssen Geltungsbereich und Ausführungsreihenfolge geprüft werden

Sichern Sie vor Änderungen die bestehende Konfiguration und prüfen Sie anschließend systematisch die Rewrite-Regeln des Servers, Weiterleitungen im Control Panel, Programm-Plug-ins und CDN-Regeln. Achten Sie insbesondere auf drei Arten von Problemen:

• Das Ziel fällt weiterhin unter die ursprüngliche Regel: Die Regel leitet alle Anfragen an eine bestimmte Adresse weiter, schließt die Zieladresse selbst jedoch nicht aus.
• Zu weit gefasster Geltungsbereich von Platzhaltern oder regulären Ausdrücken: Eine Weiterleitungsregel für die Startseite erfasst versehentlich Produktseiten, den Administrationsbereich, Schnittstellen oder statische Ressourcen.
• Fehler beim Zusammensetzen des Pfads: Verzeichnisse werden doppelt eingefügt, Schrägstriche uneinheitlich behandelt oder Rückverweise auf Erfassungsgruppen falsch verwendet, sodass die Weiterleitung zu einer nicht vorhandenen Seite führt.

Wenn der Zugriff nach vorübergehender Deaktivierung einer Regel wieder funktioniert, weist das lediglich darauf hin, dass die Regel oder ihr Zusammenspiel mit anderen Regeln das Problem verursacht. Prüfen Sie weiterhin die Auslösebedingungen, statt notwendige Einstellungen zur Vereinheitlichung der Domain einfach zu löschen. Bei Apache sind die Reihenfolge der Regeln und ihre Vererbung zu beachten; bei Nginx müssen außerdem die Zuordnungen zwischen server, location und rewrite geprüft werden. Prüfen Sie nach der Änderung zunächst die Konfigurationssyntax und laden Sie die Konfiguration anschließend neu.

Wenn die Ziel-URL nicht erreichbar ist, DNS, Zertifikat und Seitenzuordnung prüfen

Rufen Sie die vollständige Adresse im Location-Header direkt auf. Ist auch das Ziel nicht erreichbar, sollten Sie die Fehlerbehebung auf der Zielwebsite fortsetzen, statt die 301-Weiterleitung der alten Website wiederholt zu ändern.

Prüfen Sie bei einem Domainumzug, ob die A-, AAAA- oder CNAME-Einträge der neuen Domain auf den vorgesehenen Dienst verweisen. Sind sowohl IPv4 als auch IPv6 konfiguriert, aber einer der beiden Zugangswege funktioniert nicht, kann es sein, dass die Website in manchen Netzwerken erreichbar ist und in anderen nicht.

Bei HTTPS ist außerdem Folgendes zu beachten: Die alte Domain muss zuerst den TLS-Handshake abschließen, damit der Browser die von ihr zurückgegebene 301-Weiterleitung empfangen kann. Daher benötigt auch eine alte Domain, die ausschließlich für Weiterleitungen verwendet wird, ein gültiges und für sie ausgestelltes Zertifikat. Prüfen Sie sowohl die Variante mit als auch ohne www. Ein gültiges Zertifikat der Zielwebsite ersetzt nicht das Zertifikat der alten Domain.

Wenn die Startseite funktioniert, Produktseiten oder mehrsprachige Seiten jedoch einen 404-Fehler anzeigen, prüfen Sie die Zuordnung der alten zu den neuen Pfaden. Eine 301-Weiterleitung veranlasst den Browser lediglich dazu, die neue Adresse aufzurufen; sie erstellt keine Seite automatisch. Bei einem Umzug einer Außenhandelswebsite sollten alte Produktseiten, Kategorieseiten und Sprachseiten vorrangig den entsprechenden Inhalten zugeordnet werden, anstatt alle auf die Startseite umzuleiten.

Was tun, wenn der Server repariert wurde, der Browser aber weiterhin Fehler anzeigt?

301-Weiterleitungen können im Browser oder CDN zwischengespeichert werden. Wenn die Kommandozeile bereits das richtige Ergebnis liefert, der üblicherweise verwendete Browser jedoch weiterhin zum alten Ziel weiterleitet, testen Sie es mit einem neuen Browserprofil oder auf einem anderen Gerät und leeren Sie anschließend den Cache für die betreffende Domain. Wenn Sie den Cache über die Entwicklertools deaktivieren, müssen diese geöffnet bleiben.

Auch ein CDN kann weiterhin die alte Weiterleitungsantwort zurückgeben. In diesem Fall müssen Sie den Cache der betroffenen URLs leeren. Wenn der Browser HTTP automatisch auf HTTPS umstellt, kann dies außerdem an HSTS liegen. Beurteilen Sie den Sachverhalt anhand der tatsächlichen Netzwerkanfrage und gehen Sie nicht pauschal von einem 301-Cache aus.

Während der Anpassungen können Sie in geeigneten Fällen zunächst eine temporäre Weiterleitung verwenden, um Ziel und Pfad zu prüfen, und nach erfolgreicher Überprüfung auf 301 umstellen. Zwischengespeicherte permanente Weiterleitungen müssen weiterhin separat behandelt werden.

Nach Wiederherstellung des Zugriffs prüfen, ob die geschäftlich relevanten Einstiegsseiten funktionieren

Testen Sie mindestens HTTP und HTTPS, Domains mit und ohne www, die Startseite, Produktdetailseiten und Sprachverzeichnisse. Rufen Sie die Seiten außerdem über alte Links in Anzeigen oder Suchergebnissen auf. Die endgültige Seite sollte korrekt geladen werden, und der Weiterleitungsweg sollte möglichst direkt sein und unnötige Zwischenstationen vermeiden.

Wenn Anfrageformulare, Warenkörbe oder Zahlungsrückrufe betroffen sind, müssen Sie den Übermittlungsprozess separat testen. Bei manchen Clients kann eine 301-Weiterleitung dazu führen, dass POST in GET umgewandelt wird. Für solche Schnittstellen sollten nicht einfach die üblichen Regeln für Seitenweiterleitungen verwendet werden. Wenn die Request-Methode beibehalten werden muss, sollten Sie je nach Anwendungslogik 307 oder 308 in Betracht ziehen.

Prüfen Sie außerdem, ob Anzeigenparameter erhalten bleiben und ob interne Links und Sitemaps aktualisiert wurden. Wenn Sie eine Website-Plattform verwenden, können Sie dem Dienstleister die fehlerhafte URL, die Weiterleitungskette, den Zeitpunkt des Auftretens und kürzlich vorgenommene Konfigurationsänderungen mitteilen. So lässt sich schneller feststellen, ob die Änderung auf Plattform-, CDN- oder Serverebene erfolgen muss.