WordPress-HTTPS-Probleme und Weiterleitungsschleifen beheben

Kurz gesagt: Halte die genaue Fehlermeldung fest. Bei einer Zertifikatswarnung prüfst du zuerst Domain und Hosting-Zertifikat; bei einer Schleife die Abfolge der Weiterleitungen. WordPress-Adresse, Serverregeln und gegebenenfalls Proxy müssen dieselbe endgültige HTTPS-Adresse verwenden.

Bevor du anfängst

• Fehlerart notieren: Zertifikatswarnung, Verbindungsfehler, Weiterleitungsschleife oder blockierte Inhalte?
• Gewünschte endgültige Domain festlegen, einschließlich www oder ohne www.
• Letzte Änderungen an Domain, Zertifikat, Proxy, Hosting und WordPress-Adressen zusammentragen.

1. Trenne Zertifikatsfehler, Schleife und gemischte Inhalte

Bei einer Zertifikatswarnung scheitert zunächst die vertrauenswürdige verschlüsselte Verbindung zur aufgerufenen Domain. Bei einer Weiterleitungsschleife kommt dagegen eine Antwort an, die den Browser immer wieder auf eine andere oder dieselbe Adresse schickt. „Mixed Content“ bedeutet, dass eine HTTPS-Seite zusätzlich Inhalte über eine unverschlüsselte Adresse einbinden will. Diese Fälle brauchen unterschiedliche Maßnahmen.

Notiere die Adresse in der Browserleiste und den exakten Fehlertext. Tritt das Problem auf der gesamten Website oder nur beim Login auf? Funktioniert die Variante ohne www anders als die mit www? Prüfe diese Varianten ohne Passwörter oder Formulardaten einzugeben. Ignoriere eine Zertifikatswarnung nicht, um trotzdem administrative Zugangsdaten zu senden.

• ERR_TOO_MANY_REDIRECTS: weiter bei der Prüfung der Weiterleitungskette in Schritt 3.
• ERR_CERT_DATE_INVALID: Datum des Geräts sowie Gültigkeitszeitraum des Zertifikats prüfen.
• ERR_CERT_COMMON_NAME_INVALID: aufgerufenen Hostnamen mit den im Zertifikat enthaltenen Domainnamen vergleichen.
• ERR_CERT_AUTHORITY_INVALID: Zertifikatskette und Vertrauensstellung prüfen lassen; nicht durch Abschalten der Zertifikatsprüfung umgehen.
• Die Seite lädt, aber die Konsole meldet „Mixed Content“: die betroffenen Ressourcen anhand von Schritt 5 prüfen.

2. Bei einer Zertifikatswarnung zuerst das Hosting prüfen

Kontrolliere im Hostingkonto, ob für die betroffene Domain ein gültiges Zertifikat eingerichtet ist und ob die Domain dem richtigen Website-Ziel zugeordnet wurde. Ein Zertifikat für eine andere Adresse hilft der aufgerufenen Domain nicht. Nach Umzügen können einzelne Domainvarianten noch auf ein anderes Ziel zeigen. Deshalb ist die konkrete Adresse entscheidend, nicht nur der Projektname beim Hoster.

Prüfe außerdem, ob die automatische Verlängerung erfolgreich war und ob der Hoster einen Konfigurationsfehler meldet. Eine WordPress-Einstellung kann ein abgelaufenes oder am falschen Server eingebundenes Zertifikat nicht reparieren. Ändere in dieser Situation nicht wahllos die Website-Adresse: Die verschlüsselte Verbindung muss zuerst zuverlässig funktionieren, bevor die Anwendung auf dieser Adresse betrieben wird.

3. Bei einer Schleife die Weiterleitungskette sichtbar machen

Du brauchst dafür zunächst nur deinen Desktop-Browser. In Chrome öffnest du das Drei-Punkte-Menü und „Weitere Tools → Entwicklertools“. Wähle den Reiter „Netzwerk“ beziehungsweise „Network“ und aktiviere „Protokoll beibehalten“ beziehungsweise „Preserve log“. Rufe anschließend die betroffene Adresse neu auf. Der Netzwerkbereich zeichnet nur Anfragen auf, die nach seinem Öffnen stattfinden.

Dokumentiere die Abfolge, bevor du etwas abschaltest. Weiterleitungen können im Hosting, in der Serverkonfiguration, in WordPress, in einem Plugin oder einem vorgeschalteten Dienst entstehen. Wenn zwei Ebenen unterschiedliche Zieladressen erzwingen, verstärken zusätzliche Regeln das Problem. Entscheide stattdessen, welche Ebene welche Aufgabe übernehmen soll, und korrigiere den konkreten Widerspruch.

1. Die Seitenanfragen auswählen Filtere nach „Dokument“ beziehungsweise „Doc“ oder suche die Anfragen deiner betroffenen Seitenadresse. Klicke eine Anfrage mit Status 301, 302, 307 oder 308 an. Unter „Headers“ beziehungsweise „Kopfzeilen“ findest du in den Antwort-Headern „Location“: Das ist die Zieladresse der Weiterleitung.
2. Den Kreislauf notieren Notiere Ausgangs- und Zieladresse der aufeinanderfolgenden Seitenanfragen. Steht etwa bei der ersten Antwort https://example.org/ und bei der nächsten wieder http://example.org/, hast du den Widerspruch sichtbar gemacht. Eine Folge von A nach B und zurück nach A ist hilfreicher als nur der Browserfehler.
3. Nur den relevanten Befund weitergeben Teile die anonymisierte Abfolge oder einen auf die URL und den Status zugeschnittenen Screenshot. Exportiere nicht ungeprüft das gesamte Netzwerkprotokoll: Es kann Cookies, Sitzungsschlüssel und Formulardaten enthalten.

• http ↔ https: Verschlüsselungseinstellung und Erkennung der ursprünglichen Verbindung prüfen.
• www ↔ ohne www: bevorzugte Domain und widersprüchliche Domainweiterleitungen abgleichen.
• Anmeldung ↔ Adminbereich: Website-Adressen, HTTPS-Erkennung und sitzungsbezogene Regeln prüfen.
• Nur eine Unterseite betroffen: einzelne Weiterleitungsregeln und deren Ziel kontrollieren.

4. WordPress-Adressen und Proxy aufeinander abstimmen

Unter „Einstellungen → Allgemein“ stehen WordPress-Adresse und Website-Adresse. In einer einfachen Installation passen sie gewöhnlich zur vorgesehenen Domain und HTTPS-Konfiguration. Es gibt aber legitime Installationen mit WordPress in einem Unterverzeichnis. Setze beide Werte daher nicht pauschal gleich. Sichere die bestehenden Angaben und kläre die tatsächliche Struktur, bevor du sie änderst.

Die Werte können auch über die Konfiguration vorgegeben sein. Dann löst eine Änderung an einer anderen Stelle den Konflikt möglicherweise nicht. Wenn der Adminbereich nicht erreichbar ist, sollten die tatsächlich wirksamen Einstellungen fachlich geprüft werden, statt mehrere Korrekturplugins nacheinander zu installieren.

Besonders wichtig ist ein vorgeschalteter Proxy: Der Besucher kann HTTPS nutzen, während WordPress intern eine andere Verbindung sieht. Ohne korrekt eingerichtete Weitergabe und Auswertung dieser Information kann WordPress erneut auf HTTPS umleiten. Die Lösung gehört zur konkreten Serverarchitektur. Übernimm keine beliebige Header-Abfrage aus dem Internet; nur Informationen des dafür vorgesehenen, vertrauenswürdigen Proxys dürfen maßgeblich sein.

5. Gemischte Inhalte separat bereinigen

Wenn die Seite bereits über HTTPS lädt, aber Bilder, Schriften oder Skripte fehlen, prüfe die Browserkonsole auf blockierte unsichere Ressourcen. Ermittle, woher die betroffene URL stammt: ein Bild im Inhalt, eine Theme-Einstellung, ein Stylesheet oder ein externer Anbieter. Ersetze sie durch die passende erreichbare HTTPS-Adresse und teste die betreffende Funktion erneut.

Bei einer Domain- oder HTTPS-Migration können viele alte Verweise in der Datenbank liegen. Nutze für eine umfangreiche Ersetzung ein geeignetes Verfahren mit Sicherung und Vorschau. Ein blindes Suchen und Ersetzen in einem Datenbankexport kann strukturierte oder serialisierte Werte beschädigen. Externe Ressourcen, die gar kein HTTPS anbieten, müssen gegebenenfalls ersetzt oder entfernt werden.

6. Abschließend alle Einstiegswege testen

Teste die Startseite und wichtige Unterseiten in den Varianten http, https, www und ohne www. Nicht jede Variante muss eine eigene Website ausliefern; sie sollte aber nachvollziehbar am vorgesehenen sicheren Ziel enden. Prüfe anschließend Anmeldung, Formulare und gegebenenfalls den Shop. Leere nach der Korrektur passende Caches und wiederhole den Test in einer frischen Sitzung.

Ersetze in dieser Testliste example.org durch deine eigene Domain. Öffne jede Adresse einzeln und notiere Fehler sowie die endgültige Browseradresse. Wiederhole die Liste zusätzlich mit dem Pfad einer wichtigen Unterseite. Das gewünschte Ergebnis ist die richtige Seite auf deiner festgelegten HTTPS-Domain, ohne Warnung, Schleife oder verlorenen Unterseitenpfad.

Cookies zu löschen kann bei einzelnen Sitzungsproblemen helfen, behebt aber keine widersprüchlichen Serverregeln für sämtliche Besucher. Dokumentiere die endgültige Domain und die eingerichteten Weiterleitungsebenen. Für Unterstützung sind Fehlertext, betroffene URLs, Zeitpunkt und Angaben zu Hosting oder Proxy hilfreich. So kann die Reparatur an der tatsächlich verantwortlichen Ebene beginnen.

http://example.org/
https://example.org/
http://www.example.org/
https://www.example.org/

Häufige Fragen

Kann ein SSL-Plugin das Zertifikat reparieren?

Ein Plugin kann bestimmte WordPress-Einstellungen oder Inhaltsverweise beeinflussen. Ein ungültiges oder falsch eingebundenes Zertifikat am Server muss jedoch dort korrigiert werden. Prüfe daher zuerst, welche Fehlerart tatsächlich vorliegt.

Soll ich bei „zu viele Weiterleitungen“ nur die Cookies löschen?

Ein frisches Browserfenster ist ein sinnvoller Vergleichstest. Betrifft die Schleife aber auch neue Besucher, liegt die Ursache häufig in den Weiterleitungs- oder Anwendungseinstellungen. Cookies zu löschen ersetzt dann keine Prüfung der Weiterleitungskette.

Müssen WordPress-Adresse und Website-Adresse immer identisch sein?

Nein. In vielen einfachen Installationen sind sie gleich, eine Installation von WordPress in einem Unterverzeichnis kann aber absichtlich unterschiedliche Werte verwenden. Prüfe deshalb die vorhandene Struktur, bevor du Adressen vereinheitlichst.

Warum begann die Schleife erst nach der Aktivierung eines Proxys?

Ein Proxy verändert den Weg zwischen Browser und WordPress. Wenn WordPress die ursprüngliche HTTPS-Verbindung nicht korrekt erkennt oder zwei Ebenen gegensätzliche Regeln verwenden, können wiederholte Weiterleitungen entstehen. Die sichere Konfiguration muss zum eingesetzten Proxy und Server passen.