WordPress HTTPS Fehler nach Umzug: Ursachen finden und sicher beheben

Ein WordPress HTTPS Fehler nach Umzug tritt häufig auf, wenn Domain, Hosting, SSL-Zertifikat oder Datenbank nicht vollständig auf die neue Umgebung abgestimmt sind. Typische Symptome sind Weiterleitungsschleifen, Warnungen im Browser, gemischte Inhalte, nicht erreichbare Verwaltungsbereiche oder eine Website, die nach dem Umzug nur teilweise funktioniert. In diesem Leitfaden erfährst Du, wie Du die Ursache systematisch eingrenzt und HTTPS auf Deiner WordPress-Website sauber wiederherstellst.

Passende WordPress Hilfe zum Thema

Was bedeutet ein HTTPS-Fehler nach einem WordPress-Umzug?

Die Darstellung macht sichtbar, dass DNS, Zertifikat, WordPress-URL und Weiterleitung voneinander abhängen. Prüfe diese Punkte nacheinander, damit Du widersprüchliche Änderungen und unnötige Umwege vermeidest.

HTTPS verschlüsselt die Verbindung zwischen Browser und Webserver. Technisch wird dafür ein SSL- beziehungsweise TLS-Zertifikat verwendet. Beim Umzug einer WordPress-Website ändern sich häufig mehrere technische Rahmenbedingungen gleichzeitig: der Server, die IP-Adresse, die Domain-Konfiguration, das Hosting-Control-Panel, der Webserver oder die PHP-Umgebung. Dadurch kann HTTPS zwar auf dem alten System funktioniert haben, auf dem neuen Server aber fehlerhaft eingerichtet sein.

WordPress selbst speichert die Website-Adresse in der Datenbank. In den Einstellungen WordPress-Adresse (URL) und Website-Adresse (URL) steht häufig entweder http:// oder https://. Zusätzlich können URLs in Beiträgen, Menüs, Widgets, Plugin-Einstellungen, Medienpfaden und individuellen Theme-Dateien gespeichert sein. Nach einem Umzug müssen diese Stellen nicht automatisch korrekt angepasst werden.

Wichtig ist deshalb die Unterscheidung zwischen verschiedenen Fehlerarten. Eine Browserwarnung wegen eines ungültigen Zertifikats hat eine andere Ursache als eine Weiterleitungsschleife. Ein Hinweis auf gemischte Inhalte wiederum bedeutet nicht unbedingt, dass das Zertifikat selbst defekt ist. Eine präzise Diagnose spart Zeit und verhindert, dass Du vorschnell mehrere Einstellungen gleichzeitig veränderst.

Typische Symptome eines HTTPS-Problems

Die konkrete Fehlermeldung liefert oft einen ersten Hinweis. Beobachte deshalb genau, wann der Fehler auftritt: beim Aufruf der Startseite, nur im Backend, nur bei bestimmten Unterseiten oder erst nach einer Anmeldung.

Symptom	Mögliche Ursache	Erster Prüfpunkt
„Verbindung ist nicht sicher“	Fehlendes, abgelaufenes oder nicht passendes Zertifikat	Zertifikat und Domain im Hosting prüfen
„Zu viele Weiterleitungen“	Widersprüchliche HTTP- und HTTPS-Regeln	WordPress-URLs und Serverregeln vergleichen
Schloss fehlt teilweise	Gemischte Inhalte durch HTTP-Ressourcen	Browser-Entwicklertools und Quellpfade prüfen
Backend nicht erreichbar	Falsche URL, Proxy-Konfiguration oder Weiterleitung	wp-admin, wp-config.php und Hosting prüfen
Nur einzelne Bilder fehlen	Alte absolute HTTP-URLs oder falsche Dateipfade	Medien-URLs und Datenbankeinträge prüfen

Vor der Fehlerbehebung: Backup und Bestandsaufnahme

Bevor Du URLs in der Datenbank, Serverregeln oder Plugin-Einstellungen änderst, solltest Du ein vollständiges Backup erstellen. Dazu gehören mindestens die WordPress-Datenbank und die Dateien der Installation. Besonders wichtig sind wp-content, die Datei wp-config.php sowie gegebenenfalls individuelle Serverkonfigurationen.

Wenn Dein Hosting eine Staging-Umgebung anbietet, ist sie für umfangreichere Korrekturen sinnvoll. Eine Änderung an der Datenbank oder an der Weiterleitung kann dazu führen, dass die Website vorübergehend nicht erreichbar ist. Ein Backup ersetzt keine sorgfältige Prüfung, ermöglicht aber eine Rückkehr zum vorherigen Zustand.

Notiere außerdem, was sich beim Umzug geändert hat:

• Wurde nur der Webspace gewechselt oder auch die Domain?
• Hat sich die Schreibweise der Domain geändert, etwa mit oder ohne www?
• Wurde ein CDN, ein Reverse Proxy oder ein externer DNS-Dienst aktiviert?
• Wurde das SSL-Zertifikat auf dem neuen Server eingerichtet?
• Wurde die Datenbank direkt importiert oder über ein Migrationswerkzeug ersetzt?
• Wurde die Website-Adresse bereits vor dem Umzug auf HTTPS umgestellt?

Diese Informationen helfen, die wahrscheinlichste Fehlerquelle einzugrenzen, statt wahllos Plugins zu deaktivieren oder mehrere Weiterleitungen zu kombinieren.

Die wichtigsten Prüfungen in der richtigen Reihenfolge

1. DNS und erreichbaren Server prüfen

Nach einem Umzug muss die Domain auf den neuen Server zeigen. Wenn die DNS-Einträge noch auf den alten Anbieter verweisen oder unterschiedliche Nameserver widersprüchliche Antworten liefern, kann HTTPS je nach Netzwerk und Zeitpunkt unterschiedlich reagieren. Prüfe insbesondere den A-Record für die Domain sowie gegebenenfalls den Eintrag für www.

Rufe die Domain mit und ohne www auf. Beide Varianten sollten bewusst konfiguriert sein. Eine Variante sollte als bevorzugte Adresse dienen, während die andere auf sie weiterleitet. Entscheidend ist, dass nicht mehrere Systeme gleichzeitig unterschiedliche Zieladressen erzwingen.

2. SSL-Zertifikat und Zertifikatsumfang kontrollieren

Das Zertifikat muss zur aufgerufenen Domain passen. Ein Zertifikat für example.de deckt nicht automatisch jede mögliche Unterdomain ab. Ebenso kann ein Zertifikat für www.example.de unzureichend sein, wenn Besucher die Version ohne www aufrufen.

Prüfe im Hosting-Panel, ob das Zertifikat aktiv, gültig und dem richtigen virtuellen Host zugeordnet ist. Bei einem automatischen Zertifikat muss außerdem die Domain während der Ausstellung korrekt auf den Server zeigen. Wenn ein CDN oder Proxy vor dem Webserver liegt, muss geklärt werden, an welcher Stelle TLS beendet wird und wie die Verbindung zum Ursprungsserver abgesichert ist.

3. WordPress-URLs kontrollieren

Wenn Du noch Zugriff auf das Backend hast, findest Du die beiden relevanten Werte meist unter Einstellungen > Allgemein. Sowohl die WordPress-Adresse als auch die Website-Adresse sollten die gewünschte HTTPS-Domain enthalten und exakt dieselbe Schreibweise verwenden.

Ändere diese Werte nicht mehrfach hintereinander, wenn Du die Erreichbarkeit nicht geprüft hast. Bei einem falsch gesetzten Wert kann das Backend sofort auf eine nicht funktionierende Adresse umleiten. Falls der Zugriff nicht möglich ist, können die URLs je nach Situation vorübergehend in der Datei wp-config.php definiert werden. Eine solche Festlegung sollte bewusst und dokumentiert erfolgen, damit sie später nicht mit den Datenbankwerten kollidiert.

4. Weiterleitungen nur an einer zentralen Stelle festlegen

Eine HTTPS-Weiterleitung kann im Webserver, in einer Konfigurationsdatei, im Hosting-Panel, in einem Sicherheits-Plugin oder über einen Proxy eingerichtet sein. Wenn mehrere dieser Ebenen gleichzeitig weiterleiten, entsteht leicht eine Schleife.

Eine typische problematische Konstellation ist folgende: Der Proxy erkennt HTTPS, übermittelt diese Information aber nicht korrekt an den Ursprungsserver. WordPress erhält dadurch den Eindruck, dass die Anfrage über HTTP eingeht, und leitet auf HTTPS um. Der Proxy nimmt die HTTPS-Adresse wiederum entgegen und wiederholt den Vorgang. In diesem Fall muss die Proxy- oder Serverkonfiguration so angepasst werden, dass WordPress das ursprüngliche Protokoll korrekt erkennen kann.

Vermeide es, einfach zusätzliche Weiterleitungsregeln einzufügen. Zuerst sollte klar sein, welche Ebene die Weiterleitung kontrolliert. Danach kann die Regel an einer einzigen, nachvollziehbaren Stelle bereinigt werden.

Gemischte Inhalte nach der Umstellung auf HTTPS beheben

Bei gemischten Inhalten wird die Seite selbst über HTTPS geladen, einzelne Ressourcen werden aber noch über HTTP angefordert. Dazu können Bilder, Stylesheets, JavaScript-Dateien, Webfonts oder Inhalte eingebetteter Dienste gehören. Browser behandeln solche Ressourcen unterschiedlich und können sie blockieren oder als unsicher markieren.

Öffne die betroffene Seite im Browser und rufe die Entwicklertools auf. In der Konsole oder im Sicherheitsbereich werden häufig die konkreten HTTP-URLs genannt. Prüfe anschließend, woher die URL stammt:

• aus einem Bild oder Link im Beitrag;
• aus einem Widget oder Menü;
• aus den Einstellungen eines Plugins;
• aus einer CSS-Datei des Themes oder Child-Themes;
• aus einem JavaScript-Snippet oder einer individuellen Integration;
• aus einem alten Datenbankeintrag nach der Migration.

Bei eigenen Inhalten sollte die absolute HTTP-URL durch eine HTTPS-URL ersetzt werden. Relative oder protokollunabhängige Pfade können in bestimmten Fällen ebenfalls sinnvoll sein, müssen aber zum jeweiligen Anwendungsfall passen. Bei einer größeren Migration kann eine kontrollierte Suche-und-Ersetzen-Anpassung in der Datenbank erforderlich sein. Dabei muss die Serialisierung von WordPress-Daten berücksichtigt werden. Eine unvorsichtige Bearbeitung per einfachem SQL-Ersetzen kann strukturierte Plugin- oder Theme-Daten beschädigen.

Nach der Korrektur solltest Du den Cache leeren. Dazu können der WordPress-Cache, ein Plugin-Cache, der Server-Cache, ein CDN-Cache und der Browser-Cache gehören. Prüfe danach mehrere Seiten, nicht nur die Startseite.

WordPress-HTTPS-Fehler im Backend und bei Anmeldungen

Wenn die Startseite funktioniert, aber /wp-admin oder die Anmeldung nicht, liegt die Ursache häufig in einer inkonsistenten URL- oder Proxy-Konfiguration. Auch Cookies können durch eine zwischenzeitlich wechselnde Domain- oder Protokolladresse ungültig werden.

Prüfe zunächst, ob die Verwaltungsadresse exakt zur Website-Adresse passt. Lösche anschließend gegebenenfalls alte Browser-Cookies für die Domain und teste die Anmeldung erneut. Wenn ein Sicherheits- oder Cache-Plugin Weiterleitungen für Anmeldeseiten steuert, kann es vorübergehend deaktiviert werden müssen. Das sollte möglichst über einen kontrollierten Dateizugriff und mit einem vorherigen Backup erfolgen.

Bei vorgeschalteten Proxies ist außerdem die Weitergabe des ursprünglichen Protokolls relevant. WordPress kann HTTPS unter bestimmten Serverbedingungen nicht automatisch erkennen. Eine passende Konfiguration muss zur konkreten Serverumgebung passen; pauschale Codeänderungen in wp-config.php sind daher nicht immer die richtige Lösung.

Häufige Fehler und passende Lösungen

HTTPS wird erzwungen, obwohl das Zertifikat noch nicht aktiv ist

Wird unmittelbar nach einem Umzug eine globale HTTPS-Weiterleitung aktiviert, bevor das Zertifikat korrekt erreichbar ist, ist die Website unter Umständen nicht mehr aufrufbar. Prüfe zuerst Zertifikat, DNS und Serverzuordnung. Erst danach sollte die Weiterleitung aktiviert oder verschärft werden.

HTTP- und HTTPS-Version werden parallel betrieben

WordPress sollte eine eindeutige bevorzugte Adresse haben. Wenn interne Links, Canonical-URLs und Weiterleitungen unterschiedliche Varianten verwenden, entstehen unnötige Umwege und möglicherweise widersprüchliche Signale für Suchmaschinen. Korrigiere die Website-Adresse, interne Verweise und relevante SEO-Einstellungen konsistent.

Nur die Startseite funktioniert

Wenn Unterseiten einen Fehler ausgeben, kann die Rewrite-Konfiguration des Webservers fehlen oder nicht zum neuen Hosting passen. Bei Apache ist beispielsweise die Verarbeitung der WordPress-Regeln relevant, bei Nginx werden die Regeln üblicherweise in der Serverkonfiguration definiert. WordPress-Dateien allein können diese Servereinstellungen nicht ersetzen.

Ein Plugin verursacht weiterhin HTTP-Aufrufe

Plugins können eigene Endpunkte, externe Ressourcen oder gespeicherte URLs verwenden. Deaktiviere nicht sofort alle Erweiterungen dauerhaft. Führe einen kontrollierten Test durch, dokumentiere die Änderung und prüfe, ob der Fehler nach einer gezielten Deaktivierung verschwindet. Danach sollte die Konfiguration des betroffenen Plugins aktualisiert oder die Ursache in dessen Ausgabe beziehungsweise Integration behoben werden.

Ein alter Cache zeigt weiterhin die fehlerhafte Version

Nach einem Umzug können mehrere Cache-Ebenen alte Weiterleitungen oder Ressourcen ausliefern. Leere sie in einer nachvollziehbaren Reihenfolge und teste zusätzlich in einem privaten Browserfenster. Auch ein CDN kann eine andere Version ausliefern als der Ursprungsserver.

Technische Besonderheiten bei Migrationen

Datenbank und gespeicherte URLs

Eine WordPress-Migration überträgt Inhalte und Einstellungen, aber nicht jede URL wird automatisch auf die neue Umgebung angepasst. Absolute Pfade können in Beiträgen, Metadaten, Widgets, Optionen und Plugin-Tabellen vorkommen. Außerdem enthalten manche Datenbankwerte serialisierte Arrays. Deshalb sollte ein Such-und-Ersetzen-Werkzeug verwendet werden, das WordPress-Strukturen korrekt behandelt, oder die Anpassung sollte über ein geprüftes Migrationsverfahren erfolgen.

Vor einer solchen Änderung gehören ein Datenbankbackup, eine Prüfung der Ziel- und Quelladresse sowie ein Testlauf zu den sinnvollen Vorbereitungen. Ersetze nicht pauschal jede Zeichenfolge, wenn mehrere Domains oder externe URLs in der Datenbank vorkommen.

Webserver, PHP und WordPress-Core

HTTPS selbst wird in erster Linie durch Webserver und Zertifikatsverwaltung bereitgestellt. WordPress verarbeitet anschließend die Anfrage und erzeugt interne URLs. Eine passende PHP-Version und aktuelle WordPress-Komponenten sind für die Stabilität wichtig, lösen aber ein falsch zugeordnetes Zertifikat nicht automatisch.

Bearbeite keine WordPress-Core-Dateien, um eine HTTPS-Weiterleitung zu erzwingen. Solche Änderungen sind bei späteren Updates nicht updatefest. Nutze stattdessen die Konfiguration des Hostings, updatefähige Hooks, ein Child-Theme oder eine geeignete Plugin-Konfiguration. Jede individuelle Anpassung sollte dokumentiert werden.

CDN, Reverse Proxy und Weitergabe des Protokolls

Bei einer vorgeschalteten Infrastruktur gibt es mindestens zwei Verbindungen: vom Browser zum Proxy und vom Proxy zum Ursprungsserver. Beide können unterschiedlich verschlüsselt sein. Ob das für Deine Umgebung vertretbar ist, hängt von der Konfiguration und dem Schutzbedarf ab. Wichtig ist, dass der Ursprungsserver die Anfrage nicht falsch als HTTP interpretiert und dadurch eine Schleife erzeugt.

Prüfe die Einstellungen für TLS-Modus, Ursprungszertifikat und Weitergabe des ursprünglichen Protokolls. Eine Änderung am Proxy kann Auswirkungen auf Caching, Cookies, Sicherheitsheader und Webhooks haben. Deshalb sollte sie kontrolliert und anschließend mit Frontend, Backend und wichtigen Integrationen getestet werden.

Praxisbeispiel: Weiterleitungsschleife nach dem Hostingwechsel

Angenommen, eine Website wurde auf einen neuen Server verschoben. Das Zertifikat ist im Hosting-Panel aktiv, aber der Browser meldet „zu viele Weiterleitungen“. Die WordPress-Adresse steht auf HTTPS. Zusätzlich erzwingt ein Plugin HTTPS, während der vorgeschaltete Proxy die Verbindung zum Ursprungsserver anders meldet.

Eine sinnvolle Analyse beginnt nicht mit dem Löschen aller Plugins. Zuerst wird geprüft, ob die Domain tatsächlich den neuen Server erreicht und welches Zertifikat ausgeliefert wird. Danach werden die Weiterleitungen mit HTTP, HTTPS, mit und ohne www verglichen. Wenn die Schleife nur über den Proxy entsteht, wird dessen Protokollübergabe geprüft. Anschließend wird kontrolliert, ob die HTTPS-Erzwingung gleichzeitig im Plugin und im Webserver aktiv ist.

Nach der Korrektur sollte die Website in mehreren Szenarien getestet werden: Startseite, Unterseite, Anmeldung, Medien, Kontakt- oder Shop-Funktionen sowie externe Rückmeldungen wie Webhooks. Erst wenn die Tests erfolgreich sind, sollte der Cache endgültig geleert und die Änderung dokumentiert werden.

Checkliste für die systematische Behebung

1. Vollständiges Backup von Datenbank und Dateien erstellen.
2. Domain, DNS-Ziel und bevorzugte Schreibweise mit oder ohne www prüfen.
3. SSL-Zertifikat, Gültigkeit und abgedeckte Hostnamen kontrollieren.
4. WordPress-Adresse und Website-Adresse auf eine konsistente HTTPS-URL prüfen.
5. Alle Weiterleitungsebenen identifizieren: Hosting, Webserver, Plugin und Proxy.
6. Eine mögliche Weiterleitungsschleife mit verschiedenen URL-Varianten eingrenzen.
7. Gemischte Inhalte über Browser-Entwicklertools suchen.
8. Gespeicherte HTTP-URLs in Inhalten, Theme, Plugins und Datenbank kontrolliert ersetzen.
9. Caches auf WordPress-, Server-, CDN- und Browserseite leeren.
10. Frontend, Backend, Medien, Formulare, Shop-Funktionen und externe Schnittstellen testen.
11. Die endgültige Konfiguration und durchgeführte Änderungen dokumentieren.

FAQ

Warum erscheint nach dem Umzug eine HTTPS-Warnung?

Häufig ist das Zertifikat auf dem neuen Server nicht aktiv, nicht der richtigen Domain zugeordnet oder deckt die aufgerufene Variante nicht ab. Auch DNS-Einträge, die noch auf den alten Server zeigen, können dazu führen, dass ein anderes Zertifikat ausgeliefert wird.

Warum entsteht eine Weiterleitungsschleife zwischen HTTP und HTTPS?

Eine Schleife entsteht meist, wenn mehrere Systeme die Protokolladresse unterschiedlich interpretieren. WordPress, Webserver, Sicherheits-Plugin und Proxy müssen erkennen und verwenden, welche Adresse als HTTPS gilt. Prüfe die Ebenen einzeln und vermeide doppelte Weiterleitungsregeln.

Wie kann ich WordPress auf HTTPS umstellen, wenn das Backend nicht erreichbar ist?

Prüfe zunächst, ob DNS und Zertifikat funktionieren. Je nach Situation können die Website-URLs vorübergehend über die Datenbank oder die Konfiguration festgelegt werden. Erstelle vorher ein Backup und ändere nur eine klar dokumentierte Einstellung. Bei Unsicherheit ist eine kontrollierte Wiederherstellung oder technische Unterstützung sicherer als mehrere unkoordinierte Änderungen.

Was bedeutet „gemischte Inhalte“?

Die Seite wird über HTTPS geladen, fordert aber einzelne Ressourcen noch über HTTP an. Das betrifft häufig Bilder, Stylesheets, JavaScript-Dateien oder externe Einbindungen. Die konkrete HTTP-Quelle findest Du meist in den Browser-Entwicklertools.

Muss ich alle WordPress-URLs in der Datenbank ändern?

Nicht zwingend. Die beiden grundlegenden Website-URLs müssen konsistent sein, weitere alte URLs können aber in Inhalten oder Plugin-Daten gespeichert sein. Eine größere Ersetzung sollte kontrolliert erfolgen und serialisierte Daten berücksichtigen. Ein vollständiges Backup ist vorher erforderlich.

Kann ein SSL-Plugin alle HTTPS-Fehler lösen?

Ein Plugin kann bestimmte WordPress-Einstellungen oder Weiterleitungen unterstützen, aber es kann kein falsch ausgestelltes Zertifikat, ein DNS-Problem oder eine fehlerhafte Proxy-Konfiguration ersetzen. Die Ursache sollte zuerst auf der passenden technischen Ebene behoben werden.

Wie prüfe ich, ob der Fehler wirklich behoben ist?

Teste mehrere URL-Varianten, die Startseite, Unterseiten, das Backend, Medien und wichtige Funktionen. Prüfe außerdem Browserwarnungen, Weiterleitungsketten und gemischte Inhalte. Ein Test in einem privaten Browserfenster hilft, alte Cookies und Cache-Einträge auszuschließen.

Fazit

Ein WordPress HTTPS Fehler nach Umzug ist selten auf eine einzige Einstellung beschränkt. Meist müssen DNS, Zertifikat, WordPress-URLs, Weiterleitungen, gespeicherte Ressourcen und gegebenenfalls ein Proxy gemeinsam betrachtet werden. Arbeite mit Backup, klarer Reihenfolge und dokumentierten Änderungen. Prüfe zuerst die technische Erreichbarkeit und das Zertifikat, danach die WordPress-Konfiguration und zuletzt gemischte Inhalte sowie Caches. So lässt sich die Ursache nachvollziehbar eingrenzen, ohne die Website durch unkoordinierte Änderungen zusätzlich zu gefährden.