Migration von WordPress-Datenbanken

Der Umzug einer WordPress-Seite von einer Staging-Umgebung (z.B. dev.kunden-seite.de) auf eine Produktionsdomain (z.B. kunden-seite.de) ist ein Ritual, das jeder Entwickler hunderte Male durchführt. Und doch bleibt es auch im Jahr 2026 die häufigste Ursache für den berühmten “White Screen of Death”.

Warum? Weil viele Entwickler die WordPress-Datenbank immer noch wie eine einfache Excel-Tabelle behandeln, in der man einfach “Suchen und Ersetzen” kann.

Sie liegen falsch.

In diesem umfassenden 1500-Wörter-Ingenieursleitfaden analysieren wir die Architektur der WordPress-Datenbank, erklären das Konzept der Datenserialisierung und bieten Ihnen ein ausfallsicheres Protokoll für die Migration von 100GB-Datenbanken.

#Warum Serialisierung die WordPress-Migration beschädigt

Um zu verstehen, warum Migrationen scheitern, müssen Sie verstehen, wie PHP komplexe Daten speichert.

#Was ist Serialisierung?

Stellen Sie sich vor, Sie haben ein Array von Theme-Optionen:

$options = array(
    'theme_color' => 'blue',
    'logo_url'    => 'http://dev.site.com/logo.png'
);

Um dieses Array in einer einzigen Datenbankzelle zu speichern, “verpackt” PHP es in einen speziell formatierten String. Dieser Prozess heißt Serialisierung.

Das Ergebnis sieht so aus: a:2:{s:11:"theme_color";s:4:"blue";s:8:"logo_url";s:26:"http://dev.site.com/logo.png";}

#Was passiert, wenn SQL-REPLACE die Stringlänge ändert

Schauen Sie sich diesen Teil genau an: s:26:"http://dev.site.com/logo.png".

• s: String (Zeichenkette).
• 26: Die Anzahl der Zeichen.

Wenn Sie einen Standard-SQL-Befehl ausführen:

UPDATE wp_options SET option_value = REPLACE(option_value, 'dev.site.com', 'site.com');

Ändern Sie die URL zu http://site.com/logo.png (was 22 Zeichen hat). ABER der Zähler s:26 bleibt in der Datenbank unverändert.

Wenn WordPress versucht, diese Option zu laden, sagt PHP:

“Moment. Du hast mir gesagt, ich soll 26 Zeichen erwarten, aber ich habe nur 22 gefunden. Diese Daten sind beschädigt.”

Und PHP wirft das GANZE Array weg. Plötzlich setzt sich Ihr Theme auf Standard zurück, Ihre Widgets verschwinden.

#Welche Tools verstehen WordPress-Serialisierung

Aufgrund dieses Mechanismus können Sie NICHT Standard-Texteditoren oder einfaches SQL für die WordPress-Datenbankmigration verwenden.

#Methode 1: wp search-replace mit WP-CLI

Im Jahr 2026 bietet jeder seriöse Hosting-Anbieter (Kinsta, WP Engine, Raidboxes) SSH-Zugang.

Der Befehl:

wp search-replace 'https://alte-domain.de' 'https://neue-domain.de' --all-tables --precise

• --all-tables: Scannt auch benutzerdefinierte Tabellen.
• --precise: Erzwingt die Nutzung von PHP.
• --dry-run: Zeigt, was passieren würde. Führen Sie dies immer zuerst aus!

#Methode 2: Plugin Better Search Replace ohne SSH

Wenn Sie keinen SSH-Zugang haben, nutzen Sie das Plugin Better Search Replace.

1. Plugin installieren.
2. Alle Tabellen auswählen.
3. “Case-Insensitive” deaktivieren.
4. “Dry Run” ausführen.

#Wie Sie ein komplettes WordPress-Migrationsprotokoll ausführen

Handeln Sie nicht nach Gefühl. Folgen Sie dieser Checkliste.

#Schritt 1: Backup und PHP-Version prüfen

• Backup: Datenbank exportieren (mysqldump).
• Umgebung: PHP-Versionen abgleichen.

#Schritt 2: Datenbank auf den neuen Server importieren

1. Datenbank auf den neuen Server importieren.
2. wp-config.php aktualisieren.

#Schritt 3: Search-Replace ausführen

Führen Sie den WP-CLI-Befehl oder das Skript aus.

#Schritt 4: Permalinks, Cache und robots.txt

1. Permalinks: Einstellungen -> Permalinks -> “Speichern”. Das regeneriert die .htaccess.
2. Cache: Leeren Sie Redis und Page Cache.
3. Robots.txt: Stellen Sie sicher, dass Sie nicht Disallow: / kopiert haben!

#Zusammenfassung

Datenbankmigration ist keine “Textbearbeitung”. Es ist eine chirurgische Datenmanipulation. Respektieren Sie die Serialisierung. Nutzen Sie WP-CLI.

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