Migration und Multisite: Fortgeschrittenes WordPress-Management

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. Migration und Multisite sind zwei getrennte Entscheidungen, die oft vermischt werden: Eine Migration bewegt Dateien, Datenbank und DNS, Multisite legt fest, wie sich mehrere Websites eine WordPress-Codebasis teilen. Die offizielle Referenz für die Netzwerkseite ist das WordPress-Multisite-Handbuch.

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.

#Wie gelingt eine verlustfreie WordPress-Migration

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.

#Warum ein SQL-Replace serialisierte PHP-Daten zerstört

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.

#Serialisierte Daten mit WP-CLI search-replace ersetzen

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. Laut der Referenz zu search-replace bleiben Primärschlüssel dabei unverändert. Der Trockenlauf sollte exakt dieselben Tabellen und Flags verwenden wie der echte Lauf, sonst zeigt die Vorschau etwas anderes, als später passiert:

# 1. Trockenlauf: gleiche Tabellen und Flags wie der echte Lauf, nichts wird geschrieben
wp search-replace 'https://alte-seite.de' 'https://neue-seite.de' \
  --all-tables --skip-columns=guid --dry-run

# 2. Ersetzung ausführen
wp search-replace 'https://alte-seite.de' 'https://neue-seite.de' \
  --all-tables --skip-columns=guid

# 3. Cache und Permalinks leeren
wp cache flush
wp rewrite flush --hard

Zwei Flags aus älteren Anleitungen brauchen eine Korrektur. --recurse-objects ist bereits die Voreinstellung, das Hinzufügen ändert nichts. --precise ist nicht der Grund, warum serialisierte Daten heil bleiben: Standardmäßig arbeitet der Befehl mit schnellen SQL-Abfragen und wechselt bei Spalten mit serialisierten Daten selbst zu PHP. --precise erzwingt PHP für alle Spalten, das ist langsamer und lohnt sich nur bei ungewöhnlich komplexen Strukturen. Wichtiger ist --skip-columns=guid, aus dem Grund, den der Abschnitt zur Website-URL weiter unten erklärt.

#Wie läuft eine Zero-Downtime-Migration ab

Um den Umzug ohne Datenverlust und ohne Downtime für Besucher durchzuführen, empfiehlt sich ein strukturierter Ablauf in vier Schritten:

1. 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.
2. Vorab-Dateisynchronisation per rsync: Übertragen Sie das gesamte Verzeichnis /wp-content/uploads/ vorab über eine verschlüsselte SSH-Verbindung. Im Gegensatz zu FTP lässt sich rsync mit -P nach einem Verbindungsabbruch fortsetzen 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/

3. 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-replace auf dem neuen Server ausführen.
4. 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.

#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_users und wp_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 in wp_2_options und ihre Taxonomien in wp_2_terms.

+------------------------------------------------------+
|            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.

Mehrsprachigkeit allein ist selten ein Grund für Multisite. WPML, Polylang oder Sprachvarianten in einer Installation sind oft einfacher zu betreiben als ein Netzwerk mit einer Website pro Sprache. Das Handbuch argumentiert ähnlich: Müssen die Websites viele Daten oder Benutzer teilen, oder brauchen sie nur unterschiedliche Themes je Bereich, passt eine Einzelinstallation mit Plugin oft besser als ein Netzwerk.

#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.
• Getrennte Hosting-Anforderungen: Brauchen Websites unterschiedliche PHP-Versionen, Hosting-Tarife oder Sicherheitszonen, kann ein gemeinsames Netzwerk das nicht leisten.
• Schwierige spätere Ausgliederung: Das Extrahieren einer einzelnen Website aus einem Multisite-Verbund in eine eigenständige Single-Site-Installation erfordert aufwendige Datenbank-Operationen.

#Voraussetzungen vor dem Anlegen eines WordPress-Multisite-Netzwerks

Das Kapitel Before you create a network nennt Einschränkungen, die der Bildschirm Netzwerk-Einrichtung durchsetzt. Die meisten gescheiterten Umstellungen laufen in eine davon.

Ein Netzwerk lässt sich nicht anlegen, wenn die WordPress-Adresse einen anderen Port als 80 oder 443 verwendet. Eine Subdomain-Installation ist gesperrt, wenn die WordPress-URL einen Pfad enthält (WordPress liegt nicht im Document Root), wenn die Adresse localhost lautet oder wenn sie eine IP-Adresse wie 127.0.0.1 ist. Für lokale Tests empfiehlt das Handbuch, einen eigenen Hostnamen in der hosts-Datei auf 127.0.0.1 zu legen. Eine Unterverzeichnis-Installation ist gesperrt, wenn die bestehende Installation älter als einen Monat ist, weil die Beiträge der Hauptseite sonst mit den Pfaden der Unterwebsites kollidieren. In einem pfadbasierten Netzwerk erhalten die Beitrags-URLs der Hauptseite zudem das Präfix /blog/.

Auf der Serverseite braucht Apache mod_rewrite mit .htaccess-Unterstützung, FollowSymLinks darf nicht abgeschaltet sein, und AllowOverride muss für den Vhost auf All oder Options All stehen. Sprechende Permalinks müssen auf der Einzelinstallation bereits funktionieren. Klären Sie die Domain, auch die Frage nach www, vor der Aktivierung. Soll WordPress in einem eigenen Verzeichnis laufen, gehört auch diese Änderung davor. Wildcard-DNS ist nur nötig, wenn Nutzer Subdomain-Websites selbst anlegen; manuell angelegte Websites kommen mit eigenen DNS-Einträgen oder virtuellen Hosts aus.

#Welche Server-Konfiguration braucht Multisite

Die Aktivierung folgt der Anleitung Create a Network, und die Reihenfolge zählt. Sichern Sie Datenbank und Dateien. Deaktivieren Sie alle Plugins; sie lassen sich nach dem Anlegen des Netzwerks wieder aktivieren. Danach kommt der Schalter in die Datei wp-config.php, oberhalb der Zeile /* That's all, stop editing! Happy publishing. */:

// 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, die direkt unter die Zeile mit WP_ALLOW_MULTISITE gehören:

// 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);

Derselbe Bildschirm zeigt Rewrite-Regeln. Sie ersetzen den bestehenden WordPress-Block in der .htaccess (unter Nginx werden daraus Regeln im Server-Block). Sichern Sie beide Dateien vor der Änderung. Anschließend melden Sie sich über den angezeigten Link neu an; manchmal müssen dafür die Browser-Cookies gelöscht werden. Unter “Meine Websites” erscheint dann das Menü Netzwerkverwaltung. Ein späterer Wechsel zwischen Subdomains und Unterverzeichnissen ist möglich, laut Handbuch aber unter Umständen nicht einfach. Entscheiden Sie also, bevor die erste Unterwebsite existiert.

#Domain-Mapping in Multisite ohne Plugin

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 ein Vhost eingerichtet sein, der alle eingehenden Domains auf das WordPress-Hauptverzeichnis leitet.

Das Kapitel zum Domain-Mapping beschreibt die Reihenfolge. Zuerst zeigt jede Domain per DNS auf den Server. Dann bekommt die Hauptdomain ein TLS-Zertifikat, die übrigen Domains SNI-Zertifikate, damit jede Anmeldung im Backend verschlüsselt bleibt. Erst danach tragen Sie die vollständige URL, etwa https://partner-brand.de, im Feld Website-Adresse (URL) der Unterwebsite ein. Senken Sie die TTL einen Tag vorher und ändern Sie die Adresse erst, wenn der Server unter dem neuen Hostnamen antwortet. Scheitert die Anmeldung auf einer gemappten Website mit einem Hinweis auf blockierte Cookies oder ganz ohne Meldung, gehört diese Zeile unter die Netzwerkkonstanten:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

#Benutzerrollen über mehrere Websites in WordPress Multisite

In Multisite liegen alle Benutzer in einer gemeinsamen Tabelle. Mitgliedschaft und Rollen werden pro Website vergeben.

Was das in der Praxis bedeutet:

• Ein Administrator von muenchen.firma.de kann keine Plugins installieren. Das ist Aufgabe des Super Admins.
• Wer einen Benutzer in der Netzwerkverwaltung löscht, entfernt das Konto überall, nicht nur in einer Filiale.
• Ein gemeinsamer Login für mehrere Marken ergibt sich in Multisite fast von selbst; Isolation zwischen Kunden nicht.

Dokumentieren Sie, wer Super Admin ist, und halten Sie die Zahl klein. Zu viele Super Admins sind der übliche Grund für den Satz “Jemand hat ein Plugin in der Netzwerkverwaltung aktiviert, und drei Websites waren down”.

#Wie man WordPress-Websites zu einem Multisite-Netzwerk zusammenführt

Ein Netzwerk auf einer bestehenden Installation zu aktivieren, wie oben beschrieben, ist nicht dasselbe, wie fünf Einzelinstallationen zusammenzuführen. Jede weitere Website kommt per Export und Import (WXR), über WP-CLI oder mit einem Werkzeug hinein, das Multisite-Tabellenpräfixe versteht.

Empfohlene Reihenfolge:

1. Vollständige Datei- und Datenbanksicherung aller Quellen (3-2-1: drei Kopien, zwei Medien, eine außer Haus).
2. Netzwerk auf Staging mit derselben PHP-Version wie in Produktion aufbauen.
3. Leere Websites in der Netzwerkverwaltung mit den endgültigen Domains oder Subdomains anlegen.
4. Inhalte Website für Website importieren. Danach search-replace für alte URLs nur innerhalb der Tabellen dieser Website ausführen, mit --url=<website> und ohne --network.
5. Benutzer zuordnen: gleiche E-Mail-Adressen werden zu einem Konto, Rollen werden pro Website vergeben.
6. Medien prüfen. Die Uploads einer Unterwebsite liegen unter wp-content/uploads/sites/{id}/.
7. DNS-TTL senken, umschalten, Rollback-SQL bereithalten.

#Wie man eine Website aus WordPress Multisite herauslöst

Manchmal ist das Netzwerk das falsche Modell. Dann wird eine Website exportiert:

1. blog_id und Tabellenpräfix (wp_5_ usw.) ermitteln, zum Beispiel mit wp site list --fields=blog_id,url.
2. Inhalte als WXR exportieren oder die Tabellen in eine neue Datenbank mit dem Standardpräfix wp_ klonen.
3. Medien aus uploads/sites/{id}/ in das normale Verzeichnis uploads/ kopieren.
4. siteurl und home anpassen, danach search-replace ausführen.
5. Nur die Plugins und Themes installieren, die diese Website tatsächlich genutzt hat, nicht blind das ganze Netzwerkverzeichnis.

Planen Sie Weiterleitungen von den alten Subdomain-URLs auf die neue Domain. Sonst gehen Linksignale verloren, und die Search Console füllt sich mit 404-Meldungen.

#Wie man die WordPress-Website-URL nach einem Umzug ändert

Unter Einstellungen > Allgemein stehen zwei Felder: WordPress-Adresse (URL), wo die Core-Dateien liegen, und Website-Adresse (URL), die Adresse, die Besucher eintippen. Ist das Backend nach einem Umzug nicht erreichbar, beschreibt das Migrationskapitel des Handbuchs vier Wege, beide Werte zu korrigieren. Sie gelten für Einzelinstallationen; für Multisite verweist das Handbuch auf die Datenbank, siehe nächster Abschnitt.

1. wp-config.php: define( 'WP_HOME', 'https://example.de' ); und define( 'WP_SITEURL', 'https://example.de' );. Damit sind die Werte fest im Code, und die Felder unter Allgemein lassen sich nicht mehr bearbeiten.
2. functions.php: zwei Aufrufe von update_option() für siteurl und home im aktiven Theme, einmal geladen und dann wieder entfernt. Das Handbuch betont, dass der Code nicht in der Datei bleiben darf.
3. RELOCATE: define('RELOCATE', true); in die wp-config.php, dann wp-login.php unter der neuen Adresse aufrufen. Das korrigiert nur die Website-URL und sonst nichts. Die Konstante stehen zu lassen ist unsicher, weil sie in manchen Konfigurationen einem Angreifer erlaubt, die Adresse zu ändern. Sofort danach entfernen.
4. Datenbank oder WP-CLI: siteurl und home in wp_options bearbeiten oder wp option update home 'https://example.de' und wp option update siteurl 'https://example.de' ausführen.

Dasselbe Kapitel enthält eine Regel, die man nicht oft genug wiederholen kann: Die Spalte guid in wp_posts wird nie geändert. Feedreader erkennen an der GUID, welche Beiträge sie schon angezeigt haben; wer sie umschreibt, lässt alte Beiträge als neu erscheinen. Deshalb nutzt das WP-CLI-Beispiel in der Dokumentation --skip-columns=guid. Alte Adressen können auch in Transients stecken. Diese lassen sich in der migrierten Kopie gefahrlos löschen (wp transient delete --all), weil WordPress sie bei Bedarf neu erzeugt.

Für den Umzug in ein anderes Verzeichnis auf demselben Server gilt eine eigene Reihenfolge: erst beide URLs unter Einstellungen ändern, dann die Dateien verschieben. Wurden die Dateien zuerst verschoben, hilft laut Handbuch ein vorübergehender Symlink vom alten auf den neuen Pfad (ln -s /path/to/new /path/to/old), danach funktionieren die normalen Schritte.

#Wie man wp search-replace in einem Multisite-Netzwerk ausführt

In Multisite bearbeitet wp search-replace nur die Tabellen der aktuellen Website, sofern nichts anderes angegeben ist. Die Befehlsreferenz definiert die Reichweiten:

• ohne Flag: die in $wpdb registrierten Tabellen der Website, die --url angibt (standardmäßig die Hauptseite),
• --network: alle in $wpdb registrierten Tabellen des gesamten Netzwerks,
• --all-tables-with-prefix: jede Tabelle mit dem WordPress-Präfix, registriert oder nicht,
• --all-tables: jede Tabelle der Datenbank, unabhängig vom Präfix. Das Flag überschreibt --network und erreicht in einer Datenbank, die mit anderen Anwendungen geteilt wird, auch deren Tabellen.

Tabellen ohne Primärschlüssel werden stillschweigend übersprungen; wp db query 'DESCRIBE <tabelle>' zeigt, ob PRI vorhanden ist. Der dokumentierte Weg, ein Produktionsnetzwerk in eine lokale Kopie zu verwandeln, schreibt die Netzwerktabellen ausdrücklich mit um:

wp search-replace --url=example.de example.de example.test \
  'wp_*options' wp_blogs wp_site --network --skip-columns=guid

--export=netzwerk.sql schreibt die umgewandelten Daten in eine Datei statt in die laufende Datenbank. Das passt zu einem Umzug, bei dem der Import auf dem neuen Server stattfindet. Vor und nach der Änderung listet wp site list alle Websites auf, sodass sich die gespeicherten Adressen vergleichen lassen:

for url in $(wp site list --field=url); do
  echo "$url $(wp option get siteurl --url="$url")"
done

Die Hinweise des Handbuchs zum Umzug von Multisite stecken den Rahmen ab. Gleiche Domain auf neuem Server: Dateien und Datenbank kopieren wie bei einer Einzelinstallation. Neue Domain: Dateien verschieben, DOMAIN_CURRENT_SITE in der wp-config.php und die .htaccess anpassen, falls sich der Ordner geändert hat, dann wp_site und wp_blogs (Domain und Pfad) prüfen und in jeder Tabelle wp_N_options die Werte home, siteurl und fileupload_url. Ein Wechsel zwischen Subdomains und Unterverzeichnissen verlangt zusätzlich ein geändertes SUBDOMAIN_INSTALL und neue Rewrite-Regeln.

#Typische Staging-Fehler in WordPress Multisite

Multisite scheitert am häufigsten auf Staging, nicht in Produktion.

Fest verdrahtete URLs im Netzwerk. Ein Klon-Werkzeug, das nur die Hauptdomain austauscht, wp_blogs und wp_site aber auf Produktion zeigen lässt, meldet Redakteure in der falschen Umgebung an oder vermischt Cookies.

Search-replace ohne GUID-Ausschluss oder ohne Trockenlauf. Den Trockenlauf immer ausführen. Tabellen eingrenzen, wenn nur eine Website umzieht.

Cron und E-Mail. Netzwerk-Cron (wp-cron.php) und ausgehende Mails vom Staging dürfen keine echten Kunden erreichen. Ausgehendes SMTP auf Staging sperren oder auf einen Mail-Sink umleiten.

Staging-Subdomains. staging.firma.de braucht eigenes DNS und meist ein eigenes TLS-Zertifikat. Ein Wildcard-Zertifikat für *.firma.de deckt staging.andere-marke.de nicht ab. HTTPS testen, bevor Redakteure eingeladen werden.

Plugin-Aktivierung auf Netzwerkebene. Ein Test-Plugin auf Staging ist in Ordnung. Dieselbe Aktion in Produktion ohne Canary-Website nicht. Halten Sie mindestens eine Canary-Website, auf der neue Plugins zuerst aktiviert werden.

WooCommerce im Netzwerk. Ist das Netzwerk eine Ladenkette, testen Sie die Callbacks des Zahlungsanbieters pro Website-URL. Webhooks, die nach dem Go-live noch auf Staging zeigen, werden teuer. Ohne E-Commerce beschränkt sich die Migration auf Inhalte, Medien und Rollen.

#Multisite, reine Migration oder eigene Installation

#Was gehört auf die Checkliste für eine WordPress-Migration

1. Backup mit einem Wiederherstellungstest geprüft, nicht nur anhand der Dateigröße.
2. Gleiche PHP-Version und Erweiterungen auf Staging und Produktion.
3. wp search-replace --dry-run ohne Überraschungen, mit denselben Flags wie der echte Lauf.
4. Login als Super Admin und als Website-Administrator getestet.
5. Medien-URLs laden auf jeder gemappten Domain über HTTPS.
6. wp site list --field=url entspricht der erwarteten Adressliste.
7. DNS-TTL gesenkt, Rollback-Plan schriftlich (wer stellt den A-Record zurück, wo liegt der letzte SQL-Dump).

Migration ist Mechanik. Multisite ist ein Betriebsmodell. Wer beides vermischt, repariert DNS, wo er eigentlich die Kunden hätte trennen sollen, oder umgekehrt.

#Häufige Fragen zu Migration und Multisite

Sowohl sichere Migrationen als auch skalierbare Multisite-Architekturen erfordern fundiertes Know-how in Datenbankmanagement und Serveradministration. Mit Werkzeugen wie WP-CLI, strukturierten Deployment-Plänen und klaren Hosting-Grenzen stellen Sie sicher, dass Ihre Systeme stabil, performant und zukunftssicher bleiben. Wenn Sie Unterstützung bei einem bevorstehenden Relaunch oder einer Multisite-Konsolidierung suchen, beraten wir Sie im Rahmen unserer WordPress-Entwicklungsleistungen.

Auf der Delivery-Seite halten wir dieses Thema unter Next.js- oder Astro-Migration.