Nach dem Umzug öffnet die Startseite über HTTPS, aber einzelne Besucher erhalten ein altes Zertifikat. Medien laden noch von der früheren HTTP-Domain, und Zahlungs-Callbacks zeigen auf den abgeschalteten Host.
Eine erfolgreiche Startseite beweist deshalb keinen abgeschlossenen HTTPS-Umzug. DNS, Zertifikate, WordPress-Daten, CDN, Cookies und externe Integrationen müssen gemeinsam auf den neuen Zielzustand gebracht werden.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Welche Ebenen ein HTTPS-Umzug betrifft
Eine Migration verschiebt Dateien und Datenbank, während DNS, Zertifikatsbindungen und CDN-Konfiguration außerhalb von WordPress liegen. In WordPress selbst können die alte Domain oder das alte Schema in Optionen, Inhalten, Widgets und serialisierten Werten gespeichert sein.
Hinzu kommen erzeugte URLs und externe Verbraucher: Cronjobs, Webhooks, OAuth- und Zahlungs-Callbacks, Sitemaps und Links in E-Mails. Jede Abhängigkeit braucht einen eigenen Test und gegebenenfalls eine Übergangsweiterleitung.
Ein realistisches WordPress-Beispiel
Der A-Record zeigt auf den neuen Hoster, der alte AAAA-Record jedoch weiterhin auf den bisherigen Server. IPv4-Besucher sehen das neue Zertifikat, IPv6-Besucher das alte. Gleichzeitig verweist die CDN-Origin-Konfiguration noch auf die frühere Domain.
Das Team korrigiert IPv6 und CDN-Ziel, prüft beide Adressfamilien und ersetzt WordPress-URLs mit einem serialisierungssicheren Verfahren. Erst danach werden Callbacks umgestellt und der alte Host auf eine überwachte Weiterleitung reduziert.
Warum der alte Zustand zunächst erreichbar bleiben sollte
DNS-Caches, alte E-Mail-Links und externe Systeme wechseln nicht gleichzeitig. Wird der bisherige Host zu früh abgeschaltet, gehen Webhooks oder Transaktionen verloren und ein Rollback wird unnötig schwer.
Halten Sie die alte Umgebung innerhalb eines festgelegten Fensters mit gültigem TLS erreichbar. Protokollieren Sie Restzugriffe, bevor sie nur noch weiterleitet oder endgültig außer Betrieb geht.
Der einfache Weg für Einsteiger
- Sichern Sie alte und neue Website und notieren Sie DNS, WordPress-URLs und Redirects.
- Installieren Sie ein gültiges Zertifikat für jeden neuen Host.
- Prüfen Sie DNS über mehrere Resolver und berücksichtigen Sie IPv6.
- Aktualisieren Sie WordPress-Adresse, Website-Adresse und gespeicherte Verweise sicher.
- Leeren Sie WordPress-, CDN- und Browser-Caches gezielt.
- Testen Sie Medien, Login, Formulare, Checkout, Sitemap und externe Callbacks.
Der technische Weg
Führen Sie eine Migrationsmatrix mit altem Wert, neuem Wert, zuständigem System, Umschaltzeit, TTL, Test und Rollback. Einträge umfassen A- und AAAA-Records, Edge- und Originzertifikat, CDN-Origin, home, siteurl, Medienhost, Cookies, REST, Cron, OAuth, Zahlung, Webhooks und Sitemap.
- Verwenden Sie für serialisierte WordPress-Daten ein geeignetes Werkzeug.
- Vergleichen Sie komplexe Werte stichprobenartig vor und nach der Ersetzung.
- Testen Sie alte und neue Hosts über HTTP und HTTPS.
- Überwachen Sie den alten Host auf verbleibende echte Nutzung.
Risiken, häufige Fehler, Backup und Rollback
Pauschaler SQL-Textersatz kann serialisierte Daten beschädigen. Ein zu früher DNS- oder Redirect-Wechsel entfernt den Rückweg, während vergessene AAAA-Records oder CDN-Bindungen alte Zertifikate ausliefern.
- Schalten Sie die alte Umgebung erst nach dokumentierter Abnahme ab.
- Ändern Sie nicht mehrere URL-Ebenen ohne Zwischenprüfung.
- Bewahren Sie Datenbankbackup und alte Infrastrukturwerte auf.
- Rollen Sie zurück, wenn Transaktionen, Webhooks oder Login nicht zuverlässig funktionieren.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige Prüfung des HTTPS-Zustands nach einem Umzug. Damit können Sie kontrollieren, ob die Anwendung die neuen sicheren Adressen verwendet und ob die relevanten unterstützten SSL-Einstellungen am Ziel konsistent sind.
Bereiten Sie zuerst DNS, Zertifikate und den öffentlichen Endpunkt vor. Erfassen Sie anschließend die bisherigen und neuen WordPress-Adressen und nehmen Sie nur die notwendige unterstützte Anpassung vor. Testen Sie danach Startseite, Login, Administration, Medien, REST, Formulare und Checkout sowohl anonym als auch angemeldet. Alte und neue Hosts sollten während des Übergangs getrennt beobachtet werden.
Der SSL Manager ändert keine externen DNS- oder CDN-Ziele und aktualisiert keine OAuth-, Zahlungs- oder Webhook-Konfiguration bei Drittanbietern. Auch gespeicherte Inhalte müssen mit einem serialisierungssicheren Verfahren migriert werden. Halten Sie daher den bisherigen WordPress-Zustand und die alte Infrastruktur erreichbar, bis alle Abhängigkeiten geprüft sind. Wenn die WordPress-seitige Änderung Probleme verursacht, stellen Sie die vorherigen Werte wieder her und beheben zuerst DNS oder Zertifikatsbindung. AIOWS hilft bei der Anwendungsebene; die Abnahme des gesamten Umzugs bleibt eine gemeinsame Infrastruktur- und Integrationsaufgabe.
Passende AIOWS-Artikel
- SSL auf einer WordPress-Website richtig einrichten
- Mixed-Content-Bilder in WordPress beheben
- HTTPS-Canonical-URLs und Sitemaps in WordPress
Fazit und empfohlener Weg
Führen Sie den Umzug vom erreichbaren HTTPS-Ziel über WordPress bis zu allen Integrationen. Behalten Sie die alte Umgebung und einen klaren Rollback, bis DNS, Caches, Medien und externe Systeme nachweislich den neuen Host verwenden.
