So ziehen Sie eine WordPress-Website ohne Ausfallzeit zu einem neuen Hoster um

Das Kopieren einer WordPress-Website ist selten der schwierige Teil. Ausfallzeiten entstehen meist im Moment der Umstellung: DNS zeigt auf einen Server, der nicht bereit ist, die Datenbankverbindung schlägt fehl, das Zertifikat fehlt oder eine erzwungene HTTPS-Regel erzeugt eine Schleife. All das lässt sich vor der Umstellung finden, wenn Sie die Website auf dem neuen Server öffnen können, während alle anderen noch den alten sehen.

Der Ansatz in diesem Leitfaden ist einfach: Der alte Server bedient die Besucher weiter, bis der neue Seite für Seite geprüft ist. DNS wird nur einmal geändert, mit kurzer TTL, sodass sich die Änderung innerhalb von Minuten statt Stunden verbreitet.

• Zugang zum alten Hoster (Dateien und Datenbank oder ein Control Panel), zum neuen Hoster und zum DNS-Anbieter der Domain. Der DNS-Anbieter ist dort, wohin die Nameserver zeigen: oft der Registrar, manchmal Cloudflare oder der alte Hoster.
• Ein vollständiges Backup der aktuellen Website, das Sie heruntergeladen haben, nicht eines, das nur auf dem alten Server liegt.
• Die öffentliche IP-Adresse des neuen Servers. Wenn Sie nicht sicher sind, welche es ist, siehe Server-IP finden.
• Die PHP- und Datenbankversionen der alten Website. Gleichen Sie sie auf dem neuen Server an oder prüfen Sie, ob Theme und Plugins die neueren Versionen unterstützen.
• Eine Liste der wichtigen Seiten: Startseite, ein Beitrag, eine Kategorie, die Suche, das Kontaktformular, Warenkorb und Kasse, falls Sie WooCommerce nutzen, und wp-admin.

Prüfen Sie jetzt mit dem TTL-Checker die aktuelle TTL des A-Records der Domain. Sie brauchen sie für das Timing in Schritt 1.

1. 1

   Schritt 1: TTL einen Tag vorher senken

   Setzen Sie in Ihrer DNS-Oberfläche die TTL des A-Records (und ggf. AAAA) auf 300 Sekunden, weiterhin mit Ziel alter Server. Warten Sie vor der Umstellung mindestens so lange wie die alte TTL. Siehe TTL vor einem Website-Umzug senken.

2. 2

   Schritt 2: Backup der alten Website erstellen

   Erstellen Sie ein vollständiges Backup von Dateien und Datenbank und laden Sie es herunter. Das ist Ihr Rollback-Plan, falls etwas schiefgeht.

3. 3

   Schritt 3: Dateien und Datenbank zum neuen Hoster kopieren

   Nutzen Sie ein Migrations-Plugin, das Übertragungstool des Hosters oder eine manuelle Kopie mit WP-CLI. Lassen Sie home und siteurl auf der Produktionsdomain.

4. 4

   Schritt 4: Website auf dem neuen Server öffnen

   Erstellen Sie einen Vorschau-Link mit Ihrer Domain und der neuen IP. Klicken Sie sich durch die wichtigen Seiten, melden Sie sich in wp-admin an und laden Sie ein Bild hoch, um die Dateiberechtigungen zu bestätigen.

5. 5

   Schritt 5: QA-Crawl ausführen

   Führen Sie einen QA-Bericht auf der Vorschau aus, um defekte Seiten, fehlende Uploads, Weiterleitungsschleifen, Mixed Content und fest eingetragene URLs zu finden. Beheben Sie die Fehler und führen Sie ihn erneut aus.

6. 6

   Schritt 6: Inhalte einfrieren und final synchronisieren

   Stoppen Sie für einige Minuten neue Bestellungen, Kommentare und Beiträge auf der alten Website und kopieren Sie die Datenbank noch einmal, damit nichts verloren geht, was seit der ersten Kopie geschrieben wurde.

7. 7

   Schritt 7: DNS umstellen

   Lassen Sie den A-Record der Domain und von www auf die neue IP zeigen. Aktualisieren oder entfernen Sie einen alten AAAA-Record, damit IPv6-Besucher nicht weiter beim alten Hoster landen.

8. 8

   Schritt 8: Propagation beobachten und alten Hoster behalten

   Verfolgen Sie die Änderung mit dem DNS-Propagation-Checker. Behalten Sie das alte Hosting noch einige Tage, bis seine Access-Logs keine echten Besucher mehr zeigen.

Beides funktioniert. Entscheiden Sie nach Größe der Website und danach, wie viel Zugriff Sie auf beiden Seiten haben.

Für eine manuelle Kopie sehen die Befehle so aus. Führen Sie den Export auf dem alten Server und den Import auf dem neuen aus:

# Old server: export the database and pack the files
wp db export site.sql
tar -czf site-files.tar.gz --exclude=wp-content/cache .

# New server: unpack, import, check the site URL
tar -xzf site-files.tar.gz
wp db import site.sql
wp option get home
wp option get siteurl

Gibt Ihnen der neue Hoster andere Datenbank-Zugangsdaten, aktualisieren Sie vor dem Test DB_NAME, DB_USER, DB_PASSWORD und DB_HOST in wp-config.php.

WordPress speichert seine eigene Adresse in der Datenbank (home und siteurl) und baut die meisten Links daraus. Ein häufiger Fehler ist, sie zum Testen des neuen Servers auf die Server-IP oder einen temporären Hostnamen zu ändern. Das funktioniert bis zur Umstellung, und danach zeigt jeder fest eingetragene Link auf die temporäre Adresse.

Lassen Sie beide Werte auf der Produktionsdomain, etwa https://example.com, und testen Sie die Website unter diesem Namen. Genau das macht ein DNSPeek-Vorschau-Link: Er verbindet sich mit der neuen IP und fragt Ihre echte Domain an, sodass sich WordPress verhält, als wäre DNS schon umgezogen. Links, Weiterleitungen und Login-Cookies werden auf die Vorschau-Adresse umgeschrieben, sodass Sie sich in wp-admin anmelden und durch die Website klicken können. Mehr in der Doku: WordPress-Website auf neuem Hoster ansehen.

Viele Hoster stellen ein kostenloses Zertifikat erst aus, wenn die Domain auf sie zeigt, weil die Domainprüfung über HTTP auf der Domain selbst läuft. Vor der Umstellung zeigt der neue Server womöglich ein selbstsigniertes oder Standardzertifikat. Das ist normal und kein Grund zu warten.

Stellen Sie in einer DNSPeek-Vorschau den SSL-Modus des Links auf Prüfung überspringen, solange das Zertifikat fehlt. Sonst kann ein Plugin oder eine Regel, die HTTPS erzwingt, eine Weiterleitungsschleife erzeugen, wenn die Vorschau auf HTTP zurückfällt. Bestätigen Sie nach der Umstellung das echte Zertifikat mit dem SSL-Checker. Details: SSL-Modi.

Bei einem Shop oder einer Website mit Logins kommen bis zur Umstellung laufend neue Daten auf dem alten Server an. Bestellungen, Kommentare und neue Konten, die nach Ihrer Kopie entstehen, gingen verloren. Planen Sie einen kurzen Inhaltsstopp: Kündigen Sie ein Wartungsfenster für neue Bestellungen an oder versetzen Sie die alte Website nur für die Minuten der letzten Datenbanksynchronisierung in den Wartungsmodus. Seiten laden für Leser in beiden Fällen weiter.

Zahlungsanbieter und Anmeldedienste kennen nur Ihre echte Domain und schicken Kunden daher zu dem Server zurück, auf den das öffentliche DNS zeigt. Testen Sie den Bezahlvorgang mit einem Test-Gateway in der Vorschau und geben Sie direkt nach der Umstellung eine echte oder Sandbox-Bestellung auf. Siehe Was Vorschauen nicht können.