Eine neue Domain im Hostingpanel und zwei geänderte WordPress-Felder ergeben noch keinen vollständigen Websiteumzug. In einer Installation können Adressen in Texten, Menüs, Bildern, Themeoptionen und externen Diensten stecken. Zusätzlich müssen DNS, Zertifikate und Weiterleitungen zum neuen Ziel passen. Dieser Ratgeber führt durch die Zusammenhänge, damit Sie Änderungen in einer kontrollierten Reihenfolge durchführen. Er beschreibt sowohl einen Domainwechsel als auch die Umstellung einer bestehenden Adresse auf HTTPS. Eine Veränderung am öffentlichen Ziel sollte nur für die tatsächlich freigegebene Website erfolgen.
Das gewünschte Ergebnis ist eindeutig: Besucher erreichen die neue Hauptadresse mit gültigem Zertifikat, alte Links führen gezielt zu ihren entsprechenden Inhalten und die Website lädt keine versehentlich verbliebenen unsicheren Ressourcen. Für diese Arbeit benötigen Sie Zugriff auf die Installation und auf ihre Domainkonfiguration. Wenn einzelne Bereiche von verschiedenen Dienstleistern verwaltet werden, klären Sie die Zuständigkeiten zuerst. Ändern Sie keine Mail- oder globalen DNS-Einträge, nur weil Sie die Website umziehen. Web und Mail haben zwar denselben Domainnamen, aber unterschiedliche Aufgaben.
Den Umzug in drei Ebenen zerlegen
Die erste Ebene ist die Namensauflösung: Welche IP-Adressen veröffentlicht die Domain? Die zweite Ebene ist der Webserver: Welcher Website wird eine Anfrage für den Namen zugeordnet, und welches Zertifikat liefert er? Die dritte Ebene ist WordPress: Welche Hauptadresse verwendet die Anwendung und welche Links stehen in ihren Inhalten? Fehler wirken oft ähnlich, obwohl sie auf unterschiedlichen Ebenen entstehen. Eine Standardseite des Hosters deutet etwa auf eine falsche Websitezuordnung hin; eine Loginweiterleitung zur alten Domain kann aus gespeicherten WordPress-Adressen stammen.
Notieren Sie daher vor Beginn alte und neue Adresse einschließlich https://, www-Variante und eventuellem Unterverzeichnis. Legen Sie eine einzige Hauptadresse fest. Für Besucher dürfen alternative Varianten bequem weiterleiten, aber Ihre internen Links sollten möglichst direkt die Hauptadresse nutzen. Wenn gleichzeitig Pfade geändert werden sollen, behandeln Sie diese separat. Ein Domainwechsel mit unveränderten Pfaden ist leichter zu prüfen als ein Wechsel, bei dem auch jede Inhaltsadresse neu erfunden wird. Zusätzliche Strukturänderungen benötigen eine eigene Zuordnungstabelle.
Einen zusammengehörigen Ausgangsstand sichern
Erstellen Sie ein Backup von Dateien und Datenbank unmittelbar vor den Eingriffen. Notieren Sie den Zeitpunkt und kontrollieren Sie, ob alle benötigten Medien enthalten sind. Bei einem dynamischen Projekt können nach dem Backup neue Daten entstehen. Planen Sie deshalb ein passendes Wartungsfenster oder einen selektiven Transfer. Eine kopierte Datenbank von gestern kann nicht ungeprüft über heutige Bestellungen geschrieben werden. Dasselbe Prinzip gilt für Kommentare und parallele redaktionelle Änderungen, auch wenn keine Verkaufsfunktion vorhanden ist.
Exportieren Sie zusätzlich eine Liste wichtiger alter URLs. Sie kann aus Navigation, Inhaltsübersicht und bekannten externen Verlinkungen entstehen. Wählen Sie repräsentative Beispiele: Startseite, lange Artikeladresse, Kategorie, Suche und eine Datei. Notieren Sie zu jedem Beispiel den erwarteten neuen Zielpfad. Damit wird die spätere Prüfung konkret. Die WordPress-Migrationsdokumentation beschreibt verschiedene Umzugssituationen; Ihr eigenes Protokoll legt fest, welche davon tatsächlich auf das Projekt zutrifft.
| Beobachtung | Mögliche Ebene | Nächste Prüfung |
|---|---|---|
| Falsche Standardseite | Webserverzuordnung oder DNS | Domain und Hostingziel vergleichen |
| Zertifikatswarnung | TLS für angefragten Namen | Zertifikatsnamen und Kette ansehen |
| Login springt zurück | WordPress-Adresse oder Proxykonfiguration | Gespeicherte URLs kontrollieren |
| Einzelne Bilder unsicher | Inhalt oder Theme | Konkrete Ressourcenadresse ermitteln |
Neues Hostingziel und Zertifikat vorbereiten
Die neue Domain muss der richtigen Website zugewiesen sein, bevor Sie den öffentlichen Verkehr dorthin lenken. Prüfen Sie die ausgewählte IPv4- und, wenn vorgesehen, IPv6-Adresse im tatsächlichen Hostingbestand. Ein AAAA-Eintrag sollte nur veröffentlicht werden, wenn das zugehörige Ziel dieselbe Website zuverlässig über natives IPv6 bereitstellt. Eine IPv6-Adresse im Panel ist kein Beleg für vollständigen Dualstackbetrieb. Prüfen Sie die beiden Adressfamilien unabhängig und dokumentieren Sie eine fehlende Veröffentlichung ausdrücklich.
Für HTTPS benötigen Hauptdomain und verwendete Alternativnamen ein passendes Zertifikat. Kontrollieren Sie Ablaufdatum und Namensabdeckung im Browser oder mit einem geeigneten Prüfwerkzeug. Aktivieren Sie Weiterleitungen erst, wenn die Zieladresse selbst korrekt funktioniert. Andernfalls führt ein sauberer Redirect lediglich zu einer Zertifikatswarnung. Die offizielle HTTPS-Dokumentation behandelt WordPress im HTTPS-Betrieb. Berücksichtigen Sie bei einem Reverse Proxy zusätzlich, wie die Anwendung die ursprüngliche verschlüsselte Verbindung erkennt; das hängt vom konkreten Hostingaufbau ab.
Die Anwendung zunächst am neuen Ziel testen
Wenn die Umstellung vorbereitet werden kann, prüfen Sie die Kopie vor dem DNS-Wechsel über einen vorgesehenen geschützten Vorschauweg. Dieser Weg muss den tatsächlichen Domainnamen und die Serverzuordnung berücksichtigen, damit das Ergebnis aussagekräftig bleibt. Eine Prüfung über die bloße IP-Adresse kann eine andere Website und ein anderes Zertifikat erreichen. Halten Sie fest, welche Art von Vorschau Sie verwenden und welche Aussagen sie erlaubt. Auch eine technisch gelungene Direktprüfung beweist noch nicht, dass die öffentliche DNS-Auflösung bereits stimmt.
Kontrollieren Sie danach die WordPress-Adresse und die Website-Adresse. Bei einer normalen Installation im Domainhauptverzeichnis sind sie häufig gleich; bei einer Installation mit eigenem WordPress-Unterverzeichnis können sie absichtlich differieren. Ändern Sie sie nicht nach einer pauschalen Regel. Prüfen Sie die vorhandene Struktur und die zugehörige Konfiguration. Falls Konstanten die Werte vorgeben, wirken Backendfelder möglicherweise nicht wie erwartet. Dokumentieren Sie die wirksame Quelle der Adresse, damit spätere Administratoren nicht an einer scheinbar gespeicherten, tatsächlich übersteuerten Einstellung arbeiten.
Gespeicherte URLs sicher ersetzen
Für größere Datenbestände verwenden Sie eine Ersetzung, die WordPress-Datenstrukturen versteht. Mit WP-CLI search-replace lässt sich zunächst ein Probelauf durchführen. Prüfen Sie vor jedem Kommando Arbeitsverzeichnis und Zieldatenbank. Der alte Suchwert sollte die vollständige alte Websiteadresse enthalten, damit nicht versehentlich Textstellen mit einem ähnlichen Domainnamen betroffen sind. Ein pauschales SQL-Suchen-und-Ersetzen ist für serialisierte Inhalte riskant und macht die Folgen schwerer nachvollziehbar.
Erstellen Sie nach dem Probelauf eine kleine Ergebnisnotiz: welcher alte Wert, welcher neue Wert, welche Tabellen, wie viele Treffer laut Werkzeug und ob besondere Tabellen ausgelassen wurden. Die Trefferzahl ist ein Arbeitsnachweis, kein Beweis für vollständige inhaltliche Korrektheit. Prüfen Sie danach reale Seiten. Manche Pluginwerte enthalten kodierte oder zusammengesetzte Adressen; externe Dienste besitzen außerdem eigene Konfigurationen. Ersetzen Sie nichts in historischen Protokollen oder fremden Projekten, nur um eine große Trefferzahl zu erreichen.
Mixed Content an der konkreten Ressource lösen
Öffnen Sie die Browserkonsole und die Netzwerkliste einer betroffenen HTTPS-Seite. Suchen Sie die genaue Ressource, die weiterhin über HTTP geladen wird. Häufig handelt es sich um ein Bild, eine Schrift, ein Skript oder einen Hintergrund aus einer Themeoption. Prüfen Sie, wo die Adresse herkommt. Korrigieren Sie diese Quelle. Ein zusätzlicher Filter, der jede Ausgabe pauschal umschreibt, kann kurzfristig helfen, verdeckt aber möglicherweise den eigentlichen Fehler und hinterlässt unnötige Abhängigkeiten.
Bei externen Ressourcen testen Sie, ob der Anbieter eine funktionierende HTTPS-Adresse bereitstellt und ob die Nutzung überhaupt gewollt ist. Eine technische Umschreibung sollte nicht blind auf einen Dienst angewendet werden, der unter der neuen Adresse andere Inhalte liefert. Überlegen Sie bei Schriftdateien und regelmäßig genutzten Bildern, ob eine rechtmäßig lokal ausgelieferte Variante sinnvoller ist. Nach einer Korrektur leeren Sie die zuständigen Caches und wiederholen Sie denselben Aufruf. Kontrollieren Sie dabei auch die tatsächlich geladene Datei, nicht nur das verschwundene Warnsymbol.
Alte Links gezielt weiterleiten
Für einen reinen Domainwechsel sollten alte Pfade und Suchparameter am neuen Ziel erhalten bleiben. Testen Sie beispielsweise eine tiefe Artikeladresse mit einem harmlosen Testparameter. Eine Regel, die jede Anfrage auf die neue Startseite schickt, verliert den Inhaltsbezug. Für umbenannte Seiten benötigen Sie eine individuelle Zuordnung. Leiten Sie gelöschte Inhalte nur dann zu einer anderen Seite weiter, wenn diese den ursprünglichen Zweck sinnvoll übernimmt. Andernfalls ist eine hilfreiche echte Fehlerseite oft verständlicher als ein beliebiges Ziel.
Vermeiden Sie Ketten über mehrere Zwischenadressen. Idealerweise erreicht eine alte URL direkt die neue endgültige Hauptadresse. Halten Sie die alte Domain weiterhin unter Kontrolle, solange relevante alte Links bestehen. Eine Weiterleitung ist nur verfügbar, wenn Domain, DNS, Hosting und gegebenenfalls Zertifikat noch passend betrieben werden. Eine stillgelegte alte Domain kann keine Besucher mehr weiterführen. Ob und wie lange diese Infrastruktur bleibt, ist eine bewusste Betriebsentscheidung und kein automatisch gelöstes WordPress-Thema.
DNS und Erreichbarkeit getrennt kontrollieren
Prüfen Sie nach der freigegebenen DNS-Änderung die autoritativen Nameserver. Dort sehen Sie den veröffentlichten Stand unabhängig von manchen lokalen Caches. Kontrollieren Sie A und AAAA getrennt sowie die verwendete www-Variante. Testen Sie anschließend gewöhnliche Auflösung aus dem eigenen Netz und echte HTTPS-Verbindungen. Halten Sie eine direkte Verbindung zu einer ausgewählten IP und die öffentlich aufgelöste Verbindung im Protokoll auseinander. Beide können nützlich sein, beantworten aber verschiedene Fragen.
Beobachten Sie während des Übergangs, ob Anfragen weiterhin am alten Ziel eintreffen und ob dort Änderungen entstehen. Ein kurzzeitiger Parallelbetrieb kann unterschiedliche Datenstände erzeugen. Für einfache statische Inhalte lässt sich das leichter beherrschen; für Transaktionen braucht es eine ausdrücklich geplante Umschaltung. Lassen Sie sich bei Unsicherheit vom zuständigen Hostingbetreiber die tatsächliche Routing- und Proxykonfiguration erklären. Raten an Weiterleitungsregeln oder das Abschalten von Zertifikatsprüfungen erzeugt keine belastbare Lösung.
Abschluss und Übergabe
Prüfen Sie Anmeldung, Medien, Navigation, Suche und gegebenenfalls kontrollierte Formularabläufe auf der neuen Hauptadresse. Aktualisieren Sie interne Dokumentation, ausgewählte externe Profile und technische Dienste, soweit deren Änderung zum Auftrag gehört. Neue Hauptadressen sollten auch in Canonicals und gegebenenfalls strukturierten Daten konsistent auftauchen. Ein SEO-Plugin kann dabei unterstützen, ersetzt aber die Sichtprüfung der ausgegebenen Seite nicht. Behaupten Sie keine bereits erreichte Indexierung oder Rankings nach dem Umzug; dafür braucht es echte nachfolgende Beobachtung.
Der Zielzustand ist erreicht, wenn neue und alte Beispieladressen das erwartete Verhalten zeigen und der Betrieb den neuen Standort eindeutig kennt. Bewahren Sie Ausgangsbackup, Umstellungsnotiz und offene Punkte geschützt auf. Für eine spätere Fehlersuche hilft der Ratgeber zu 404 und Permalinks. Wenn die neue Umgebung zunächst geschützt bleibt, halten Sie diesen Status auch nach der URL-Umstellung aufrecht. Ein technisch erfolgreich vorbereiteter Domainwechsel ist keine automatische Freigabe zur Veröffentlichung.