Verwaltung von 100+ Websites mit WordPress Multisite

Eine Handvoll Websites zu verwalten ist einfach. Über 100 Websites für einen globalen Konzern oder ein Franchise-Netzwerk zu verwalten ist ein logistisches Problem, es sei denn, Sie nutzen die richtige Architektur. Auch 2026 ist WordPress Multisite der eingebaute Weg, eine große Flotte von Websites aus einer einzigen WordPress-Installation zu betreiben.

So planen, steuern und skalieren Sie ein Netzwerk mit 100 Websites.

Die kurze Antwort: WordPress Multisite funktioniert 2026 weiterhin sehr gut, wenn Sie zentrale Kontrolle, gemeinsamen Code und einheitliche Governance über viele Websites brauchen. Die falsche Wahl ist es, wenn Sie strikte Datenisolierung, grundlegend unterschiedliche Infrastruktur pro Website oder volle Autonomie für jedes Team benötigen.

Mehr zur WordPress-Entwicklung für Unternehmen bei WPPoland.

#100 WordPress-Websites über eine Codebasis aktualisieren

Der Hauptvorteil von Multisite: Sie verwalten eine einzige Core-Codebasis. Alles Weitere in diesem Leitfaden baut darauf auf.

#Zentrale Updates

Wenn ein Sicherheitspatch erscheint, spielen Sie ihn einmal auf Netzwerkebene ein, und der neue Code ist im selben Moment auf allen 100 Websites aktiv. Bei 100 separaten Installationen bedeutet derselbe Patch 100 Update-Durchläufe, und jede Website, die wartet, bleibt länger angreifbar.

In dieser Größenordnung zählt ein Detail: Ein Core-Update kann auch das Datenbankschema ändern. Der Code ist gemeinsam, aber jede Website hat ihre eigenen Tabellen, deshalb fordert WordPress Sie nach einem Core-Update auf, Netzwerk aktualisieren auszuführen. Das Handbuch zur Netzwerkverwaltung beschreibt es so: Die Funktion “geht jede Website durch, jeweils fünf auf einmal, und stellt sicher, dass alle Datenbankänderungen angewendet werden” (eigene Übersetzung). Deaktivierte Websites werden übersprungen und erhalten ihr Update, wenn sich nach der Reaktivierung ein Administrator dieser Website anmeldet.

#Gemeinsame Bibliothek

Themes und Plugins werden geteilt. Wenn Sie die Markenfarben des Unternehmens aktualisieren möchten, ändern Sie ein Theme, und die Änderung erscheint auf allen regionalen Websites, die es nutzen.

Gemeinsame Ressourcen verwalten:

• Unternehmens-Theme: ein Parent-Theme, Varianten pro Marke als Child-Themes
• Kern-Plugins: SEO, Sicherheit, Cache und Analytics, einmal vom Super Admin installiert
• Must-use-Plugins: Dateien in mu-plugins laden auf jeder Website und lassen sich nicht pro Website deaktivieren

#Markenkonsistenz und ihre Grenze

Schriften, Farben und Abstände, die in der theme.json des Themes definiert sind, gelten für jede Website, die das Theme nutzt. Die Grenze ist die Datenbank: Das Handbuch hält fest, dass “Stiländerungen im Website-Editor nur einzelne Websites betreffen” (eigene Übersetzung), weil sie in den Tabellen der jeweiligen Website gespeichert werden. Wenn Ihnen Markenkonsistenz wichtig ist, halten Sie das Designsystem in Theme-Dateien unter Versionskontrolle und schränken Sie ein, wer im Website-Editor Stile bearbeiten darf.

#WordPress-Multisite-Netzwerk einrichten

Das offizielle Verfahren ist kurz, und die Anleitung Create a Network legt die Reihenfolge fest:

1. Sichern Sie Datenbank und Dateien, prüfen Sie, ob sprechende Permalinks funktionieren, und deaktivieren Sie alle aktiven Plugins.
2. Wenn WordPress aus einem eigenen Verzeichnis läuft, richten Sie das ein, bevor Sie Multisite aktivieren.
3. Fügen Sie define( 'WP_ALLOW_MULTISITE', true ); in wp-config.php oberhalb der Zeile ein, die das Bearbeiten beendet. Damit erscheint Werkzeuge > Netzwerk-Einrichtung.
4. Wählen Sie im Bildschirm Netzwerk-Einrichtung Subdomains oder Unterverzeichnisse und installieren Sie.
5. Fügen Sie die von WordPress erzeugten Zeilen in wp-config.php und .htaccess ein und melden Sie sich erneut an.

Das Handbuch zur Netzwerkadministration ergänzt einen Punkt, der auf modernen Stacks Zeit spart: WordPress kann Rewrite-Regeln für Apache und IIS erzeugen, “aber keine Nginx-Konfiguration generieren” (eigene Übersetzung). Unter Nginx schreiben Sie die Multisite-Regeln selbst, anhand der dokumentierten Beispiele.

Auf der Kommandozeile erledigt WP-CLI dieselbe Umstellung mit wp core multisite-convert: Der Befehl legt die Multisite-Tabellen an und ergänzt die Konstanten in wp-config.php. Für ein domainbasiertes Netzwerk fügen Sie --subdomains hinzu.

#Multisite mit Subdomains oder Unterverzeichnissen

Die Wahl entscheidet, wie die URLs der Websites aussehen und was der Server unterstützen muss. Die Anleitung zur Vorbereitung des Netzwerks nennt die Regeln:

Ein Netzwerk lässt sich gar nicht anlegen, wenn die WordPress-Adresse einen anderen Port als 80 oder 443 nutzt. Ein späterer Wechsel des Typs ist möglich, aber aufwendig: Das Ändern von SUBDOMAIN_INSTALL und der Rewrite-Regeln “migriert keine bestehenden Website-Adressen und konfiguriert weder DNS, virtuelle Hosts, TLS-Zertifikate, Weiterleitungen noch Cookies” (eigene Übersetzung). Für einen Plan mit 100 Websites entscheiden Sie das einmal und testen es auf Staging.

#WordPress Multi-Network und Datenbank-Sharding

Für Organisationen, die über ein einzelnes Netzwerk hinausgewachsen sind, gruppieren Multi-Network-Setups Websites in mehrere Netzwerke innerhalb einer Installation. Der Core unterstützt das Datenmodell, die Verwaltungsoberfläche stammt jedoch aus Plugins wie WP Multi Network.

#Regionale Gruppierung

Sie können ein Netzwerk für Europa, eines für Amerika und eines für den asiatisch-pazifischen Raum betreiben, alles innerhalb einer Installation. Jedes Netzwerk hat eigene Einstellungen und eine eigene Liste netzwerkweit aktivierter Plugins.

In WP-CLI hat jedes Netzwerk eine numerische ID. wp site create --network_id=2 fügt dem zweiten Netzwerk eine Website hinzu, und wp site list --network=2 listet nur dessen Websites auf.

#Sharding mit einem db.php-Drop-in

Damit die Datenbank nicht zum Flaschenhals wird, verteilt ein db.php-Drop-in wie HyperDB die Tabellen der Websites auf mehrere Datenbankserver und leitet Lesezugriffe an Replikate weiter.

Sharding-Strategien:

• Nach Region: Jedes regionale Netzwerk hat einen eigenen Datenbankserver
• Nach Volumen: Websites mit viel Traffic erhalten dedizierte Server
• Hybrid: eine Mischung aus beidem, je nach gemessener Last

#Was gemeinsam ist und was pro Website

Das Handbuch zur Netzwerkadministration ergänzt außerdem, dass das netzwerkweite Aktivieren eines Plugins “nicht ändert, wo das Plugin seine Daten speichert” (eigene Übersetzung). Ob Einstellungen netzwerkweit oder pro Website gelten, hängt davon ab, wie das jeweilige Plugin geschrieben ist. Prüfen Sie das, bevor Sie ein Plugin für das Netzwerk freigeben.

#SSO und Benutzerrollen in WordPress Multisite

Bei 100 Websites haben Sie wahrscheinlich Hunderte Benutzer. Diese können Sie nicht manuell verwalten.

#SSO-Integration

Verbinden Sie Ihre Multisite mit einem Identity Provider wie Okta oder Microsoft Entra ID (früher Azure AD). Wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Zugriff auf alle 100 Websites an einer Stelle entzogen. Das schließt die Lücke verwaister Konten, ein häufiger Einstiegsweg in alte Websites.

#Kontrollen für den Super Admin

Legen Sie fest, welche Websites welche Plugins aktivieren dürfen. Ein regionales Marketingteam sollte kein riskantes Plugin installieren dürfen, das das gesamte Netzwerk lahmlegen könnte. Einen Teil davon erzwingt WordPress standardmäßig: In einem Netzwerk “können Website-Administratoren keine neuen Themes oder Plugins installieren und die Profile der Benutzer ihrer Website nicht bearbeiten” (eigene Übersetzung). Das kann nur der Super Admin.

Empfohlene Rollenhierarchie:

Eigene Rollen, etwa ein SEO-Manager mit Zugriff nur auf Meta-Felder, sind mit einem Rollen-Plugin oder per Code möglich, und sie werden pro Website definiert.

#Plugin-Zugriff für Website-Administratoren

Standardmäßig sehen Website-Administratoren den Plugins-Bildschirm überhaupt nicht. Der Bildschirm Netzwerk-Einstellungen enthält unter Menü-Einstellungen eine Option, die ihn freischaltet. Selbst dann können Website-Administratoren nur Plugins aktivieren oder deaktivieren, die der Super Admin installiert hat; netzwerkweit aktivierte Plugins erscheinen als Netzwerkweit aktiviert und lassen sich nicht deaktivieren.

Ein Plugin kann außerdem Network: true in seinem Header angeben, was es zu einem reinen Netzwerk-Plugin macht.

#Themes pro Website

Ein Theme netzwerkweit freizuschalten stellt keine Website darauf um. Es macht das Theme nur verfügbar. Ein Theme lässt sich auch für eine einzelne Website freischalten, im Bildschirm Website bearbeiten, Tab Themes. Neue Websites erhalten das neueste Standard-Theme, es sei denn, Sie setzen WP_DEFAULT_THEME in wp-config.php auf den Ordnernamen Ihres Unternehmens-Themes, was bei jeder neuen Website einen manuellen Schritt spart.

#Inhalte in einem WordPress-Multisite-Netzwerk syndizieren

Websites in einem Netzwerk teilen standardmäßig keine Inhalte. Das Handbuch vergleicht ein Netzwerk mit “einer Miniversion von WordPress.com” (eigene Übersetzung) und verweist für das Teilen auf Plugins. Planen Sie Syndizierung als Funktion, die Sie ergänzen, nicht als eine, die Sie mitgeliefert bekommen.

#Eine Ankündigung auf jeder Website veröffentlichen

Mit Broadcast-Plugins veröffentlichen Sie eine globale Unternehmensankündigung einmal und kopieren sie auf alle 100 Websites. Typische Kandidaten sind Pressemitteilungen, Produkt-Updates, Sicherheits- und Compliance-Hinweise sowie saisonale Kampagnen.

#Globale Suche

Nutzen Sie Elasticsearch (über ElasticPress), um eine Suchleiste bereitzustellen, die Inhalte auf jeder Website im gesamten Netzwerk findet. Die native WordPress-Suche fragt die Tabellen einer einzigen Website ab.

#Inhalte anderer Websites lesen

Jede Website stellt ihre eigene REST API bereit, sodass eine Hub-Website Beiträge regionaler Websites über HTTP abrufen kann. In PHP lassen switch_to_blog() und restore_current_blog() den Code direkt die Tabellen einer anderen Website lesen. So funktionieren die meisten Syndizierungs-Plugins.

#Performance-Checkliste für WordPress Multisite mit über 100 Websites

#Redis für Multisite

• Schlüssel pro Website: Der Object Cache bildet seine Schlüssel mit der Website-ID, sodass sich Websites nicht gegenseitig den Cache überschreiben
• Globale Gruppen: Benutzer und Netzwerkoptionen werden einmal für das Netzwerk gecacht
• Speicher-Warnungen: Eine große Website kann den gemeinsamen Cache füllen

#Upload-Limits pro Website

Die Netzwerk-Einstellungen steuern auch den Speicherplatz. Standardmäßig ist der Upload-Speicher jeder Website auf 50 MB und die maximale Dateigröße beim Upload auf 1500 KB begrenzt, beides lässt sich ändern. Erlaubte Dateitypen sind eine Liste für das ganze Netzwerk; ein dort ergänzter Typ “funktioniert NICHT” (eigene Übersetzung), wenn er nicht zusätzlich über den Filter upload_mimes erlaubt ist. Bei 100 Websites legen Sie diese Limits bewusst fest, statt sie bei jeder Beschwerde anzuheben.

#WordPress Multisite mit WP-CLI und CI/CD automatisieren

#Automatisierte Deployments

In einem Netzwerk mit über 100 Websites skalieren manuelle Deployments nicht:

• CI/CD-Pipeline: Jede Code-Änderung durchläuft automatisierte Tests auf Staging
• Schrittweiser Rollout: Wenn Sie mehrere Netzwerke oder Installationen betreiben, liefern Sie zuerst an die kleinste Gruppe aus
• Rollback: Halten Sie das vorherige Release bereit, um es wiederherzustellen

#WP-CLI im großen Maßstab

WP-CLI ist das wichtigste Werkzeug, um ein Netzwerk von der Kommandozeile aus zu betreiben. Die folgenden Befehle stammen aus der offiziellen WP-CLI-Befehlsreferenz:

# Core einmal aktualisieren, dann das Datenbank-Update auf jeder Website ausführen
wp core update
wp core update-db --network

# Ein Plugin für das ganze Netzwerk aktivieren
wp plugin activate my-plugin --network

# Ein Plugin nur auf jeder Website von Netzwerk 2 aktivieren
wp site list --network=2 --field=url | xargs -I {} wp plugin activate my-plugin --url={}

# Veröffentlichte Beiträge pro Website zählen
wp site list --field=url | while read url; do
  echo "$url $(wp post list --post_type=post --post_status=publish --format=count --url="$url")"
done

#Befehle für den Lebenszyklus einer Website

Archivieren und Deaktivieren lassen sich rückgängig machen, und die Netzwerkverwaltung behandelt Archivieren in der Praxis wie Deaktivieren. Spam macht eine Website für alle unerreichbar. Löschen entfernt die Website, deshalb skripten Sie es mit --keep-tables, solange Sie kein geprüftes Backup haben.

#Monitoring und Warnungen pro Website

Jede Website im Netzwerk braucht eigene Warnungen:

• Uptime pro Website (die Hauptwebsite kann laufen, während eine Unterwebsite ausgefallen ist)
• Core Web Vitals pro Website
• PHP-Fehler pro Website (ein auf einer Website aktiviertes Plugin kann nur dort Fehler verursachen)
• Datenbankwachstum pro Website

#Eigene Domain für eine Multisite-Website einrichten

Domain-Mapping ist laut der Anleitung zum Domain-Mapping seit WordPress 4.5 nativ. Die Schritte:

1. Richten Sie das DNS der Domain auf den Server und parken Sie sie auf der Hauptdomain des Netzwerks.
2. Installieren Sie für jede Domain ein TLS-Zertifikat; die Anleitung empfiehlt SNI für die zusätzlichen Domains.
3. Öffnen Sie in der Netzwerkverwaltung den Bereich Websites, bearbeiten Sie die Website und setzen Sie Website-Adresse (URL) auf die vollständige Domain, zum Beispiel https://example.com.
4. Wenn Anmeldungen mit einem Cookie-Fehler scheitern, fügen Sie define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); in wp-config.php ein.

Bei 100 Marken auf 100 Domains wird die Erneuerung der Zertifikate zur wiederkehrenden Aufgabe, also automatisieren Sie sie auf dem Server.

#Wann man Multisite nicht verwenden sollte

Multisite ist nicht immer die Antwort. Das Handbuch selbst warnt: Wenn Sie Websites planen, die in enger Verbindung “Daten oder Benutzer teilen”, ist “ein Multisite-Netzwerk möglicherweise nicht die beste Lösung” (eigene Übersetzung). Verzichten Sie darauf, wenn:

1. Besondere Anforderungen: Website A braucht eine völlig andere Serverkonfiguration oder eine andere PHP-Version als Website B.
2. IP-Reputation: Wenn eine Website im Netzwerk als Spam-Quelle gilt, kann das den Ruf aller anderen Websites auf derselben IP beeinträchtigen. Das betrifft vor allem Websites, die auf zuverlässige E-Mail-Zustellung angewiesen sind.
3. Datenisolierung: Ein Kunde verlangt aus rechtlichen Gründen, dass seine Daten in einer völlig getrennten Datenbank liegen.
4. Autonomie der Teams: Jedes Team muss eigene Plugins auswählen und installieren können.
5. Eine dominante Website: Eine Website trägt den Großteil des Traffics und braucht eine eigene Infrastruktur.

#Alternativen zu Multisite

#Schritt für Schritt zu WordPress Multisite migrieren

#Phase 1: Audit

• Bestandsaufnahme aller bestehenden Websites
• Analyse der genutzten Plugins und Themes und ob jedes davon in Multisite funktioniert
• Anforderungen an Daten und Isolierung
• Integrationen pro Website

#Phase 2: Architektur

• Netzwerkstruktur (ein Netzwerk oder mehrere)
• Subdomain oder Unterverzeichnis, einmal entschieden
• Datenbankstrategie
• Rollen und Berechtigungen

#Phase 3: Umsetzung

• Multisite-Umgebung auf Staging
• Migration der Inhalte Website für Website
• SSO und Governance
• Cache und CDN

#Phase 4: Optimierung

• Lasttests
• Feinabstimmung von Cache und Datenbank
• Schulung für Netzwerk-Administratoren
• Schriftliche Runbooks für Updates und neue Websites

Das Handbuch warnt, dass der Umzug einer Multisite “komplizierter ist als der Umzug einer Einzelinstallation” (eigene Übersetzung). Testen Sie den Migrationsweg deshalb auf Staging, bevor Sie die Produktion umstellen.

#Fazit

WordPress Multisite ist ein starkes Werkzeug für alle, die eine Flotte von Websites betreiben. Es verbindet die Effizienz einer zentralen Verwaltung mit der Flexibilität einer dezentralen Inhaltserstellung.

Wenn Sie von 10 auf 100 oder 1000 Websites skalieren möchten, ist die korrekte Architektur Ihrer Multisite vom ersten Tag an die wichtigste technische Entscheidung, die Sie treffen werden.

Wer eine Flotte regionaler Seiten plant, entscheidet die Multisite-Architektur am Anfang, nicht nachträglich. Wenn Sie diese Entscheidung nicht allein treffen wollen, sehen Sie sich an, wie wir WordPress-Projekte technisch begleiten.

#Weiterführende Ressourcen

• WordPress-Entwicklung
• WordPress-Geschwindigkeitsoptimierung
• WordPress-Sicherheitsaudit
• WordPress-Wartung
• WooCommerce-Entwicklung
• WPPoland kontaktieren