Hoster oder Server einer WordPress-Website wechseln

Eine WordPress-Website wechselt aus guten Gründen den Hoster oder Server: unzureichende Leistung, ein zu teures Angebot, eine PHP-Version, die nicht mehr gepflegt wird, ein Bedarf an Sicherheit oder Support. Der Inhalt ändert sich nicht, aber alles, was ihn betreibt, zieht um: die Dateien, die Datenbank, die Konfiguration, das Zertifikat. Gut gemacht, ist der Umzug für Besucher wie für Google unsichtbar.

Dieser Artikel behandelt den Umzug einer Website, die bereits unter WordPress läuft. Ist Ihre Website noch nicht unter WordPress, lesen Sie unsere Artikel zur Migration einer HTML-Website zu WordPress und zur Migration von Wix zu WordPress.

Eine WordPress-Website besteht aus zwei Teilen, die zusammen umziehen:

• die Dateien: der WordPress-Kern, der Ordner wp-content (Themes, Plugins, hochgeladene Medien), die Datei wp-config.php und unter Apache die Datei .htaccess, die Permalinks und Weiterleitungen enthält;
• die Datenbank: Beiträge, Seiten, Einstellungen, Konten, Kommentare und Bestellungen, falls es einen Shop gibt.

Hinzu kommt, was beim Hoster liegt und nicht kopiert wird: das HTTPS-Zertifikat, geplante Aufgaben, die E-Mail-Adressen der Domain und die Regeln des Webservers, wenn es Nginx ist. Erstellen Sie die Liste, bevor Sie beginnen.

Plugins wie Duplicator oder All-in-One WP Migration packen Dateien und Datenbank in ein Archiv, das auf dem neuen Server wiederhergestellt wird. Viele Hoster bieten auch ein eigenes Migrationstool an. Für eine Website überschaubarer Größe ist das der einfachste Weg; bei einer großen Website können die Größe des Archivs oder die Grenzen des Servers ihn scheitern lassen.

Man kopiert die Dateien per SFTP oder rsync, exportiert die Datenbank (mysqldump oder WP-CLI) und importiert sie auf dem neuen Server, dann aktualisiert man wp-config.php mit den neuen Zugangsdaten der Datenbank. Ändert sich die Adresse der Website, erfolgt das Suchen und Ersetzen mit wp search-replace oder einem Plugin, das serialisierte Daten berücksichtigt: Ein rohes Ersetzen in der SQL-Datei zerstört die Einstellungen von Themes und Plugins.

1. Sichern Sie die gesamte Website, Dateien und Datenbank, und bewahren Sie die Kopie außerhalb beider Server auf.
2. Testen Sie den neuen Server vor der Umstellung: Wenn Sie die Domain nur auf Ihrem eigenen Rechner auf die neue IP-Adresse zeigen lassen (Datei hosts), sehen Sie die Website so, wie sie sein wird, mit ihrem echten Domainnamen.
3. Senken Sie die Gültigkeitsdauer (TTL) der DNS-Einträge ein bis zwei Tage vorher, damit sich die Änderung schnell verbreitet.
4. Frieren Sie die Inhalte ein während der Umstellung: Ein Kommentar oder eine Bestellung, die nach der Kopie auf dem alten Server eingehen, gingen verloren.
5. Ändern Sie die DNS und lassen Sie den alten Server einige Tage online, bis alle Besucher auf dem neuen ankommen.

Solange die Adressen der Seiten gleich bleiben, erfordert ein Hosterwechsel keine Weiterleitung. Anders ist es, wenn Sie den Umzug nutzen, um den Domainnamen zu ändern, auf HTTPS umzustellen oder die Permalink-Struktur zu ändern: Dann muss jede alte URL mit einer 301-Weiterleitung auf die neue antworten, in einem einzigen Schritt. Melden Sie einen Domainwechsel außerdem in der Search Console (Tool zur Adressänderung). Siehe unseren Artikel zur Umstellung auf HTTPS und den zu Weiterleitungen in WordPress.

Crawlen Sie die Website vor dem Umzug und bewahren Sie die Liste ihrer URLs mit ihrem Antwortcode auf; crawlen Sie sie nach der Umstellung erneut und vergleichen Sie. Prüfen Sie auch, was am häufigsten verloren geht:

• das Kästchen „Suchmaschinen davon abhalten, diese Website zu indexieren“, auf dem Testserver angehakt und unverändert übernommen;
• die Datei robots.txt und die Sitemap, die auf dem neuen Server antworten müssen;
• das HTTPS-Zertifikat, installiert und gültig vor der DNS-Änderung;
• die Antwortzeiten, oft der Grund für den Umzug: Vergleichen Sie sie.

Beobachten Sie danach einige Wochen lang die Search Console: Crawling-Fehler, indexierte Seiten, Rankings.

Geht der Umzug mit einem Relaunch oder einer Änderung der Adressen einher, wird der Weiterleitungsplan zur Hauptsache. Swan crawlt die alte Website und die Staging-Umgebung, schlägt für jede alte URL die Seite vor, die sie nach semantischer Nähe ersetzt, lässt Sie die Zweifelsfälle bestätigen und prüft dann die Weiterleitungen vor und nach dem Go-live. Die Schritte, die jeder Plattformwechsel gemeinsam hat, beschreibt das Vorgehen beim CMS-Wechsel.