Ein Multisite-Netzwerk ist eine einzige WordPress-Installation, die mehrere eigenständige Websites (Subsites) über eine gemeinsame Code- und Plugin-Basis verwaltet. Sinnvoll ist dieses Setup, wenn Sie viele ähnliche Sites zentral pflegen wollen, etwa Marken-Portale, Franchise-Netzwerke oder Kundenportale mit einheitlichem Funktionsumfang. Ungeeignet ist Multisite dagegen fast immer dann, wenn Ihre Sites stark unabhängig laufen sollen und eigene Plugin-Versionen, eigene Release-Zyklen oder komplett getrennte Zugriffsrechte brauchen.
Kurz zusammengefasst, wann Multisite passt:
- Viele strukturell ähnliche Websites mit gemeinsamem Design und gemeinsamen Funktionen
- Zentrale Governance ist gewünscht, einzelne Teams brauchen keine volle Plugin-Hoheit
- Updates, Backups und Wartung sollen an einer Stelle gebündelt werden
Wichtige Erkenntnisse
Ein Multisite-Netzwerk lohnt sich dann, wenn zentrale Governance und geteilte Wartung wichtiger sind als vollständige Unabhängigkeit einzelner Sites.
| Thema | Details |
|---|---|
| Definition | Eine WordPress-Installation verwaltet mehrere Subsites mit gemeinsamem Core, aber getrennten Inhalten und Upload-Ordnern. |
| Passende Anwendungsfälle | Franchise-Netzwerke, Bildungseinrichtungen, Agenturen und Marken mit mehreren ähnlichen Sites profitieren am meisten. |
| Größtes Risiko | Ein fehlerhaftes Plugin-Update kann theoretisch alle Sites im Netzwerk gleichzeitig beeinträchtigen. |
| URL-Modell vorab klären | Subdomain braucht Wildcard-DNS, Subdirectory funktioniert ohne zusätzliche DNS-Konfiguration. |
| Vor Aktivierung testen | Backup, Staging-Umgebung und Permalink-Check gehören vor jede Netzwerk-Aktivierung. |
Inhaltsverzeichnis
- Was ist ein Multisite-Netzwerk genau?
- Wie funktioniert ein Multisite-Netzwerk technisch?
- Für wen lohnt sich Multisite? Typische Anwendungsfälle
- Vorteile einer Multisite-Installation
- Nachteile, Risiken und Betriebsfallen
- Subdomain, Subdirectory oder Domain-Mapping: Was passt?
- Technische Voraussetzungen und Checkliste vor der Aktivierung
- Wie aktiviert man Multisite Schritt für Schritt?
- Netzwerkverwaltung: Rollen und Rechte im Überblick
- Plugins und Themes richtig verwalten
- Bestehende Sites in ein Netzwerk migrieren
- Best Practices für den produktiven Betrieb
- Agentur-Perspektive: Wann empfiehlt Werbeeinfach Multisite?
- Quellen
- FAQ
Was ist ein Multisite-Netzwerk genau?
Ein Network ist die übergeordnete Installation, eine Site (auch Subsite genannt) ist eine einzelne Website innerhalb dieses Netzwerks. Jede Subsite hat eigene Inhalte, eigene Nutzer-Zuordnungen und einen eigenen Upload-Ordner, teilt sich aber Core-Dateien, Plugins und Themes mit allen anderen Sites im selben Netzwerk. Das ist der entscheidende Unterschied zwischen Multisite und mehreren separaten WordPress-Installationen: Bei Letzteren pflegen Sie jede Codebasis einzeln, bei Multisite einmal für alle.
Technisch bedeutet das: Ein WordPress-Multisite-Netzwerk ist laut Learn.WordPress.org eine Sammlung von Sites, die dieselbe Installation aus Core, Plugins und Themes nutzen, während jede Subsite eigene Datenbanktabellen für ihre Inhalte erhält. Die Rolle des Super-Admin sitzt über allem und verwaltet das gesamte Netzwerk, während einzelne Site-Admins nur ihre eigene Subsite steuern.
| Element | Geteilt im Netzwerk | Getrennt pro Site |
|---|---|---|
| Core-Dateien | Ja | Nein |
| Plugins und Themes (Dateien) | Ja | Nein |
| Inhalte (Beiträge, Seiten) | Nein | Ja |
| Upload-Ordner | Nein | Ja |
| Nutzerkonten (wp_users) | Ja | Nein |
Zusätzlich legt WordPress beim Aktivieren von Multisite neue globale Tabellen an, etwa wp_blogs, wp_site und wp_sitemeta, dazu für jede Subsite einen eigenen, nummerierten Satz an Inhaltstabellen. Diese Struktur beschreibt die WPMU-Datenbankdokumentation im Detail. Wer die Multisite-Erklärung wirklich verinnerlichen will, sollte sich genau diese Trennung merken: gemeinsamer Code, getrennte Inhalte.
Wie funktioniert ein Multisite-Netzwerk technisch?
Auf Datenbankebene entstehen neue globale Tabellen wie wp_blogs, wp_site und wp_sitemeta, die den Überblick über alle Sites im Netzwerk halten. Jede einzelne Subsite bekommt dazu einen eigenen, durchnummerierten Satz an Tabellen, etwa wp_2_posts oder wp_3_options, während wp_users als einzige Tabelle netzwerkweit geteilt bleibt und dafür zusätzliche Felder für Rollenzuordnungen erhält, so die WPMU-Datenbankdokumentation.
Im Dateisystem sieht es ähnlich aus: Core-Dateien, Plugin-Ordner und Theme-Verzeichnisse liegen einmal zentral vor und werden von allen Sites genutzt. Uploads dagegen landen getrennt, meist unter /wp-content/uploads/sites/2/ für Site 2 und so weiter. Das verhindert, dass Mediendateien unterschiedlicher Sites sich vermischen.
Beim Routing unterscheidet WordPress zwei Modelle: Subdomain-Installationen (site.beispiel.de) und Subdirectory-Installationen (beispiel.de/site). Beide brauchen funktionierende URL-Umschreibung, unter Apache also mod_rewrite und angepasste .htaccess-Regeln, unter nginx entsprechende Server-Block-Anweisungen. Ohne diese Konfiguration bricht das Routing zwischen Netzwerk-Hauptseite und Subsites zusammen, wie die Vorbereitungsdokumentation von WordPress erklärt.
Aktiviert wird das Ganze über eine einzige Konstante in wp-config.php:
define( 'WP_ALLOW_MULTISITE', true );
Danach erscheint im Dashboard unter Werkzeuge der Punkt „Netzwerk-Setup“, über den Sie Subdomain- oder Subdirectory-Struktur festlegen.
Profi-Tipp: Testen Sie die Multisite-Aktivierung immer zuerst auf einer lokalen Umgebung oder einem Staging-Server mit lokalem DNS-Eintrag. Wildcard-Subdomains lassen sich lokal über die hosts-Datei simulieren, bevor Sie echte DNS-Einträge beim Provider anlegen.
Für wen lohnt sich Multisite? Typische Anwendungsfälle
Multisite spielt seine Stärken dort aus, wo viele strukturell ähnliche Sites zentral organisiert werden müssen:
- Bildungseinrichtungen mit Fakultäts- oder Instituts-Websites unter einer Dachmarke
- Franchise-Unternehmen mit Standort-Sites, die dasselbe Design nutzen
- Agenturen, die mehrere Kundenprojekte unter einer Wartungsstruktur bündeln
- Marken mit regionalen Länder- oder Sprachversionen
- SaaS-Anbieter mit Produktportalen für unterschiedliche Kundensegmente
- Interne Kundenportale mit rollenbasiertem Zugriff auf einzelne Bereiche
Ob sich das Modell lohnt, hängt von wenigen Kriterien ab:
- Wie viele Sites entstehen aktuell und in den nächsten zwei bis drei Jahren?
- Wie wichtig ist zentrale Governance gegenüber Autonomie einzelner Teams?
- Brauchen einzelne Sites unterschiedliche Plugin-Versionen oder eigene Update-Zyklen?
- Wie hoch ist das Risiko, dass eine Site durch Traffic-Spitzen die Performance anderer Sites beeinträchtigt?
Wenn Teams unbedingt eigene Plugins installieren oder unabhängig voneinander Releases fahren wollen, ist eine klassische Einzel-Installation pro Site oder ein separates Hosting mit zentraler Design-Bibliothek oft die bessere Wahl. Auch bei sehr unterschiedlichen technischen Anforderungen, etwa wenn eine Site headless über eine API läuft, passt Multisite selten gut.
Vorteile einer Multisite-Installation
Der größte praktische Gewinn liegt in der zentralen Verwaltung: Ein Plugin-Update, ein Theme-Update, ein Sicherheits-Patch, alles läuft einmal für das gesamte Netzwerk statt mehrfach pro Site. Das reduziert Duplikation erheblich und senkt den Wartungsaufwand pro Site messbar.
- Themes und Plugins müssen nur einmal gepflegt und aktualisiert werden
- Konsistentes Branding und einheitliche Templates lassen sich netzwerkweit durchsetzen
- Backups laufen zentral, was Skaleneffekte gegenüber vielen Einzelinstallationen bringt
- Die Betriebskosten pro Site sinken oft, weil Hosting-Ressourcen gemeinsam genutzt werden
- Neue Sites lassen sich innerhalb von Minuten anlegen, ohne komplette Neuinstallation
Für Agenturen, die mehrere Kundenprojekte mit ähnlichem Funktionsumfang betreuen, ist genau dieser Effekt der eigentliche Business Case hinter Multisite.
Nachteile, Risiken und Betriebsfallen
Die zentrale Struktur ist zugleich die größte Schwachstelle: Ein fehlerhaftes Plugin-Update kann theoretisch alle Sites im Netzwerk gleichzeitig lahmlegen, nicht nur eine einzelne. Genau diesen Trade-off beschreibt der Enterprise-Leitfaden von WordPress VIP als zentrales Betriebsrisiko großer Netzwerke.
Zentrale Governance und konsistente Templates sparen Wartungsaufwand, erhöhen aber gleichzeitig das Risiko technischer Schulden und Betriebsstörungen, wenn Observability, Backup und Isolation nicht sauber geplant sind.
Weitere Punkte, die Sie vor der Entscheidung kennen sollten:
- Site-Admins können in der Standardkonfiguration keine eigenen Plugins installieren, das bleibt dem Super-Admin vorbehalten
- Migration einzelner Sites aus dem Netzwerk heraus oder Rollback nach einem fehlgeschlagenen Update ist deutlich komplexer als bei einer Einzelinstallation
- Bei hohem Traffic auf einer Site kann die gemeinsame Datenbank zum Engpass für alle anderen Sites werden
Wer diese Risiken unterschätzt, zahlt den Wartungsvorteil später mit unangenehmen Ausfällen zurück.
Subdomain, Subdirectory oder Domain-Mapping: Was passt?
Bei der Einrichtung müssen Sie sich für eines von zwei URL-Modellen entscheiden, das lässt sich später nur mit Aufwand ändern.
| Modell | Beispiel-URL | Besonderheit |
|---|---|---|
| Subdomain | site.beispiel.de | Braucht Wildcard-DNS-Eintrag beim Hoster |
| Subdirectory | beispiel.de/site | Kein Wildcard-DNS nötig, einfacher bei Shared Hosting |
| Domain-Mapping | eigene-domain.de | Eigene Domain zeigt auf eine Subsite, zusätzliche DNS-Konfiguration |
Subdomain-Installationen wirken auf Suchmaschinen oft wie separate Domains, was bei stark unterschiedlichen Themen zwischen den Sites SEO-Vorteile bringen kann. Subdirectory-Installationen sind technisch schlanker, weil kein Wildcard-DNS-Eintrag nötig ist, das macht sie auf einfacheren Hosting-Paketen leichter umsetzbar.
Wichtige Punkte zur Entscheidung:
- Subdomain erfordert einen Wildcard-DNS-Eintrag (
*.beispiel.de) beim Provider, bevor Sie das Netzwerk-Setup starten - Subdirectory funktioniert meist ohne zusätzliche DNS-Konfiguration, ist aber schwerer nachträglich auf Subdomain umzustellen
- Domain-Mapping, also eigene Domains für einzelne Subsites, verlangt zusätzliche DNS-Einträge pro gemappter Domain und ein SSL-Zertifikat für jede Domain
Diese Grundlagen beschreibt die Vorbereitungsdokumentation von WordPress ausführlich, inklusive der jeweiligen Hosting-Voraussetzungen.
Technische Voraussetzungen und Checkliste vor der Aktivierung
Bevor Sie Multisite aktivieren, sollten folgende Punkte geklärt sein:
- Apache-Server mit aktiviertem
mod_rewrite, alternativ eine funktionierende nginx-Konfiguration mit passenden Server-Block-Regeln - Aktuelle PHP-Version entsprechend den WordPress-Mindestanforderungen und ausreichender Datenbankzugriff für zusätzliche Tabellen
- Bei Subdomain-Struktur: Wildcard-DNS-Eintrag beim Hoster, oft nur mit Root- oder SSH-Zugriff konfigurierbar
- Bei Shared Hosting: Prüfen, ob der Provider Wildcard-Subdomains und Multisite überhaupt unterstützt, viele günstige Tarife schließen das aus
- Vollständiges Backup der bestehenden Installation vor jeder Änderung an
wp-config.php - Staging-Umgebung zum Testen von Permalinks, Login-Verhalten und SSL-Zertifikaten für Subdomains
Diese Server- und Hosting-Checks nennt auch die offizielle Vorbereitungsdokumentation als Grundvoraussetzung, bevor das Netzwerk-Setup überhaupt startet.
Wie aktiviert man Multisite Schritt für Schritt?
Der Ablauf folgt immer demselben Muster, unabhängig davon, ob Sie Subdomain oder Subdirectory wählen:
- Vollständiges Backup von Datenbank und Dateien anlegen, idealerweise auf einer Staging-Kopie testen
- Permalinks prüfen und einmal neu speichern, damit die URL-Struktur sauber funktioniert
WP_ALLOW_MULTISITEinwp-config.phpauftruesetzen- Unter Werkzeuge im Dashboard das Netzwerk-Setup öffnen und Subdomain oder Subdirectory wählen
- Netzwerktitel und Admin-E-Mail-Adresse festlegen
- Die von WordPress generierten Code-Blöcke in
wp-config.phpund.htaccessbeziehungsweise die nginx-Konfiguration einfügen
Die offizielle Anleitung zur Netzwerkerstellung generiert genau diese Regeln automatisch, sobald Sie das Netzwerk-Setup durchlaufen.
Typische Fehlerquellen dabei:
- Vergessene Anpassung der
.htaccess-Datei, was zu 404-Fehlern auf allen Subsites führt - Fehlender Wildcard-DNS-Eintrag bei Subdomain-Struktur, wodurch neue Sites nicht erreichbar sind
- SSL-Zertifikate, die nur die Hauptdomain abdecken, aber nicht die Subdomains einzelner Sites
Ein Minimalbeispiel für die generierte nginx-Regel enthält meist eine Rewrite-Anweisung für wp-content, wp-includes und die dynamischen Site-Pfade, die exakte Syntax liefert WordPress erst nach dem Netzwerk-Setup passend zu Ihrer gewählten Struktur.
Netzwerkverwaltung: Rollen und Rechte im Überblick
Der Super-Admin steht über dem gesamten Netzwerk, verwaltet Themes, Plugins, neue Sites und Nutzerkonten netzwerkweit. Ein Site-Admin dagegen sieht nur seine eigene Subsite, kann dort Inhalte und Design innerhalb der freigegebenen Themes anpassen, aber standardmäßig keine neuen Plugins installieren oder aktivieren.
Nutzerkonten liegen in der gemeinsamen Tabelle wp_users und lassen sich einer oder mehreren Sites zuordnen, mit jeweils unterschiedlichen Rollen. Ein Nutzer kann also auf Site A Redakteur sein und auf Site B gar keinen Zugriff haben.
Für die Sicherheit gilt das Prinzip der geringsten Rechte: Vergeben Sie Super-Admin-Rechte nur an wenige, vertrauenswürdige Personen, da ein kompromittiertes Super-Admin-Konto Zugriff auf das gesamte Netzwerk gewährt. Regelmäßiges Monitoring der Admin-Aktivitäten und aktuelle Wartungsverträge für WordPress helfen, verdächtige Änderungen früh zu erkennen.
Plugins und Themes richtig verwalten
Drei Aktivierungswege stehen zur Verfügung: Network Activate schaltet ein Plugin für alle Sites gleichzeitig frei, Site-spezifische Aktivierung erlaubt einzelnen Sites, ein Plugin selbst ein- oder auszuschalten, und Must-Use Plugins laufen zwangsweise auf allen Sites, ohne dass sie deaktiviert werden können. Welcher Modus passt, hängt vom jeweiligen Plugin ab, wie die Netzwerk-Administrationsdokumentation beschreibt.
Vor dem Einsatz eines Plugins in Multisite lohnt sich eine kurze Kompatibilitätsprüfung:
- Speichert das Plugin Daten pro Site oder geht es fälschlich von einer Einzelinstallation aus?
- Nutzt es eigene Cron-Jobs, die bei vielen Sites gleichzeitig Server-Last erzeugen können?
- Greift es auf externe APIs zu, die möglicherweise pro Domain unterschiedliche Zugangsdaten brauchen?
Testen Sie neue Plugin-Versionen zuerst auf einer einzelnen Site oder in einer Staging-Umgebung, bevor Sie sie netzwerkweit ausrollen. Individuelle Anpassungen lassen sich bei Bedarf auch über eine maßgeschneiderte Plugin-Entwicklung lösen, wenn Standard-Plugins die Multisite-Anforderungen nicht sauber erfüllen.
Bestehende Sites in ein Netzwerk migrieren
Der Grundablauf bei der Migration einer bestehenden Einzel-Site in ein Multisite-Netzwerk folgt diesen Schritten:
- Inhalte, Medien und Nutzerdaten der bestehenden Site vollständig exportieren
- Neue Subsite im Netzwerk anlegen und Basisstruktur einrichten
- Inhalte importieren und alle Medienpfade auf die neue Upload-Struktur prüfen
- Permalinks kontrollieren und Redirects von alten URLs auf die neue Struktur einrichten
Häufige Probleme dabei sind geänderte URLs, die Google-Rankings beeinflussen können, doppelte Nutzerkonten bei der Zusammenführung sowie Bildpfad-Kollisionen, wenn zwei migrierte Sites zufällig gleich benannte Dateien im Upload-Ordner haben. Testen Sie jede Migration zuerst auf einer Staging-Kopie und halten Sie einen vollständigen Rollback-Plan bereit, falls die Live-Migration fehlschlägt.
Best Practices für den produktiven Betrieb
Backups sollten sowohl netzwerkweit als auch pro Site möglich sein, damit sich eine einzelne fehlerhafte Site ohne Downtime für das gesamte Netzwerk wiederherstellen lässt. Bei Performance helfen ein CDN, Object Caching und eine bewusste Isolation ressourcenintensiver Sites, damit eine Traffic-Spitze auf einer Site nicht die anderen ausbremst.
- Testen Sie größere Updates zuerst auf einer Staging-Kopie des gesamten Netzwerks, nicht nur einer einzelnen Site
- Definieren Sie klar, ob Sie zentral oder föderiert verwalten, also wer im Netzwerk welche Entscheidungen trifft
- Planen Sie Observability von Anfang an ein, Enterprise-Netzwerke scheitern selten an der Technik, sondern an fehlender Betriebskapazität
Profi-Tipp: Führen Sie vor jedem größeren Plugin-Update ein Canary-Rollout durch: Aktivieren Sie die neue Version zunächst nur auf einer unkritischen Test-Site im Netzwerk, bevor Sie netzwerkweit ausrollen.
Agentur-Perspektive: Wann empfiehlt Werbeeinfach Multisite?
Bei Werbeeinfach empfehlen wir Multisite dann, wenn der Governance-Bedarf klar über dem Wunsch nach Team-Autonomie liegt und die Betriebsressourcen für zentrale Wartung tatsächlich vorhanden sind. Reine Kostenersparnis beim Hosting ist dagegen selten ein guter Grund, denn die Ersparnis frisst sich schnell wieder auf, wenn Plugin-Konflikte zwischen Sites entstehen.
Ein typisches Projekt aus unserer Praxis: ein Franchise-Portal mit mehreren Standort-Sites, die dasselbe Design, dieselben Formulare und dieselbe Terminbuchung nutzen sollen, aber jeweils eigene lokale Inhalte pflegen. Genau hier spielt Multisite seine Stärke aus, zentrale Updates, konsistentes Branding, geringerer Pflegeaufwand pro Standort.
Kriterien, die wir vor jeder Empfehlung prüfen:
- Wie hoch ist der tatsächliche Governance-Bedarf im Vergleich zur gewünschten Autonomie einzelner Sites?
- Wie oft werden Releases gefahren und wie unabhängig müssen sie voneinander laufen?
- Ist genug Betriebskapazität für Monitoring, Backups und Performance-Isolation vorhanden?
Für Kunden, die Multisite planen, bieten wir Beratung, Migration und laufende Betreuung als WordPress-Agentur an, von der ersten Architekturentscheidung bis zum produktiven Betrieb. Auch bei Event-Netzwerken mit mehreren Standort-Sites lohnt sich ein Blick auf integrierte Lösungen wie die Event-Plattform von Intermedia Solutions, wenn zusätzlich zur Website eine eigene Buchungs- oder Event-App gefragt ist.
Wenn Sie prüfen, ob Multisite zu Ihrem Projekt passt, oder bereits wissen, dass Sie mehrere Sites zentral verwalten wollen, lohnt sich ein Gespräch, bevor Sie die Architektur festlegen. Werbeeinfach unterstützt Sie bei der Entwicklung Ihrer WordPress-Website, egal ob als Multisite-Netzwerk oder als klassische Einzelinstallation, inklusive Migration bestehender Sites und laufender technischer Betreuung danach.
Quellen
Wer tiefer in die Technik einsteigen möchte, findet bei WordPress selbst die verlässlichsten Referenzen:
- Prepare A Network — WordPress Developer Resources
- Learn
- Enterprise Multisite Architecture Guide | WordPress VIP
Diese Links lohnen sich als Lesezeichen, besonders wenn Sie eine Migration oder Ersteinrichtung planen.
FAQ
Ist WordPress noch zeitgemäß für Multisite-Projekte?
Ja, WordPress bleibt eine der aktivsten Content-Management-Plattformen und Multisite ist seit mehreren WordPress-Versionen fester Bestandteil des Cores, wird also aktiv weiterentwickelt und gepflegt.
Ist WordPress Multisite für Anfänger geeignet?
Nein, Multisite verlangt Grundkenntnisse in Server-Konfiguration, DNS und Datenbankstruktur, weshalb sich Einsteiger zunächst mit einer klassischen Einzelinstallation vertraut machen sollten.
Kann ich mehrere Websites mit WordPress zentral verwalten?
Ja, genau dafür ist Multisite gedacht, allerdings lohnt sich der Aufwand erst ab mehreren strukturell ähnlichen Sites mit gemeinsamem Wartungsbedarf.
Wofür braucht man ein Multisite-Netzwerk konkret?
Multisite eignet sich für Franchise-Portale, Bildungseinrichtungen, Agenturen mit mehreren Kundenprojekten und Marken mit regionalen Länderseiten, überall dort, wo zentrale Updates und konsistentes Branding wichtiger sind als volle Unabhängigkeit einzelner Sites.
Was ist der Unterschied zwischen Multisite und mehreren separaten Websites?
Bei Multisite teilen sich alle Sites eine Installation aus Core, Plugins und Themes, während separate WordPress-Installationen jeweils eigene Codebasen haben, die unabhängig voneinander aktualisiert und gewartet werden müssen.
