- WordPress Multisite betreibt mehrere Sites in einer einzigen WordPress-Installation, mit gemeinsamer Datenbank, gemeinsamen Plugins und Themes, aber getrennten Inhalten.
- Sinnvoll ist es vor allem für Franchise-Betriebe, Filialnetzwerke und Agenturen, die viele gleichartige Sites zentral verwalten. Für zwei oder drei unabhängige Projekte ist es fast immer zu viel Aufwand.
- Ein einziges Update, ein fehlerhaftes Plugin oder ein Serverproblem trifft in Multisite alle Sites gleichzeitig. Das Risiko ist höher als bei getrennten Installationen.
- Für die meisten KMU, die schlicht zwei Websites oder mehrere Sprachen brauchen, sind getrennte Installationen die bessere Wahl.
Ein Kunde kommt mit dem Wunsch, sein Unternehmen habe drei Websites, und ob man die nicht „irgendwie zusammenfassen“ könne. Die Antwort ist meistens: lieber nicht. WordPress Multisite kann das theoretisch, aber ob es die richtige Wahl ist, hängt von konkreten Bedingungen ab. Die meisten Anfragen scheitern nicht am Konzept, sondern daran, dass Verwaltungsaufwand und Fehlerrisiko unterschätzt werden.
Was WordPress Multisite ist und wie es funktioniert
Seit WordPress 3.0 ist Multisite direkt im Kern integriert, es braucht kein Plugin dafür. Ein sogenanntes Netzwerk entsteht, wenn man in der wp-config.php die Zeile define( 'WP_ALLOW_MULTISITE', true ); setzt und dann unter Werkzeuge die Netzwerk-Konfiguration abschließt. Danach gibt es einen Super-Admin, der das gesamte Netzwerk verwaltet, und für jede Sub-Site einen eigenen Site-Admin mit eingeschränkten Rechten.
Die URL-Struktur lässt sich bei der Einrichtung einmalig wählen: entweder Unterverzeichnisse (ihp-media.com/marke-a/) oder Subdomains (marke-a.ihp-media.com). Domain-Mapping auf vollständig eigene Domains ist möglich, erfordert aber zusätzliche Konfiguration. Diese Entscheidung ist nach der Aktivierung nur mit erheblichem Aufwand änderbar, weshalb sie vor dem Start durchdacht sein muss.
Technisch teilen sich alle Sites einer Multisite-Installation die Datenbankverbindung und die Datenbankpräfix-Struktur. Jede Sub-Site bekommt eigene Tabellen für ihre Inhalte, aber Benutzerkonten und bestimmte Einstellungen werden auf Netzwerkebene gespeichert. Ein Benutzer kann in mehreren Sub-Sites gleichzeitig aktiv sein, mit je unterschiedlicher Rolle.
Einen anschaulichen Vergleich: Multisite ist wie ein Bürogebäude mit gemeinsamer Haustechnik. Alle Büros teilen den Aufzug, die Heizung und den Hausmeister. Jedes Büro hat seine eigenen Türschlüssel und richtet sich innen selbst ein. Wenn die Heizung ausfällt, friert jedes Büro gleichzeitig.
Wann Multisite eine echte Lösung ist
WordPress Multisite löst ein konkretes Problem: viele gleichartige Sites, die dieselbe technische Basis brauchen, aber inhaltlich getrennt sind. Drei Szenarien, in denen es wirklich Sinn ergibt:
Franchise-Betriebe und Filialnetzwerke
Eine Restaurantkette mit 40 Standorten braucht 40 Websites, die alle gleich aussehen und dieselben Plugins verwenden, sich aber in Öffnungszeiten, Speisekarte und lokalem Inhalt unterscheiden. Mit 40 getrennten Installationen würde ein Update-Durchlauf Stunden dauern, jede Sicherheitslücke müsste 40-mal gepatcht werden. In Multisite passiert das einmalig zentral. Der Netzwerk-Admin spielt das Theme-Update einmal ein, alle 40 Standorte profitieren davon.
Das funktioniert gut, solange alle Standorte dasselbe Theme und dieselben Plugins verwenden. Sobald einzelne Standorte abweichende Anforderungen haben, wird es komplizierter.
Mehrere Marken unter einem Dach
Ein Unternehmen, das mehrere Marken betreibt, die nichts miteinander zu tun haben sollen (zum Beispiel eine Holdinggesellschaft mit drei eigenständigen Unternehmensmarken), kann Multisite nutzen, wenn alle Marken denselben Tech-Stack verwenden. Das spart Serverkosten und vereinfacht die zentrale Pflege. Voraussetzung: Die Marken müssen bereit sein, dieselbe Plugin-Ausstattung zu teilen, und dürfen keine stark voneinander abweichenden technischen Anforderungen haben.
Agentur-Mandanten mit gleicher Anforderung
Agenturen, die viele Mandanten mit demselben Produkt (z. B. ein standardisiertes Vereins- oder Arztpraxis-WordPress) betreuen, können Multisite nutzen, um Updates und Sicherheits-Patches zentral zu spielen. Hier ist der Effizienzgewinn real, er hängt aber stark davon ab, dass die Mandanten wirklich gleichartige Anforderungen haben. Sobald ein Mandant ein spezielles Plugin benötigt, das mit einem anderen Mandanten kollidiert, ist die Effizienz dahin.
Wann getrennte Installationen besser sind
Die meisten Anfragen nach Multisite kommen von Betreibern, für die getrennte Installationen die bessere Wahl wären. Konkrete Situationen, in denen man Multisite lassen sollte:
Zwei oder drei eigenständige Websites. Zwei Websites in Multisite zu stecken, um Verwaltungsaufwand zu sparen, lohnt nicht. Der Einrichtungsaufwand und die erhöhte Komplexität beim Backup und bei der Migration fressen den eingesparten Aufwand schnell wieder auf. Drei getrennte WordPress-Installationen, die mit einem Tool wie ManageWP oder MainWP zentral überwacht werden, sind für die meisten KMU die praktischere Lösung.
Mehrsprachige Website. Wer eine Website auf Deutsch und Englisch will, braucht dafür kein Multisite. Plugins wie WPML oder Polylang lösen das innerhalb einer einzigen Installation. Multisite für Sprachen zu nutzen, ist möglich, wird aber selbst von WordPress nicht als primäres Anwendungsgebiet geführt und bringt Komplexität ohne echten Mehrwert.
Sites mit sehr unterschiedlichem Charakter. Ein Onlineshop und eine Unternehmenswebsite haben unterschiedliche Plugin-Anforderungen, unterschiedliche Sicherheitsprofile und unterschiedliche Performance-Anforderungen. Sie in Multisite zusammenzuführen, bedeutet, dass ein Problem im Shop auch die Unternehmenswebsite betrifft. Das ist kein guter Tausch.
Unterschiedliche Hosting-Anbieter oder Server. Multisite setzt voraus, dass alle Sites auf demselben Hosting-Paket laufen. Wer aus Leistungs- oder Datenschutzgründen Sites auf verschiedenen Servern betreiben muss, scheidet Multisite aus.
Multisite vs. getrennte Installationen im Vergleich
| Kriterium | WordPress Multisite | Getrennte Installationen |
|---|---|---|
| Updates (Kern, Plugins, Themes) | Einmalig für alle Sites, großer Zeitvorteil bei vielen Sites | Jede Installation einzeln, mit Verwaltungstool (MainWP, ManageWP) bündelbar |
| Fehlerrisiko bei Updates | Hoch: ein fehlerhaftes Update trifft alle Sites gleichzeitig | Begrenzt: ein Problem bleibt auf eine Installation beschränkt |
| Plugin-Verwaltung | Nur der Super-Admin installiert Plugins; Site-Admins können vorhandene nur nutzen | Jede Installation verwaltet eigene Plugins unabhängig |
| Plugin-Kompatibilität | Nicht jedes Plugin unterstützt Multisite; vorab prüfen | Kein Unterschied zu Standard-WordPress |
| Backup und Wiederherstellung | Komplex: einzelne Sites lassen sich nur mit speziellen Tools isoliert sichern | Einfach: jede Installation separat sichern und wiederherstellen |
| Migration einzelner Sites | Aufwändig, erfordert Spezialwerkzeuge (z. B. NS Cloner) | Mit Standard-Migrationsplugins problemlos |
| Serverkosten | Alle Sites teilen ein Hosting-Paket, Einsparung bei vielen Sites | Pro Installation ein Hosting-Paket nötig |
| Datentrennung | Benutzerkonten sind netzwerkweit; vollständige Isolation nicht möglich | Vollständige Trennung, auch auf Datenbankebene |
| Geeignet für DSGVO-Trennungsanforderungen | Eingeschränkt: geteilte Datenbank erschwert saubere Trennung | Gut geeignet |
| Einrichtungsaufwand | Höher als eine Single-Site, aber einmalig | Jede Installation separat aufsetzen |
| Skalierung auf viele Sites | Sehr gut: 50+ Sites zentral wartbar | Verwaltungsaufwand wächst linear mit der Anzahl |
Risiken, die vor der Entscheidung bekannt sein müssen
Wer eine Multisite-Entscheidung auf Basis der Vorteile trifft, ohne die Risiken zu kennen, erlebt oft eine böse Überraschung. Vier Punkte verdienen besondere Aufmerksamkeit:
Ein fehlerhaftes Plugin trifft alle Sites
In einer Multisite-Installation kann der Super-Admin Plugins netzwerkweit aktivieren. Das ist praktisch, bis ein fehlerhaftes Plugin oder ein konflikthaftes Update das ganze Netzwerk in den Wartungsmodus zwingt oder weißen Bildschirm (White Screen of Death) hervorruft. Bei getrennten Installationen ist der Schaden begrenzt. In Multisite zieht ein Fehler alle Sites in Mitleidenschaft, auch die, die gerade reibungslos liefen.
Die offizielle WordPress-Dokumentation zur Netzwerkverwaltung weist ausdrücklich darauf hin, dass „nicht alle Plugins im Repository in einer Multisite-Umgebung funktionieren“. Plugin-Kompatibilität muss vor der Einrichtung geprüft werden, nicht danach.
Backup und Wiederherstellung sind komplizierter
Standard-Backup-Plugins wie UpdraftPlus oder Duplicator sind auf Single-Site ausgelegt. In einer Multisite sichern sie zwar das gesamte Netzwerk, aber das selektive Wiederherstellen einer einzelnen Sub-Site ist mit Standard-Werkzeugen kaum möglich. Wer eine einzelne Sub-Site auf einen früheren Stand zurücksetzen will, braucht entweder Spezialwerkzeuge oder muss manuell auf Datenbankebene eingreifen. Das ist ein echtes operationelles Risiko, besonders wenn mehrere Mandanten auf demselben Netzwerk laufen. Mehr zu sinnvollen Backup-Konzepten steht im Ratgeber zur DSGVO-konformen Backup-Strategie.
Migration einzelner Sites wird zum Projekt
Was passiert, wenn ein Mandant die Agentur wechselt oder eine Sub-Site auf einen eigenen Hosting-Account wandern soll? Bei einer normalen WordPress-Installation ist das eine Stunde Arbeit mit einem Migrations-Plugin. In Multisite ist es ein Sonderprojekt. Inhaltsdatenbank, Mediendateien und Konfiguration müssen manuell extrahiert und in eine neue Single-Site-Installation überführt werden. Je länger eine Sub-Site in Multisite gelebt hat, desto aufwändiger wird diese Migration.
Geteilte Benutzerkonten sind kein Problem bis sie eines sind
In WordPress Multisite existiert ein Benutzer netzwerkweit. Wer auf Site A ein Konto hat, existiert auch auf Site B, zwar ohne Rechte, aber als Datensatz in der Benutzertabelle. Das kann DSGVO-relevant werden, wenn verschiedene Mandanten oder Marken saubere Datentrennung fordern. Ein Benutzer, der nur für Site A registriert ist, steht technisch in derselben Datenbanktabelle wie die Benutzer von Site B.
Technischer Hintergrund für Entscheider
Dieser Abschnitt richtet sich an technisch Verantwortliche. Wer nur die Entscheidung braucht, kann direkt zur Checkliste springen.
Die Datenbankstruktur einer Multisite unterscheidet sich von einer Single-Site dadurch, dass jede Sub-Site eigene Präfix-Tabellen bekommt (z. B. wp_2_posts, wp_2_options für Site 2), während Benutzertabellen (wp_users, wp_usermeta) netzwerkweit geteilt werden. Die Netzwerk-Einstellungen liegen in wp_site und wp_blogs.
Die URL-Struktur ist bei der Einrichtung zu wählen: Subverzeichnisse funktionieren auf nahezu jedem Standard-Hosting, Subdomains erfordern Wildcard-DNS-Konfiguration auf Serverebene. Domain-Mapping auf komplett eigene Domains (z. B. marke-a.de statt marke-a.ihp-media.com) ist möglich, erfordert aber zusätzliche Server-Konfiguration oder ein Mapping-Plugin und kann bei shared Hosting problematisch sein.
Für die Staging-Umgebung gelten besondere Regeln. Eine Multisite kann nicht einfach mit einem Standard-Staging-Plugin gespiegelt werden, da URL-Strukturen und Domain-Mappings explizit umgeschrieben werden müssen. Wer für Multisite-Sites ein Staging braucht, sollte das vor dem Produktivstart testen. Details dazu im Ratgeber zur Staging-Umgebung.
Die offizielle Anleitung zur Netzwerk-Erstellung verlangt vor der Aktivierung: Pretty Permalinks aktiviert, alle Plugins deaktiviert, ein vollständiges Backup erstellt. Wer das überspringt, riskiert eine kaputte Konfiguration bei der Einrichtung.
Praxisbeispiel aus einem Agenturprojekt
In einem Projekt für einen regionalen Handwerksbetrieb mit fünf Standorten kam die Frage, ob Multisite sinnvoll wäre. Die Ausgangslage: fünf eigenständige Websites, je mit eigenem Google-Profil, eigenen Öffnungszeiten und eigenen Ansprechpartnern, aber dasselbe Design und dieselbe Unternehmensstruktur im Hintergrund.
Auf den ersten Blick ein Paradefall für Multisite. Bei genauerer Betrachtung zeigte sich ein Problem: Zwei Standorte hatten WooCommerce-Shops mit unterschiedlichen Produktkatalogen, ein dritter nutzte ein spezielles Buchungs-Plugin, das mit dem WooCommerce-Plugin auf demselben Netzwerk Konflikte verursacht hätte. Außerdem hatte jeder Standort seinen eigenen Ansprechpartner, der eigenständig Bilder hochladen und Texte ändern wollte, aber kein technisches Hintergrundwissen hatte.
Das Ergebnis: Wir haben fünf getrennte WordPress-Installationen auf einem gemeinsamen Hosting-Paket eingerichtet, über ManageWP zentral verwaltet. Updates laufen in einem Durchgang, die Standortbetreiber arbeiten vollständig getrennt voneinander. Ein Plugin-Conflict bei Standort 3 blieb auf Standort 3 begrenzt. Die Alternative Multisite hätte die kurzfristige Update-Verwaltung vereinfacht, aber auf Kosten eines schwereren Fehlerrisikos und einer komplizierten Plugin-Situation, die sich nicht elegant lösen ließ.
Multisite wäre die richtige Wahl gewesen, wenn alle fünf Standorte dasselbe Plugin-Set gebraucht hätten, also keine WooCommerce-Shops und kein Buchungs-Sonderbedarf. Schon ein Ausreißer kippt die Rechnung. Wer sich fragt, welche Website-Struktur für sein Unternehmen sinnvoll ist, findet auf unserer Leistungsseite Websites und Onlineshops einen Überblick, wie wir solche Projekte angehen.
Entscheidungs-Checkliste: Multisite oder getrennte Installationen?
Gehen Sie diese Fragen durch. Wer bei den Fragen zur Multisite-Eignung fünfmal Ja antwortet, kann Multisite ernsthaft in Betracht ziehen. Schon zwei oder drei Nein-Antworten sprechen für getrennte Installationen.
- Brauche ich wirklich mehr als fünf Sites, die dauerhaft zentralisiert gepflegt werden sollen?
- Sind alle Sites so gleichartig, dass sie dieselben Plugins und dasselbe Theme verwenden können?
- Habe ich einen technisch versierten Super-Admin, der das Netzwerk dauerhaft betreut?
- Ist Domain-Mapping auf meinem Hosting möglich und dokumentiert?
- Habe ich alle geplanten Plugins auf Multisite-Kompatibilität geprüft, bevor ich anfange?
- Habe ich eine Backup-Lösung, die einzelne Sub-Sites isoliert sichern und wiederherstellen kann?
- Sind die Datenschutzanforderungen der Sites vereinbar mit geteilten Benutzertabellen?
- Ist eine Migration einer einzelnen Sub-Site nach draußen ein akzeptiertes Risiko, falls nötig?
- WordPress Multisite eignet sich für viele gleichartige Sites, nicht für wenige unterschiedliche.
- Ein fehlerhaftes Update, ein konflikthaftes Plugin oder ein Serverausfall trifft in Multisite alle Sites gleichzeitig. Das Fehlerrisiko ist höher als bei getrennten Installationen.
- Backup, Wiederherstellung und Migration einzelner Sites sind in Multisite deutlich aufwändiger als im Standard.
- Für die meisten KMU mit zwei bis fünf Websites sind getrennte Installationen mit zentralem Verwaltungstool die pragmatischere Wahl.
Häufige Fragen zu WordPress Multisite
Was kostet die Einrichtung eines WordPress-Multisite-Netzwerks?
Die Einrichtung selbst kostet keinen Aufpreis, WordPress Multisite ist Teil des WordPress-Kerns. Der Aufwand liegt in der Konfiguration: Domain-Mapping, Plugin-Tests auf Multisite-Kompatibilität und die initiale Einrichtung aller Sub-Sites. Wer das durch eine Agentur machen lässt, sollte je nach Komplexität mit mehreren Stunden Einrichtungsarbeit rechnen, zuzüglich des laufenden Verwaltungsaufwands für den Super-Admin.
Kann ich bestehende WordPress-Sites nachträglich in ein Multisite-Netzwerk migrieren?
Ja, aber mit Aufwand. Eine bestehende WordPress-Single-Site in ein Multisite-Netzwerk zu importieren, erfordert spezielle Migrationswerkzeuge, weil die Datenbankpräfixe angepasst werden müssen. Plugin- und Theme-Konfigurationen müssen manuell übertragen werden. Das ist kein Hexenwerk, aber auch kein einfacher Copy-and-paste-Vorgang. Ein vorheriges vollständiges Backup ist Pflicht.
Funktionieren WooCommerce-Shops in WordPress Multisite?
WooCommerce ist grundsätzlich Multisite-kompatibel, aber mit Einschränkungen. Einige WooCommerce-Erweiterungen von Drittanbietern unterstützen Multisite nicht. Vor allem Lizenzmodelle, die eine Domain-Bindung haben, können in einem Netzwerk mit mehreren Domains Probleme bereiten. Wer WooCommerce in Multisite betreiben will, sollte alle geplanten Erweiterungen vorab in einer Testumgebung prüfen.
Ist WordPress Multisite schwieriger zu sichern als eine einzelne Installation?
Das Sicherheitsprofil ist nicht grundsätzlich schlechter, aber das Schadenspotenzial bei einem Angriff oder einer Sicherheitslücke ist höher, weil alle Sites gleichzeitig betroffen sind. Besondere Aufmerksamkeit verdienen Benutzerrechte: Wer zu viele Super-Admin-Konten anlegt, schafft ein großes Angriffsziel. Die Absicherung des WordPress-Logins ist in Multisite deshalb besonders wichtig, mehr dazu im Ratgeber WordPress Login gegen Brute-Force-Angriffe absichern.
Kann ich Multisite auf jedem Hosting nutzen?
Subverzeichnis-basierte Multisite funktioniert auf den meisten Standard-Hosting-Paketen. Subdomain-basierte Multisite braucht Wildcard-DNS, was nicht jeder Anbieter anbietet oder einfach konfigurierbar macht. Domain-Mapping auf individuelle Domains erfordert ebenfalls Konfigurationsmöglichkeiten auf Serverebene, die bei günstigem Shared Hosting oft eingeschränkt sind. Vor der Einrichtung beim Hosting-Anbieter nachfragen. Welches Hosting für welche Anforderung passt, zeigt der Hosting-Vergleich für Managed, Shared und VPS.
Was ist der Unterschied zwischen WordPress Multisite und einem WordPress-Verwaltungstool wie MainWP?
Das sind zwei verschiedene Ansätze für dasselbe Grundproblem. WordPress Multisite ist eine einzige Installation mit mehreren Sites darin. MainWP oder ManageWP sind externe Dashboards, die viele unabhängige WordPress-Installationen von einer zentralen Oberfläche aus verwalten, Updates spielen und Backups anstoßen. MainWP lässt die Sites technisch vollständig getrennt, bündelt aber den Verwaltungsaufwand. Für die meisten KMU-Szenarien ist dieser Weg die risikoärmere Alternative zu Multisite.
Wann ist WordPress Multisite die falsche Wahl?
Für zwei bis vier Websites, für Sites mit stark unterschiedlichen Plugin-Anforderungen, für mehrsprachige Sites (dort sind WPML oder Polylang besser geeignet), und für Situationen, in denen einzelne Sites vollständige Datentrennung benötigen. Auch wenn kein dauerhaft verfügbarer technischer Super-Admin vorhanden ist, sollte man Multisite vermeiden.
