Ein Wechsel des Hosting-Anbieters gehört zum normalen Lebenszyklus einer WordPress-Website: ein auslaufender Vertrag, mehr benötigte Leistung, der Umstieg auf Self-Hosting. Das Risiko liegt fast nie im Kopieren der Dateien selbst, sondern in der DNS-Umschaltung und der Reihenfolge der einzelnen Schritte. Ein gut vorbereiteter Umzug besteht aus wenigen Einstellungen, die mehrere Tage im Voraus vorgenommen werden – nicht am eigentlichen Tag.
Warum die DNS-Umschaltung der kritische Punkt ist
Jeder DNS-Eintrag trägt eine Lebensdauer, den TTL-Wert (Time To Live), angegeben in Sekunden. Solange diese Frist nicht abgelaufen ist, antworten zwischengeschaltete DNS-Resolver – die von Internetanbietern, Browsern, Unternehmens-Caches – weiterhin mit der alten IP-Adresse. Bei einem Standard-TTL von 86.400 Sekunden (24 Stunden) kann ein Teil der Besucher noch einen ganzen Tag nach der Umschaltung auf dem alten Server landen, was zum Problem wird, sobald der alte Server abgeschaltet wird oder sich die Inhalte zwischen beiden Umgebungen unterscheiden.
| Zeitpunkt | Maßnahme | Ziel |
|---|---|---|
| Tag -3 | TTL des A-Eintrags auf 300 Sekunden senken | Das Propagationsfenster vor der Umschaltung verkleinern |
| Tag -1 | Dateien und Datenbank auf den neuen Server kopieren, lokal über die hosts-Datei testen | Die Website prüfen, ohne den Produktions-DNS anzufassen |
| Tag 0, morgens | Letzte Delta-Synchronisierung, dann DNS umstellen | Den Inhaltsunterschied zwischen beiden Kopien minimieren |
| Tag 0, einige Stunden später | Logs beider Server prüfen, Traffic-Umzug bestätigen | Sicherstellen, dass kein Besucher auf dem alten Server hängen bleibt |
| Tag +7 | Alten Hosting-Vertrag abschalten | Spielraum für die langsamsten DNS-Caches lassen |
Den neuen Hoster vorbereiten, bevor irgendetwas kopiert wird
Bevor auch nur eine Datei verschoben wird, muss die neue Umgebung bereit sein, die Website unter gleichwertigen oder besseren Bedingungen aufzunehmen: mindestens dieselbe PHP-Version, dieselben aktiven Erweiterungen, ein bereits eingerichtetes TLS-Zertifikat für die endgültige Domain. Auf einem Self-Hosting-Panel wie dem bereits behandelten Self-Hosting von WordPress mit CloudPanel beschränkt sich dieser Schritt darauf, die Website und ihr Zertifikat vor jeder Kopie anzulegen. Diese Umgebung im Voraus bereitzustellen erlaubt es, die Serverkonfiguration (URL-Rewriting, PHP-Speichergrenzen, Caching-Einstellungen) unabhängig vom Inhaltsumzug zu testen und Konfigurationsprobleme von Datenproblemen zu trennen.
Dateien und Datenbank fehlerfrei synchronisieren
Das Kopieren läuft in zwei getrennten Strängen: die Dateien über rsync oder eine SFTP-Übertragung, die Datenbank über einen SQL-Export. WP-CLI vereinfacht diesen Schritt auf einem selbst gehosteten Server deutlich, insbesondere beim Ersetzen von URLs in serialisierten Feldern, die generische Suchen-und-Ersetzen-Werkzeuge oft beschädigen.
# Auf dem alten Server: sauberer Datenbank-Export
wp db export backup.sql --add-drop-table
# Dateien kopieren, Cache und Logs ausschließen
rsync -avz --exclude 'wp-content/cache' --exclude '*.log' \
./ user@neuer-server:/var/www/site/
# Auf dem neuen Server: Import und Umschreiben der URLs
wp db import backup.sql
wp search-replace 'https://alte-domain.tld' 'https://neue-domain.tld' \
--all-tables --precise
Die Wahl von wp search-replace anstelle eines einfachen Textersatzes verhindert, dass serialisierte PHP-Arrays und -Objekte beschädigt werden, die WordPress in bestimmten Feldern speichert (Widgets, Theme-Optionen, Daten von Seiten-Buildern): Ein naiver Ersatz ändert die Länge einer Zeichenkette, ohne den davorstehenden Zeichenzähler zu aktualisieren, wodurch die Daten still und leise beschädigt werden.
DNS umschalten und prüfen, bevor der alte Server abgeschaltet wird
Sobald die abschließende Synchronisierung erfolgt ist, löst die Aktualisierung des DNS-Eintrags die schrittweise Verlagerung des Traffics aus. Jetzt gilt es, die Zugriffslogs beider Server parallel zu beobachten: Ein allmählicher Rückgang des Traffics auf dem alten Server bei gleichzeitigem Anstieg auf dem neuen bestätigt eine normale Propagation. Die Website von mehreren Netzwerken aus zu testen (Mobilfunk, Festnetz, VPN) liefert ein realistischeres Bild dessen, was Besucher tatsächlich sehen, als ein Test von nur einem Gerät aus.
Wird der TTL drei Tage vor der Umschaltung auf 300 Sekunden gesenkt, schrumpft das DNS-Propagationsfenster auf wenige Minuten, statt mehrerer Stunden mit dem Standardwert von 86.400 Sekunden.
Hinweis: Das alte Hosting nicht abschalten, sobald das neue korrekt antwortet. Die langsamsten DNS-Resolver und manche Unternehmens-Caches können die alte Antwort noch mehrere Tage über den angegebenen TTL hinaus behalten. Den alten Server, und sei es nur lesend, mindestens eine Woche weiterlaufen zu lassen verhindert, dass einzelne Besucher auf einer leeren Seite landen.
Typische Fehler bei einem schlecht vorbereiteten Umzug
Drei Fehler treten am häufigsten auf. Der erste besteht darin, den DNS zu ändern, bevor die Website auf dem neuen Server getestet wurde: Ohne Umschaltung erlaubt ein Test über die lokale hosts-Datei (die die Domain vorübergehend von einem einzelnen Rechner aus auf die neue IP-Adresse zeigen lässt), Darstellung und Funktionen zu prüfen, ohne eine noch instabile Website öffentlich zugänglich zu machen. Der zweite Fehler ist, fest einprogrammierte URLs in Drittanbieter-Plugins zu vergessen: Seiten-Builder, Formular-Plugins oder Zahlungsdienste speichern die alte Adresse manchmal außerhalb der von wp search-replace --all-tables erfassten Tabellen, weshalb auch die eigenen Konfigurationsdateien dieser Plugins geprüft werden müssen. Der dritte betrifft geplante Aufgaben (WordPress-Cron oder System-Cron): Eine automatische Sicherung oder ein Massen-E-Mail-Versand, der noch auf dem alten Server ausgelöst wird, kann mehrere Tage lang doppelt laufen, wenn niemand daran denkt, ihn zu deaktivieren.
Ein Hosting-Vertrag mit festem Enddatum bringt eine weitere Einschränkung mit sich: Es ist besser, die DNS-Umschaltung mehrere Tage vor Vertragsende einzuplanen statt am letzten Tag selbst, um Spielraum zu behalten, falls die Abschlussprüfung durch etwas Unvorhergesehenes verzögert wird.
Nach dem Umzug aufräumen und überwachen
Sobald die Umschaltung bestätigt ist, müssen noch Drittdienste aktualisiert werden, die ausdrücklich auf die alte IP-Adresse oder den alten Server verweisen: Backup-Bots, Monitoring-Dienst, eine eventuelle Web Application Firewall sowie die SPF-Einträge, falls der E-Mail-Versand über denselben Hoster läuft. Das ist auch ein guter Zeitpunkt, um die minimale Härtungsbasis auf dem neuen Server erneut zu prüfen, da sich die Standardeinstellungen oft vom alten Hoster unterscheiden. Eine Kontrolle in der Search Console einige Tage nach dem Umzug hilft, einen Crawling-Fehler durch ein falsch konfiguriertes TLS-Zertifikat oder eine vergessene Rewrite-Regel auf dem neuen Server zu erkennen.
Was man sich merken sollte
Das Risiko bei einem Hosterwechsel liegt fast nie im Kopieren der Daten, sondern in der DNS-Propagationsverzögerung und der Reihenfolge der Schritte rund um die Umschaltung. Den TTL mehrere Tage im Voraus zu senken, die neue Umgebung vor dem DNS-Wechsel zu validieren und den alten Server eine Woche nach der Umschaltung weiterlaufen zu lassen, deckt die meisten vermeidbaren Ausfallszenarien ab.
Der häufigste gescheiterte Umzug, den ich gesehen habe, geht immer auf dasselbe Versäumnis zurück: der TTL, der auf seinem Standardwert belassen wurde und erst auffällt, wenn der alte Server bereits abgeschaltet ist. Den TTL drei Tage im Voraus zu senken kostet fünf Minuten Konfiguration und verhindert fast jeden Umschaltungsvorfall, den ich für Kunden sonst noch im Eiltempo beheben muss — Simon Janvier.
Zum Weiterlesen: die offizielle Dokumentation zum Befehl wp search-replace.
