Im professionellen Betrieb von WordPress-Websites begegnen Administratoren zwei Aufgaben, die besondere Sorgfalt verlangen: die unterbrechungsfreie Migration komplexer Unternehmenswebsites auf eine neue Server-Infrastruktur und die Konzeption von WordPress Multisite-Netzwerken.
Beide Prozesse bergen bei unbedachtem Vorgehen erhebliche Risiken. Wer einen Domainwechsel mit einfachen Textwerkzeugen durchführt, riskiert korrupte Datenbankeinträge. Und wer Multisite für ungeeignete Projektstrukturen wählt, schafft einen schwerfälligen Monolithen, bei dem ein einzelner PHP-Fehler das gesamte Unternehmensnetzwerk lahmlegt.
In diesem Leitfaden erläutern wir die Best Practices für verlustfreie Datenbankmigrationen mit WP-CLI und analysieren, wann eine Multisite-Architektur einen echten Mehrwert bietet.
Wenn Sie Unterstützung bei anspruchsvollen Migrationen oder der Server-Optimierung benötigen, finden Sie Details in unserer Übersicht zur WordPress-Entwicklung und technischen Betreuung.
1. Verlustfreie Migration: Datenintegrität an erster Stelle
Viele Serverumzüge scheitern nicht an den Dateien, sondern an der Datenbank. WordPress nutzt an zahlreichen Stellen (insbesondere in der Tabelle wp_options für Themes und Plugins wie ACF oder Elementor) das interne PHP-Serialisierungsformat.
Das Problem mit serialisierten PHP-Strings
Ein typischer serialisierter Datensatz in MySQL sieht wie folgt aus:
a:2:{s:4:"host";s:13:"alte-seite.de";s:4:"port";i:3306;}Hierbei steht s:13 für einen String mit einer Länge von exakt 13 Zeichen (alte-seite.de). Ersetzt man diese Adresse in einem herkömmlichen Texteditor oder per einfachem SQL-Befehl durch neue-praxis.de (14 Zeichen), bleibt im Header weiterhin s:13 stehen.
Beim nächsten Aufruf versucht der PHP-Interpreter 13 Zeichen einzulesen, stolpert über die Syntax und wirft einen Deserialisierungsfehler aus (unserialize(): Error at offset). Das Plugin verliert seine gesamte Konfiguration und setzt sich auf den Standardzustand zurück.
Die saubere Lösung: Suchen und Ersetzen mit WP-CLI
Das offizielle Kommandozeilenwerkzeug WP-CLI löst dieses Problem verlässlich. Es liest serialisierte Objekte in den Arbeitsspeicher ein, deserialisiert sie, führt die Textersetzung durch, berechnet die Längenwerte neu und speichert die Daten intakt zurück in die MySQL-Tabellen:
# 1. Trockenlauf (Dry-Run) zur Prüfung der betroffenen Zeilen
wp search-replace 'https://alte-seite.de' 'https://neue-seite.de' --dry-run
# 2. Vollständige Ersetzung über alle Tabellen hinweg
wp search-replace 'https://alte-seite.de' 'https://neue-seite.de' \
--all-tables \
--precise \
--recurse-objects
# 3. Cache und Permalinks leeren
wp cache flush
wp rewrite flush --hard2. Der Zero-Downtime-Migrationsprozess
Um den Umzug ohne Datenverlust und ohne Downtime für Besucher durchzuführen, empfiehlt sich ein strukturierter Ablauf in vier Schritten:
- DNS-Vorbereitung (48 Stunden vorab): Reduzieren Sie die TTL (Time to Live) der DNS-A-Records Ihrer Domain auf 300 Sekunden (5 Minuten). Dies stellt sicher, dass die weltweiten DNS-Resolver die neue Server-IP nach der Umschaltung binnen weniger Minuten anerkennen.
- Vorab-Dateisynchronisation per rsync: Übertragen Sie das gesamte Verzeichnis
/wp-content/uploads/vorab über eine verschlüsselte SSH-Verbindung. Im Gegensatz zu FTP brichtrsyncbei Verbindungsabbrüchen nicht ab und überträgt nur geänderte Blöcke:
rsync -avzP --delete \
--exclude 'wp-content/cache/*' \
--exclude '*.log' \
[email protected]:/var/www/vhosts/seite.de/httpdocs/ /var/www/html/- Wartungsfenster und Datenbankabgleich:
- Alten Server kurzzeitig in den Wartungsmodus versetzen (
wp maintenance-mode activate). - Finalen Datenbank-Dump exportieren (
wp db export dump-final.sql). - Dump auf den neuen Server übertragen und importieren (
wp db import dump-final.sql). - WP-CLI
search-replaceauf dem neuen Server ausführen.
- Alten Server kurzzeitig in den Wartungsmodus versetzen (
- DNS-Umschaltung: Tragen Sie die IP-Adresse des neuen Servers im DNS-Management ein. Sobald der TTL-Zeitraum abgelaufen ist, fließen alle Nutzeranfragen direkt auf das neue System.
3. WordPress Multisite: Architektur und Einsatzszenarien
WordPress Multisite (ehemals WPMU) verwandelt eine gewöhnliche Installation in ein globales Netzwerk virtueller Websites, die sich einen gemeinsamen Codebestand und eine zentrale Datenbank teilen.
Das Datenbankschema von Multisite
Während ein Standard-WordPress 12 Basistabellen besitzt, strukturiert Multisite die Datenhaltung nach einem zweistufigen Prinzip:
- Globale Tabellen (Netzwerkweit geteilt):
wp_usersundwp_usermeta: Alle Benutzerkonten existieren netzwerkweit nur einmal. Ein Benutzer kann jedoch in Blog 1 die Rolle “Abonnent” und in Blog 2 die Rolle “Administrator” besitzen.wp_blogs,wp_site,wp_sitemeta: Speichern die Metadaten des gesamten Netzwerks, Domain-Zuordnungen und globale Optionen.
- Standortspezifische Tabellen:
- Jede Unterwebsite erhält eigene Beitrags- und Optionstabellen mit fortlaufendem ID-Präfix. Die Website mit ID 2 speichert ihre Artikel in
wp_2_posts, ihre Einstellungen inwp_2_optionsund ihre Taxonomien inwp_2_terms.
- Jede Unterwebsite erhält eigene Beitrags- und Optionstabellen mit fortlaufendem ID-Präfix. Die Website mit ID 2 speichert ihre Artikel in
+------------------------------------------------------+
| WordPress Multisite Datenbank |
+------------------------------------------------------+
| Globale Netzwerktabellen: |
| - wp_users / wp_usermeta |
| - wp_blogs / wp_site / wp_sitemeta |
+------------------------------------------------------+
| Hauptseite (Site ID: 1): |
| - wp_posts, wp_options, wp_terms... |
+------------------------------------------------------+
| Unterseite (Site ID: 2 - z. B. muenchen.firma.de): |
| - wp_2_posts, wp_2_options, wp_2_terms... |
+------------------------------------------------------+
| Unterseite (Site ID: 3 - z. B. wien.firma.de): |
| - wp_3_posts, wp_3_options, wp_3_terms... |
+------------------------------------------------------+Wann ist Multisite die richtige Wahl?
- Filialnetzwerke und Franchises: Ein zentrales Theme und einheitliche Plugins für 80 Standorte, wobei jeder Standortleiter nur seine eigenen Kontaktdaten und lokalen Öffnungszeiten pflegt.
- Universitäten und Bildungseinrichtungen: Zentrale Bereitstellung von Webspaces für Institute, Lehrstühle und Professoren unter der Hauptdomain der Hochschule.
- SaaS-Plattformen und Website-Baukästen: Automatisierte Ausspielung vorgefertigter Templates für Kunden über ein zentrales Dashboard.
Wann Sie auf Multisite verzichten sollten
- Unabhängige Kundenprojekte einer Agentur: Ein fatales Script in der Website eines Kunden kann den gesamten Server lahmlegen und alle anderen Mandanten gefährden.
- Stark divergierende Plugin-Anforderungen: Wenn Site A komplexe E-Commerce-Erweiterungen benötigt und Site B ein spezialisiertes Buchungstool verlangt, bläht sich die gemeinsame Codebasis unnötig auf.
- Schwierige spätere Ausgliederung: Das Extrahieren einer einzelnen Website aus einem Multisite-Verbund in eine eigenständige Single-Site-Installation erfordert aufwendige Datenbank-Operationen.
4. Technische Einrichtung und Server-Konfiguration
Die Aktivierung erfolgt in der Datei wp-config.php:
// Schritt 1: Netzwerk-Setup im Backend freischalten
define('WP_ALLOW_MULTISITE', true);Anschließend wählen Sie unter Werkzeuge > Netzwerk-Einrichtung zwischen einer Subdomain-Installation (berlin.firma.de) oder einer Unterverzeichnis-Installation (firma.de/berlin/). Nach Bestätigung generiert WordPress die finalen Konstanten:
// Schritt 2: Multisite im Subdomain-Modus aktivieren
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'firma.de');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);Natives Domain-Mapping
Seit WordPress 4.5 ist kein zusätzliches Plugin mehr für Domain-Mapping erforderlich. Sie können jeder Unterwebsite in den Netzwerk-Einstellungen eine vollwertige eigene Top-Level-Domain zuweisen (z. B. partner-brand.de). Auf Serverebene (Nginx oder Apache) muss lediglich ein Wildcard-Vhost eingerichtet sein, der alle eingehenden Domains auf das WordPress-Hauptverzeichnis leitet.
