WordPress-Multisite-Migration: das komplette Playbook für 2026

Wahrscheinlich befinden Sie sich gerade in einer von zwei Situationen. Entweder ist ein Multisite-Netzwerk über den Server, das Governance-Modell oder die URL-Struktur hinausgewachsen, mit denen es gestartet ist, oder jemand auf Geschäftsseite hat entschieden, dass eine Subsite zu einer eigenen Plattform werden soll, ohne die Sichtbarkeit in Suchmaschinen, die redaktionellen Abläufe und den Umsatz zu gefährden.

Genau hier hört eine WordPress-Multisite-Migration auf, eine Routineaufgabe beim Hosting zu sein, und wird zu einem Engineering-Projekt. Der technische Umzug ist wichtig, aber die größeren Risiken liegen meist woanders: eine Plugin-Lizenz, die nach der Herauslösung nicht mehr validiert wird, ein mehrsprachiges Setup, das seine Canonical-Tags verliert, eine Mediathek, die gut aussieht, bis die Redaktion drei Tage später defekte Dateien entdeckt, oder ein Rollback-Plan, der nur als vages Versprechen existiert.

Die saubersten Migrationen, die ich gesehen habe, folgen alle demselben Muster. Sie behandeln den Datenbankumzug als einen Teil einer größeren, kontrollierten Änderung. Sie legen den Umfang früh fest, testen wie Ermittler und gehen davon aus, dass etwas scheitern wird, solange es nicht verifiziert ist. Diese Denkweise verhindert, dass eine Multisite-Migration zu einem nächtlichen Incident wird.

Strategie vor der Migration und Risikobewertung

Freitag, 20:40 Uhr. Das DNS wird gleich umgestellt, der Datenbankimport ist abgeschlossen, und jemand fragt, ob die hreflang-Tags der französischen Subsite erhalten geblieben sind und welche Lizenzen für Premium-Plugins den Umzug überstehen. Wenn diese Frage in der Migrationsnacht aufkommt, ist die Planung gescheitert.

Eine WordPress-Multisite-Migration beginnt mit Umfangskontrolle und Ausfallplanung. Datenbank und Dateien sind wichtig, aber Projekte mit hohem Risiko scheitern meist an Fragen der Geschäftskontinuität: an Plugin-Lizenzen, die an die alte Domain oder den Installationstyp gebunden sind, an Regeln für mehrsprachiges SEO, die nach der Herauslösung verschwinden, und an Rollback-Plänen, die gut klingen, bis jemand unter Druck entscheiden muss, ob das DNS zurückgestellt wird.

Behandeln Sie den Plan wie ein Incident-Runbook. Bevor jemand die Produktion anfasst, sollte er vier Fragen beantworten:

1. Was genau wird umgezogen
2. Was muss verfügbar bleiben
3. Was löst einen Rollback aus
4. Wer ist befugt, den Go-live freizugeben oder rückgängig zu machen

Legen Sie den Migrationsumfang fest, bevor Sie Tools auswählen

„Die Multisite umziehen” ist kein brauchbarer Umfang. In der Praxis ist die Anforderung oft unübersichtlicher: eine umsatzstarke Subsite als eigenständiges WordPress herauslösen, zwei ältere Subsites zurücklassen, gemappte Domains erhalten, dafür sorgen, dass die Redaktion am Montagmorgen arbeiten kann, und keine Rankings in drei Sprachen verlieren.

Erstellen Sie zuerst ein Inventar.

• Jede Subsite: aktuelle URL, gemappte Domain, fachlich verantwortliche Person und Toleranz für Ausfallzeiten
• Aktivierungsmodell: netzwerkweit aktivierte Plugins im Vergleich zu Plugins auf Website-Ebene
• Eigener Code: mu-plugins, Drop-ins, eigene Tabellen, Cronjobs, Webhooks und Theme-Overrides
• Gemeinsame Abhängigkeiten: Medienverweise, API-Integrationen, SSO, Formulare, Suche und Analytics-Skripte

Wenn niemand sagen kann, welche Subsites offline sein dürfen und wie lange, ist die Migration nicht bereit.

An diesem Punkt entscheiden Teams auch, ob sie die Arbeit intern erledigen oder einen Spezialisten für WordPress-Migrationsdienste hinzuziehen. Die Abwägung ist einfach. Interne Teams kennen den Stack. Externe Dienstleister bringen oft ein saubereres Runbook, mehr Disziplin beim Rollback und weniger Annahmen mit.

Prüfen Sie die Schwachstellen, die nach dem Go-live wehtun

Datenbankexport und -import sind der einfache Teil. Die teuren Ausfälle zeigen sich später, wenn die Website „im Großen und Ganzen in Ordnung” aussieht.

Plugin-Lizenzierung ist ein häufiger Fall. Premium-Plugins können ihre Lizenz anhand der primären Domain, des Netzwerkkontexts, der Anzahl der Websites oder der Umgebung prüfen. Eine aus der Multisite herausgelöste Subsite kann korrekt starten und trotzdem den Zugriff auf Updates, Feld-Rendering, Übersetzungsfunktionen oder Checkout-Integrationen verlieren, weil die Lizenz nicht mehr zur neuen Installation passt. Prüfen Sie die Bedingungen der Anbieter vor dem Umzug, nicht danach.

Mehrsprachiges SEO verdient dieselbe Aufmerksamkeit. Wenn das Netzwerk WPML, Polylang, eine eigene hreflang-Ausgabe, marktspezifische Canonicals oder übersetzte Slugs verwendet, dokumentieren Sie das aktuelle Verhalten. Dazu gehören Title-Tags, Canonicals, hreflang-Tags, XML-Sitemaps, Weiterleitungsregeln und gebietsschemabasierte Templates. Eine Website kann die visuelle QA bestehen und trotzdem Suchwert verlieren, weil sich die Metadatenebene unbemerkt geändert hat.

Medien sind eine weitere Falle. In einer Multisite fügen Redakteure oft Datei-URLs über Subsites hinweg ein, nutzen benutzerdefinierte Felder, die auf alte Upload-Pfade verweisen, oder verlassen sich auf Plugins, die die Medienverwaltung umschreiben. Defekte Vorschaubilder sind ärgerlich. Defekte Dokumente, Kampagnenmaterialien und lokalisierte PDFs erzeugen schnell Support-Tickets.

Erstellen Sie ein Risikoprotokoll, das Sie tatsächlich nutzen können

Halten Sie es so kurz, dass die Migrationsleitung es während der Umstellung liest.

Legen Sie objektive Rollback-Auslöser fest

Ein Rollback sollte nicht von Zuversicht, Stimmung oder davon abhängen, wer im Call am lautesten spricht. Legen Sie vor dem Go-live messbare Auslöser fest.

Beispiele:

• Der Admin-Zugang für die Hauptverantwortlichen der Websites funktioniert nicht
• Checkout, Lead-Formulare oder Login-Abläufe schlagen fehl
• Das Domain-Mapping leitet Traffic auf die falsche Subsite
• Auf Produktionsseiten fehlen kritische mehrsprachige Metadaten
• Die Plugin-Lizenzierung deaktiviert benötigte Funktionen
• Die Fehlerraten steigen sprunghaft an und lassen sich innerhalb des Wartungsfensters nicht korrigieren

Halten Sie den Schwellenwert schriftlich fest und lassen Sie ihn von der Migrationsleitung, dem Product Owner und der Person, die das DNS kontrolliert, freigeben. Ich empfehle außerdem, die genauen Befehle und Schritte für den Rollback aufzuschreiben, nicht nur die Entscheidungsregel. Bei echten Incidents schlägt Klarheit Optimismus.

Wenn der Rollback zum Beispiel die Wiederherstellung der alten Datenbank und das Zurückstellen des DNS umfasst, schreiben Sie die Reihenfolge auf:

# Example rollback checks
wp site list
wp plugin list --network
wp search-replace 'https://new.example.com' 'https://old.example.com' --network --dry-run

Nutzen Sie Testläufe (Dry Runs) in der Planungsphase, um zu bestätigen, dass das Team die Zugänge hat, die es zu haben glaubt. In der Migrationsnacht kosten fehlende WP-CLI-Berechtigungen oder der falsche SSH-Schlüssel genau die Zeit, die Sie für die Wiederherstellung gebraucht hätten.

Gute Multisite-Migrationen sind kontrollierte Änderungen. Die Teams, die sie sauber bewältigen, legen den Umfang früh fest, dokumentieren versteckte Abhängigkeiten, testen das Verhalten von Lizenzen und SEO vor der Umstellung und definieren den Rollback so, als würden sie ihn tatsächlich brauchen.

Umgebungen und DNS vorbereiten

Die meisten gescheiterten Migrationen beginnen mit einer Abweichung zwischen alter und neuer Umgebung. Keine dramatische Abweichung. Eine stille. Eine fehlende PHP-Erweiterung auf dem Zielsystem, ein Berechtigungsproblem im Dateisystem bei uploads, eine Lücke in den Rewrite-Regeln oder DNS-Änderungen, die bis zur letzten Stunde liegen bleiben.

Die neue Umgebung sollte langweilig sein. Genau das ist das Ziel. Wenn sich das Ziel auf eine Weise anders verhält als die Quelle, die Sie nicht berücksichtigt haben, bringt die Migration diese Unterschiede als abgebrochene Sessions, Medienprobleme oder Plugin-Ausfälle ans Licht.

Bauen Sie das Ziel passend zur Quelle auf

Beginnen Sie mit einer sauberen WordPress-Installation auf dem Zielsystem und bereiten Sie sie für Multisite vor, bevor Sie irgendetwas importieren. Wenn Sie in ein neues Netzwerk umziehen, bilden Sie dasselbe Strukturmuster nach, das Sie bereits verwenden. Wechseln Sie nicht in derselben Migration von Unterverzeichnissen zu Subdomains, es sei denn, es gibt einen zwingenden Grund und einen separaten Teststrang.

Bestätigen Sie in dieser Phase:

• PHP-Kompatibilität: Gleichen Sie die unterstützten Versionen ab, die das aktuelle Theme und der Plugin-Stack benötigen.
• Datenbankzugriff: Testen Sie CLI-Zugriff, Importberechtigungen und das Verhalten beim Anlegen von Tabellen.
• Dateisystem-Eigentümer: Stellen Sie sicher, dass WordPress ohne Berechtigungs-Workarounds in die richtigen Verzeichnisse schreiben kann.
• Shell-Zugang: Bestätigen Sie den Zugang über SSH und WP-CLI vor dem Migrationstag.
• E-Mail und externe Dienste: Bereiten Sie alles vor, was das Netzwerk für Formulare, Transaktionsabläufe oder Webhooks benötigt.

Für Teams, die im Rahmen eines Hosterwechsels auch die Infrastruktur umziehen, wird an dieser Stelle ein praktischer Leitfaden zum Umzug einer WordPress-Website zu einem neuen Host relevant, weil sich Hosterwechsel und Multisite-Umzug operativ oft überschneiden, auch wenn der Datenpfad ein anderer ist.

Bereiten Sie das DNS für Launch und Rückzug vor

DNS-Planung bekommt in den meisten Migrationsleitfäden zu wenig Aufmerksamkeit. Das sollte sie aber. Sie möchten, dass die endgültige Umstellung schnell geht, aber auch, dass der Rückzug schnell geht, falls die Validierung in der Produktion scheitert.

Die wichtigste Gewohnheit ist, die TTLs lange vor dem Migrationsfenster zu senken. Das ermöglicht eine sauberere Umstellung und eine realistische Rollback-Option. Wenn Sie die DNS-Vorbereitung zu spät angehen, können Sie trotzdem migrieren, aber Ihr Wiederherstellungsfenster wird schwerer kontrollierbar.

Nutzen Sie diese Checkliste vor der Umstellung:

• TTLs früh senken: Tun Sie es lange vor dem Launch, nicht währenddessen.
• Gemappte Domains dokumentieren: Besonders bei Multisite-Netzwerken mit Domains für Marken, Sprachversionen oder Kunden.
• SSL-Abdeckung bestätigen: Subdomains und gemappte Domains müssen nach der Umstellung sauber aufgelöst werden.
• Verifizierungshosts vorbereiten: Nutzen Sie nicht öffentliche Validierungsmethoden, um das Routing zu testen, bevor Sie den Produktions-Traffic umstellen.

Verzichten Sie nicht auf eine saubere Installation

Viele Teams möchten zuerst die gesamte alte Installation kopieren und „später aufräumen”. Damit werden meist alte Annahmen in die neue Umgebung mitgeschleppt. Eine frische Installation auf dem Zielsystem gibt Ihnen eine bekannte Ausgangsbasis und erleichtert es, Fehler einzugrenzen.

Wenn der Umzug die Umwandlung einer eigenständigen Website in eine Subsite oder das vorherige Anlegen eines Netzwerks auf dem Zielsystem umfasst, muss die Vorbereitung der Umgebung auch die Multisite-Konstanten und die Website-Struktur berücksichtigen, die die importierten Daten erwarten. An dieser Stelle bleiben Migrationsprojekte entweder unter Kontrolle oder beginnen, Einzelkorrekturen anzuhäufen.

Vollständiges Backup und Datenbankmigration

In dieser Phase kann ein einziger falscher Befehl jede Website im Netzwerk lahmlegen. In einer Multisite sind Benutzer, Rollen, Website-Tabellen, Netzwerkeinstellungen und viele Plugin-Daten miteinander verknüpft. Ein nachlässiger Import scheitert nicht sauber. Er erzeugt Teilschäden, die die Redaktion Tage später findet.

Es gibt zwei praktikable Wege. Nutzen Sie ein für Multisite gebautes Migrations-Plugin, oder führen Sie den Umzug mit WP-CLI durch und verantworten Sie jeden Schritt selbst. Ich nutze beides. Die richtige Wahl hängt von der Größe des Netzwerks, dem Änderungsfenster und davon ab, wie viel operative Disziplin das Team um 2 Uhr nachts aufrechterhalten kann.

Wählen Sie die Migrationsmethode nach Risiko, nicht nach Vorliebe

Ein Plugin ist oft sicherer, wenn das Projekt ein kurzes Wartungsfenster, ein weniger erfahrenes Übergabeteam oder ein Netzwerk mit vielen Subsites und gemappten Domains hat. All-in-One WP Migration bleibt eine häufige Wahl, weil es das Netzwerk so verpackt, dass Fehler auf Tabellenebene reduziert werden, und beim Import ein WordPress-bewusstes Suchen und Ersetzen durchführt. Dieser Schutz ist in einer Multisite wichtig, weil serialisierte Werte in Optionen, Widgets, Page-Builder-Daten und Plugin-Einstellungen im gesamten Netzwerk stecken.

WP-CLI passt besser, wenn Sie skriptbare Wiederholbarkeit, selektive Ersetzungen, umgebungsspezifische Kontrolle oder ein Migrationsprotokoll brauchen, das Sie beim Rollback an einen anderen Engineer übergeben können. Es ist auch die bessere Option, wenn Anforderungen auf Enterprise-Niveau über die reine Datenübertragung hinausgehen. Die Plugin-Lizenzierung kann nach einem Domain- oder Serverwechsel brechen. Mehrsprachige Plugins speichern SEO-Metadaten oft in eigenen Tabellen oder serialisierten Optionssätzen. Werden diese Werte nicht sauber migriert, können Rankings und Lizenzaktivierungen gleichzeitig wegbrechen.

Wenn das Zielsystem von Grund auf neu aufgebaut wird, beginnen Sie mit einem sauberen Netzwerk, das der Struktur entspricht, die die importierten Daten erwarten. Das ist umso wichtiger, wenn Sie eine eigenständige Installation in ein Netzwerk umwandeln oder zwischen Subdomain- und Unterverzeichnis-Modus wechseln. Nutzen Sie vor dem Import einen dokumentierten Prozess zur Installation und Einrichtung von WordPress Multisite, damit die Datenbank in einem Netzwerk mit den richtigen Konstanten und Tabellenannahmen landet.

WP-CLI-Workflow für Teams, die Kontrolle brauchen

Beginnen Sie mit einem vollständigen Export. Nicht mit einem Teil-Dump. Nicht „nur mit den Tabellen der aktiven Website”. Mit dem gesamten Netzwerk.

wp db export network-backup.sql --all-tables

Führen Sie vor dem Ändern der URLs einen Testlauf durch und prüfen Sie die Ausgabe:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables --dry-run

Wenn der Umfang korrekt aussieht, führen Sie die eigentliche Ersetzung aus:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables

Diese Flags leisten echte Arbeit. --network verhindert Abweichungen von Website zu Website. --precise tauscht Geschwindigkeit gegen Genauigkeit, was bei einer Migration meist der richtige Tausch ist. --recurse-objects schützt serialisierte Strukturen. --all-tables erfasst Plugin- und eigene Tabellen, die Teams vergessen, bis etwas Geschäftskritisches ausfällt.

Serialisierte Daten sind die Landmine. Wenn das Tool die WordPress-Serialisierung nicht versteht, halten Sie es von der Datenbank fern.

Wichtige WP-CLI-Befehle für Search-Replace in Multisite

Sichern Sie das Netzwerk so, als würden Sie einen Rollback erwarten

Ein brauchbares Backup umfasst mehr als einen SQL-Export in einem freigegebenen Ordner. Bei Netzwerken, bei denen viel auf dem Spiel steht, möchte ich vier Dinge haben, bevor jemand die Produktion anfasst:

• Vollständiger Datenbank-Dump: Einschließlich Netzwerktabellen, Benutzertabellen, Plugin-Tabellen und allem Benutzerdefinierten.
• Snapshot von wp-content: Themes, Plugins, mu-plugins, Uploads, Sprachdateien und Code eigener Integrationen.
• Kopien der Konfiguration: wp-config.php, Object-Cache-Einstellungen, vhost-Regeln des Servers und jede an das Netzwerk gebundene Cron- oder Worker-Konfiguration.
• Notizen zur Wiederherstellung: Genauer Speicherort für die Wiederherstellung, wer ihn verifiziert hat, welche Version gesichert wurde und wie lange die Wiederherstellung voraussichtlich dauert.

An dieser Stelle sollten Sie auch alles exportieren, was einen normalen Umzug von Dateien und Datenbank möglicherweise nicht sauber übersteht. Lizenzschlüssel für Premium-Plugins sind ein typisches Beispiel. Manche Anbieter binden Aktivierungen an Domains, IP-Adressen oder Maschinen-Fingerprints. Deaktivieren Sie, wo sinnvoll, dokumentieren Sie die aktuellen Aktivierungen und klären Sie die Bedingungen für eine Neuausstellung vor der Umstellung. Wenn im Netzwerk mehrsprachige SEO-Plugins laufen, prüfen Sie, wo hreflang-Daten, übersetzte Slugs, Weiterleitungsregeln und SEO-Metadaten gespeichert sind. Der Verlust dieser Daten zeigt sich nicht immer als PHP-Fehler. Er zeigt sich eine Woche später als Traffic-Verlust.

Wiederkehrende Datenbankfehler in Multisite-Projekten

Dieselben Fehler tauchen immer wieder auf:

• Rohes SQL-Replace auf serialisierte Inhalte anwenden
• Nur sichtbare Website-Tabellen exportieren und Netzwerk- oder Plugin-Tabellen übersehen
• In ein Zielsystem mit falschem Multisite-Modus oder falschen Annahmen zum Tabellenpräfix importieren
• Die Reaktivierung von Plugin-Lizenzen vergessen, bis kritische Funktionen nicht mehr funktionieren
• Primäre Domains ändern, ohne mehrsprachige SEO-Felder, Canonical-Tags oder hreflang-Verweise zu prüfen

Die Lösung ist nicht kompliziert, erfordert aber Disziplin. Exportieren Sie das gesamte Netzwerk. Protokollieren Sie jeden Befehl. Testen Sie Ersetzungen mit --dry-run. Bewahren Sie eine unveränderte Kopie der Datenbank vor der Migration auf. Bei Enterprise-Migrationen sind Befehlsverlauf, SQL-Artefakte und Lizenzinventare Teil der Geschäftskontinuität, kein zusätzlicher Papierkram.

Dateien migrieren und das Netzwerk konfigurieren

Nächtliche Umstellungen am Freitag scheitern hier häufiger als irgendwo sonst. Die Datenbank wird sauber importiert, die Startseite wird gerendert, alle entspannen sich, und dann entdeckt die Redaktion fehlende Medien, lizenzierte Plugins fallen in einen eingeschränkten Modus zurück, oder eine gemappte regionale Website liefert die falschen Assets aus. Bei einer Multisite-Migration entscheiden Dateisystem und Netzwerkkonfiguration darüber, ob der Go-live stabil ist oder nur in den ersten zehn Minuten stabil aussieht.

Das Verzeichnis mit dem höchsten Risiko ist meist wp-content/uploads. Es ist groß, unordentlich und voller geschäftskritischer Dateien, die niemand bemerkt, bis eine Kampagnen-Landingpage, ein übersetztes PDF oder ein Produktbild verschwindet.

Dateien umziehen: zuerst Integrität, dann Geschwindigkeit

Bei großen Netzwerken ist rsync die Standardwahl, weil es die Struktur erhält, sauber fortgesetzt werden kann und Ihnen eine Übertragungsmethode bietet, die Sie vor der Umstellung mehrmals ausführen können. Das ist wichtig. Eine einzige große Kopie auf einmal lässt sich langsamer validieren und ist weniger vertrauenswürdig.

Ein Standardmuster sieht so aus:

rsync -avz --progress /path/to/source/wp-content/ /path/to/destination/wp-content/

Bei Enterprise-Netzwerken teile ich die Übertragung in Phasen auf. Zuerst werden Themes, Plugins und mu-plugins kopiert. Die Uploads werden separat kopiert. Dann folgt kurz vor der Umstellung eine abschließende Synchronisierung, die nur die geänderten Dateien erfasst:

rsync -avz --delete /path/to/source/wp-content/uploads/ /path/to/destination/wp-content/uploads/

Das Flag --delete ist nützlich, aber nur, wenn Sie sicher sind, dass das Ziel entbehrlich oder bereits verifiziert ist. Unvorsichtig eingesetzt, kann es Assets löschen, die manuell auf dem Zielsystem bereitgestellt wurden.

Vermeiden Sie für diese Arbeit lange FTP-Sitzungen. Sie sind langsam, verbergen teilweise Fehlschläge und hinterlassen unübersichtliche Audit-Trails, wenn jemand fragt, welche Dateien übertragen wurden. Bei großen Upload-Verzeichnissen ist schrittweises Kopieren mit rsync ein praktischer Weg, die Dateiintegrität zu wahren und die Übertragung wiederholbar zu halten.

Berechtigungen verdienen eine eigene Prüfung. Wenn sich Eigentümer oder Dateimodi beim Umzug verändern, können Bildgenerierung, Cache-Schreibvorgänge und Plugin-Updates nach dem Launch fehlschlagen. Validieren Sie sie ausdrücklich:

find /path/to/destination/wp-content -type d -exec chmod 755 {} ;
find /path/to/destination/wp-content -type f -exec chmod 644 {} ;
chown -R www-data:www-data /path/to/destination/wp-content

Konfigurieren Sie Multisite in wp-config.php korrekt

Das Zielsystem muss zum Netzwerkmodell passen, das Sie migrieren. Ein kleiner Tippfehler in wp-config.php kann sich als Login-Schleife, defekte Cookies oder Subsites äußern, die auf die Hauptwebsite aufgelöst werden.

Wenn Multisite auf dem Zielsystem aktiviert wird, fügen Sie Folgendes hinzu:

define('WP_ALLOW_MULTISITE', true);

Diese Konstante gehört direkt vor die Zeile /* That's all, stop editing! Happy publishing. */. Nachdem Sie die Netzwerkeinrichtung abgeschlossen haben, erzeugt WordPress die übrigen Multisite-Konstanten und Rewrite-Regeln auf Basis des Subdomain- oder Unterverzeichnis-Modus. Übernehmen Sie diese generierten Werte exakt. Sie ohne Grund von Hand zu bearbeiten ist der Weg, auf dem funktionierende Netzwerke inkonsistent werden.

Wenn Sie bei der Prüfung von Architekturentscheidungen eine Referenz für die Installationsseite brauchen, ist dieser Leitfaden zur Installation von WordPress Multisite hilfreich, bevor Sie die Zielkonfiguration festlegen.

Zwei Einstellungen verdienen bei der Migration besondere Aufmerksamkeit: die Domainstruktur und Annahmen über Pfade. Wenn das Quellnetzwerk Unterverzeichnisse verwendet hat und das Ziel mit Subdomains neu aufgebaut wird, passen Plugin-Einstellungen, Weiterleitungslogik und Pfade für mehrsprachiges SEO möglicherweise nicht mehr zu den gespeicherten Erwartungen. Die Startseite kann weiterhin laden, während hreflang-Verweise, Canonicals und sprachspezifische Medien-URLs brechen.

Der Leitfaden von Updraft zum Umwandeln von WordPress in eine Multisite erinnert außerdem daran, dass WP_ALLOW_MULTISITE nur der Einstiegspunkt ist. Bei Projekten, in denen eine Einzelwebsite zur Subsite wird, kommt es auf den Plugin-Status und das richtige Wiederherstellungsziel an. Eine Wiederherstellung im falschen Website-Kontext kann die falschen Tabellen überschreiben oder die Subsite wie eine eigenständige Installation konfiguriert zurücklassen.

Wählen Sie die Struktur nach dem Betrieb, nicht nach Vorliebe

Subdomains und Unterverzeichnisse sind beide zulässig. Die richtige Wahl hängt davon ab, wie das Unternehmen arbeitet.

• Subdomains passen besser, wenn jede Website als eigene Marke, eigenes Land oder eigene juristische Person mit eigenem DNS, SSL und eigenen Marketingabläufen behandelt wird.
• Unterverzeichnisse passen besser, wenn sich das Netzwerk wie eine einzige Publishing-Plattform mit gemeinsamer Autorität und eng verwandten Inhalten verhält.
• Gemappte Domains erhöhen das operative Risiko, weil jede gemappte Property zusätzliche Aspekte bei SSL, DNS, Weiterleitungen, Cache und Rollback mit sich bringt.

Hier treten auch Konflikte bei der Plugin-Lizenzierung zutage. Manche Premium-Plugins werden pro Domain, pro Umgebung oder pro aktiver Website lizenziert. Ein Netzwerk, das auf dem Quellserver funktioniert hat, kann nach der Migration auf gemappten Domains plötzlich deaktivierte Funktionen zeigen. Prüfen Sie die Lizenz-Dashboards vor dem Launch, besonders bei Plugins für SEO, Formulare, Übersetzungen und Page Builder. Diese Ausfälle erzeugen nicht immer einen sichtbaren Fehler. Sie zeigen sich als fehlende Schema-Ausgabe, blockierte Updates oder Admin-Hinweise, die nur Netzwerkadministratoren sehen.

Hier ist eine nützliche Anleitung, bevor Sie diese Einstellungen finalisieren:

Übersehen Sie nicht den Code, der außerhalb des Themes liegt

Multisite-Ausfälle gehen oft auf Code zurück, der nie im aktiven Theme lag.

Prüfen Sie alle folgenden Punkte:

• Must-use-Plugins
• Drop-ins
• Eigene Cron-Skripte
• Umgebungsspezifische Includes
• Abhängigkeiten von Rewrite-Regeln des Servers

Prüfen Sie außerdem Object-Cache-Drop-ins, die Sunrise-Konfiguration, falls das Domain-Mapping davon abhängt, sowie alle beim Deployment angelegten Symlinks. Diese Bausteine unterstützen oft Authentifizierung, Weiterleitungen, Seiten-Caching, Bildverarbeitung und mehrsprachiges Routing. Fehlt einer davon, kann das Netzwerk funktionsfähig aussehen, während wichtige Geschäftsabläufe unter Last oder auf sekundären Domains scheitern.

Behandeln Sie den Umzug des Dateisystems wie ein Produktions-Deployment. Inventarisieren Sie es, synchronisieren Sie es in Etappen und verifizieren Sie zuerst die Teile, die Umsatz, SEO und Rollback betreffen.

Tests nach der Migration und Domain-Mapping

Die Migration ist nicht abgeschlossen, wenn die Startseite lädt. Das ist der erste Zug der Tests, nicht ihr Abschluss. Ein Multisite-Netzwerk kann auf den ersten Blick gesund aussehen und dabei defekte Benutzerrollen, ungültige Medienpfade, fehlerhafte Weiterleitungen oder eine gemappte Domain verbergen, die auf die falsche Website führt.

Am schnellsten erkennen Sie das, wenn Sie die Validierung nach der Migration wie forensische Arbeit behandeln. Sie beweisen nicht, dass die Website lädt. Sie versuchen zu beweisen, dass nichts Kritisches fehlt.

Beginnen Sie mit den fehleranfälligsten Systemen

Delicious Brains berichtet, dass der falsche Umgang mit Pfaden von Mediendateien eine häufige Falle bei Multisite-Migrationen ist und bei etwa 35 % der manuellen Migrationsversuche auftritt, während automatisierte Migrationen mit Vorabprüfungen 92 % Erfolg erreichen können und manuelle Migrationen ohne Vorabprüfungen mit einer Quote von 28 % scheitern, so der Beitrag über das Aufteilen einer WordPress-Multisite und die Migration einer Subsite.

Diese Daten decken sich mit dem, was Teams in der Produktion sehen. Medien brechen zuerst, weil sie gleichzeitig von Pfadstruktur, Berechtigungen und korrekten URLs abhängen.

Beginnen Sie mit:

• Mediatheken: Öffnen Sie alte Beiträge, nicht nur neue. Prüfen Sie Beitragsbilder, Galerien, eingebettete Bilder und Downloads.
• Admin-Zugang: Verifizieren Sie Network Admin, Subsite-Admin und rollenspezifische Logins.
• Kritische Formulare und Transaktionen: Testen Sie Formularübermittlungen, Suche, Warenkörbe, geschützte Inhalte und per E-Mail ausgelöste Aktionen.
• Plugin-Ausgabe: Prüfen Sie alles, was eigene URLs schreibt, Skripte einbettet oder Daten in eigenen Tabellen speichert.

Die Startseite ist bei einer Multisite-Migration die am wenigsten nützliche Testseite. Tiefer liegende Inhalte zeigen den echten Schaden.

Führen Sie eine strukturierte Prüfrunde durch

Eine gute Prüfrunde nach der Migration geht von Prüfungen auf Netzwerkebene zu Prüfungen auf Subsite-Ebene. Springen Sie nicht hin und her.

Prüfungen auf Netzwerkebene

• Website-Verzeichnis: Bestätigen Sie, dass jede erwartete Subsite existiert und korrekt geroutet wird.
• Gemeinsame Benutzer: Testen Sie einen Benutzer, der zu mehreren Websites gehört, und prüfen Sie seine Berechtigungen auf jeder davon.
• Netzwerk-Plugins: Bestätigen Sie, dass netzwerkweit aktivierte Plugins weiterhin wie vorgesehen funktionieren.
• Verfügbarkeit von Themes: Stellen Sie sicher, dass aktivierte Themes dort sichtbar sind, wo sie sein sollen.

Prüfungen auf Subsite-Ebene

• Frontend-Rendering: Prüfen Sie Startseite, wichtige Landingpages, Beitragsarchive und Formulare.
• Redaktionserlebnis: Öffnen Sie den Block-Editor, den Medien-Uploader, wiederverwendbare Muster und benutzerdefinierte Felder.
• URL-Verhalten: Prüfen Sie Permalinks, Paginierung und Weiterleitungen.
• Lokalisierte Inhalte: Prüfen Sie sprachspezifische Inhalte und Navigation, wenn das Netzwerk mehrsprachig ist.

Ein einfaches Testprotokoll hilft Teams, ehrlich zu bleiben:

Mappen Sie Domains erst, wenn das Netzwerk die Validierung bestanden hat

Das Domain-Mapping sollte einer der letzten Schritte sein, keine frühe Vermutung. Sobald das importierte Netzwerk auf dem Zielsystem stabil ist, richten Sie jede gemappte Property bewusst aus und validieren die Antwort Website für Website.

Bei SEO-sensiblen Netzwerken überschneidet sich das Domain-Mapping auch mit der Suchstruktur. Wenn eine mehrsprachige Subsite oder eine regionale Domain nach dem Umzug ihr Verhalten ändert, müssen Sie Canonicals, Alternate-Tags und Crawl-Pfade prüfen. Das ist besonders relevant für Teams, die für WordPress-Multisite-SEO verantwortlich sind, wo technisches Routing und Suchsignale eng miteinander verknüpft sind.

Erneut speichern und prüfen, aber sich nicht allein darauf verlassen

Ja, das erneute Speichern der Permalinks hilft nach einem Import oft. Nein, es ist keine vollständige Lösung. Es stellt keine fehlenden Uploads wieder her, löst keine Probleme mit Plugin-Lizenzen und repariert keine fehlerhaften Rollenzuordnungen.

Ein ausgereifter Testdurchlauf endet erst, wenn echte Benutzer ihre Arbeit im neuen Netzwerk erledigen können. Bis dahin ist die Migration weiterhin vorläufig.

Rollback-Pläne und Go-live-Optimierung

Um 2:07 Uhr nachts ist die DNS-Umstellung live, der Login funktioniert noch, und die Startseite sieht gut aus. Zehn Minuten später landet bezahlter Traffic auf der falschen regionalen Website, ein Premium-Plugin fällt auf zwei Subsites in den Testmodus, und die Canonicals verweisen wieder auf die alte Domain. Das ist der Teil einer WordPress-Multisite-Migration, den Standard-Checklisten unterschätzen. Die Übertragung kann gelingen und der Launch trotzdem scheitern.

Ein Rollback muss ein Betriebsverfahren sein, kein vages Versprechen, „das Backup wiederherzustellen”. In der Agenturarbeit ist der Unterschied einfach. Ein echter Rollback-Plan benennt den genauen Wiederherstellungspunkt, den Befehlsweg, wer die Rückabwicklung freigeben darf, wer das DNS ändert und welche Bedingungen die Entscheidung auslösen. Ohne das verlieren Teams 30 bis 60 Minuten mit Diskussionen, während Benutzer und Crawler weiterhin auf einen defekten Stack treffen.

Schreiben Sie den Plan so, dass die Rufbereitschaft ihn im Halbschlaf ausführen kann. Halten Sie ihn kurz und konkret:

1. Release-Kennung, verknüpft mit dem finalen Datenbank-Dump und dem Datei-Snapshot
2. Wiederherstellungsbefehle für Datenbank und Uploads
3. Verantwortliche Person für das Zurückstellen des DNS sowie der Zugangsweg zu Registrar oder CDN
4. Notizen zur Wiederherstellung von Plugin-Lizenzen für alles, was an Domain, IP-Adresse oder Umgebung gebunden ist
5. Geschäftlicher Auslöser für den Rollback, etwa ein Checkout-Ausfall, ausgesperrte Admins oder domainübergreifende Routing-Fehler
6. Validierung nach dem Rollback für die wenigen Funktionen, die zuerst zählen

Wenn die Zieldatenbank zum Beispiel bereits geladen ist und Sie schnell zurückkehren müssen, sollte das Runbook die genauen Befehle enthalten, nicht einen Verweis auf „das Backup in S3”:

wp db import /backups/prod-prelaunch.sql
rsync -av /backups/uploads/ wp-content/uploads/
wp cache flush

Wenn Object Cache oder Redis im Spiel sind, fügen Sie auch diesen Befehl hinzu. Wenn Ihre Edge-Schicht Weiterleitungen übernimmt, notieren Sie, ob der Rollback das Deaktivieren von Page Rules oder Origin-Overrides umfasst. Ich habe technisch korrekte Datenbankwiederherstellungen scheitern sehen, weil Cloudflare, Route 53 oder ein Load Balancer weiterhin den neuen Origin ausgeliefert haben.

Das DNS ist meist der langsamste Teil einer Rückabwicklung, deshalb beginnt die Go-live-Optimierung vor der Launch-Nacht. Kurze TTLs helfen, garantieren aber keine sofortige Korrektur. Manche Resolver ignorieren sie. Manche Clients sitzen hinter aggressivem Caching. Planen Sie eine Phase mit gemischtem Traffic ein, in der ein Teil des Publikums den alten Stack und ein Teil den neuen sieht.

Diese Realität verändert die Art, wie Sie launchen. Frieren Sie Inhalte vor der Umstellung ein. Stellen Sie Bestellungen oder redaktionelle Änderungen in eine Warteschlange, wenn das Unternehmen das tolerieren kann. Wenn nicht, brauchen Sie einen Abgleichplan für Kommentare, Formulare, Commerce-Daten und Benutzerregistrierungen, die während des Überlappungsfensters entstehen.

Mehrsprachiges SEO braucht einen eigenen Rollback-Schwellenwert. In der Praxis ist dies einer der Bereiche, in denen Geschäftsrisiken am leichtesten übersehen werden, weil die Seite normal gerendert wird. Die versteckten Fehler liegen in Canonicals, hreflang-Paaren, regionalen Weiterleitungen, übersetzten Slugs, XML-Sitemaps und Marktumschaltern. Unserer Erfahrung nach verlieren migrierte Multisite-Properties bei der Herauslösung oder beim Neu-Mapping von Domains oft einen Teil dieser Signale, besonders wenn SEO-Plugins Einstellungen auf einer anderen Ebene speichern, als das Team erwartet hat.

Prüfen Sie diese Punkte unmittelbar nach der Umstellung:

• Canonical-Tags auf den wichtigsten Templates und Landingpages
• Hreflang-Paare für jede Sprach- oder Marktvariante
• Lokalisierte URL-Strukturen wie /de/ oder Länder-Subdomains
• Sitemaps, die vom aktiven SEO-Plugin auf dem Zielsystem erzeugt werden
• Weiterleitungsverhalten von alten regionalen URLs
• Indexierungssteuerung, damit noindex-Regeln aus dem Staging nicht mit in den Launch gelangen

Die Plugin-Lizenzierung verdient dieselbe Aufmerksamkeit. Enterprise-Teams werden hier überrascht, weil das Plugin im alten Netzwerk funktioniert hat und dann auf der herausgelösten Website oder der neuen Domain versagt. Der Fehler ist selten dramatisch. Oft ist es eine fehlende Feldgruppe, ein deaktivierter Formularversand, ein blockierter Update-Kanal oder ein Banner, das nach Ablauf des Caches zu fehlerhafter Ausgabe wird. Wenn ein Plugin-Anbieter die Lizenz an das ursprüngliche Netzwerk bindet, nehmen Sie die manuellen Aktivierungsschritte in das Launch-Runbook auf und entscheiden Sie, ob dieser Zustand ein Rollback-Auslöser oder eine bekannte Aufgabe nach dem Launch ist.

Die Go-live-Optimierung folgt nach den Stabilitätsprüfungen, nicht davor. Leeren Sie die Cache-Ebenen. Wärmen Sie die wichtigen Seiten vor. Prüfen Sie PHP-Logs, Webserver-Logs, Weiterleitungsketten, Cron-Ereignisse und Transaktions-E-Mails. Testen Sie dann die kommerziellen Pfade unter realen Bedingungen: angemeldete Sessions, Sprachwechsel, Formularübermittlungen, Suche, Checkout und alle Callbacks von Drittanbietern.

Nutzen Sie WP-CLI für Aufräumarbeiten, die wiederholbar sein sollen:

wp cache flush
wp rewrite flush --hard
wp cron event run --due-now
wp search-replace 'https://staging.example.com' 'https://example.com' --network --skip-columns=guid

Dieser letzte Befehl ist mächtig und gefährlich. Führen Sie ihn in einer Multisite erst aus, nachdem Sie die Zieldomains, die gemappten Hosts und den Umfang der serialisierten Daten bestätigt haben. Eine fehlerhafte netzwerkweite Ersetzung ist der Weg, einen zweiten Ausfall zu verursachen, während man den ersten behebt.

Ein starker Launch ist im besten Sinne langweilig. Die Benutzer arbeiten weiter. Die Suchsignale bleiben intakt. Lizenzierte Plugins werden weiterhin validiert. Und wenn eines davon so schwer bricht, dass Umsatz oder Betrieb gefährdet sind, erfolgt der Rollback schnell, weil das Team Auslöser, verantwortliche Person und genaue Befehle bereits festgelegt hat.

Fortgeschrittene Szenarien und wichtige FAQ

Freitag, 17:30 Uhr: Der Datenbankimport ist abgeschlossen, die Uploads sind an Ort und Stelle, und die Subsite lädt. Dann verschwinden Übersetzungen aus den hreflang-Tags, ein Formular-Plugin fällt in den Testmodus, und das SEO-Team bemerkt, dass die Canonicals jetzt auf die alte Netzwerkdomain zeigen. Das ist der Teil, den Standardleitfäden zur Multisite-Migration meist übersehen.

Die teuren Ausfälle bei einer WordPress-Multisite-Migration passieren, nachdem Dateien und Tabellen umgezogen sind. Die Plugin-Lizenzierung kann brechen, wenn eine Subsite ein Netzwerk verlässt. Mehrsprachige Plugins können weiterhin Seiten rendern und dabei Sprachbeziehungen oder Metadaten verlieren. Ein Rollback-Plan, der auf dem Papier gut aussah, kann zerfallen, wenn Lizenzreaktivierung, DNS-Timing oder Callbacks von Drittanbietern nie getestet wurden.

Plugin-Lizenzierung ist ein operatives Risiko, keine Aufräumaufgabe

Diskussionen im Support-Forum zur Multisite-Migration auf WordPress.org nennen immer wieder defekte Plugins als häufiges Problem nach der Migration, oft im Zusammenhang mit Lizenzierung, fehlenden Multisite-Add-ons oder netzwerkspezifischen Einstellungen. Behandeln Sie das als Arbeitsstrang vor dem Launch, nicht als Überraschung danach.

Ein Premium-Plugin kann sich innerhalb eines Netzwerks korrekt verhalten und in dem Moment versagen, in dem eine Website eigenständig wird. Am häufigsten sehe ich das bei domaingebundenen Lizenzen, bei Plugins, die ihren Status in wp_sitemeta statt in Optionen pro Website speichern, und bei Anbietern, die Multisite-Unterstützung als separate Berechtigung verkaufen.

Prüfen Sie diese Punkte, bevor Sie die Umstellung freigeben:

• Unterstützt das Plugin sowohl Multisite- als auch eigenständige Installationen?
• Ist die aktuelle Lizenz für die Zieldomain gültig?
• Liegen die Aktivierungsdaten in Netzwerkoptionen, Website-Optionen, eigenen Tabellen oder einer externen API?
• Kann das Plugin per CLI reaktiviert werden oder nur über wp-admin?
• Wenn die Lizenz versagt: Verliert die Website Funktionen, verliert sie Updates, oder rendert sie kritische Inhalte nicht mehr?

Wenn der Anbieter diese Fragen nicht klar beantworten kann, planen Sie manuelle Nacharbeit ein und entscheiden Sie, ob ein Plugin-Ausfall den Launch blockiert.

Den Geltungsbereich von Optionen können Sie mit WP-CLI schnell prüfen:

wp option get active_plugins
wp site option get active_sitewide_plugins
wp db query "SELECT meta_key FROM wp_sitemeta ORDER BY meta_key;"

Vergleichen Sie auf herausgelösten Subsites auch die pluginspezifischen Tabellen. Manche Plugins speichern Lizenzen, Sprachzuordnungen oder Warteschlangenstatus außerhalb der normalen Optionen.

Mehrsprachiges SEO bricht leise

Eine mehrsprachige Subsite kann für die Redaktion gut aussehen und nach der Migration trotzdem Suchwert verlieren. Die typischen Fehler sind falsche Canonicals, fehlende hreflang-Tags, defekte übersetzte URL-Slugs und Sprachumschalter, die auf alte Hosts verweisen. Deshalb gehört die mehrsprachige Validierung in die Launch-Checkliste und nicht nur in die allgemeine QA.

Prüfen Sie bei WPML, Polylang oder eigenen mehrsprachigen Setups auf der migrierten Website alle folgenden Punkte:

• Canonical-Tags verweisen auf die richtige Live-Domain
• Hreflang-Tags verweisen auf die richtigen Sprachvarianten
• Übersetzte Seiten sind weiterhin miteinander verknüpft
• XML-Sitemaps enthalten jede Sprache und die richtigen Hostnamen
• Weiterleitungsregeln erhalten alte Sprachpfade und Abfrageparameter, wo nötig

Verlassen Sie sich nicht auf eine Prüfung der Startseite. Testen Sie tiefe URLs, paginierte Archive und die Seiten, die Umsatz erzeugen.

Drei wichtige FAQ

Kann man eine Einzelwebsite in ein bestehendes Multisite-Netzwerk migrieren?
Ja, aber legen Sie zuerst die Ziel-Subsite an und stellen Sie im richtigen Blog-ID-Kontext wieder her. Wenn Sie Daten mit der falschen Website-ID importieren, können Upload-Pfade, Benutzerrollen und Plugin-Einstellungen an die falschen Tabellen gebunden werden. Prüfen Sie das Ziel vor dem Import mit:

wp site list
wp db tables | grep _2_

Ersetzen Sie _2_ durch die tatsächliche Blog-ID, die Sie verwenden möchten.

Kann man eine Subsite in eine eigene, eigenständige WordPress-Installation herauslösen?
Ja. Die Übertragung selbst ist meist unkompliziert. Das Risiko liegt in allem, was sie umgibt: Umschreiben von Medienpfaden, geplante Jobs, lizenzierte Plugins und SEO-Signale, die zuvor auf Netzwerkebene verwaltet wurden. In echten Projekten wird bei der Herauslösung die Geschäftskontinuität auf die Probe gestellt.

Was ist mit Benutzern und Berechtigungen?
Benutzer sind in einer Multisite global. Rollen nicht. Bestätigen Sie nach der Migration die Berechtigungen auf der Zielwebsite, besonders für Redakteure, Shop-Manager und alle per SSO integrierten Konten. Wenn das ursprüngliche Netzwerk Benutzer über mehrere Properties hinweg geteilt hat, prüfen Sie, ob diese Benutzer auf der herausgelösten Website überhaupt existieren sollten.

Die Frage, die niemand früh genug stellt

Was ist der schnellste sichere Rollback, wenn die migrierte Website live ist und umsatzrelevante Abläufe ausfallen?
Nutzen Sie einen Rollback, der die letzte funktionierende Datenbank wiederherstellt, den Traffic zurück auf die alte Umgebung leitet und alle Schritte bei Anbietern umfasst, die nötig sind, um Lizenzen erneut zu validieren oder mehrsprachige Dienste wieder zu aktivieren. Wenn Ihr Rollback davon abhängt, dass Menschen während eines Ausfalls Dinge herausfinden, ist er kein Rollback-Plan.

Halten Sie eine schriftliche Abfolge mit namentlich benannten Verantwortlichen, Annahmen zu DNS-TTLs und genauen Wiederherstellungsbefehlen bereit. Zum Beispiel:

wp db import prelaunch-backup.sql
wp search-replace 'https://new.example.com' 'https://old.example.com' --skip-columns=guid
wp cache flush

Führen Sie das nur in der Umgebung aus, die Sie wiederherstellen möchten. In einer Multisite kann ein unvorsichtiges Search-Replace den Ausfall vergrößern.

Der schwierige Teil einer Multisite-Migration ist, das Geschäftsverhalten unter Druck zu erhalten. Die Datenübertragung ist nur eine Ebene. Lizenzierung, mehrsprachiges SEO und Rollback-Disziplin verhindern, dass der Umzug zu einem umsatzrelevanten Incident wird.

Wenn Ihr Team erfahrene Unterstützung für einen risikoreichen Multisite-Umzug braucht, ist IMADO die Art von Engineering-Partner, die man früh einbinden sollte. IMADO übernimmt die Teile, die meist unterschätzt werden, darunter mehrsprachige Architektur, Multisite-Komplexität, Performance und Launch-Disziplin, ohne das Projekt zu einem generischen „Website-Umzug” zu machen.