--- title: "Domain einer WordPress-Website ändern: URLs sicher ersetzen und umleiten" date: 2026-09-30T22:15:22+02:00 modified: 2026-10-12T01:20:07+02:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-domain-aendern-urls-search-replace-umleiten keywords: - WordPress - Domain - WP-CLI - Migration - Weiterleitung reading_time: 9 --- # 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. **Kurzfassung:** Richten Sie die neue Domain mit HTTPS beim Hoster ein, bevor Sie WordPress umstellen. Sichern Sie die Datenbank mit `wp db export`. Prüfen Sie mit `wp search-replace 'https://alte-domain.de' 'https://neue-domain.de' --skip-columns=guid --dry-run --report-changed-only`, was sich ändern würde, und führen Sie den Befehl dann ohne `--dry-run` aus. WP-CLI passt dabei serialisierte Daten korrekt an, ein SQL-`REPLACE` tut das nicht. Leiten Sie die alte Domain per 301 auf die neue um und melden Sie den Umzug in der Google Search Console. ## 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: ```bash $ 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: ```bash $ 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. > **Prüfen:** 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: ```bash $ 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](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen). > **Prüfen:** 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: ```plaintext 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: ```plaintext 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. > **Prüfen:** 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: ```bash 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: ```plaintext 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`: ```bash 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` und legt die Datei außerhalb des öffentlich erreichbaren Webverzeichnisses ab. Im Labor schrieb WP-CLI dann „Made 7 replacements and exported to wp-content/neu.sql.“ und ließ die Datenbank selbst unverändert. > **Prüfen:** 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`: ```apache # Alte Domain dauerhaft auf neue Domain umleiten RewriteEngine On RewriteCond %{HTTP_HOST} ^(www\.)?alte-domain\.de$ [NC] RewriteRule ^(.*)$ https://www.neue-domain.de/$1 [R=301,L] ``` 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=95) übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Firewall. > **Prüfen:** `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](https://s-edv.com/anleitungen/wordpress-staging-umgebung-wp-cli-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](https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=95). ## Weiterführende Anleitungen und Quellen - [WordPress-Datenbank mit WP-CLI sichern und wiederherstellen](https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen) - [Staging-Umgebung für WordPress einrichten](https://s-edv.com/anleitungen/wordpress-staging-umgebung-wp-cli-einrichten) - [WordPress auf HTTPS umstellen und Mixed Content beheben](https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben) - [WP-CLI-Handbuch: wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/) - [Advanced Administration Handbook: Moving WordPress](https://developer.wordpress.org/advanced-administration/upgrade/migrating/) - [nginx-Dokumentation: return](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return) - [Google Search Central: Website-Umzug mit URL-Änderungen](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)