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 untermauert.
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 großen 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 – Einrichtung eines Multisite-Netzwerks
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 nativ Unterverzeichnisse, Subdomains oder vollständig benutzerdefinierte Domains verwenden.
Mythos 4: „Alle Seiten teilen sich eine Datenbanktabelle.“
Realität: Jede Seite in einem Multisite-Netzwerk erhält ihren eigenen Satz von Tabellen (wie wp_2_posts, wp_2_options usw.). Nur wenige Tabellen – wie die Seitenregistrierung und Benutzer – werden geteilt.
Quelle: Learn WordPress – Multisite-Datenbanktabellen
Fazit: Seiten sind auf Tabellenebene isoliert, nicht alle zusammengeworfen.
Mythos 5: „Plugins und Themes müssen überall aktiv sein.“
Realität: Multisite ermöglicht es, einmal zu installieren und dann zu wählen:
- Network Activate für alle Seiten
- Aktivieren für Seiten-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 große Unternehmen.“
Realität: Multisite hilft jedem, der mehrere verwandte Seiten verwaltet – sei es ein Universitätsnetzwerk, eine SaaS-Plattform oder eine Marketingagentur, die Kunden betreut. Die Größe 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 Seiten verwalten.
Fazit: Richtig konfiguriertes Multisite kann die Angriffsflächendrift über viele Seiten hinweg reduzieren.
Mythos 8: „Multisite skaliert nicht.“
Realität: WordPress.com, Edublogs und große 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-Seite.
Beispiele aus der Praxis für WordPress Multisite in Aktion
| Organisation / Netzwerk | Anwendungsfall | Anmerkungen |
|---|---|---|
| WordPress.com | Globale Blogging-Plattform | Betreibt Millionen einzelner Seiten auf einem einzigen Multisite-Netzwerk. |
| BBC America | Unterhaltungsnetzwerk | Jede Show-Seite 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 innerhalb des NYT-Multisite-Netzwerks. |
| Cheapflights | Lokalisierte Inhalte | Verwaltet mehrere länderspezifische Seiten in einer Codebasis. |
| Universitätsnetzwerke | Abteilungen und Kurse | Viele Hochschulen betreiben hunderte von Abteilungsseiten 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 Seiten 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 Subseiten ausgelöst werden.
- Speicherlecks und übermäßige Objekterstellung in Schleifen oder Hooks wie
init. - Option-Tabellen-Aufblähung und automatisch geladene Daten, die jede Anfrage verlangsamen.
- Einzelseiten-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 Seite.
- Verwenden Sie persistentes Objekt-Caching (Redis oder Memcached).
- Vermeiden Sie große 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 – Leistung auf großen Seiten verbessern,
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 Seite 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 Seite in ihrem eigenen Silo leben muss.
Abschließende Gedanken
WordPress Multisite ist eine der am meisten missverstandenen und dennoch leistungsstärksten Funktionen in WordPress. Es ist im großen Maßstab bewiesen von großen Marken, Universitäten und SaaS-Anbietern. Mit richtigem Caching, Plugin-Governance und Tests bietet es unübertroffene Effizienz für die Verwaltung vieler Seiten 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