Eine WordPress-Multisite ermöglicht die zentrale Verwaltung mehrerer Websites aus einer einzigen Installation heraus. Für die meisten Unternehmen mit zwei bis fünf Websites reicht dieser Vorteil jedoch nicht aus, um die zusätzliche technische Komplexität und das erhöhte Risiko bei Störungen zu rechtfertigen. Separate Installationen mit zentralem Update-Management bleiben in der Regel die sicherere Wahl.
Was eine WordPress-Multisite technisch bedeutet
Bei einer Multisite-Installation teilen sich alle Websites eine gemeinsame WordPress-Kerninstallation, eine Datenbank und ein Dateisystem. Jede Website erhält eigene Tabellen in der Datenbank, aber die zentralen Systemdateien, Plugins und Themes liegen auf einer einzigen Ebene. Ein Administrator kann von einem Dashboard aus auf alle Websites zugreifen, Benutzer verwalten und Updates einspielen.
Diese Architektur unterscheidet sich fundamental von separaten WordPress-Installationen, bei denen jede Website vollständig autonom läuft. Die Multisite-Struktur erinnert eher an ein Hochhaus mit gemeinsamer Infrastruktur als an einzelne Gebäude auf einem Grundstück.
Die drei Szenarien, in denen Multisite tatsächlich passt
Multisite lohnt sich nur unter engen Bedingungen, die in der Praxis selten zusammentreffen:
Gleiche technische Basis, unterschiedliche Inhalte: Ein Unternehmen betreibt mehrere regionale Auftritte oder Fachportale, die identische Funktionalität nutzen, aber eigene Inhalte pflegen. Dabei müssen alle Websites dasselbe Theme und denselben Plugin-Satz verwenden können.
Strikte Zentralverwaltung: Eine zentrale IT- oder Marketingabteilung steuert alle Websites allein, ohne dass einzelne Standorte oder Marken eigene technische Anpassungen fordern. Dezentrale Eigenständigkeit ist bei Multisite systematisch schwierig.
Gemeinsame Benutzerbasis: Nutzer sollen sich mit einem Account auf mehreren Websites bewegen können, etwa bei einem Netzwerk von Fachzeitschriften oder einem Franchise-System mit zentraler Mitgliederverwaltung.
Wer diese Kriterien nicht vollständig erfüllt, sollte die Finger von Multisite lassen.
Wann separate Installationen die bessere Wahl bleiben
Für die typische Unternehmensrealität sprechen mehrere Gründe gegen Multisite. Verschiedene Marken mit unterschiedlichem Design, eigene Plugin-Anforderungen oder unterschiedliche Entwicklungszyklen passen schlecht in ein zentrales Korsett. Gleiches gilt für Websites mit externen Agenturen, die jeweils eigenständig arbeiten sollen.
Besonders relevant ist die Unabhängigkeit bei technischen Problemen. Wenn eine Website unter separatem Hosting ausfällt, laufen die anderen unbeeinträchtigt weiter. Bei Multisite fällt das gesamte Netzwerk aus – ein Szenario, das für umsatzrelevante Auftritte schwer zu kommunizieren ist.
Unternehmen, die mehrere Websites betreiben, sollten stattdessen in ein zentrales Update-Management investieren. Tools wie InfiniteWP, MainWP oder verwaltete Hosting-Lösungen erlauben die Massenverwaltung separater Installationen, ohne deren technische Unabhängigkeit aufzugeben. Mehr dazu findet sich im Ratgeber WordPress für kleine Unternehmen: Wann es sinnvoll ist.
Konkrete Einschränkungen bei Plugins, Themes und Funktionalität
Nicht jedes Plugin funktioniert in Multisite-Umgebungen. Viele Erweiterungen sind für Einzelinstallationen konzipiert und verursachen bei Netzwerkaktivierung Datenbankfehler, doppelte Einträge oder unvorhersehbare Nebeneffekte zwischen den Websites. Besonders problematisch sind E-Commerce-Lösungen wie WooCommerce, Mitglieder-Plugins, SEO-Tools mit individuellen Konfigurationen und Sicherheitsplugins mit Firewall-Funktionen.
Themes müssen explizit multisite-fähig sein, um pro Website unterschiedliche Einstellungen zu erlauben. Anpassungen am Code einer einzelnen Website sind kaum möglich, ohne das gesamte Netzwerk zu beeinflussen. Wer also glaubt, mit Multisite die Flexibilität behält, wird enttäuscht: Die Struktur erzwingt Uniformität, wo separate Installationen Individualität erlauben würden.
Updates erfordern zudem sorgfältige Planung. Ein Plugin-Update, das auf Website A problemlos läuft, kann auf Website B die Darstellung zerstören – mit einem einzigen Klick für alle Betroffenen.
Was ein zentraler Ausfall bedeutet: Das Ein-All-Risiko
Die zentrale Verwaltung birgt das zentrale Risiko. Ein Fehler in der Hauptinstallation, ein kompromittiertes Theme oder ein fehlerhaftes Datenbank-Update betrifft sofort alle Websites im Netzwerk. Die Fehlersuche wird komplexer, weil die Ursache in der gemeinsamen Infrastruktur liegen kann, während die Symptome auf einer einzelnen Website auftreten.
Bei separatem Hosting können Ausfälle isoliert werden. Bei Multisite steht und fällt alles mit der gemeinsamen Basis. Das ist kein theoretisches Problem: Serverfehler, Speicherlimits bei gleichzeitigen Zugriffen oder Datenbank-Deadlocks bei großen Netzwerken führen regelmäßig zu kompletten Ausfällen, die sich nur schwer auf einzelne Websites eingrenzen lassen.
Backup, Wiederherstellung und Hosting-Anforderungen
Backups bei Multisite sind aufwändiger als gedacht. Eine vollständige Sicherung umfasst die gemeinsame Dateistruktur plus die gesamte Datenbank mit allen Websitetabellen. Die Wiederherstellung einer einzelnen Website aus diesem Gesamtpaket ist technisch komplex und fehleranfällig – sie erfordert das Extrahieren bestimmter Tabellen aus der Gesamtdatenbank, wobei Abhängigkeiten zu zentralen Konfigurationen erhalten bleiben müssen.
Die Hosting-Anforderungen steigen merklich. Multisite-Netzwerke benötigen mehr Arbeitsspeicher, da alle Websites denselben PHP-Prozess teilen. Bei Traffic-Spitzen auf einer Website leiden die anderen mit. Datenbank-Optimierung wird zur kontinuierlichen Aufgabe, weil eine wachsende Datenbank alle Websites ausbremst. Managed Hosting für Multisite kostet deutlich mehr als vergleichbare Pakete für Einzelinstallationen, und nicht jeder Provider unterstützt die Konfiguration überhaupt. Wer die technischen Grundlagen verstehen will, findet im Artikel Gutes Hosting für die Unternehmenswebsite weitere Orientierungshilfen.
Domain-Mapping und URL-Strukturen: Mehr Aufwand als gedacht
Multisite ohne Domain-Mapping zeigt Unterwebsites als Subdomains oder Unterverzeichnisse – etwa `marke2.hauptdomain.de` oder `hauptdomain.de/marke2`. Für eigenständige Marken ist das unbrauchbar. Domain-Mapping leitet eigene Domains auf die einzelnen Websites um, erfordert aber zusätzliche Konfiguration, SSL-Zertifikatsverwaltung und DNS-Einstellungen.
Die URL-Struktur wirkt sich auf SEO aus. Suchmaschinen bewerten Subdomains oft als eigenständige Domains, während Unterverzeichnisse die Autorität der Hauptdomain stärken. Diese Abwägung muss bewusst getroffen werden, nicht nachträglich korrigiert werden.
Performance-Aspekte bei gemeinsamer Datenbank
Die gemeinsame Datenbank ist der Flaschenhals jeder Multisite. Cache-Plugins müssen zwischen den Websites unterscheiden können, Datenbankabfragen werden komplexer, und die Tabellen wachsen mit jeder zusätzlichen Website. Bei zehn Websites mit je 50 Plugins entsteht eine Konfigurationsmatrix, die kaum noch überschaubar ist.
Datenbank-Optimierungsplugins, die bei Einzelinstallationen zuverlässig arbeiten, können in Multisite-Umgebungen Daten anderer Websites beeinflussen oder gar löschen. Performance-Tuning erfordert spezialisiertes Wissen, das in der Regel extern eingekauft werden muss.
Benutzerverwaltung und Rollen: Weniger flexibel als erwartet
Die zentrale Benutzerverwaltung klingt vorteilhaft, schränkt aber die Autonomie ein. Ein Benutzer, der auf Website A Administrator ist, kann auf Website B nur eine eingeschränkte Rolle erhalten – die Vergabe erfolgt zentral, nicht durch die einzelnen Website-Verantwortlichen. Das funktioniert bei hierarchischen Strukturen, nicht aber bei gleichberechtigten Marken oder kooperierenden Organisationen.
Benutzer, die auf mehreren Websites aktiv sein sollen, müssen explizit für jede Website freigeschaltet werden. Die Rollenverwaltung über das Netzwerk hinweg wird schnell unübersichtlich und ist fehleranfällig bei der Rechtevergabe.
Migration zurück zu Einzelinstallationen: Der Ausstieg ist aufwändig
Wer Multisite einmal gewählt hat und zurückkehren will, steht vor einem erheblichen technischen Aufwand. Die Migration erfordert das Extrahieren einzelner Websitetabellen aus der Gesamtdatenbank, die Neuinstallation aller Plugins und Themes in der korrekten Version, die Anpassung von URLs und Pfaden sowie die Überprüfung aller internen Verlinkungen. Benutzerkonten müssen übertragen, Passwörter zurückgesetzt, Mediadateien neu zugeordnet werden.
Dieser Aufwand übersteigt bei weitem die Einsparungen bei der initialen Einrichtung. Multisite ist technisch gesehen eine Einbahnstraße, die nur mit erheblichem Ressourceneinsatz verlassen werden kann. Wer vor der Entscheidung steht, sollte daher die Testumgebung sorgfältig nutzen – ein Thema, das im Beitrag Testumgebungen beim Relaunch: Warum sie wichtig sind vertieft wird.
Entscheidungskriterien: Checkliste für die Praxis
Vor der Wahl einer Multisite-Architektur sollten Unternehmer folgende Fragen beantworten:
- Sind alle Websites technisch identisch in Funktionalität und Design?
- Gibt es eine zentrale, alleinverantwortliche Verwaltung ohne dezentrale Anpassungswünsche?
- Ist die gemeinsame Benutzerbasis ein zwingendes Geschäftsanforderung?
- Sind alle benötigten Plugins explizit als multisite-kompatibel dokumentiert?
- Ist das Hosting auf Multisite ausgelegt und budgetiert?
- Existiert ein Notfallplan für die Wiederherstellung einzelner Websites?
- Ist der Ausstieg in Einzelinstallationen als kostenintensives Risiko eingeplant?
Bei auch nur einer verneinenden Antwort spricht mehr dagegen als dafür. Die vermeintliche Effizienz zentraler Verwaltung wird durch erhöhte Komplexität bei Fehlersuche, eingeschränkte Plugin-Auswahl und das zentrale Ausfallrisiko teuer erkauft.
Multisite bleibt ein Spezialwerkzeug für spezifische Anwendungsfälle, kein Standardansatz für die Mehrheit der Unternehmen. Die pragmatische Alternative – separate Installationen mit professionellem Update-Management – bietet mehr Flexibilität, geringeres Risiko und langfristig niedrigere Gesamtkosten.
Wer unsicher ist, welche Architektur zum eigenen Szenario passt, kann die konkrete Situation durch einen neutralen Vergleich der Möglichkeiten klären lassen.
