WordPress Multisite-Mythen — entlarvt
WordPress Multisite hat alles betrieben, von persönlichen Blog-Netzwerken bis hin zu massiven Publishing-Plattformen wie WordPress.com. Doch selbst nach mehr als einem Jahrzehnt im Kern halten sich Mythen darüber. Lassen Sie uns Fakten von Fiktion trennen — mit realen Beispielen und Daten, die es untermauern.
Mythos 1: «Multisite ist langsam.»
Realität: Multisite kann genauso schnell sein wie eine einzelne WordPress-Installation — vorausgesetzt, Sie befolgen dieselben Best Practices. Die Geschwindigkeit hängt von Caching, Abfragen und Hosting-Qualität ab, nicht von der Multisite-Funktion selbst.
- Seiten-Caching und persistentes Objekt-Caching (Redis oder Memcached) reduzieren die Datenbanklast drastisch.
- WordPress 6.1+ enthält jetzt Site Health Checks sowohl für Seiten-Cache als auch für Objekt-Cache aufgrund ihrer grossen Auswirkungen auf die Leistung.
Quelle: WordPress Performance Team (Make/Core)
Fazit: Multisite ist nicht langsam — schlechtes Caching oder ineffizienter Code ist es.
Mythos 2: «Multisite ist schwer einzurichten.»
Realität: Es sind nur wenige Schritte nötig:
- Fügen Sie
define('WP_ALLOW_MULTISITE', true);inwp-config.phpein. - Gehen Sie zu Tools → Network Setup.
- Wählen Sie Subdomains oder Unterverzeichnisse.
- Fügen Sie die generierten Regeln ein und melden Sie sich erneut an.
Quelle: Learn WordPress — Setup a Multisite Network
Fazit: Multisite ist nicht «schwer», es ist nur eine einmalige Einrichtung mit einer neuen Admin-Ebene namens Network Admin.
Mythos 3: «Multisite funktioniert nur mit Subdomains oder Unterordnern.»
Realität: Seit WordPress 4.5 ist Domain Mapping im Kern integriert. Sie können jeder Subsite benutzerdefinierte Domains zuweisen, ohne zusätzliche Plugins.
Quelle: WordPress Multisite Dokumentation
Fazit: Sie können Unterverzeichnisse, Subdomains oder vollständig benutzerdefinierte Domains nativ verwenden.
Mythos 4: «Alle Sites teilen sich eine Datenbanktabelle.»
Realität: Jede Site in einem Multisite-Netzwerk erhält ihren eigenen Satz von Tabellen (wie wp_2_posts, wp_2_options usw.). Nur wenige Tabellen — wie die Site-Registrierung und Benutzer — werden geteilt.
Quelle: Learn WordPress — Multisite Datenbanktabellen
Fazit: Sites sind auf Tabellenebene isoliert, nicht alle zusammengeworfen.
Mythos 5: «Plugins und Themes müssen überall aktiv sein.»
Realität: Multisite erlaubt es, einmal zu installieren und dann zu wählen:
- Network Activate für alle Sites
- Aktivieren für Site-Admins, um sie einzeln zu aktivieren
Fazit: Sie kontrollieren den Umfang — global, wenn nötig, lokal, wenn nicht.
Mythos 6: «Multisite ist nur für grosse Unternehmen.»
Realität: Multisite hilft jedem, der mehrere verwandte Sites verwaltet — sei es ein Universitätsnetzwerk, eine SaaS-Plattform oder eine Marketingagentur, die Kunden betreut. Die Grösse spielt keine Rolle; der Bedarf an zentralisierter Verwaltung tut es.
Fazit: Selbst kleine Teams können von gemeinsamen Benutzern, Updates und Plugins profitieren.
Mythos 7: «Multisite ist ein Sicherheitsrisiko.»
Realität: Zentrale Governance verbessert oft die Sicherheit. Multisite fügt eine spezielle Super Admin-Rolle hinzu, die Netzwerkänderungen kontrolliert, während normale Admins nur ihre eigenen Sites verwalten.
Fazit: Richtig konfiguriertes Multisite kann die Angriffsflächendrift über viele Sites hinweg reduzieren.
Mythos 8: «Multisite skaliert nicht.»
Realität: WordPress.com, Edublogs und grosse Medienmarken beweisen das Gegenteil. Die Leistung hängt von Caching, effizienten Plugins und Infrastruktur ab — nicht davon, ob es Multisite ist oder nicht.
Quelle: WordPress Performance Field Guide
Fazit: Die Skalierung eines Multisite-Netzwerks folgt dem gleichen Playbook wie die Skalierung jeder modernen WordPress-Site.
Beispiele aus der Praxis für WordPress Multisite in Aktion
| Organisation / Netzwerk | Anwendungsfall | Anmerkungen |
|---|---|---|
| WordPress.com | Globale Blogging-Plattform | Betreibt Millionen einzelner Sites auf einem einzigen Multisite-Netzwerk. |
| BBC America | Unterhaltungsnetzwerk | Jede Show-Site läuft als Subsite auf einer Multisite-Installation. |
| Edublogs / CampusPress | Bildungsnetzwerke | Hostet Lehrer-, Schüler- und Universitätsblogs unter einer Plattform. |
| The New York Times Blogs | Publishing | Jeder thematische Blog läuft als Subsite im NYT-Multisite-Netzwerk. |
| Cheapflights | Lokalisierte Inhalte | Verwaltet mehrere länderspezifische Sites in einer Codebasis. |
| Universitätsnetzwerke | Abteilungen und Kurse | Viele Hochschulen betreiben hunderte von Abteilungssites auf einem gemeinsamen Multisite. |
Quellen: Elegant Themes, WP Engine, Pantheon und WP Cloud Multisite-Fallstudien.
Die versteckte Gefahr: schlecht geschriebene Plugins
Selbst ein perfekt konfiguriertes Multisite-Netzwerk kann durch schlechte Plugins verlangsamt werden. Da alle Sites dieselbe Plugin-Codebasis teilen, kann ein einziges fehlverhaltendes Plugin die Leistung netzwerkweit beeinträchtigen.
Häufige Probleme durch schlechte Plugins
- Schwere Datenbankabfragen oder nicht indizierte JOINs, die bei jedem Seitenaufruf ausgeführt werden.
- Unkontrollierte Cron-Jobs, die zu oft auf allen Sub sites ausgelöst werden.
- Speicherlecks und übermässige Objekterstellung in Schleifen oder Hooks wie
init. - Option-Table-Aufblähung und automatisch geladene Daten, die jede Anfrage verlangsamen.
- Einzel-Site-Annahmen (hartcodierte Tabellennamen, fehlende
switch_to_blog()-Logik).
So verhindern Sie pluginbedingte Verlangsamungen
- Testen Sie im Staging vor der Netzwerkaktivierung.
- Profilieren Sie Abfragen mit Tools wie Query Monitor oder New Relic.
- Begrenzen Sie die Netzwerkaktivierung — aktivieren Sie Plugins nach Möglichkeit pro Site.
- Verwenden Sie persistentes Objekt-Caching (Redis oder Memcached).
- Vermeiden Sie grosse Autoloads in Optionen und bereinigen Sie alte Daten.
- Prüfen Sie die Plugin-Qualität — achten Sie auf aktive Wartung und Multisite-Unterstützung in der Dokumentation.
Quellen: WPMU DEV — Improve Performance on Large Sites,
Multidots — Multisite Best Practices
Fazit: Schlecht geschriebene Plugins sind der wahre Feind der Leistung — nicht Multisite selbst.
Wann Multisite nicht die richtige Wahl ist
- Sie benötigen völlig unterschiedliche Plugin-/Theme-Stacks pro Site ohne gemeinsamen Code.
- Sie möchten separate Hosting-Umgebungen oder physische Isolation.
- Sie sind auf Nischen-Plugins angewiesen, die nicht Multisite-kompatibel sind.
Faustregel: Multisite glänzt, wenn Sie gemeinsame Governance, Code und Effizienz wünschen — nicht, wenn jede Site in ihrem eigenen Silo leben muss.
Abschliessende Gedanken
WordPress Multisite ist eine der am meisten missverstandenen und dennoch leistungsstärksten Funktionen in WordPress. Es ist im grossen Massstab bewährt von grossen Marken, Universitäten und SaaS-Anbietern. Mit richtigem Caching, Plugin-Governance und Tests bietet es unübertroffene Effizienz für die Verwaltung vieler Sites gleichzeitig.
Anstatt Multisite zu fürchten, umarmen Sie es als das, was es wirklich ist: ein Kraftmultiplikator für Ihr WordPress-Netzwerk.
Quellen: WordPress.org Dokumentation, Learn WordPress, WP Engine, Elegant Themes, WPMU DEV, Multidots, Pantheon und WP Cloud.

Leave a Reply