Wie viele Websites kann ein WordPress-Multisite-Server 2026 hosten?

Ein WordPress-Multisite-Server hat keine allgemeingültige Website-Grenze: Entscheidend sind die gemessenen Lastspitzen, die Bedeutung der einzelnen Websites und die erforderliche Isolation. Bündeln Sie zunächst nur wenig kritische, ähnliche Websites; behandeln Sie Shops, APIs und stark belastete Seiten getrennt, bis Tests eine sichere gemeinsame Nutzung belegen.

Dieser Leitfaden richtet sich an Betreiber mehrerer WordPress-Inhaltsseiten, die eine gemeinsame Hosting-Umgebung erwägen.
Auch technische Verantwortliche von Onlineshops und Teams, die Websites für verschiedene Kunden betreuen, finden hier Kriterien für Ressourcenplanung und Zugriffsgrenzen.

Zuletzt aktualisiert am 22.10.2026. Die Versionsangaben wurden anhand der offiziellen WordPress-Mitteilung zur Sicherheits- und Wartungsversion 7.1.3 geprüft.

Zuerst den Begriff „Website“ festlegen

Eine Domain, eine WordPress-Installation und eine Website innerhalb eines WordPress-Netzwerks sind unterschiedliche Zähleinheiten. Wer nur Domains zählt, kann die technische Last und den Verwaltungsaufwand leicht falsch einschätzen.

Eine Domain kann auf eine eigenständige WordPress-Installation zeigen. Umgekehrt kann ein WordPress-Netzwerk mehrere Websites innerhalb einer gemeinsamen Installation verwalten. Die offizielle Dokumentation zu WordPress Multisite beschreibt diese Netzwerkstruktur und ihre gemeinsamen Verwaltungsfunktionen. Sie ist keine Kapazitätszusage: Die Zahl der Netzwerk-Websites sagt nicht aus, wie viele gleichzeitige Anfragen, Hintergrundaufgaben oder Datenbankänderungen der Server verarbeiten kann.

Vor der Planung sollte deshalb feststehen, was gezählt werden soll:

• Domains: Welche Hostnamen sollen auf die Serverumgebung zeigen?
• Installationen: Wie viele getrennte WordPress-Kerninstallationen werden betrieben?
• Netzwerk-Websites: Wie viele Websites gehören zu einem Multisite-Netzwerk?
• Lastprofile: Welche davon sind überwiegend statisch, welche führen Transaktionen oder regelmäßige Hintergrundaufgaben aus?

Auch die Webserver-Konfiguration ist Teil dieser Zuordnung. Bei Nginx wird die Zuordnung eines Hostnamens unter anderem über server_name geregelt; die Nginx-Dokumentation zu Servernamen erläutert die entsprechenden Regeln. Eine zusätzliche Domain erzeugt also nicht automatisch eine eigene Laufzeitumgebung oder eine eigene Sicherheitsgrenze.

Geringe Last: gemeinsame Ressourcen mit klarer Zuständigkeit

Unternehmensauftritte und kleinere Informationsseiten mit überwiegend lesenden Zugriffen lassen sich häufig gemeinsam verwalten, wenn ihre Anforderungen ähnlich sind. Das bedeutet jedoch nicht, dass sie kostenlos zusätzliche Kapazität erhalten: PHP-Prozesse, Datenbank, Arbeitsspeicher, Plattenplatz und Dateizugriffe werden weiterhin von derselben Maschine bereitgestellt.

Der Nutzen der Zusammenlegung liegt oft zuerst in der Verwaltung. Eine gemeinsame Umgebung kann wiederkehrende Arbeiten wie Aktualisierungen, Konfiguration und Überwachung vereinheitlichen. Der Nachteil ist die größere Reichweite eines Fehlers: Eine misslungene Änderung, ein kompromittiertes Administratorkonto oder ein überlasteter Prozess kann weitere Websites beeinträchtigen, wenn Rechte und Laufzeitumgebung nicht sauber getrennt sind.

Beurteilen Sie daher pro Website mindestens:

• Speicherbedarf für WordPress-Dateien, Medien und Protokolle;
• Datenbankgröße und Wachstum;
• verwendete Plugins und deren geplante Aufgaben;
• Zugriffsmuster zu Spitzenzeiten;
• Wiederherstellungsanforderungen und geschäftliche Bedeutung;
• verantwortliche Personen und deren Administrationsrechte.

Die WordPress-Rollen und Berechtigungen regeln, welche Aktionen Nutzer innerhalb der Anwendung ausführen dürfen. Die Dokumentation zu Rollen und Fähigkeiten ersetzt jedoch keine Dateisystem-, Prozess- oder Betriebssystemrechte. Wer Kunden-Websites zusammenführt, sollte deshalb sowohl die WordPress-Rollen als auch die Rechte außerhalb des Dashboards prüfen.

Inhaltsseiten: Spitzen und Hintergrundaufgaben statt Durchschnitt betrachten

Bei redaktionellen Websites kann der Monatsdurchschnitt unauffällig wirken, während einzelne Vorgänge die Maschine zeitweise stark beanspruchen. Dazu gehören ein plötzlicher Besucherstrom, eine Suche mit vielen Datenbankabfragen, die Verarbeitung hochgeladener Bilder, ein nicht mehr wirksamer Seiten-Cache oder mehrere gleichzeitig fällige geplante Aufgaben.

WordPress kann geplante Aktionen über WP-Cron auslösen. Die WordPress-Dokumentation zu Cron-Aufgaben beschreibt, wie dieser Mechanismus funktioniert. Für die Kapazitätsplanung folgt daraus: Nicht nur die Zahl der Besucher zählt, sondern auch, wann Hintergrundaufgaben starten und ob sie mit redaktionellen oder externen Zugriffsspitzen zusammenfallen.

Erheben Sie eine Ausgangslinie, bevor Sie Seiten zusammenlegen. Beobachten Sie CPU-Auslastung, verfügbaren Arbeitsspeicher, Plattenbelegung, Antwortzeiten, Fehlerprotokolle und Datenbankaktivität. Vergleichen Sie diese Werte während ruhiger Zeiten mit den Zeiträumen, in denen Inhalte veröffentlicht werden oder die Nachfrage erfahrungsgemäß steigt. Ein einzelner Mittelwert kann kurze, aber geschäftskritische Engpässe verdecken.

Seiten-Cache, Objekt-Cache und ein vorgeschaltetes CDN können die Zahl bestimmter Anfragen reduzieren oder statische Inhalte näher an Besucher ausliefern. Wie viel sie bewirken, hängt aber von Cache-Regeln, dynamischen Funktionen, angemeldeten Nutzern und dem Anteil nicht cachebarer Anfragen ab. Behandeln Sie eine Cache-Einstellung deshalb als zu prüfende Maßnahme, nicht als feste Leistungssteigerung.

Shops und APIs: Last und Berechtigungen gezielt abgrenzen

Eine Produktseite und ein Shop mit Warenkorb, Bestandsänderungen und Zahlungsvorgängen haben nicht dasselbe Lastprofil. Transaktionen erzeugen Datenbank-Schreibzugriffe; APIs können in kurzer Zeit viele dynamische Anfragen auslösen. Eine Kapazitätsannahme, die für überwiegend lesende Inhaltsseiten passt, lässt sich nicht ungeprüft auf solche Dienste übertragen.

Wenn mehrere Installationen auf derselben Maschine laufen, richten Sie für unterschiedliche Anwendungen getrennte Betriebssystembenutzer, Dateirechte, Datenbankkonten und PHP-FPM-Pools ein. Begrenzen und beobachten Sie die Prozesse so, dass ein auffälliger Dienst nicht unbemerkt alle verfügbaren Ressourcen belegt. PHP-FPM-Pools unterstützen die Trennung von Konfiguration und Ausführung; die PHP-Dokumentation zu FPM-Konfiguration und Pools macht aber deutlich, dass ein Pool keine vollständige Sicherheitsgrenze darstellt.

Für sensible Kundendaten oder Anwendungen mit nicht akzeptabler gegenseitiger Beeinflussung reicht eine Pool-Konfiguration möglicherweise nicht aus. Dann kommen getrennte Installationen, zusätzliche Betriebssystem- und Datenbankgrenzen oder eine separate Maschine in Betracht. Entscheidend ist, welche Auswirkungen ein Ausfall oder eine Rechteausweitung haben darf—not die Frage, ob sich alle Websites technisch auf derselben Hardware starten lassen.

Hinweis: WordPress Multisite zentralisiert bestimmte Verwaltungsaufgaben, ist aber keine automatische Trennung von Kunden, Dateien und Serverprozessen. Für die Netzwerkadministration gelten außerdem andere Zuständigkeiten als für einzelne Websites; prüfen Sie dazu die Dokumentation zu Netzwerk- und Website-Administratoren.

Betriebsmodelle nach Verwaltungs- und Sicherheitsgrenzen vergleichen

Ein gemeinsames Multisite-Netzwerk und mehrere unabhängige Installationen lösen unterschiedliche Verwaltungsprobleme. Die Wahl sollte daher nicht allein nach dem geringsten Einrichtungsaufwand erfolgen.

Bei Multisite unterscheidet WordPress zwischen Netzwerkverwaltung und der Verwaltung einzelner Websites. Netzwerkadministratoren können zentrale Entscheidungen treffen, die über eine einzelne Website hinausreichen. Die jeweiligen Befugnisse sind in der WordPress-Dokumentation zur Netzwerkadministration beschrieben. Ein solches Modell passt vor allem dann, wenn die Websites organisatorisch zusammengehören und einheitliche Regeln akzeptieren.

Bei mehreren Kunden oder voneinander unabhängigen Teams sind einzelne Installationen oft leichter nach Zuständigkeit und Plugin-Anforderungen zu ordnen. Das allein macht die Websites aber nicht sicher voneinander isoliert. Wenn mehrere Installationen unter demselben Betriebssystemkonto laufen oder auf gemeinsame Datenbankzugänge zugreifen, bleibt die Trennung unvollständig. Legen Sie vor der Migration fest, wer Dateien ändern, Datenbanken verwalten und Updates freigeben darf.

Kapazität in Etappen prüfen

Ein sinnvoller Belastungstest beginnt nicht mit einer Schätzung der maximalen Website-Zahl. Er beginnt mit einer Bestandsaufnahme und einem reproduzierbaren Vergleich zwischen Ausgangszustand und zusätzlicher Last. Testen Sie möglichst in einer Staging-Umgebung, ohne echte Bestellungen oder produktive Kundendaten zu verändern.

1. Websites inventarisieren: Notieren Sie pro Installation Domains, WordPress-Erweiterungen, PHP-Anforderungen, Datenbank, Medienbestand, Hintergrundaufgaben, Geschäftsrelevanz und verantwortliche Personen.
2. Lastprofile gruppieren: Trennen Sie überwiegend statische Seiten von redaktionellen Plattformen, Shops und APIs. Markieren Sie Websites, deren Ausfall oder Datenverlust besonders hohe Folgen hätte.
3. Ausgangswerte erfassen: Protokollieren Sie CPU, Arbeitsspeicher, Plattenbelegung, Datenbankaktivität, PHP-Fehler, Antwortzeiten und HTTP-Fehler während repräsentativer Betriebsphasen.
4. Testanfragen vorbereiten: Verwenden Sie realistische Seitenaufrufe, Suchvorgänge und Hintergrundaufgaben. Tests müssen dem tatsächlichen Anwendungsmuster entsprechen; künstliche Abrufe einer einzigen statischen Seite bilden einen Shop oder ein Redaktionssystem nicht ab.
5. Last schrittweise erhöhen: Nehmen Sie zunächst eine kleine, risikoarme Gruppe hinzu und wiederholen Sie denselben Test. Ändern Sie nicht gleichzeitig mehrere Komponenten, sonst bleibt unklar, wodurch eine Veränderung verursacht wurde.
6. Engpässe zuordnen: Prüfen Sie, ob CPU, Arbeitsspeicher, Datenbank, Plattenzugriffe, PHP-Prozesse oder externe Abhängigkeiten zuerst auffällig werden. Ordnen Sie Fehler und Verzögerungen nach Website und Prozess zu.
7. Entscheidung dokumentieren: Halten Sie fest, welche Websites gemeinsam betrieben werden dürfen, welche Grenzen überwacht werden und welches Ereignis eine erneute Prüfung oder Trennung auslöst.

Die Prüfliste lässt sich für eine Freigabe vor der Migration verwenden:

• [ ] Sind Domains, Installationen und Multisite-Websites getrennt erfasst?
• [ ] Sind Spitzenlasten und geplante Aufgaben für jede wichtige Website bekannt?
• [ ] Verfügt jede unabhängige Installation über passende Dateirechte und ein eigenes Datenbankkonto?
• [ ] Sind PHP-FPM-Pools so konfiguriert, dass Prozesse beobachtet und begrenzt werden können?
• [ ] Wurden Fehlerprotokolle und Ressourcenwerte während repräsentativer Tests geprüft?
• [ ] Gibt es einen festgelegten Auslöser, bei dem ein Shop oder eine kritische Website getrennt wird?
• [ ] Sind Verantwortlichkeiten für Updates, Zugriffe und Wiederherstellung dokumentiert?

Trennung bei messbaren Auswirkungen auslösen

Eine einzelne hohe Messung ist nicht automatisch ein Grund für einen Serverwechsel. Sie sollte aber eine Ursachenanalyse auslösen, besonders wenn sie mit langsamen Seiten, fehlgeschlagenen Aufgaben oder Fehlern für weitere Websites zusammenfällt. Prüfen Sie zuerst, ob eine bestimmte Erweiterung, eine ineffiziente Abfrage, ein falsch konfigurierter Cache oder ein einzelner Prozess den Engpass verursacht.

Eine Trennung wird plausibel, wenn ein Shop wiederholt Ressourcen beansprucht, die andere Websites benötigen; wenn Ausfälle einer Installation nicht auf andere Kunden übergreifen dürfen; oder wenn Berechtigungen und Wartungsfenster nicht mehr gemeinsam verwaltet werden können. Auch unterschiedliche Anforderungen an Plugins und Laufzeitumgebungen können gegen ein gemeinsames Multisite-Netzwerk sprechen.

Eine separate Maschine ist dagegen nicht automatisch wirtschaftlicher oder sicherer. Für wenige, wenig genutzte Seiten kann die gemeinsame Umgebung einfacher zu betreiben sein. Bei kurzfristigen Tests oder sehr geringer Last kann ein kleineres Hosting-Angebot ausreichen. Die Entscheidung sollte Kosten, Zuständigkeit und Ausfallfolgen einbeziehen, statt allein auf die Möglichkeit zu zielen, möglichst viele Websites auf einer Maschine unterzubringen.

Nächster Schritt: Betriebsmodell und Server getrennt bewerten

Gemeinsames Hosting kann bei mehreren Websites die Administration vereinfachen, bringt aber geteilte Ressourcen, ein größeres Fehlerausmaß und mehr Anforderungen an Dateirechte und Prozessgrenzen mit sich. Wenn diese Einschränkungen bei dauerhaft betriebenen Websites zum Risiko werden, kann ein exklusiv genutzter AMD-Server die passendere Grundlage sein—vorausgesetzt, die Last wurde getestet und die eigene Betriebsverantwortung ist eingeplant. CloudUDP betreibt dedizierte AMD-Server in Japan; konkrete Optionen und Kosten sollten vor der Entscheidung in der CloudUDP-Produktübersicht geprüft werden. Eine feste Zahl unterstützter WordPress-Websites lässt sich daraus nicht ableiten.

Vor der Anfrage sollten Website-Typen, gemessene Spitzen, gewünschte Isolation und Zuständigkeiten schriftlich vorliegen. Für die geplante Administration helfen außerdem die Hinweise zum Serverzugang per SSH oder RDP; sensible personenbezogene Daten erfordern zusätzlich eine Prüfung der einschlägigen Datenschutzpflichten. Die Serverwahl ersetzt weder diese Prüfung noch eine belastbare Kapazitätsmessung.