WordPress ERR_TOO_MANY_REDIRECTS nach Domainwechsel: SSL prüfen

Ausgangslage: WordPress unter einer neuen URL erreichbar machen

Für eine vorhandene WordPress-Installation sollte vorübergehend eine neue Subdomain verwendet werden. Die Installation selbst lag weiterhin im bisherigen Webspace-Verzeichnis. Damit WordPress die neue Adresse verwendet, wurden in der wp-config.php zunächst die beiden URLs fest vorgegeben:

Das ist grundsätzlich ein sinnvoller Weg, wenn man wegen einer geänderten URL nicht mehr in den WordPress-Adminbereich kommt. Die Werte überschreiben die in der Datenbank gespeicherten WordPress-Adressen, solange die Konstanten in der wp-config.php vorhanden sind.

Das Symptom: ERR_TOO_MANY_REDIRECTS

Beim Aufruf des Adminbereichs erschien anschließend jedoch nur:

Der Browser empfiehlt in diesem Fall gern, Cookies zu löschen. Das kann bei Login-Problemen sinnvoll sein, löst aber keine serverseitige HTTP-/HTTPS-Schleife. Deshalb lohnt sich eine systematische Prüfung, bevor man die WordPress-Datenbank verändert.

1. Die .htaccess auf echte Redirects prüfen

Mein erster Verdacht war eine alte Weiterleitung auf die produktive Domain. In der .htaccess fanden sich jedoch nur die normalen WordPress-Rewrite-Regeln sowie Regeln von Imagify, Wordfence und Cache-Plugins. Eine explizite Weiterleitung auf die andere Domain war nicht vorhanden.

Wer eine Redirect-Kette genauer untersuchen möchte, findet hier eine ergänzende Anleitung: Tatsächliche HTTP-Weiterleitung einer Domain überprüfen.

2. Plugins und WordPress-Cache als Ursache ausschließen

Als Nächstes kann man den Plugin-Ordner testweise umbenennen. Wichtig ist dabei: Das deaktiviert nicht zwangsläufig jeden frühen Cache-Mechanismus. Dateien wie wp-content/advanced-cache.php oder object-cache.php können bereits vor den normalen Plugins geladen werden. Für eine saubere Fehlersuche kann außerdem WP_CACHE vorübergehend auf false gesetzt werden.

Auch dieser Test änderte in meinem Fall nichts. Damit wurde immer wahrscheinlicher, dass die Schleife nicht durch ein gewöhnliches WordPress-Plugin verursacht wurde.

3. Statische Testdatei: Läuft der Request überhaupt durch WordPress?

Ein sehr nützlicher Test ist eine einfache Datei wie test.html im WordPress-Stammverzeichnis. Ihr Inhalt kann lediglich OK lauten. Wird selbst diese Datei nicht direkt ausgeliefert, sollte man die Fehlersuche vom WordPress-Code weg und hin zu Webserver, vHost, Proxy, Domainzuordnung oder SSL verschieben.

Gerade nach Domainwechseln ist dieser Test wertvoll, weil man damit schnell erkennt, ob man wirklich die richtige Installation beziehungsweise den richtigen virtuellen Host erreicht.

4. Der entscheidende Fund bei ALL-INKL: SSL-Schutz deaktiviert

In der Subdomain-Konfiguration bei ALL-INKL war das Stammverzeichnis korrekt eingetragen und das Ziel stand auf Webspace. Der entscheidende Eintrag war jedoch:

Gleichzeitig war WordPress über WP_HOME und WP_SITEURL bereits fest auf eine https://-Adresse eingestellt. Damit passten WordPress-Konfiguration und Serverkonfiguration nicht zusammen.

Nach dem Aktivieren des SSL-Schutzes beziehungsweise des Let’s-Encrypt-Zertifikats für die neue Subdomain war die entscheidende Ursache beseitigt. Genau deshalb sollte man bei ERR_TOO_MANY_REDIRECTS nach einem Domainwechsel nicht nur nach Redirect-Regeln suchen, sondern immer auch prüfen, ob HTTPS für den neuen Hostnamen auf Providerseite tatsächlich eingerichtet ist.

Warum daraus eine Redirect-Schleife entstehen kann

WordPress erwartet aufgrund seiner Konfiguration eine HTTPS-Verbindung. Der neue Hostname ist serverseitig aber noch nicht sauber für HTTPS eingerichtet. Je nach Webserver-, Proxy- oder Providerkonfiguration kann ein Request dadurch zwischen unterschiedlichen Zuständen beziehungsweise virtuellen Hosts hin- und hergeschickt werden. Für den Browser sieht das nur wie eine endlose Kette von Weiterleitungen aus.

Ein verwandtes Thema ist die gezielte HTTPS-Aktivierung im Backend. Dazu gibt es bereits den Beitrag WordPress: SSL / HTTPS für Backend / Adminbereich zuschalten.

Meine Reihenfolge für die Fehlersuche

Schritt 1: Prüfen, ob WP_HOME und WP_SITEURL wirklich auf den gewünschten Hostnamen zeigen.

Schritt 2: .htaccess und gegebenenfalls eine übergeordnete .htaccess nach alten 301-/302-Regeln durchsuchen.

Schritt 3: Plugins und frühe Cache-Dateien testweise ausschließen.

Schritt 4: Mit einer statischen test.html prüfen, ob die Domain wirklich im erwarteten Webspace beziehungsweise vHost landet.

Schritt 5: Beim Provider kontrollieren: Domainziel, Stammverzeichnis, PHP-Zuordnung und vor allem SSL/Let’s Encrypt für exakt diesen Hostnamen.

Schritt 6: Erst danach Datenbankwerte, Redirect-Plugins oder komplexere WordPress-Mechanismen anfassen.

Wichtig nach erfolgreicher Reparatur

Die Einträge WP_HOME und WP_SITEURL können als temporäre Rettungsmaßnahme sehr praktisch sein. Wenn die endgültige Domain feststeht, sollten die Werte sauber in WordPress beziehungsweise der Datenbank stimmen. Danach kann man entscheiden, ob die Konstanten dauerhaft bleiben oder wieder entfernt werden.

Wer zusätzlich mit www-/non-www-Weiterleitungen arbeitet, sollte darauf achten, dass nur eine Stelle die kanonische Weiterleitung übernimmt. Dazu passt auch mein Beitrag WordPress: Weiterleitung von www auf die Hauptdomain finden und prüfen.