So migrieren Sie eine Website mit WP-CLI

Wenn Sie eine große WordPress-Site verwalten und sie zu einem neuen Hoster verschieben müssen, bietet Ihnen WP-CLI einen schnelleren, besser skriptfähigen Weg.

Es wird Ihnen keine PHP-Timeouts bei großen Datenbanken geben. Außerdem haben Sie einen Prozess, den Sie für mehrere Sites wiederholen oder automatisieren können.

In diesem Tutorial zeige ich Ihnen, wie Sie eine WordPress-Site mit WP-CLI migrieren. Am Ende läuft Ihre Site auf dem neuen Server, und Sie haben bestätigt, dass sie funktioniert, bevor auch nur ein einziger Besucher den neuen Hoster erreicht.

Hier sind die wichtigsten Erkenntnisse:

• Die WP-CLI-Migration ist für große Sites schneller als die plugin-basierte Migration, erfordert jedoch SSH-Zugriff auf beiden Servern und WP-CLI, das auf jedem installiert ist.
• Das Flagge --precise bei wp search-replace ist der wichtigste Befehl in diesem Tutorial. Ohne ihn werden serialisierte Daten stillschweigend beschädigt, und Theme-Einstellungen, Widgets und Plugin-Optionen werden ohne Fehlermeldung zurückgesetzt.
• Das Kopieren von wp-config.php vom alten Server auf den neuen Server übernimmt die falschen Datenbankanmeldeinformationen. Sie müssen DB_NAME, DB_USER, DB_PASSWORD und DB_HOST auf dem neuen Server aktualisieren, bevor Sie importieren.
• Schalten Sie niemals DNS um, bevor Sie die Migration überprüft haben. Schritt 7 behandelt eine Checkliste vor dem DNS-Umschalten mit wp option get, wp core verify-checksums und einer Hosts-Datei-Vorschau.
• wp duplicator build erstellt ein vollständiges Site-Backup vom Terminal, bevor Sie beginnen. Wenn während der Migration etwas schiefgeht, stellt die Notfallwiederherstellungs-URL von Duplicator die ursprüngliche Site ohne SSH auf dem alten Server wieder her.
• Wenn Sie zu einer neuen Domain migrieren, fügen Sie --skip-columns=guid in Ihren search-replace-Befehl ein. Das Ersetzen von GUIDs unterbricht RSS-Abonnements.

Inhaltsverzeichnis

Wann Sie WP-CLI zum Migrieren einer WordPress-Site verwenden sollten

WP-CLI ist nicht das richtige Werkzeug für jede Migration. Hier erfahren Sie, wann es sinnvoll ist, den Kommandozeilenweg zu wählen (und wann ein anderer Ansatz besser passt).

Verwenden Sie WP-CLI, wenn:

• Ihre Site so groß ist, dass browserbasierte Tools während der Übertragung PHP-Timeouts oder Speicherlimits erreichen
• Ihr Hoster Ihnen nicht genügend temporären Speicherplatz zur Verfügung stellt, um ein vollständiges Backup über den Browser zu erstellen
• Sie migrieren mehrere Sites und wünschen sich einen wiederholbaren, skriptfähigen Prozess. wp duplicator build innerhalb eines Bash-Skripts kümmert sich um Stapelsicherungen ohne manuelle Arbeit
• Sie die volle Kontrolle über jeden Schritt wünschen: was übertragen wird, was ersetzt wird und was vor DNS-Änderungen überprüft wird

Erwägen Sie stattdessen ein Migrations-Plugin, wenn:

• Sie haben keinen SSH-Zugriff auf dem Quell- oder Zielserver
• Sie sind mit der Kommandozeile nicht vertraut
• Sie wünschen einen geführten, visuellen Prozess mit Fortschrittsanzeigen und integrierter Rollback-Funktion

Welche Methode Sie verwenden, hängt von Ihrer Einrichtung und Ihren Vorlieben ab.

Was Sie vor dem Start benötigen

Richten Sie alles ein, bevor Sie einen einzigen Befehl ausführen. Wenn Sie mitten in der Migration etwas vermissen (insbesondere Datenbankanmeldedaten oder Dateipfade), landen Sie mit einer halb importierten Datenbank und einer ausgefallenen Website auf beiden Servern.

• SSH-Zugriff auf beide Server. Sie müssen zu verschiedenen Zeitpunkten dieses Prozesses Befehle auf dem alten und dem neuen Server ausführen.
• WP-CLI auf beiden Servern installiert. Wenn es noch nicht installiert ist, folgen Sie der offiziellen Installationsanleitung. Sie benötigen es auf dem neuen Server für die Überprüfungsschritte in Schritt 7, nicht nur auf dem alten Server.
• Duplicator Pro auf dem alten Server installiert und aktiv. Dieses Backup-/Migrations-Plugin verfügt über die Befehle wp duplicator build, wp duplicator info und wp duplicator cleanup.
• Eine neue Datenbank, die bereits auf dem neuen Server erstellt wurde, mit einem Benutzer, der über volle Berechtigungen verfügt. wp db import erstellt die Datenbank nicht für Sie – wenn sie nicht existiert, schlägt der Import fehl.
• Die Datenbankanmeldedaten Ihres neuen Servers bereit: DB_NAME, DB_USER, DB_PASSWORD und DB_HOST. Sie benötigen diese in Schritt 4.
• Die absoluten Dateipfade für beide WordPress-Installationen. Führen Sie pwd im jeweiligen WordPress-Stammverzeichnis aus und kopieren Sie die Ausgabe irgendwohin.
• Wenn Sie Domains ändern: Ihre alte und neue URL bereit zum Kopieren/Einfügen, genau wie sie in der Datenbank erscheinen, einschließlich des Protokolls (https:// vs http://).

So migrieren Sie eine WordPress-Site mit WP-CLI

Hier ist, was Sie tun werden. Jeder Schritt baut direkt auf dem vorherigen auf, also arbeiten Sie sie in der richtigen Reihenfolge durch.

• Schritt 1: Führen Sie eine Vorabprüfung durch und erstellen Sie ein vollständiges Backup mit wp duplicator info und wp duplicator build
• Schritt 2: Exportieren Sie die Datenbank vom alten Server mit wp db export
• Schritt 3: Übertragen Sie WordPress-Dateien und die Datenbank mit rsync und scp auf den neuen Server
• Schritt 4: Aktualisieren Sie wp-config.php auf dem neuen Server mit Ihren neuen Datenbankanmeldedaten
• Schritt 5: Setzen Sie die Datenbank auf dem neuen Server zurück und importieren Sie sie mit wp db reset und wp db import
• Schritt 6: Führen Sie Search-Replace aus, um URLs zu aktualisieren (nur bei Domainänderungen) mit wp search-replace
• Schritt 7: Leeren Sie den Cache und überprüfen Sie die Migration, bevor Sie die DNS-Einstellungen ändern
• Schritt 8: Aktualisieren Sie die DNS-Einstellungen und gehen Sie live
• Schritt 9: Bereinigen Sie den alten Server mit wp duplicator cleanup

Schritt 1: Sichern Sie die ursprüngliche Site

Bevor Sie etwas exportieren, benötigen Sie einen sauberen Wiederherstellungspunkt auf dem ursprünglichen Server. Wenn während der Migration etwas schiefgeht, möchten Sie ohne Hektik zu einer funktionierenden Website zurückkehren können.

Ich verwende Duplicator zum Schutz von WordPress-Backups. Es ist ein Backup- und Migrations-Plugin, das von über 1,5 Millionen WordPress-Profis verwendet wird und über integrierte WP-CLI-Befehle verfügt.

Das bedeutet, dass Sie ein vollständiges Website-Backup erstellen können, ohne das Terminal zu verlassen. Für einen Workflow über die Befehlszeile ist das wichtig.

Beginnen Sie damit, zu überprüfen, ob die Backup-Konfiguration von Duplicator korrekt funktioniert. Melden Sie sich per SSH am alten Server an, navigieren Sie zu Ihrem WordPress-Stammverzeichnis und führen Sie aus:

wp duplicator info

Sobald dies fehlerfrei zurückkehrt, erstellen Sie Ihr Backup:

wp duplicator build

Dies erstellt ein vollständiges Backup Ihrer Website vom Terminal aus.

Wenn Sie das Backup an einem bestimmten Ort statt am Standardort speichern möchten, verwenden Sie:

wp duplicator build --dir=/path/to/backup/location

Führen Sie wp duplicator build --help aus, um alle verfügbaren Flags anzuzeigen, einschließlich --template=<ID> für vordefinierte Backup-Vorlagen und Archivierungs-Engine-Optionen wie --phpsqldump, --phpzip und --duparchive.

Wenn diese Migration etwas kaputt macht, kann die Notfallwiederherstellungs-URL von Duplicator Ihre Website wiederherstellen, selbst wenn WordPress auf dem alten Server vollständig gesperrt ist. Das ist Ihr Sicherheitsnetz, bevor Sie etwas anderes anfassen.

Schritt 2: Exportieren Sie die Datenbank vom alten Server

Navigieren Sie immer noch auf dem alten Server zu Ihrem WordPress-Stammverzeichnis und exportieren Sie die Datenbank:

wp db export site-backup.sql

Wenn es fertig ist, sehen Sie: Success: Exported to 'site-backup.sql'.

Die Datei wird in Ihrem aktuellen Verzeichnis gespeichert. Merken Sie sich, wo das ist, da Sie sie im nächsten Schritt übertragen werden.

Eine Sache, die Sie tun sollten, bevor Sie weitermachen. Wenn Ihre .sql-Datei in einem webzugänglichen Verzeichnis wie /public_html oder /htdocs landet, verschieben oder löschen Sie sie sofort nach der Übertragung.

Eine offengelegte .sql-Datei ist eine vollständige Kopie Ihrer Datenbank, einschließlich Benutzernamen, gehashten Passwörtern und jedem Inhalt der Website. Es ist kein theoretisches Risiko.

Wenn Sie ein WordPress Multisite-Netzwerk migrieren, hängen Sie --all-tables an, um netzwerkweite Daten zu erfassen:

wp db export site-backup.sql --all-tables

Schritt 3: Übertragen Sie WordPress-Dateien und die Datenbank auf den neuen Server

Zwei Dinge müssen auf den neuen Server übertragen werden: die WordPress-Dateien und der gerade erstellte .sql-Export.

Für die Dateien verwenden Sie rsync. Es bewältigt große Übertragungen gut, zeigt den Fortschritt an und setzt dort fort, wo es unterbrochen wurde, wenn die Verbindung abbricht:

rsync -avz --progress /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Mit dem Schrägstrich kopiert rsync den Inhalt des Verzeichnisses. Ohne ihn kopiert rsync das Verzeichnis selbst, was Ihre Dateien eine Ebene tiefer als erwartet auf dem neuen Server platziert.

Führen Sie zuerst einen Testlauf durch, um zu überprüfen, was übertragen wird, bevor Sie fortfahren:

rsync -avz --progress --dry-run /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Für die Datenbankdatei verwenden Sie scp:

scp site-backup.sql user@newserver:/path/to/new-wordpress/

Wenn Sie es vorziehen, zuerst alles in ein einziges Archiv zu komprimieren, funktioniert das auch:

tar -czf site_files.tar.gz .
scp site_backup.sql site_files.tar.gz user@newserver:/path/to/new-wordpress/

Extrahieren Sie es dann auf dem neuen Server:

tar -xzf site_files.tar.gz

Dieser Ansatz funktioniert gut für kleinere Websites oder Hosts, die Einzeldatei-Übertragungen zuverlässiger als rsync-Verbindungen handhaben.

Schritt 4: Aktualisieren Sie wp-config.php auf dem neuen Server

Dies ist der Schritt, den die meisten WP-CLI-Migrations-Tutorials überspringen, und er ist der häufigste Grund, warum eine Migration unmittelbar nach dem Import fehlschlägt.

Als Sie Ihre WordPress-Dateien im letzten Schritt übertragen haben, wurde wp-config.php mit ihnen übertragen. Das ist die richtige Datei, aber sie enthält immer noch die Datenbankanmeldeinformationen Ihres alten Servers. Wenn Sie den Import jetzt ausführen, versucht WP-CLI, eine Verbindung zu einer Datenbank herzustellen, die auf dem neuen Server nicht existiert.

SSHen Sie auf den neuen Server, navigieren Sie zu Ihrem WordPress-Stammverzeichnis und öffnen Sie wp-config.php:

nano /path/to/new-wordpress/wp-config.php

Aktualisieren Sie diese vier Werte mit den Datenbankdetails Ihres neuen Servers:

• DB_NAME: der Name der Datenbank, die Sie auf dem neuen Server erstellt haben
• DB_USER: der Datenbankbenutzername
• DB_PASSWORD: das Datenbankpasswort
• DB_HOST: normalerweise localhost, aber bestätigen Sie dies mit Ihrem Hoster. Einige Managed Hosts verwenden hier einen anderen Wert.

Speichern und beenden. Bei Nano ist das Strg+O zum Speichern und Strg+X zum Beenden.

Vergessen Sie diesen Schritt nicht. Wenn die Anmeldeinformationen falsch sind, wird wp db import eine Verbindung zur falschen Datenbank herstellen oder mit „Fehler beim Aufbau einer Datenbankverbindung“ fehlschlagen, und es wird nicht immer offensichtlich sein, dass wp-config.php die Ursache ist.

Schritt 5: Setzen Sie die Datenbank auf dem neuen Server zurück und importieren Sie sie

SSHen Sie auf den neuen Server und navigieren Sie zu Ihrem WordPress-Stammverzeichnis. Wenn Sie eine frische WordPress-Installation auf dem neuen Server haben, löschen Sie deren Standardtabellen, bevor Sie importieren. Das Überspringen dieses Schritts kann zu Konflikten zwischen den vorhandenen Tabellen und denen in Ihrem Export führen.

wp db reset --yes

Sie sehen: Erfolg: Datenbank zurückgesetzt.

Das Flag --yes überspringt die Bestätigungsaufforderung. Ohne dieses fragt WP-CLI Sie, bevor alle Tabellen gelöscht werden.

Importieren Sie nun die Datenbank:

wp db import site-backup.sql

Sobald der Import bestätigt ist, löschen Sie die SQL-Datei:

rm site-backup.sql

SSHen Sie dann zurück zum alten Server und löschen Sie sie auch dort.

Dies ist keine optionale Aufräumarbeit. Eine .sql-Datei in einem webzugänglichen Verzeichnis ist eine vollständige Kopie Ihrer Datenbank. Löschen Sie sie von beiden Servern, bevor Sie etwas anderes tun.

Schritt 6: Führen Sie Search-Replace aus, um URLs zu aktualisieren

Wenn Sie dieselbe Domain beibehalten und nur den Hoster wechseln, überspringen Sie diesen Schritt und fahren Sie direkt mit Schritt 7 fort. Ihre URLs sind in der Datenbank bereits korrekt.

Wenn Sie die Domain wechseln, ist dies der Punkt, an dem die meisten Migrationen leise scheitern. Nicht mit einem Fehler – sondern mit Theme-Einstellungen, die falsch aussehen, verschwundenen Widgets und Plugin-Optionen, die auf Standardwerte zurückgesetzt wurden. Die Ursache ist fast immer dieselbe: ein Suchen-Ersetzen, das serialisierte Daten nicht korrekt verarbeitet hat.

Führen Sie vor der Ausführung einen Testlauf durch:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Dies führt den vollständigen Vorgang aus und zeigt Ihnen eine Tabelle mit der Anzahl der Ersetzungen pro Datenbanktabelle an, ohne Änderungen zu speichern. Überprüfen Sie diese.

Suchen Sie nach Tabellen, bei denen Sie Ersetzungen erwarten würden (wp_options, wp_posts, wp_postmeta), und stellen Sie sicher, dass die Zählungen angemessen erscheinen. Unerwartete Nullen bei diesen Tabellen sind es wert, untersucht zu werden, bevor Sie fortfahren.

Wenn Sie zufrieden sind, führen Sie es ohne –dry-run aus:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Warum --precise wichtig ist: WordPress speichert einige Daten als serialisiertes PHP. Theme-Customizer-Einstellungen, Widget-Konfigurationen, Plugin-Optionen – diese werden nicht als Klartext gespeichert. Sie werden als strukturierte PHP-Strings gespeichert, die Zeichenzählungen enthalten.

Ein Standard-SQL-basiertes Suchen-Ersetzen tauscht den URL-String aus, berechnet aber diese Zeichenzählungen nicht neu. PHP liest die Zählung, findet eine Diskrepanz und verwirft die Daten stillschweigend.

Ihr Theme wird zurückgesetzt. Ihre Widgets verschwinden. Nichts wirft einen Fehler – die Website sieht einfach falsch aus.

Das Flag --precise zwingt WP-CLI, PHP anstelle von SQL zu verwenden. Es deserialisiert jeden Wert, nimmt die Ersetzung vor, berechnet die Zeichenanzahl neu und serialisiert das Ergebnis korrekt neu. Es ist bei großen Datenbanken langsamer. Verwenden Sie es trotzdem.

Eine Sache, die wp search-replace standardmäßig korrekt überspringt: die guid-Spalte in wp_posts. Versuchen Sie nicht, GUIDs zu ersetzen.

Die WordPress-Dokumentation besagt ausdrücklich, dass GUIDs konstant bleiben müssen. Sie identifizieren Beiträge für Feed-Reader, und ihre Änderung bricht RSS-Abonnements.

Wenn Sie ein Multisite-Netzwerk migrieren, fügen Sie das Flag –network hinzu:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --network

Die offizielle WordPress-Dokumentation beschreibt eine andere Reihenfolge: Aktualisieren Sie Ihre URLs in Einstellungen » Allgemein auf dem alten Server, bevor Sie migrieren, exportieren Sie dann die bereits aktualisierte Datenbank und überspringen Sie den Such- und Ersetzungsschritt auf dem neuen Server vollständig. Es funktioniert. Der Ansatz in diesem Tutorial (zuerst migrieren, dann suchen und ersetzen) ist einfacher zu überprüfen, da Sie einen Testlauf durchführen können, bevor Sie URL-Änderungen vornehmen.

Schritt 7: Leeren Sie den Cache und überprüfen Sie, bevor Sie DNS ändern

Sobald die Suche und der Ersatz abgeschlossen sind, ist es verlockend, direkt zum DNS zu wechseln. Tun Sie das nicht.

Wenn Sie das DNS ändern, bevor Sie bestätigt haben, dass die Website funktioniert, bedeutet dies, dass alle Probleme, die Sie finden, Live-Probleme sind, die für echte Besucher sichtbar sind. Nehmen Sie sich hier zehn Minuten Zeit und überprüfen Sie zuerst alles auf dem neuen Server.

Beginnen Sie mit dem Leeren des Objekt-Caches:

wp cache flush

Leeren Sie dann die Rewrite-Regeln:

wp rewrite flush

Überprüfen Sie nun, ob die URLs in der Datenbank korrekt sind. Führen Sie beide aus:

wp option get siteurl
wp option get home

Beide sollten Ihre korrekte Domain zurückgeben. Wenn eine von beiden die alte Domain zurückgibt, können Sie sie manuell aktualisieren:

wp option update siteurl 'https://newdomain.com'

wp option update home 'https://newdomain.com'

Überprüfen Sie als Nächstes, ob Ihre WordPress-Core-Dateien ohne Beschädigung übertragen wurden:

wp core verify-checksums

Wenn Fehler zurückgegeben werden, notieren Sie, welche Dateien markiert sind. Eine Handvoll geänderter Dateien in wp-content ist zu erwarten und kein Problem – das sind Ihre Theme- und Plugin-Dateien, die nicht Teil des Checksummenvergleichs sind. Fehler bei Core-Dateien in wp-admin oder wp-includes sind untersuchenswert.

Sehen Sie sich die Website in der Vorschau an, bevor Sie das DNS aktualisieren. Fügen Sie Ihrer Hosts-Datei auf Ihrem lokalen Computer eine temporäre Zeile hinzu, die Ihre Domain auf die IP-Adresse des neuen Servers verweist. Öffnen Sie unter Mac oder Linux /etc/hosts in einem Texteditor und fügen Sie hinzu:

123.456.789.0 yourdomain.com

Ersetzen Sie 123.456.789.0 durch die IP-Adresse Ihres neuen Servers. Speichern Sie die Datei und öffnen Sie dann Ihre Domain in einem Browser. Sie sehen jetzt den neuen Server, während alle anderen immer noch den alten erreichen.

Überprüfen Sie jeden dieser Punkte, bevor Sie fortfahren:

• Homepage wird korrekt geladen
• Admin-Login funktioniert unter /wp-admin
• Bilder werden in Beiträgen und Seiten angezeigt
• Navigationsmenüs sind intakt
• Widgets werden korrekt in der Seitenleiste oder im Footer angezeigt
• Das Erscheinungsbild des Themes entspricht dem Original

Wenn alles stimmt, entfernen Sie die Zeile, die Sie zu Ihrer Hosts-Datei hinzugefügt haben. Dann sind Sie bereit für ein DNS-Update.

Schritt 8: Aktualisieren Sie DNS und gehen Sie live

Richten Sie den A-Record Ihrer Domain auf die IP-Adresse Ihres neuen Servers aus. Wo Sie dies tun, hängt davon ab, wohin die Nameserver Ihrer Domain zeigen: entweder Ihr Domain-Registrar oder der DNS-Manager Ihres Hosting-Providers.

Melden Sie sich an, finden Sie den A-Record für Ihre Domain und aktualisieren Sie die IP.

Die DNS-Weiterleitung dauert je nach Registrar und der TTL-Einstellung (Time to Live) Ihrer Domain zwischen wenigen Minuten und 48 Stunden. Während dieses Zeitfensters treffen einige Besucher auf den alten Server und einige auf den neuen. Das ist normal. Es ist kein Zeichen dafür, dass etwas kaputt gegangen ist.

Lassen Sie den alten Server nach der DNS-Aktualisierung mindestens 24-48 Stunden laufen. Wenn Sie ihn während der Weiterleitung abschalten, landen einige Besucher ins Leere.

Sobald Sie sicher sind, dass die Weiterleitung abgeschlossen ist, leeren Sie den Cache auf dem neuen Server ein letztes Mal:

wp cache flush

Schritt 9: Bereinigen mit wp duplicator cleanup

Wenn der neue Server live und stabil bestätigt ist, gehen Sie zurück zum alten Server und führen Sie aus:

wp duplicator cleanup

Dies entfernt die Backup-Dateien und alle temporären Daten, die Duplicator während des Erstellungsprozesses in Schritt 1 erstellt hat. Es hält den alten Server sauber und beseitigt alle Migrationsartefakte, bevor Sie ihn stilllegen.

Führen Sie dies nur aus, wenn Sie sicher sind, dass die Migration abgeschlossen ist. Sobald die Backup-Dateien weg sind, ist auch die Disaster-Recovery-Option aus Schritt 1 mit ihnen weg.

Wenn Sie das Backup als Langzeitarchiv aufbewahren möchten, verschieben Sie es in einen Remote-Speicher, bevor Sie die Bereinigung durchführen.

Fehlerbehebung bei häufigen WP-CLI-Migrationsfehlern

Selbst eine sorgfältige Migration kann auf Schwierigkeiten stoßen. Hier sind die häufigsten Fehlerquellen, wie sie aussehen und wie man sie behebt.

„Fehler beim Herstellen einer Datenbankverbindung“ nach dem Import

Was Sie sehen: WordPress zeigt einen weißen Bildschirm oder die Meldung „Fehler beim Herstellen einer Datenbankverbindung“ auf dem neuen Server unmittelbar nach dem Import an.

Warum es passiert: wp-config.php enthält immer noch die Datenbankanmeldeinformationen des alten Servers. Dies ist der häufigste Fehler bei einer WP-CLI-Migration und wird leicht übersehen, wenn Sie die Dateien übertragen haben, bevor Sie die Konfiguration aktualisiert haben.

So beheben Sie es: Öffnen Sie wp-config.php auf dem neuen Server und aktualisieren Sie DB_NAME, DB_USER, DB_PASSWORD und DB_HOST, damit sie mit der Datenbank Ihres neuen Servers übereinstimmen. Speichern Sie die Datei und laden Sie die Website neu.

Theme-Einstellungen, Widgets oder Plugin-Optionen nach der Migration zurückgesetzt

Was Sie sehen: Die Website wird geladen, aber das Theme sieht falsch aus, Widgets fehlen oder Plugin-Einstellungen sind auf die Standardwerte zurückgesetzt. Keine Fehlermeldungen irgendwo.

Warum es passiert: Sie haben wp search-replace ohne das Flag --precise ausgeführt. Der URL-Ersatz hat serialisierte Daten in der Datenbank beschädigt, und WordPress hat die fehlerhaften Werte stillschweigend verworfen.

So beheben Sie es: Führen Sie search-replace erneut aus mit --precise und --all-tables:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

Wenn die Daten bereits stark beschädigt sind und das erneute Ausführen von search-replace die Einstellungen nicht wiederherstellt, stellen Sie das Duplicator-Backup wieder her, das Sie in Schritt 1 erstellt haben, und führen Sie die Migration erneut durch.

„wp: command not found“ auf dem neuen Server

Was Sie sehen: Jeder WP-CLI-Befehl auf dem neuen Server gibt wp: command not found oder command not found: wp zurück.

Warum es passiert: WP-CLI ist auf dem neuen Server nicht installiert, oder es ist installiert, aber nicht in Ihrem PATH.

So beheben Sie es: Installieren Sie WP-CLI auf dem neuen Server. Wenn Sie keine Berechtigung haben, die Datei auf Ihrem Host ausführbar zu machen, können Sie Befehle stattdessen mit php wp-cli.phar anstelle von wp ausführen.

rsync wird mit „Zugriff verweigert“ beendet

Was Sie sehen: rsync läuft, wird aber frühzeitig mit einer oder mehreren „Zugriff verweigert“-Fehlermeldungen für bestimmte Dateien oder Verzeichnisse beendet.

Warum es passiert: Entweder ist Ihr SSH-Schlüssel nicht korrekt für den Zielserver konfiguriert, oder es gibt eine Diskrepanz bei den Dateibesitzern zwischen den beiden Servern.

So beheben Sie es: Überprüfen Sie zuerst den SSH-Schlüsselzugriff mit ssh user@newserver. Wenn dies fehlschlägt, klären Sie die Schlüsselauthentifizierung, bevor Sie rsync erneut versuchen. Wenn die Verbindung funktioniert, aber bestimmte Dateien verweigert werden, müssen Sie möglicherweise die übertragenen Dateien auf dem neuen Server mit chown an den Webbenutzer anpassen, den Ihr Host verwendet – üblicherweise www-data unter Ubuntu oder der Benutzername des Kontos auf cPanel-Hosts.

Seite wird geladen, aber Bilder sind defekt

Was Sie sehen: Seiten werden korrekt geladen, aber Bilder zeigen defekte Bildsymbole auf der gesamten Website an.

Warum es passiert: Entweder wurde der Ordner wp-content/uploads nicht vollständig übertragen, oder hartcodierte Bild-URLs im Post-Inhalt wurden nicht von search-replace erfasst.

So beheben Sie es: Führen Sie rsync erneut aus, wobei Sie nur den Uploads-Ordner anvisieren, um alle Dateien zu erfassen, die nicht übertragen wurden:

rsync -avz --progress /path/to/old-wordpress/wp-content/uploads/ user@newserver:/path/to/new-wordpress/wp-content/uploads/

Führen Sie dann search-replace mit --dry-run erneut aus, um zu prüfen, ob noch Bild-URLs auf die alte Domain verweisen.

Nichts funktioniert: Wiederherstellen und neu beginnen

Wenn die Website komplett kaputt ist und Sie keine klare Ursache identifizieren können, verbringen Sie nicht stundenlang damit, einen halb migrierten Zustand zu debuggen. Stellen Sie das Duplicator Pro-Backup wieder her, das Sie in Schritt 1 erstellt haben.

Die Notfall-URL von Duplicator kann die alte Website wiederherstellen, auch wenn WordPress gesperrt ist.

Sobald Sie wieder einen sauberen, funktionierenden Zustand haben, gehen Sie die Schritte noch einmal langsam durch. Verwenden Sie –dry-run für rsync und wp search-replace, bevor Sie etwas committen, und überprüfen Sie die wp-config.php-Anmeldeinformationen doppelt, bevor Sie den Import ausführen.

Häufig gestellte Fragen (FAQs)

Ihre Website ist auf dem neuen Server. Hier ist, was Sie als Nächstes beachten sollten.

Sie haben die Datenbank exportiert, die Dateien übertragen, wp-config.php aktualisiert, importiert, einen Such- und Ersetzungsvorgang durchgeführt, alles auf dem neuen Server überprüft und die DNS geändert. Das ist die vollständige Migration.

Die ersten 48 Stunden sind es wert, beachtet zu werden. DNS-Propagation bedeutet, dass einige Besucher während dieses Zeitfensters immer noch den alten Server erreichen. Nehmen Sie ihn also noch nicht außer Betrieb.

Achten Sie auf Caching-Ebenen, die möglicherweise veraltete Inhalte ausliefern. Ein vollständiges Leeren des Caches auf dem neuen Server, sobald die Propagation bestätigt ist, dauert zehn Sekunden und schließt viele Anzeigeprobleme aus.

Wenn nach Abschluss der Propagation immer noch etwas nicht stimmt, verwenden Sie wp search-replace --dry-run als Diagnosewerkzeug, bevor Sie etwas ändern:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Dies zeigt Ihnen, welche Tabellen noch die alte Domain enthalten, ohne Änderungen vorzunehmen. Es ist der schnellste Weg, um zu bestätigen, ob eine verbleibende URL ein Such- und Ersetzungsfehler ist oder etwas fest in einer Theme-Datei kodiert wurde.

Fest kodierte URLs in benutzerdefinierten Theme-Dateien werden von Such- und Ersetzungsvorgängen überhaupt nicht erfasst. Sie müssen diese manuell im Theme-Code finden und aktualisieren.

Migrieren Sie mit Zuversicht mit Duplicator Pro

Eine Migration ohne Backup ist ein Glücksspiel. Server verhalten sich unerwartet, Importe werden unterbrochen und serialisierte Daten überstehen eine Such- und Ersetzung nicht immer sauber.

Ein Wiederherstellungspunkt, bevor Sie beginnen, bedeutet, dass jede dieser Situationen ein kleiner Rückschlag statt ein ernstes Problem ist.

Duplicator Pro macht das Backup zu einem einzigen Befehl vom Terminal: wp duplicator build. Und wenn doch etwas schief geht, bringt die Notfall-URL Ihre ursprüngliche Website zurück, selbst wenn WordPress vollständig gesperrt ist.

Über 1,5 Millionen WordPress-Profis nutzen Duplicator Pro, um ihre Websites zu sichern, zu migrieren und zu klonen. Schließen Sie sich ihnen an!

Wenn dieses Tutorial hilfreich war, sind diese Anleitungen auch lesenswert.

• So verschieben Sie eine WordPress-Website zu einem neuen Hoster
• Warum Sie sich nach einer Migration nicht bei WordPress anmelden können
• DNS-Migration richtig gemacht: So vermeiden Sie die häufigsten Fehler
• Die vollständige Checkliste für Tests nach der WordPress-Migration
• So überprüfen Sie Inhalte vor einer Website-Migration
• So migrieren Sie eine WordPress-Site KOSTENLOS