WordPress umziehen: neuer Server, neuer Hoster oder neue Domain

Einen WordPress-Umzug machst du in vier Teilen: Dateien kopieren, Datenbank kopieren, wp-config.php auf die neue Datenbank einstellen, DNS umstellen. Bleibt die Domain dieselbe, ist das laut WordPress-Dokumentation der einfache Fall: Dateien und Datenbank kopieren, bei geändertem Datenbanknamen oder Benutzer die wp-config.php anpassen. Kommt eine neue Domain dazu, wird es eine Stufe aufwendiger, weil die alte Adresse an vielen Stellen in der Datenbank steht und jede alte URL eine Weiterleitung braucht.

Die Website ist selten das Einzige beim alten Hoster. Oft liegen dort auch die Postfächer, die DNS-Zone und die Domain selbst. Wer nur WordPress umzieht und den alten Vertrag kündigt, verliert Tage später die Mails.

Was beim alten Hoster alles dranhängt#

Bevor du etwas kopierst, schreib auf, was der alte Vertrag tatsächlich liefert. Der Weg dauert zehn Minuten im Kundenmenü:

1. Webspace und Datenbank: die WordPress-Installation selbst, samt PHP-Version.
2. Postfächer: Steht der MX-Eintrag der Domain auf einem Server des alten Hosters, laufen die Mails dort. Was MX- und A-Einträge tun, steht in DNS-Einträge erklärt.
3. DNS-Zone: Wer verwaltet die Einträge? Liegt die Zone beim alten Hoster, verschwindet sie mit dem Vertrag.
4. Domain: Ist der alte Hoster auch Registrar, ist der Domain-Transfer ein eigener Vorgang. Bei .at brauchst du dafür die Authinfo, die du laut nic.at jederzeit beim bisherigen Registrar anfordern kannst. Gibt er sie nicht heraus, kann der neue Registrar bei nic.at einen Bestätigungs-Token anfordern, der 21 Tage gültig ist. Wem die Domain gehört und wie du das prüfst, steht in Domain absichern.
5. Cronjobs: Hat jemand DISABLE_WP_CRON gesetzt und beim Hoster einen echten Cronjob auf wp-cron.php eingerichtet, muss der beim neuen Hoster neu angelegt werden. Sonst laufen geplante Beiträge, Sicherungen und Update-Prüfungen nicht mehr.

Wer nur das Hosting wechselt, muss die Domain nicht mit umziehen. Webspace und Domain-Transfer am selben Tag sind zwei Fehlerquellen auf einmal.

Plugin oder von Hand#

Ohne SSH-Zugang ist ein Plugin der realistische Weg. Mit SSH und WP-CLI ist der Weg von Hand nicht länger und du siehst jeden Schritt. Was die drei bekanntesten Plugins laut ihrer Seite auf wordpress.org können:

• All-in-One WP Migration exportiert die Seite in eine .wpress-Datei, die du auf der neuen Installation unter „Import“ hochlädst. Die Grenze setzt der Hoster: „Your hosting company decides how large a file you can upload“, die Import-Seite zeigt den Wert an. Uploads über dieses Limit hinaus gibt es nur mit der kostenpflichtigen Unlimited Extension.
• Duplicator packt Dateien und Datenbank in ein Archiv und spielt es am Ziel mit einem Installationsassistenten ein, auch mit eigenen Suchen-und-Ersetzen-Regeln. Die Gratisversion ist laut Beschreibung die Lite-Ausgabe von Duplicator Pro; Multisite-Unterstützung nennt der Hersteller als Pro-Funktion.
• Migrate Guru überträgt über die eigenen Server des Anbieters, laut Seite für Websites bis 200 GB. Am Ziel muss WordPress schon installiert sein. Die Daten laufen dabei über einen Dritten, bei einem Shop mit Kundendaten gehört das in deine Datenschutzabwägung.

Jedes dieser Plugins ist ein weiteres Plugin mit Zugriff auf die ganze Installation. Nach dem Umzug deaktivieren und löschen, samt der Archive, die es angelegt hat. Darin steckt die ganze Datenbank.

Der Weg von Hand, Schritt für Schritt#

Voraussetzung: SSH auf beiden Servern, WP-CLI auf dem neuen, und beim neuen Hoster eine leere Datenbank mit eigenem Benutzer, im Kundenmenü angelegt. Zuerst eine frische Sicherung, die du auch zurückspielen kannst; wie das aussieht, steht in WordPress-Backup.

# 1. auf dem alten Server: Datenbank exportieren
cd ~/public_html
wp db export ~/umzug.sql

# 2. auf dem neuen Server: Dateien und Export holen
rsync -az --exclude 'wp-content/cache' alt@alt-server.example:public_html/ ~/public_html/
rsync -az alt@alt-server.example:umzug.sql ~/

# 3. wp-config.php auf die neue Datenbank umstellen
cd ~/public_html
wp config set DB_NAME neu_db
wp config set DB_USER neu_user
wp config set DB_PASSWORD 'neues-passwort'
wp config set DB_HOST localhost

# 4. Datenbank einspielen und prüfen
wp db import ~/umzug.sql
wp option get home
wp option get siteurl

# 5. Permalinks neu schreiben, Export löschen
wp rewrite flush --hard
rm ~/umzug.sql

Ohne SSH geht dasselbe mit einem SFTP-Programm für die Dateien und phpMyAdmin für die Datenbank: beim alten Hoster exportieren, beim neuen importieren. wp db export ist nichts anderes als mysqldump mit den Zugangsdaten aus der wp-config.php.

Drei Hinweise zu den Befehlen. Welchen Wert DB_HOST braucht, steht im Kundenmenü des neuen Hosters, nicht immer ist es localhost; was in der Datei sonst steht, erklärt die wp-config.php. wp rewrite flush --hard schreibt laut WP-CLI-Dokumentation auch die .htaccess neu, auf Apache aber nur, wenn mod_rewrite in der wp-cli.yml eingetragen ist. Ohne das reicht es, im Backend unter „Einstellungen → Permalinks“ einmal auf „Speichern“ zu klicken, das empfiehlt auch die WordPress-Dokumentation. Und die Datei umzug.sql gehört sofort gelöscht, auf beiden Servern, denn sie enthält alle Benutzer samt Passwort-Hashes.

Testen, bevor jemand die neue Seite sieht#

Solange der DNS-Eintrag auf den alten Server zeigt, siehst du unter deiner Domain die alte Seite. Um die neue unter der echten Adresse zu prüfen, sagst du nur deinem eigenen Rechner, wo die Domain jetzt liegt. Dafür ist die hosts-Datei da, auf Linux und macOS /etc/hosts:

203.0.113.10  www.deine-domain.example deine-domain.example

203.0.113.10 steht für die IP-Adresse des neuen Servers aus dem Kundenmenü. Für einen schnellen Blick ohne Systemdatei tut es auch curl mit --resolve, laut Handbuch „a sort of /etc/hosts alternative“:

curl -sI --resolve www.deine-domain.example:443:203.0.113.10 https://www.deine-domain.example/

Kommt 200 und die Seite sieht im Browser richtig aus, Startseite, eine Unterseite, ein Bild, das Kontaktformular und die Anmeldung durchklicken. Danach die Zeile aus der hosts-Datei wieder entfernen, sonst siehst du später etwas anderes als alle anderen.

Das Zertifikat vor der DNS-Umstellung#

Stellst du den DNS-Eintrag um, bevor der neue Server ein gültiges Zertifikat hat, sieht jeder Besucher eine Zertifikatswarnung. Das Problem dabei: Die übliche HTTP-Prüfung von Let's Encrypt legt eine Datei unter http://<deine-domain>/.well-known/acme-challenge/ ab und ruft sie über Port 80 ab. Solange die Domain auf den alten Server zeigt, landet diese Abfrage dort.

Es gibt zwei saubere Wege. Die DNS-Prüfung von Let's Encrypt setzt stattdessen einen TXT-Eintrag unter _acme-challenge.<deine-domain> und funktioniert unabhängig davon, wohin die Website gerade zeigt. Oder du fragst den neuen Hoster, wie er Zertifikate für Domains ausstellt, die noch nicht auf ihn zeigen; viele lösen das im Kundenmenü. Ein Test über die hosts-Datei mit https:// zeigt dir vorher, ob das Zertifikat passt.

DNS umstellen, ohne dass Mails verloren gehen#

Wie lange ein alter Eintrag noch in Zwischenspeichern steht, bestimmt seine TTL; RFC 1035 definiert sie als die Zeit, die ein Eintrag zwischengespeichert werden darf. Google empfiehlt für einen Hosterwechsel, die TTL mindestens eine Woche vorher auf einen niedrigen Wert zu senken, etwa ein paar Stunden. Wie du das konkret einstellst und warum die alte TTL die Wartezeit bestimmt, steht in DNS-Einträge erklärt.

Umgestellt werden dann:

• der A-Eintrag auf die IPv4-Adresse des neuen Servers,
• der AAAA-Eintrag auf seine IPv6-Adresse oder gelöscht, wenn der neue Server keine hat. Bleibt er stehen, landen Geräte mit IPv6 weiter auf der alten Seite.
• der MX-Eintrag nur, wenn auch die Mails umziehen. Bleiben die Postfächer beim alten Anbieter, bleibt der MX, wie er ist, und der alte Mailvertrag läuft weiter.

Kündigst du den alten Hoster, bevor die Mails woanders laufen, kommen keine Mails mehr an. Kläre deshalb vorher, ob und wie die Postfächer samt gespeicherten Mails mitkommen, und stelle den MX erst um, wenn die neuen Postfächer stehen. Liegt die DNS-Zone selbst beim alten Hoster, übertrage zuerst alle Einträge zum neuen Verwalter, auch die TXT-Einträge für SPF, DKIM und DMARC.

Den alten Server lässt du laufen, bis dort nichts mehr ankommt. Google formuliert es so: Erst wenn der Verkehr beim alten Anbieter in dessen Serverprotokollen auf null gefallen ist, kann die alte Infrastruktur abgeschaltet werden.

Zusätzlich beim Domainwechsel#

Zieht die Seite auf eine neue Domain, kommen drei Schritte dazu.

Adressen in der Datenbank umschreiben. Die WordPress-Dokumentation warnt ausdrücklich vor einem einfachen Suchen-und-Ersetzen über die ganze Datenbank, weil manche Themes und Widgets die Länge der Adresse mitspeichern: „When this changes, things break.“ wp search-replace behandelt serialisierte PHP-Daten laut WP-CLI-Dokumentation richtig. Zuerst mit --dry-run ansehen, was ersetzt würde, dann ausführen:

wp search-replace 'https://www.alte-domain.example' 'https://www.neue-domain.example' --skip-columns=guid --dry-run
wp search-replace 'https://www.alte-domain.example' 'https://www.neue-domain.example' --skip-columns=guid

Die Spalte guid bleibt unverändert; die WordPress-Dokumentation nennt es „critical“, diesen Inhalt nicht zu ändern, weil Feedreader Beiträge daran erkennen. Plugins mit eigenen Tabellen ohne WordPress-Präfix erreichst du mit --all-tables.

Jede alte Adresse per 301 auf ihre neue. Google empfiehlt serverseitige dauerhafte Weiterleitungen und warnt davor, viele alte Adressen auf eine einzige Seite wie die Startseite zu schicken; das kann als Soft 404 gelten. Bleiben die Pfade gleich, reicht auf dem alten Server eine Regel in der .htaccess, vor dem WordPress-Block:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?alte-domain\.example$ [NC]
RewriteRule ^(.*)$ https://www.neue-domain.example/$1 [R=301,L,NE]

Das =301 ist wichtig: Ohne Angabe schickt mod_rewrite laut Apache-Dokumentation 302.

Adressänderung in der Search Console. Das Tool zur Adressänderung setzt voraus, dass du Inhaber beider Properties im selben Google-Konto bist und die Weiterleitungen schon laufen. Für den Wechsel von HTTP auf HTTPS ist es nicht gedacht. Laut Google sollen die Weiterleitungen mindestens 180 Tage stehen bleiben, die Anleitung zum Website-Umzug spricht von mindestens einem Jahr; die alte Domain sollst du mindestens ein Jahr weiter bezahlen, damit sie niemand für schädliche Zwecke kauft. Welche Reihenfolge bei einem Relaunch mit neuer Struktur gilt, steht in Website überarbeiten lassen.

In eigener Sache: cyberscale ist am 10.10.2026 von cyberscale.io auf www.cyberscale.dev umgezogen. Das war eine statische Seite, kein WordPress, aber Weiterleitungen, Adressänderung und die weiterbezahlte alte Domain sind dieselben Schritte.

Prüfliste nach dem Umzug#

• [ ] Startseite, Unterseiten, Bilder und Anmeldung unter der echten Adresse geprüft, mit und ohne www
• [ ] Kontaktformular abgeschickt und die Mail ist angekommen, nicht im Spam
• [ ] Neue Postfächer empfangen und senden, MX zeigt auf den richtigen Server
• [ ] Cronjob beim neuen Hoster angelegt, falls DISABLE_WP_CRON gesetzt ist
• [ ] Caching-Plugin und Seitencache geleert, Einstellungen auf den neuen Server angepasst
• [ ] Sicherung beim neuen Hoster eingerichtet und einmal zurückgespielt
• [ ] Migrations-Plugin und seine Archive gelöscht, umzug.sql auf beiden Servern weg
• [ ] TTL wieder auf den üblichen Wert gesetzt
• [ ] Bei neuer Domain: Weiterleitungen Stichprobe für Stichprobe geprüft, Adressänderung in der Search Console gestellt
• [ ] Alter Vertrag erst gekündigt, wenn dort keine Zugriffe und keine Mails mehr ankommen

Typische Fehler und wo es weitergeht#

„Fehler beim Aufbau einer Datenbankverbindung“#

Fast immer stimmen DB_NAME, DB_USER, DB_PASSWORD oder DB_HOST in der wp-config.php nicht mit dem neuen Server überein. Wie du die Fehlernummer liest und die Zugangsdaten prüfst, steht in Fehler beim Aufbau einer Datenbankverbindung.

Weiße Seite#

Meist ein PHP-Fehler, den niemand angezeigt bekommt. Nach einem Umzug liegt der Verdacht nahe, dass der neue Server eine andere PHP-Version hat als der alte; sie steht im Kundenmenü. Wie du das Fehlerprotokoll findest und den Verursacher abschaltest, steht in WordPress zeigt eine weiße Seite.

Mixed Content: Schloss fehlt, Stile fehlen#

Die Seite läuft über HTTPS, lädt aber Bilder, Skripte oder Schriften noch über http://. Einfache Bilder rüsten Browser laut MDN automatisch auf, Skripte, Stylesheets und Schriften blockieren sie. Stehen die alten http://-Adressen in der Datenbank, hilft derselbe wp search-replace, mit 'http://www.deine-domain.example' als Such- und 'https://www.deine-domain.example' als Ersatzwert, zuerst mit --dry-run.

Weiterleitungsschleife#

Steht der neue Server hinter einem Proxy, der HTTPS übernimmt, während WordPress selbst ohne HTTPS läuft, führen die HTTPS-Einstellungen laut WordPress-Dokumentation zunächst in eine Endlosschleife („infinite redirect loop“). Die Lösung dort ist eine Zeile in der wp-config.php, die den Header X-Forwarded-Proto auswertet; der neue Hoster sagt dir, ob du sie brauchst.

Mails kommen nicht an#

Entweder zeigt der MX noch auf den alten, gekündigten Server, oder WordPress versendet jetzt von einem Server, der nicht im SPF-Eintrag der Domain steht. Den sauberen Versand über SMTP beschreibt WordPress-Mails kommen nicht an.

Was nicht hilft#

Suchen und Ersetzen in der SQL-Datei mit dem Editor. Das zerstört serialisierte Einträge, sobald sich die Länge der Adresse ändert, und das merkst du oft erst an fehlenden Widgets oder kaputten Theme-Einstellungen.

RELOCATE in der wp-config.php stehen lassen. Die Konstante hilft in einer Notlage, die Adresse über die Anmeldeseite zu korrigieren. Die WordPress-Dokumentation nennt es ausdrücklich unsicher, sie danach drinzulassen.

Den alten Hoster am Tag der Umstellung kündigen. Solange Zwischenspeicher noch die alte Adresse liefern, landen Besucher und Mails dort.

Wenn du es nicht selbst machen willst#

cyberscale bin ich, Stefan Haun aus Tirol. Einen Umzug zu einem anderen Hoster oder auf eine neue Domain mit Weiterleitungen übernehme ich als WordPress-Freelancer nach Aufwand, 60 € je Stunde, mit einem Rahmen in Stunden vorher. Hosting und Domain laufen dabei weiter über dich. Soll danach jemand regelmäßig an der Seite arbeiten, gibt es die Website-Betreuung für 149 € im Monat, mit bis zu zwei Stunden Änderungen und Wartung. Geht es nur um Updates, Sicherung und Überwachung beim neuen Hoster, reicht die WordPress-Wartung für 49 € im Monat.

Häufige Fragen#

Stand 26.10.2026. WordPress- und WP-CLI-Dokumentation, die Plugin-Seiten auf wordpress.org, Google Search Central, nic.at, Let's Encrypt, MDN, Apache-Dokumentation, RFC 1035 und das curl-Handbuch an diesem Tag gelesen. Menüs und Zertifikatswege unterscheiden sich je nach Hoster.