Domain einer WordPress-Website ändern: URLs sicher ersetzen und umleiten

Ein neuer Firmenname, eine Fusion oder der Wechsel von einer Länderendung auf eine andere: Irgendwann soll eine WordPress-Website unter einer neuen Domain erreichbar sein. WordPress speichert die Adresse der Website aber nicht an einer Stelle, sondern in Einstellungen, in jedem Beitrag mit Link oder Bild, in Widgets und in Daten von Plugins, teilweise in serialisierter Form. Wer hier mit einem einfachen Suchen und Ersetzen in der Datenbank arbeitet, zerstört Einstellungen, ohne es sofort zu merken. Diese Anleitung zeigt, wie Sie die Umstellung mit WP-CLI sicher durchführen, vorher prüfen, was geändert wird, und die alte Domain sauber auf die neue umleiten. Jeder Befehl wurde im Labor mit WordPress 7.1.2 und WP-CLI ausgeführt.

Voraussetzungen

• WordPress: eine aktuelle Installation, getestet mit WordPress 7.1.2 in deutscher Sprache.
• PHP: eine von WordPress unterstützte Version, im Labor PHP 8.4.
• Zugriff: SSH mit WP-CLI auf dem Server, Rolle Administrator im Backend und Zugang zur DNS-Verwaltung beider Domains. Ohne SSH bieten viele Hoster ein Werkzeug für Suchen und Ersetzen, das serialisierte Daten beherrscht, fragen Sie danach.
• Neue Domain: registriert, per DNS auf den Server zeigend und mit gültigem TLS-Zertifikat. Die alte Domain bleibt ebenfalls auf den Server gerichtet, sonst funktioniert die Umleitung nicht.
• Backup: eine frische Sicherung von Datenbank und Dateien, zusätzlich zum Export in Schritt 2.
• Zeitfenster: eine ruhige Stunde, in der niemand Inhalte bearbeitet oder bestellt.

Schritt 1: Neue Domain vorbereiten und Bestand aufnehmen

Die Umstellung in WordPress ist der letzte Schritt, nicht der erste. Zuerst muss die neue Domain technisch bereitstehen. Richten Sie sie beim Hoster für dasselbe Verzeichnis wie die bestehende Website ein und aktivieren Sie ein Zertifikat, etwa über Let's Encrypt. Prüfen Sie die Erreichbarkeit vorab auf der Kommandozeile:

curl -sI https://www.neue-domain.de/ | head -3

Solange WordPress noch auf die alte Adresse eingestellt ist, antwortet es auf Anfragen an die neue Domain mit einer Weiterleitung auf die gespeicherte Adresse. Das ist erwartetes Verhalten und zeigt, dass Anfragen bei WordPress ankommen. Im Labor leitete die Startseite nach dem Ändern der Adresse ohne passende Serverkonfiguration mit HTTP/1.1 301 Moved Permanently weiter.

Notieren Sie dann die bisherige Adresse exakt, wie WordPress sie gespeichert hat:

wp option get home
wp option get siteurl

Beide Werte entsprechen im Backend unter Einstellungen > Allgemein den Feldern „Website-Adresse (URL)“ und „WordPress-Adresse (URL)“. Achten Sie auf Details wie www und https. Genau diese Zeichenfolge suchen Sie später, ein Unterschied führt zu null Treffern.

Verifizieren: Die neue Domain liefert über HTTPS eine Antwort ohne Zertifikatsfehler, und Sie haben den bisherigen Wert von home und siteurl notiert.

Schritt 2: Datenbank sichern

Suchen und Ersetzen ändert Tausende Datensätze in einem Durchgang. Ein Tippfehler in der Zieladresse lässt sich nur mit einer Sicherung zuverlässig rückgängig machen. Exportieren Sie die Datenbank direkt vor der Umstellung:

wp db export ~/vor-domainwechsel.sql

Im Labor meldete der Befehl „Success: Exported to …“. Legen Sie die Datei außerhalb des Webroots ab, damit sie nicht über den Browser abrufbar ist. Später hat ein Wiederherstellen mit wp db import die Laborinstanz vollständig auf den alten Stand gebracht. Mehr zur Sicherung per WP-CLI steht in WordPress-Datenbank mit WP-CLI sichern und wiederherstellen.

Verifizieren: Die Exportdatei existiert, ist größer als wenige Kilobyte und enthält die Zeile CREATE TABLE für die Tabelle wp_options.

Schritt 3: Warum kein SQL-REPLACE

Die naheliegende Idee ist ein SQL-Befehl mit REPLACE. Das Problem sind serialisierte Daten. WordPress und viele Plugins speichern Einstellungen als PHP-serialisierte Zeichenketten, in denen vor jedem Text dessen Länge steht. Im Labor sah eine Widget-Einstellung so aus:

a:2:{s:3:"url";s:31:"http://127.0.0.1:21248/kontakt/";s:5:"titel";s:4:"Test";}

Die Angabe s:31 nennt die Länge der Adresse. Ein SQL-REPLACE auf die neue, längere Domain ergab im Labor:

a:1:{s:3:"url";s:31:"https://www.neue-domain.test/kontakt/";}

Die Länge stimmt nicht mehr, der Text hat 37 Zeichen. PHP kann die Einstellung nicht mehr lesen. wp option get meldete danach: „Error: Could not get 'widget_kopie' option. Does it exist?“ Die Option war für WordPress schlicht verschwunden, obwohl sie in der Datenbank stand. Auf einer echten Website äußert sich das als leeres Widget, verlorene Theme-Einstellungen oder ein Plugin, das auf Standardwerte zurückfällt.

wp search-replace entpackt serialisierte Daten, ersetzt darin und schreibt sie mit korrekten Längen zurück. Die Ausgabe zeigt das in der Spalte „Type“: PHP für Datensätze, die auf diese Weise behandelt wurden, SQL für einfache Textfelder. Die Entwicklerdokumentation von WordPress zum Umzug einer Website weist ausdrücklich auf dieses Problem hin.

Verifizieren: Sie verwenden für die Umstellung ausschließlich wp search-replace oder ein Werkzeug, das serialisierte Daten ausdrücklich unterstützt.

Schritt 4: Probelauf und Umstellung mit WP-CLI

Starten Sie immer mit einem Probelauf. Er ändert nichts und zeigt, wo wie viele Ersetzungen stattfinden würden:

wp search-replace 'https://www.alte-domain.de' 'https://www.neue-domain.de' \
  --skip-columns=guid --dry-run --report-changed-only

Im Labor lieferte der Probelauf für eine kleine Installation mit einer Seite, einem Widget und einem Benutzer:

Table	Column	Replacements	Type
wp_options	option_value	3	PHP
wp_posts	post_content	3	SQL
wp_users	user_url	1	SQL
Success: 7 replacements to be made.

Zu den Optionen: --skip-columns=guid lässt die Spalte guid in wp_posts unverändert. Laut Entwicklerdokumentation dient sie Feed-Readern als dauerhafte Kennung eines Beitrags und darf sich nie ändern. Ohne diese Option wollte WP-CLI im Labor vier zusätzliche Ersetzungen in guid vornehmen. --report-changed-only blendet Tabellen ohne Treffer aus.

Zwei Sonderfälle sollten Sie im Probelauf gezielt prüfen:

• JSON mit maskierten Schrägstrichen: Einige Page Builder speichern Adressen als https:\/\/www.alte-domain.de. Im Labor fand die normale Suche einen solchen Eintrag in wp_postmeta nicht, erst ein zweiter Durchlauf mit 'https:\/\/www.alte-domain.de' 'https:\/\/www.neue-domain.de' meldete „1 replacement to be made“.
• Eigene Tabellen von Plugins: WP-CLI durchsucht standardmäßig nur die Tabellen, die WordPress kennt. Eine Plugin-Tabelle wp_eigene_links erschien im Labor erst mit der Option --all-tables-with-prefix, die Zahl stieg von 7 auf 8 Ersetzungen.

Passt das Ergebnis, führen Sie denselben Befehl ohne --dry-run aus, bei Bedarf ergänzt um --all-tables-with-prefix:

wp search-replace 'https://www.alte-domain.de' 'https://www.neue-domain.de' \
  --skip-columns=guid --all-tables-with-prefix --report-changed-only
wp cache flush
wp rewrite flush

Im Labor meldete WP-CLI „Success: Made 7 replacements.“ Danach lieferten wp option get home und wp option get siteurl die neue Adresse, die serialisierte Widget-Einstellung trug die korrekte Länge s:37, und Links wie Bilder im Seiteninhalt zeigten auf die neue Domain. wp cache flush leert den Objekt-Cache, wp rewrite flush erneuert die Permalink-Regeln. Leeren Sie zusätzlich den Seiten-Cache eines Cache-Plugins oder des Hosters.

Wer lieber vorher eine Datei prüfen möchte, statt direkt in die Datenbank zu schreiben, nutzt --export=neu.sql. Im Labor schrieb WP-CLI dann „Made 7 replacements and exported to wp-content/neu.sql.“ und ließ die Datenbank selbst unverändert.

Verifizieren: Ein erneuter Probelauf mit der alten Domain meldet „0 replacements to be made“, und die Startseite öffnet sich unter der neuen Domain ohne Weiterleitungsschleife.

Schritt 5: Alte Domain umleiten und Umzug abschließen

Die alte Domain darf nicht einfach ins Leere laufen. Suchmaschinen, Lesezeichen, gedruckte Visitenkarten und Links auf anderen Websites verweisen weiter auf sie. Eine dauerhafte Weiterleitung mit Statuscode 301 führt Besucher und Suchmaschinen auf die gleiche Seite unter der neuen Adresse. Auf Apache tragen Sie das in die .htaccess ein, oberhalb des Blocks # BEGIN WordPress:

# Alte Domain dauerhaft auf neue Domain umleiten
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?alte-domain\.de$ [NC]
RewriteRule ^(.*)$ https://www.neue-domain.de/$1 [R=301,L]
</IfModule>

Im Labor mit den Testdomains leitete die Regel /kontakt/?x=1 auf der alten Domain mit 301 Moved Permanently auf https://www.neue-domain.test/kontakt/?x=1 weiter, Pfad und Parameter blieben erhalten. Anfragen an die neue Domain blieben unberührt. Auf nginx lösen Sie das mit einem eigenen server-Block für die alte Domain und return 301 https://www.neue-domain.de$request_uri;, die Syntax beschreibt die nginx-Dokumentation zu return.

Anschließend erledigen Sie die Aufgaben außerhalb von WordPress:

• Google Search Console: neue Domain als Property anlegen und in der alten Property die Adressänderung melden.
• E-Mail: Prüfen Sie Absenderadressen in Formular- und SMTP-Einstellungen, sie ändern sich nicht automatisch mit.
• Externe Dienste: Zahlungsanbieter, Newsletter-Dienst, Analyse-Werkzeug und API-Zugänge auf die neue Domain umstellen.
• Impressum und Datenschutzerklärung: Domain und gegebenenfalls Firmierung anpassen.
• Alte Domain behalten: Kündigen Sie sie nicht, die Weiterleitung braucht die Domain dauerhaft.

In den Wochen nach dem Umzug zeigen Fehlerprotokolle und die Search Console, ob noch Adressen ins Leere laufen. Wer diese Nacharbeit zusammen mit Updates und Backups nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Firewall.

Verifizieren: curl -sI https://alte-domain.de/kontakt/ liefert 301 mit Location auf die neue Domain und denselben Pfad. Unter Einstellungen > Allgemein stehen beide Adressfelder auf der neuen Domain.

Typische Fehler

• „Could not get '…' option. Does it exist?“ nach dem Umzug: Serialisierte Daten wurden per SQL-REPLACE beschädigt. Datenbank aus der Sicherung zurückspielen und mit wp search-replace wiederholen.
• Weiterleitungsschleife oder Login unmöglich: home und siteurl passen nicht zur tatsächlichen Adresse oder zum Protokoll. Werte mit wp option get prüfen. Im Notfall setzen die Konstanten WP_HOME und WP_SITEURL in der wp-config.php die Werte fest, im Labor hatten sie Vorrang vor der Datenbank.
• „0 replacements“ im Probelauf: Die gesuchte Adresse stimmt nicht exakt, etwa ohne www oder mit http statt https. Wert aus Schritt 1 verwenden.
• Einzelne Bilder oder Links zeigen weiter auf die alte Domain: Sie liegen in maskiertem JSON oder in Plugin-Tabellen. Zweiten Durchlauf mit \/ und --all-tables-with-prefix ausführen.
• Feed-Reader zeigen alle Beiträge als neu: Die Spalte guid wurde mit ersetzt. Künftig immer --skip-columns=guid verwenden.

Häufige Fragen

Reicht es, die Adressen unter Einstellungen > Allgemein zu ändern?

Nein. Damit ändern Sie nur home und siteurl. Links und Bilder in Beiträgen, Widgets und Plugin-Daten behalten die alte Adresse und funktionieren nur, solange die Weiterleitung besteht.

Wie lange muss die Weiterleitung bestehen bleiben?

Dafür gibt es keine feste Frist. Google empfiehlt in seiner Dokumentation zu Website-Umzügen, Weiterleitungen möglichst lange beizubehalten, mindestens aber ein Jahr. Solange externe Links oder Drucksachen auf die alte Domain verweisen, lohnt sich die Weiterleitung.

Kann ich die Umstellung vorher gefahrlos testen?

Ja, auf einer Kopie der Website. Die Anleitung Staging-Umgebung für WordPress einrichten nutzt genau diesen Befehl für die Staging-Adresse.

Wechselt gleichzeitig das Protokoll von HTTP auf HTTPS?

Dann ersetzen Sie in einem Durchgang http://alte-domain.de durch https://neue-domain.de. Hinweise zu Mixed Content gibt WordPress auf HTTPS umstellen.

Testumfang

Getestet im Labor mit WordPress 7.1.2 (deutsch), PHP 8.4 und WP-CLI: Export und Import der Datenbank, Beschädigung serialisierter Daten durch SQL-REPLACE, wp search-replace mit und ohne --skip-columns=guid, Probelauf, Ersetzung mit Kontrolle der Längenangabe, maskiertes JSON in wp_postmeta, Plugin-Tabelle mit --all-tables-with-prefix, --export, Vorrang von WP_HOME und die 301-Regel in der .htaccess mit Testdomains per Host-Header. Nicht getestet: echte Domains und Zertifikate, nginx, Multisite, Search Console.

Fazit

Ein Domainwechsel ist mit WP-CLI in wenigen Befehlen erledigt, wenn die Reihenfolge stimmt: neue Domain bereitstellen, Datenbank sichern, Probelauf lesen, ersetzen, alte Domain dauerhaft umleiten. Der wichtigste Grundsatz lautet, serialisierte Daten nie per SQL anzufassen. Wenn Sie Updates, Backups und die Kontrolle nach solchen Umstellungen lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Datenbank mit WP-CLI sichern und wiederherstellen
• Staging-Umgebung für WordPress einrichten
• WordPress auf HTTPS umstellen und Mixed Content beheben
• WP-CLI-Handbuch: wp search-replace
• Advanced Administration Handbook: Moving WordPress
• nginx-Dokumentation: return
• Google Search Central: Website-Umzug mit URL-Änderungen