Zum Hauptinhalt springen
How Can We Help?
< All Topics

Multisite betreibt mehrere Websites mit einer Codebasis und einer Datenbank. Das spart Wartungsaufwand, schafft aber gemeinsame Risiken.

Architektur

  • Eine WordPress-Installation, ein Satz Plugins und Themes.
  • Pro Site eigene Tabellen (wp_2_posts, wp_2_options …), gemeinsam: wp_users, wp_usermeta, wp_site, wp_blogs, wp_sitemeta.
  • Subdomain- oder Unterverzeichnis-Modus; eigene Domains per Domain-Mapping (seit 4.5 im Core).
  • Neue Rolle Super Admin mit Netzwerk-weiten Rechten. Normale Administratoren dürfen standardmässig keine Plugins installieren und kein ungefiltertes HTML (unfiltered_html) speichern.

Wann Multisite passt

  • Viele gleichartige Sites (Filialen, Sprachversionen, Kursseiten) mit identischem Plugin-Set.
  • Zentrale Benutzerverwaltung ist gewünscht.
  • Ein Team betreut alles, die Sites gehören derselben Organisation.

Wann nicht

  • Sites mit unterschiedlichen Eigentümern oder Kunden: Ein kompromittiertes Plugin betrifft alle Sites, eine Datenbank enthält alle Daten.
  • Stark unterschiedliche Plugin-Anforderungen.
  • Getrennte Hosting- oder Backup-Anforderungen pro Site. Einzelne Sites zu restoren oder herauszulösen ist aufwendig.

Sicherheit und Betrieb

  • Blast Radius: Eine Schwachstelle trifft das ganze Netzwerk. Plugin-Auswahl entsprechend streng halten.
  • Super Admins minimieren und mit 2FA schützen.
  • Updates gelten netzwerkweit: Staging für das gesamte Netzwerk ist Pflicht.
  • WP-CLI über alle Sites: wp site list --field=url | xargs -I % wp --url=% cache flush
  • Persistenten Object Cache (Redis) einsetzen; Multisite profitiert besonders.

Alternative: getrennte Installationen mit Automatisierung

Mit Composer, Git-Deployments und WP-CLI-Aliasen lassen sich viele Einzelinstallationen fast genauso effizient pflegen, bei besserer Isolation. Für Agenturen mit Kundensites ist das meist die bessere Wahl.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: