Die meisten Anleitungen zur Installation von WordPress Multisite fangen am falschen Ende an. Sie beginnen wp-config.php, sagen dir, wo du eine Konstante einfügen sollst, und behandeln das Netzwerk wie ein technisches Upgrade.
Das ist verkehrt herum.
Multisite ist eine architektonische Entscheidung. Es kann die Steuerung, die Veröffentlichung und die Wartung der Plattform vereinfachen. Es kann aber auch dazu führen, dass nicht miteinander verbundene Websites an ein einziges Betriebsmodell, einen einzigen Bereitstellungspfad und eine einzige Ausfalldomäne gebunden werden. Die Installation dauert nur wenige Minuten. Mit dieser Entscheidung muss man jedoch jahrelang leben.
Table of Contents
Das ist wichtig, weil WordPress selbst in enormem Umfang genutzt wird. WordPress betreibt 43,5 % aller Websites weltweit, und im März 2025 gab es etwa 1,19 Milliarden Websites im Netz – deshalb bleibt Multisite für Unternehmen relevant, die mehrsprachige, domänenübergreifende oder standortübergreifende Webauftritte auf dem marktbeherrschenden CMS betreiben (Pantheons WordPress-Statistikübersicht). Die Funktion ist ausgereift. Die größere Frage ist, ob es dein Unternehmen auch ist.
Wann man WordPress Multisite nutzen sollte und wann man es vermeiden sollte
Teams greifen oft auf Multisite zurück, obwohl sie eigentlich eine bessere Steuerung brauchen und keine gemeinsame Architektur. Das sind zwei verschiedene Probleme.
Nutze Multisite, wenn du viele Websites innerhalb einer einzigen, kontrollierten Plattform betreiben musst. Das eignet sich in der Regel für Franchise-Unternehmen, Universitäten, Agenturen, Publisher-Netzwerke und Unternehmensgruppen mit wiederkehrenden Website-Mustern, gemeinsamen Authentifizierungsanforderungen, einheitlichen Designsystemen und einer zentralisierten Plugin-Verwaltung. WordPress Multisite wurde genau für diese Größenordnung entwickelt. Ein Netzwerk kann mehrere Websites aus einer einzigen Installation heraus hosten, und manche Organisationen betreiben „Hunderte oder sogar Tausende“ von Websites in einem einzigen Netzwerk (Fellowship über WordPress Multisite).
Verzichte darauf, wenn die Seiten nur in einer Präsentation ähnlich aussehen. Wenn Geschäftsbereiche separate Release-Zeitpläne, unterschiedliche Plugin-Stacks, eigenständige Hosting-Entscheidungen, eine strikte rechtliche Trennung oder die Freiheit brauchen, vom gemeinsamen Theme-System abzuweichen, wird Multisite zum Hindernis.
Anzeichen für eine gute Passform
- Zentrale Verwaltung ist wichtig: Ein Plattformteam muss Themes, Plugins und die Nutzungsrichtlinien für viele Websites verwalten.
- Die Grundrisse wiederholen sich: Neue Standorte sind Varianten eines genehmigten Entwurfs und keine maßgeschneiderten Bauten.
- Gemeinsame Abläufe sind ein Vorteil: Sicherheits-, Wartungs- und redaktionelle Standards sollten zentral durchgesetzt werden.
- Eine Expansion ist zu erwarten: Teams, die regionale Markteinführungen planen oder skalierbare Microsites erstellen, profitieren oft von einem wiederverwendbaren Netzwerkmodell.
Signale für eine schlechte Passform
- Jede Website verhält sich wie ein eigenständiges Produkt: Eigenständige Roadmaps und maßgeschneiderte Integrationen erfordern in der Regel separate Installationen.
- Die Autonomie der Plugins ist entscheidend: Multisite schränkt diese Freiheit von Grund auf ein.
- Die Organisation ist politisch dezentralisiert: Technische Zentralisierung überlebt das Chaos in der Führung meist nicht.
- Die Datentrennung ist eine zwingende Voraussetzung: Getrennte Installationen sind oft sowohl betrieblich als auch vertraglich übersichtlicher.
Faustregel: Wenn dein Team mehr Wert auf gemeinsame Kontrolle als auf gemeinsame Komfortfunktionen legt, könnte Multisite passen. Wenn es zwar gemeinsame Komfortfunktionen will, aber überall lokale Ausnahmen erwartet, ist das in der Regel nicht der Fall.
Für Unternehmensteams, die vor der Entwicklung fachliche Unterstützung bei der Abwägung dieser Vor- und Nachteile benötigen, sind WordPress-Lösungen für Unternehmen oft hilfreicher als eine weitere Checkliste für die Einrichtung.
Die entscheidenden Unterbereiche vs. Unterverzeichnisse
Die erste wichtige Entscheidung bei einer Multisite-Installation betrifft nicht den Code, sondern die URL-Struktur.
Die meisten Tutorials gehen darüber nur flüchtig hinweg, obwohl diese Entscheidung langfristig zu Problemen bei der Migration führen kann, wenn man sich falsch entscheidet. Auch die offiziellen Lernmaterialien von WordPress lassen hier eine Lücke. Den Teams wird zwar gezeigt, wie man das Netzwerk aktiviert, aber nicht, wie sie beurteilen können, ob die Wahl zwischen einer permanenten Subdomain oder einem Unterverzeichnis zu ihrem Betriebsmodell passt (Lektion zur Einrichtung von WordPress.org Multisite).
Was ändert sich bei den einzelnen Strukturen?
| Aufbau | Besser, wenn | Meistens schwieriger, wenn |
|---|---|---|
| Subdomains | Die Websites brauchen eine klarere Abgrenzung, unterschiedliche Veröffentlichungsrhythmen oder letztendlich eigene Domains | DNS, SSL-Planung und Einrichtung der Umgebung |
| Unterverzeichnisse | Die Websites stehen unter einer übergeordneten Marke und sollten sich wie Bereiche einer einheitlichen Plattform anfühlen | Zukünftige Trennung, Domänenänderungen und einige Migrationsmuster |
Unterverzeichnisse sorgen dafür, dass alles übersichtlich unter einer übergeordneten Marke zusammengefasst ist. Das ist für ein zentrales Marketingteam oft übersichtlicher. Außerdem reduziert es den Aufwand für die anfängliche DNS-Koordination und vereinfacht in der Regel die erste Einführung.
Subdomains sorgen für klarere Abgrenzungen. Sie sind oft die sicherere Wahl für Unternehmensnetzwerke, in denen jede Region, Abteilung oder jeder Geschäftsbereich mittlerweile eine eigene Identität benötigt – auch wenn hinter den Kulissen alles zentral verwaltet wird.
Auswirkungen auf SEO und die Marke
Diese Entscheidung ist nie nur technischer Natur.
Unterverzeichnisse sind in der Regel sinnvoll, wenn die übergeordnete Domain die Marke ist und jede Website dazu dient, diese Marke zu stärken. Länderseiten, Content-Hubs für Geschäftsbereiche oder Kampagnenbereiche können in diesem Modell gut funktionieren, wenn die Steuerung streng ist und die User Journey einheitlich gestaltet ist. Teams, die die Website-Struktur auf dieser Ebene durchdenken, sollten in diesem Leitfaden zum SEO-Potenzial von URLs in der Website-Navigation auch prüfen, wie sich Navigation und URL-Gestaltung auf die Auffindbarkeit auswirken.
Subdomains sind dann sinnvoller, wenn jede Website als relativ eigenständig wahrgenommen werden soll. Ein Franchise-Netzwerk, ein Partnerprogramm oder ein regional autonomer Betrieb profitiert oft von dieser Trennung. Das sorgt später für übersichtlichere Strukturen bei der Domain-Zuordnung und weniger umständliche Kompromisse, wenn sich die Websites weiterentwickeln.
Entscheide dich für Unterverzeichnisse, wenn es sich um eine Marke mit vielen Bereichen handelt. Entscheide dich für Subdomains, wenn es sich um eine Plattform mit vielen Identitäten handelt.
Teams unterschätzen die operativen Folgen
Subdomains bedeuten mehr Arbeit an der Infrastruktur. Du musst dir Gedanken über das Verhalten von Platzhaltern, die SSL-Abdeckung und die Auflösung neuer Websites machen, bevor die Redakteure überhaupt das Dashboard nutzen können.
Unterverzeichnisse scheinen beim Start einfacher zu sein, können aber teuer werden, wenn eine Website später auf eine eigene Domain umziehen oder aus dem Netzwerk ausgegliedert werden muss. Das sind die versteckten Kosten, die die meisten Schnellstartanleitungen außer Acht lassen.
Ein nützlicher Test ist folgender: Frag dich, ob eine Website in den nächsten Jahren vielleicht eine eigene Marke, eine eigene Domain oder eine halbwegs unabhängige Verwaltung brauchen könnte. Wenn die Antwort „Ja“ lautet, sind Subdomains in der Regel der sicherere Ausgangspunkt. Wenn die Antwort „Nein“ lautet und das Unternehmen eine streng einheitliche Webpräsenz anstrebt, bewähren sich Unterverzeichnisse oft besser auf lange Sicht.
Vorbereitung deiner Hosting- und DNS-Umgebung
Eine Multisite-Einführung scheitert schon lange bevor WordPress versagt. Sie scheitert an der DNS-Konfiguration, der Zertifikatsplanung, falschen Annahmen zum Caching und einer schlechten Wahl des Hosting-Anbieters.
Wenn dieses Netzwerk für den Produktivbetrieb gedacht ist, betrachte die Hosting-Ebene als Teil des Anwendungsdesigns. Behandle sie nicht wie eine technische Infrastruktur, um die du dich später kümmern wirst.
Was „Produktionsreife“ eigentlich bedeutet
Für ein professionelles Netzwerk muss die Umgebung eine wiederholbare Bereitstellung, kontrollierte Implementierungen und ein vorhersehbares Routing-Verhalten unterstützen. Das bedeutet, dass sich dein Infrastruktur-Team und dein WordPress-Team darüber einigen sollten, wie Domains, Zertifikate, Weiterleitungen, Cache-Ebenen und Staging-Umgebungen funktionieren, bevor das Netzwerk aktiviert wird.
Mangelhafte Planung führt oft dazu, dass viele Projekte aus dem Ruder laufen. Entwickler können WordPress Multisite zwar korrekt installieren, aber wenn DNS-Einträge, Zertifikatsabdeckung und das Verhalten des Reverse-Proxys nie geplant wurden, wird der Start der ersten Live-Domain zu einer ganzen Kette von Support-Anfragen.
Checkliste vor der Installation
- Entscheide dich für einen Hosting-Anbieter, der sich mit WordPress auskennt: Ein generisches Shared-Hosting-Angebot ist die falsche Grundlage für ein Netzwerk, das mehrere Marken oder Märkte unterstützen soll.
- Plane das Verhalten von Platzhaltern frühzeitig ein: Wenn du Subdomains verwendest, muss die Infrastruktur die Art und Weise unterstützen, wie neue Websites aufgelöst werden.
- Leg fest, wer für SSL zuständig ist: Entscheide, ob die Zertifikate vom Host, vom Plattformteam oder von einem externen Betriebsteam verwaltet werden.
- Kompatibilität der Umleitung prüfen: Die Regeln für Apache oder Nginx müssen mit der Art und Weise übereinstimmen, wie WordPress die Netzwerkseiten weiterleitet.
- Trenne die Staging-Umgebung von den Erwartungen an die Produktionsumgebung: Ein Staging-Netzwerk sollte das Domain- und Cache-Verhalten so genau widerspiegeln, dass Probleme beim Start aufgedeckt werden, bevor sie die Nutzer erreichen.
Die Inszenierung ist kein optionaler Schritt
Ein Multisite-Staging-Setup dient nicht nur zum Testen von Code. Hier überprüfst du den gesamten Prozess – von der Erstellung der Website über die Zuweisung der Domain bis hin zur sicheren Bereitstellung. Ohne das wird dein erster echter Launch zum Testfall.
Teams, die das noch nicht formell geregelt haben, sollten zumindest nach einem klaren Staging-Prozess vorgehen, damit DNS-Annahmen, die SSL-Einrichtung und die Reihenfolge der Bereitstellung unter kontrollierten Bedingungen getestet werden.
Wenn dein Hosting-Team sagt: „Die Domain-Zuordnung können wir nach der Installation regeln“, dann setz das Projekt erst mal auf Eis. Bei Infrastruktur-Korrekturen nach der Installation fangen sonst auch noch so gut durchdachte Multisite-Pläne an, chaotisch zu werden.
Was du klären solltest, bevor du dich an WordPress wagst
| Fläche | Entscheidung zum Lockdown |
|---|---|
| Domains | Welche Websites werden zuerst die Netzwerk-URLs verwenden, und welche werden unter den zugeordneten Domains starten? |
| Zertifikate | Wie SSL-Zertifikate im Netzwerk ausgestellt, erneuert und validiert werden |
| Caching | Ob Cache-Regeln standortübergreifend gelten oder standortbezogen sind |
| Umgebungen | Wie Staging, Vorproduktion und Produktion mit zugeordneten Domains umgehen |
| Support-Modell | Wer ist verantwortlich für DNS-Änderungen, Einführungszeiträume und Rollback-Entscheidungen? |
Eine stabile Multisite-Installation hängt weniger von der define() Zeile ab, als oft angenommen wird. Die Herausforderung besteht darin, die Umgebung so vorhersehbar zu gestalten, dass jeder Start einer neuen Website dem gleichen Betriebsmuster folgt.
Aktivieren und Konfigurieren des WordPress-Netzwerks
Die eigentliche Installation ist unkompliziert. Auf die Reihenfolge kommt es an.
Eine WordPress-Multisite-Installation erfolgt in zwei Phasen. Zuerst aktivierst du die Funktion, indem du define('WP_ALLOW_MULTISITE', true); zu wp-config.phphinzufügst. Nutze anschließend „Extras“ → „Netzwerk-Setup“, um die Netzwerkstruktur auszuwählen und den endgültigen Code zu generieren, der sowohl für wp-config.php und .htaccess (MultilingualPress-Installationsanleitung).
Beginne mit einem Backup und einer sauberen Admin-Sitzung. Deaktiviere Plugins, bevor du das Netzwerk aktivierst. Das reduziert Störungen während der Einrichtung und vermeidet die Fehlersuche bei Plugin-Verhalten, das nichts mit Multisite selbst zu tun hat.
Phase eins: Aktivierung der Funktion
Bearbeiten wp-config.php und füge Folgendes hinzu:
define('WP_ALLOW_MULTISITE', true);
Füge dies oberhalb der Zeile ein, die lautet /* That's all, stop editing! */.
Diese Zeile erstellt das Netzwerk nicht von selbst. Sie macht den Bildschirm „Netzwerk-Einrichtung“ im WordPress-Adminbereich sichtbar, damit die Anwendung den Rest der Konfiguration basierend auf der von dir gewählten Struktur generieren kann.
Phase zwei: Erstellen der Netzwerkkonfiguration
Geh im Admin-Bereich zu „Extras“ → „Netzwerk-Einrichtung“.
Wähle „Subdomains“ oder „Unterverzeichnisse“ aus, gib den Netzwerktitel und die Admin-Daten ein und lass WordPress die erforderlichen Snippets generieren. Du erhältst einen Block für wp-config.php und einen weiteren für .htaccess.
Die generierten Regeln sind keine reine Dekoration. Sie sagen WordPress, wie es Netzwerk-Anfragen erkennen, korrekt weiterleiten und mit der umgeschriebenen URL-Struktur umgehen soll, auf der das Netzwerk basiert.
Hier ist der Arbeitsablauf, der zuverlässig funktioniert:
- Erste Sicherung: Dateien und Datenbank.
- Plugins deaktivieren: Vor allem alles, was mit Weiterleitungen, Sicherheit oder Seiten-Caching zu tun hat.
- Füge die Multisite-Konstante hinzu: Speichern
wp-config.php. - Führe die Netzwerkeinrichtung durch: Wähle das URL-Modell, für das du dich bereits entschieden hast.
- Füge den generierten Code sorgfältig ein: Füge jeden Block in die richtige Datei ein.
- Melde dich erneut an: WordPress aktualisiert die Berechtigungen und stellt die neue Netzwerkschnittstelle bereit.
Ein Video-Leitfaden kann hilfreich sein, wenn du deine Vorgehensweise mit einem visuellen Einrichtungsablauf vergleichen möchtest:
Häufige Fehler bei der Installation
- Plugins aktiv lassen: Das führt oft zu Fehlalarmen bei der ersten Anmeldung nach der Umstellung.
- Code an der falschen Stelle einfügen:
wp-config.phpund.htaccesserfüllen unterschiedliche Aufgaben. Vermische sie nicht. - Vorhandene Rewrite-Regeln ignorieren: Wenn die Website bereits benutzerdefiniertes Serververhalten hatte, füge die Regeln sorgfältig zusammen, anstatt sie blind zu überschreiben.
- Die Aktualisierung der Anmeldung als Fehler betrachten: Eine erneute Authentifizierung nach der Einrichtung ist zu erwarten.
Was der generierte Code tut
Die hinzugefügten wp-config.php Werte teilen WordPress mit, dass die Website nun ein Netzwerk ist, und legen fest, wie sich dieses Netzwerk verhalten soll. Die .htaccess Regeln kümmern sich um die URL-Umschreibung, damit Anfragen die richtige Seite innerhalb des Netzwerks erreichen.
Du musst dir nicht jede Anweisung merken, aber du musst die Reihenfolge und die Dateigrenzen beachten. Die meisten fehlgeschlagenen Installationen passieren, weil jemand den richtigen Codeausschnitt an die falsche Stelle kopiert oder die Struktur generiert hat, bevor die Entscheidung zur Infrastruktur feststand.
Das Netzwerk-Admin-Dashboard beherrschen
Schon am ersten Tag nach der Installation zeigt sich, ob das Netzwerk ordentlich bleiben wird.
Ein Super-Admin meldet sich an, öffnet „Meine Seiten“ und sieht eine neue Steuerungsebene. Das ist der Punkt, an dem Multisite aufhört, eine reine Einrichtungsaufgabe zu sein, und zu einem Betriebsmodell wird.
Prioritäten am ersten Tag
Die erste Aufgabe besteht nicht darin, weitere Sites zu erstellen. Es geht darum, festzulegen, was Site-Admins tun dürfen.
Erstelle die anfängliche Site-Struktur. Füge eine oder zwei repräsentative Sites hinzu, nicht zwanzig. Installiere nur die Themes und Plugins, die das Netzwerk unterstützen kann. Entscheide, welche Plugins netzwerkweit aktiviert werden und welche für die lokale Aktivierung auf den einzelnen Seiten verfügbar sind. Wenn du diesen Governance-Schritt überspringst, werden Redakteure und Kundenadministratoren das Netzwerk wie eine normale WordPress-Einzelseiten-Installation behandeln, und du wirst den nächsten Monat damit verbringen, vermeidbare Ausnahmen zu beheben.
Ein disziplinierter Ablauf am ersten Tag sieht so aus:
- Erstelle die Basis-Websites: Hauptmarke, eine regionale Website, eine Test-Website.
- Schränke den Plugin-Katalog ein: Installiere nur das, was das Netzwerk zu unterstützen bereit ist.
- Lege Benutzerrollen bewusst fest: Trenne die Befugnisse des Super-Admins sofort von denen des Seiten-Admins.
- Überprüfe die Registrierungseinstellungen: Lass keine offenen Möglichkeiten zur Erstellung von Seiten oder Benutzern, es sei denn, das ist beabsichtigt.
Das Dashboard verändert die Verteilung der Verantwortlichkeiten
Bei einer Standardinstallation kann sich jeder Seitenadministrator souverän fühlen. In Multisite ist diese Souveränität nur teilweise gegeben.
Der Netzwerk-Admin ist zuständig für die Plugin-Installation, die Verfügbarkeit von Themes und die allgemeinen Benutzerrichtlinien. Site-Admins verwalten Inhalte, Menüs, Widgets und lokale Konfigurationen im Rahmen der ihnen zugewiesenen Berechtigungen. Diese Aufteilung ist sinnvoll, wenn sie dokumentiert ist. Sie führt zu Chaos, wenn sie nur stillschweigend vorausgesetzt wird.
Ein stabiles Multisite-Netzwerk bietet weniger Freiheiten als eine lose Ansammlung einzelner Websites. Das ist ein Vorteil, kein Nachteil.
Ein praktisches Governance-Modell
Ein nützliches Modell besteht darin, das Netzwerk wie ein Plattformprodukt zu behandeln:
| Rolle | Besitzt |
|---|---|
| Super-Admin | Core-Updates, Themes, Plugin-Übersicht, Netzwerkeinstellungen |
| Webseitenadministrator | Inhalte, Medien, Menüs, Aktivierung lokaler Plugins, sofern zulässig |
| Plattformleiter | Standards, Startgenehmigungen, Freigaberichtlinien |
| Redaktionelle Schwerpunkte | Taxonomien, Arbeitsabläufe, Qualität der Inhalte |
Diese Struktur hilft Agenturen und Unternehmensteams dabei, den häufigsten Fehler bei Dashboards zu vermeiden. Sie installieren Multisite, um alles zu zentralisieren, und vergeben dann Berechtigungen, die wieder zu einer Fragmentierung führen.
Eine weitere Gewohnheit, die man von Anfang an beibehalten sollte, ist die Namensgebung. Website-Slugs, Zuständigkeiten für Admin-E-Mails, Umgebungsbezeichnungen und Domain-Pläne sollten alle einem einheitlichen Muster folgen. Tun sie das nicht, wird selbst ein technisch einwandfreies Netzwerk schwer zu prüfen und zu betreuen.
SSL-Domainzuordnung und Veröffentlichung von Live-Websites
An dieser Stelle sind die meisten Installationsanleitungen nicht mehr hilfreich.
Das Netzwerk einzurichten ist einfach. Das, was wirklich zählt, ist, echte Websites auf echten Domains zu starten – ohne fehlerhafte Weiterleitungen, Zertifikatsprobleme, Cache-Verwirrung oder SEO-Schäden. Für Agenturen und Unternehmensteams besteht die größte Herausforderung nicht nur darin, Multisite zu aktivieren. Es geht darum, es sicher über verschiedene Märkte und Domains hinweg in Betrieb zu nehmen – einschließlich DNS, SSL, Cache-Isolierung und Migrationsplanung (Pagely zum Betrieb von WordPress Multisite).
Domain-Mapping ist ein Einführungsprozess und kein einfaches Ankreuzen eines Kästchens
Sobald das Netzwerk eingerichtet ist, müssen für jede Live-Website noch eigene Domain-Einstellungen vorgenommen werden. In der Praxis bedeutet das, dass die Domain auf die richtige Umgebung verweisen muss, die zugeordnete Website innerhalb des Netzwerks korrekt zugewiesen sein muss und SSL vor dem Start gültig sein muss.
Das klingt einfach, bis mehrere Teams beteiligt sind. Die Marketingabteilung ist für die Markendomain zuständig. Die IT-Abteilung kümmert sich um das DNS. Der Host stellt die Zertifikate bereit. Das WordPress-Team aktualisiert die Website-Einstellungen. Wenn diese Schritte nicht in der richtigen Reihenfolge abgearbeitet werden, geht es am Tag der Veröffentlichung schnell drunter und drüber.
Eine wiederholbare Startreihenfolge
Erstelle die Website in der Netzwerkverwaltung
. Erstelle die Website zunächst mit einer temporären Netzwerk-URL. Überprüfe das Theme, die Plugins und die Inhaltsstruktur, bevor du die Live-Domain einbindest.Bereite die benutzerdefinierte Domain
vor. Die Domain sollte so eingerichtet sein, dass sie auf die Umgebung verweist, in der das Netzwerk gehostet wird. Plane keine Zeitfenster für den Content-Freeze ein, solange die Eigentumsverhältnisse nicht geklärt sind.Weise die zugeordnete Domain der Website
zu. Verbinde im Netzwerk die gewünschte Domain mit der richtigen Website. Vergewissere dich, dass du nicht die falsche Domain einer ähnlich benannten Unterseite zuordnest.SSL vor dem öffentlichen Start
einrichten Eine zugeordnete Domain ohne gültiges HTTPS ist noch nicht startbereit. Der Zertifikatsstatus sollte überprüft werden, bevor die Weiterleitungen umgestellt werden.Teste auch Szenarien abseits des „Happy Paths
“: Überprüfe das Frontend, den Admin-Login, Medien-URLs, das kanonische Verhalten, Formularaktionen und alle fest codierten Verweise, die noch auf die temporäre Netzwerk-URL verweisen.
Fehler bei der Domain-Zuordnung sind selten auf WordPress selbst zurückzuführen. Sie entstehen dadurch, dass Teams die DNS-, SSL- und Anwendungseinstellungen in der falschen Reihenfolge ändern.
Eine bestehende eigenständige Website ins Netzwerk migrieren
Das ist der Aspekt, der oft unterschätzt wird. Eine eigenständige Website hat bereits eine Vorgeschichte. Sie verfügt über indexierbare URLs, Weiterleitungsregeln, Plugin-Annahmen, fest programmierte Assets und ein Bereitstellungsmodell, das darauf ausgelegt ist, eigenständig zu funktionieren.
Entscheide vor der Migration, ob die Website aus Governance-Gründen oder nur aus Bequemlichkeitsgründen in das Netzwerk integriert wird. Wenn es nur um Bequemlichkeit geht, behalte sie separat. Die Integration einer bestehenden Website in Multisite führt zu Abhängigkeiten bei URLs, Domains und im Betrieb, die begründet sein sollten.
Eine praktische Checkliste für die Migration:
- Überprüfung von Inhalten und Medien: Stelle sicher, dass beim Import die Struktur und die Verweise erhalten bleiben.
- Plugin-Prüfung: Manche Plugins verhalten sich in Multisite anders oder müssen auf Netzwerkebene verwaltet werden.
- Umleitungsplan: Alte Wege dort erhalten, wo es darauf ankommt.
- Überprüfung von „Suchen und Ersetzen“: Erkenne Probleme mit Umgebungs-URLs, Medienverweisen und serialisierten Daten.
- Definition von „Rollback“: Mach dich mit den Begriffen „Abbruch“ und „Revert“ vertraut, bevor du den Live-Verkehr umschaltest.
SSL und Cache-Isolation erfordern eine explizite Zuordnung
Die SSL-Bereitstellung wird schwieriger, wenn das Netzwerk viele Domains mit unterschiedlichen Startterminen hostet. Jemand muss die Verantwortung für die Ausstellung von Zertifikaten, die Nachverfolgung von Verlängerungen und die Validierung übernehmen. Wenn diese Person nicht benannt wird, wird der Projektmanager ungewollt zum Zertifikatskoordinator.
Auch die Cache-Isolation spielt eine Rolle. Die Cache-Logik einer Website sollte kein unerwartetes Verhalten bei einer anderen Website auslösen, die andere Cookies, Lokalisierungsregeln oder andere Verhaltensmuster bei angemeldeten Nutzern aufweist. Wenn der Host oder die Caching-Ebene das Netzwerk zu pauschal behandelt, kann die Fehlerbehebung in einem Markt Auswirkungen auf einen anderen haben.
Die Checkliste für den Start, die Zeit spart
| Überprüfen | Was du überprüfen solltest |
|---|---|
| Domain-Auflösung | Die zugeordnete Domäne erreicht die vorgesehene Umgebung |
| HTTPS | Das Zertifikat ist gültig und es treten keine Probleme mit gemischten Inhalten auf |
| Administratorzugriff | Redakteure können sich über den richtigen Domain-Pfad anmelden |
| Weiterleitungen | Alte URLs und bevorzugte Canonical-Links verhalten sich wie erwartet |
| Vermögenswerte | Medien, Skripte und Formulare werden von der richtigen Domain geladen |
Die reibungslosesten Multisite-Einführungen gelingen dann, wenn die Domain-Zuordnung als kontrollierter Freigabeprozess behandelt wird und nicht als eine Einstellung, die man erst am Ende umschaltet.
Leistung, Sicherheit und Skalierung deines Netzwerks
Das Schwierige an Multisite fängt erst nach der Installation an.
Ein Netzwerk verändert das Betriebsmodell von WordPress. Leistungsprobleme sind nicht mehr lokal begrenzt. Sicherheitsentscheidungen sind nicht mehr auf einzelne Websites beschränkt. Jede Ausnahme, die du für eine Marke, eine Region oder einen Kunden zulässt, bedeutet zusätzlichen Aufwand für das Team, das für den Rest des Netzwerks verantwortlich ist.
Leistungsausfälle bleiben selten auf sich beschränkt
Ein Plugin, das nicht richtig funktioniert, ein ressourcenintensives Abfragemuster oder ein Massenimport können die Leistung des Admin-Bereichs auf mehreren Seiten beeinträchtigen. Bei einer reinen Präsentationsseite ist das nur ein Ärgernis. In einem Netzwerk mit aktiven Redakteuren, Kampagnen-Traffic und geplanten Veröffentlichungen wird es jedoch zu einem Betriebsvorfall.
Plane von Anfang an eine gemeinsam genutzte Infrastruktur ein. Das bedeutet in der Regel persistentes Objekt-Caching, sorgfältig festgelegte Regeln für den Seiten-Cache, kontrolliertes Cron-Verhalten und die Überwachung von Abfragen in der Staging-Umgebung, bevor irgendetwas im Netzwerk aktiviert wird. Es bedeutet auch, sich die wirtschaftlichen Aspekte von Plugins ehrlich vor Augen zu führen. Ein Plugin, das auf einer einzelnen Website akzeptabel ist, kann zu kostspielig werden, wenn es auf Dutzende von Websites und Tausende von Anfragen angewendet wird.
Ein Skalierungsansatz, der sich in der Produktion bewährt, umfasst in der Regel:
- Zentrale Plugin-Freigabe: Behandle jedes Plugin als Plattformabhängigkeit mit Auswirkungen auf Support, Updates und Rollbacks.
- Website-spezifische Cache-Regeln: Berücksichtigen von Cookies, Anmeldestatus, Sprachvarianten und domänenspezifischem Verhalten.
- Steuerung von Hintergrundaufgaben: Stelle Importe, Synchronisierungsaufgaben und die Suchindexierung in eine Warteschlange oder begrenze sie, damit eine Arbeitslast die anderen nicht ausbremst.
- Ein eng gefasstes Thema und ein einheitlicher Standard: Weniger unterstützte Muster beschleunigen das Testen, die Veröffentlichungen und die Reaktion auf Vorfälle.
- Grundsätze der Datenbankwartung: Automatisch geladene Optionen, verwaisten Tabellen und übergroße Protokolle werden mit der Zeit zu einer netzwerkweiten Belastung.
Sicherheit beginnt mit der Gestaltung der Berechtigungen
Die Sicherheit von Multisite-Systemen wird meist eher durch schlechte Verwaltung untergraben als durch einen ausgeklügelten Angriff. Der Super-Admin-Zugriff ist das offensichtliche Risiko, aber eine schlampige Rollenvergabe verursacht genauso viele Probleme. Redakteure erhalten Berechtigungen, die sie eigentlich nicht haben sollten. Seitenadministratoren richten Workarounds ein, die gegen die Richtlinien verstoßen. Agenturen übergeben ein Netzwerk ohne klares Berechtigungsmodell, und sechs Monate später kann niemand mehr erklären, wer was tun darf.
Lege die Grenzen frühzeitig fest. Beschränke den Super-Admin-Zugriff auf die kleine Gruppe, die für Plattformänderungen zuständig ist. Lege fest, welche Themes und Plugins überhaupt verfügbar sind. Überprüfe die Regeln für Datei-Uploads, das Registrierungsverhalten, die API-Freigabe und jeglichen benutzerdefinierten Code, der Website-Grenzen überschreitet. Auch die Protokollierung ist wichtig. Wenn das Netzwerk nicht sagen kann, wer eine Einstellung geändert, ein Plugin aktiviert oder eine Website erstellt hat, verlangsamt sich die Reaktion auf Vorfälle schnell.
Auch die Sicherheitswerkzeuge müssen zur Architektur passen. Ratenbegrenzung, Malware-Scans, WAF-Regeln und Audit-Protokollierung sollten unter Berücksichtigung der Domain-Zuordnung und der Eigentumsverhältnisse bei mehreren Standorten konfiguriert werden – und nicht einfach nur angehängt, als handele es sich um eine einzige, einfache Installation.
Backups sind nur dann sinnvoll, wenn die Wiederherstellung dem Netzwerkmodell entspricht
Viele Teams behaupten, sie hätten Backups, dabei haben sie in Wirklichkeit nur ein Häkchen beim Anbieter gesetzt und keinen getesteten Wiederherstellungspfad.
Bei einem Multisite-Setup muss man sich mit schwierigeren Fragen auseinandersetzen. Kannst du einen Standort wiederherstellen, ohne die anderen zu beeinträchtigen? Kannst du Medien, Tabellen und zugeordnete Domänen-Einstellungen für eine einzelne Immobilie nach einer fehlgeschlagenen Bereitstellung wiederherstellen? Wie lange dauert eine vollständige Netzwerkwiederherstellung, und wer genehmigt sie, wenn sich mehrere Geschäftsbereiche denselben Stack teilen?
Teams, die für die Verwaltung von WordPress-Seiten in mehreren Umgebungen zuständig sind, stellen meist fest, dass die Wiederherstellung des Designs wichtiger ist als die Sicherung des Brandings. Schreib dir die Wiederherstellungspfade auf. Teste sie. Unterscheide dabei zwischen der Vorgehensweise bei einem Fehler im Inhalt einer einzelnen Seite und einem netzwerkweiten Ausfall.
Bei der Skalierung geht es genauso sehr um Zurückhaltung wie um Infrastruktur
Gesunde Netzwerke wachsen nicht dadurch, dass man bei jeder Ausnahme „Ja“ sagt. Sie wachsen dadurch, dass man Abweichungen im Griff behält.
Verwende einen Freigabeprozess, bei dem gemeinsam genutzte Komponenten vor der Einführung getestet werden. Überprüfe inaktive Websites und archiviere diejenigen, die keine geschäftliche Funktion mehr erfüllen. Verfolge, welche Anpassungen langfristige Supportkosten verursachen. Wenn eine Website ungewöhnliche Plugins, Hosting-Einstellungen oder redaktionelle Arbeitsabläufe benötigt, überlege dir noch einmal, ob sie überhaupt ins Netzwerk gehört.
Die leistungsstärksten Multisite-Umgebungen haben einige Gemeinsamkeiten:
- Strenge Änderungskontrolle für Einstellungen auf Netzwerkebene
- Kleine, bewährte Plugin-Auswahl
- Nachweis der Eigentumsrechte für Domains, SSL, Caching und DNS
- Klare Ein- und Austrittsverfahren für die Standorte
- Regelmäßige Überprüfungen auf ungenutzte Immobilien, veraltete Vorschriften und die schleichende Ausweitung von Befugnissen
Multisite eignet sich für die Plattform eines großen Unternehmens oder einer Agentur. Es kann aber auch dazu führen, dass sich Risiken auf eine einzige Codebasis, eine einzige Datenbankebene und ein einziges Governance-Modell konzentrieren. Teams, die damit erfolgreich sind, behandeln das Netzwerk wie ein Produkt mit Standards, Verantwortlichen und operativer Disziplin.
Wenn du gerade überlegst, ob Multisite die richtige Architektur für dich ist, oder wenn du Hilfe brauchst, um ein bestehendes Netzwerk in eine stabile Betriebsplattform umzuwandeln, unterstützt IMADO WordPress-Projekte, die fachliche Expertise in den Bereichen Multisite, mehrsprachige Einführung, Governance, Migrationsplanung und laufende Wartung erfordern.
