Wie aktualisiert man URLs in der WordPress-Datenbank beim Domainumzug?

Der Umzug einer WordPress-Website (z. B. von dev.site.de auf site.de) scheint einfach zu sein: Einfach “Suchen und Ersetzen” in der Datenbank ausführen, oder?

FALSCH.

Wenn Sie versuchen, eine rohe SQL-Abfrage wie diese auszuführen: UPDATE wp_options SET option_value = replace(option_value, 'alt.de', 'neu.de')

…werden Sie Ihre Website beschädigen. Konkret: Sie verlieren Widgets, Theme-Optionen und die Konfiguration vieler Plugins.

#WordPress-URL in der Datenbank ändern: der sichere Weg

Der sichere Weg, die WordPress-URL in der Datenbank zu ändern, ist ein einziger WP-CLI-Befehl, ausgeführt nach einem Backup:

wp search-replace 'https://old.com' 'https://new.com' --all-tables --precise

Der Befehl aktualisiert siteurl und home in wp_options, jede URL in Inhalten und Metadaten und behandelt serialisierte Daten korrekt. Wenn Sie keinen Shell-Zugang haben, gilt diese Reihenfolge: zuerst ein Plugin, das Serialisierung versteht (Better Search Replace), danach phpMyAdmin, aber ausschließlich für die beiden Zeilen siteurl und home in wp_options, und niemals ein rohes SQL REPLACE() über alle Tabellen. Der Rest dieses Leitfadens erklärt, warum die letzte Methode Websites beschädigt, und führt Sie Schritt für Schritt durch jede Alternative.

#Der häufige Fehler: Einfaches “Suchen & Ersetzen”

Viele Entwickler (und sogar einige Hosting-Anbieter) schlagen vor, eine einfache SQL REPLACE()-Funktion zu verwenden, um URLs zu aktualisieren. Dieser Ansatz scheint logisch, ist aber im WordPress-Ökosystem grundlegend fehlerhaft.

Die Versuchung:

-- Das sieht sicher aus, ist es aber NICHT
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'https://alt.de', 'https://neu.de');

Was passiert:

• Einige URLs werden korrekt aktualisiert (z. B. im Beitragsinhalt).
• Serialisierte Daten werden beschädigt.
• Widgets verschwinden.
• Theme-Optionen werden zurückgesetzt.
• Plugin-Einstellungen gehen verloren.
• Die Website wird teilweise unbrauchbar.

Warum es scheitert: WordPress speichert nicht alle Daten als reinen Text. Vieles davon wird als serialisierte PHP-Daten gespeichert, was eine spezielle Behandlung erfordert.

#Serialisierung verstehen: Das Kernproblem

#Was ist Serialisierung?

WordPress speichert komplexe Datenstrukturen (Arrays, Objekte) in der Datenbank als Serialisierte Strings. Die Serialisierung wandelt PHP-Datenstrukturen in eine Zeichenkette um, die in der Datenbank gespeichert werden kann.

Beispiel für serialisierte Daten:

// Originales PHP-Array
array(
    'home' => 'https://alt.de',
    'siteurl' => 'https://alt.de',
    'admin_email' => '[email protected]'
)

// Serialisierter String (in der DB gespeichert)
a:3:{s:4:"home";s:14:"https://alt.de";s:7:"siteurl";s:14:"https://alt.de";s:11:"admin_email";s:13:"[email protected]";}

#Den serialisierten String aufschlüsseln

Lassen Sie uns s:14:"https://alt.de" entschlüsseln:

• s = String (Zeichenkette)
• 14 = Länge des Strings (Anzahl der Zeichen)
• "https://alt.de" = der Wert

Der kritische Teil: Die Zahl 14 repräsentiert die exakte Zeichenanzahl des Strings "https://alt.de".

#Was passiert beim einfachen Ersetzen?

Original:

s:14:"https://alt.de"

Nach einfachem SQL-Replace (alt.de -> neue-domain.de):

Das Problem:

• Die Stringlänge hat sich von 14 auf 22 Zeichen geändert.
• Die Serialisierung sagt immer noch s:14 (erwartet 14 Zeichen).
• PHP versucht, 14 Zeichen zu lesen: "https://neue-dom"
• Das Ende fehlt.
• Das gesamte Array wird ungültig.
• Die Daten sind korrupt.

Ergebnis: WordPress kann die Einstellungen oder Widgets nicht lesen, also werden sie ignoriert oder zurückgesetzt.

#Wo befinden sich serialisierte Daten?

#Häufige Orte

1. wp_options Tabelle:

• siteurl und home.
• Widget-Daten (sidebars_widgets).
• Theme-Modifikationen (theme_mods_*).
• Plugin-Optionen.

2. wp_postmeta Tabelle:

• Benutzerdefinierte Felder (Custom Fields).
• ACF-Daten.
• Anhang-Metadaten.

#Die Lösung: Serialisierungs-bewusste Tools

Sie benötigen ein Tool, das:

1. Daten entserialisiert (String zurück in PHP-Array wandelt).
2. Text innerhalb der Datenstruktur ersetzt.
3. Zeichenanzahl neu berechnet.
4. Daten neu serialisiert.
5. Die Datenbank aktualisiert.

#Methode 1: WP-CLI (Empfohlen)

Der professionelle Weg: Wenn Sie SSH-Zugang haben, ist WP-CLI das beste Werkzeug.

Grundlegende Nutzung:

wp search-replace 'https://alt.de' 'https://neu.de' --all-tables

Erweiterte Optionen:

## Dry run (Vorschau ohne Änderungen)
wp search-replace 'https://alt.de' 'https://neu.de' --all-tables --dry-run

#Methode 2: Better Search Replace Plugin

Für Nicht-CLI-Nutzer: Wenn Sie keinen SSH-Zugang haben, nutzen Sie das Plugin Better Search Replace.

Anleitung:

1. Installieren Sie das Plugin.
2. Gehen Sie zu Werkzeuge > Better Search Replace.
3. Geben Sie die alte und neue URL ein.
4. Wählen Sie die Tabellen aus.
5. Wichtig: Haken Sie zuerst “Run as dry run?” an.
6. Klicken Sie auf “Run Search/Replace”.

#Zusammenfassung

Im Jahr 2026 ist der korrekte Umgang mit serialisierten Daten keine Option, sondern Pflicht bei der WordPress-Migration.

• Verwenden Sie niemals einfaches SQL REPLACE.
• Bearbeiten Sie niemals Datenbank-Dumps mit einem Texteditor.
• Verwenden Sie immer WP-CLI oder Tools wie Better Search Replace.

Dies stellt sicher, dass Ihre Widgets und komplexen Einstellungen den Domainumzug überleben.

Mehr über unsere WordPress-Migrationen zu Astro und Next.js.