WordPress Multisite ist keine Multi-Site: Architektur, die auf 500 Standorte skaliert

WordPress Multisite klingt, als würde man mehrere Seiten bekommen. Was man tatsächlich bekommt, ist eine WordPress-Installation, die so tut, als wären es mehrere Seiten, indem sie eine Nummer vor die Datenbanktabellennamen setzt. Die Hauptseite verwendet wp_posts. Subsite 2 verwendet wp_2_posts. Subsite 3 verwendet wp_3_posts. Das ist keine Multi-Site-Architektur. Das ist eine Datenbank mit nummerierten Kopien der gleichen Tabellen. Und das hat Konsequenzen.

Ich habe Netzwerke mit 15, 40 und einmal 87 Subsites von WordPress Multisite migriert. Jedes Mal dachte der Kunde, er würde unabhängige Seiten bekommen. Jedes Mal entdeckten sie auf die harte Tour, dass das nicht so war. Wenn du ein Franchise, ein Unternehmen mit mehreren Standorten oder ein Universitätsdepartment-Netzwerk auf WordPress Multisite betreibst, wird dieser Artikel etwas wehtun. Aber es ist besser, es jetzt zu wissen, als nachdem Subsite #47 alle 46 anderen zum Absturz bringt.

Inhaltsverzeichnis

WordPress Multisite ist keine Multi-Site: Architektur, die auf 500 Standorte skaliert

Was WordPress Multisite tatsächlich unter der Haube tut

Schauen wir uns an, was passiert, wenn man Multisite in WordPress aktiviert. Man fügt ein paar Zeilen zu wp-config.php hinzu:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

WordPress erstellt dann ein paar Netzwerk-Level-Tabellen (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) und beginnt, deine Kerntabellenstruktur für jede neue Subsite zu duplizieren.

So sieht die Datenbank nach nur 5 Subsites aus:

wp_posts              (Hauptseite)
wp_postmeta           (Hauptseite)
wp_options            (Hauptseite)
wp_users              (geteilt - alle Seiten)
wp_usermeta           (geteilt - alle Seiten)
wp_2_posts            (Subsite 2)
wp_2_postmeta         (Subsite 2)
wp_2_options          (Subsite 2)
wp_3_posts            (Subsite 3)
wp_3_postmeta         (Subsite 3)
wp_3_options          (Subsite 3)
...
wp_5_posts            (Subsite 5)
wp_5_postmeta         (Subsite 5)
wp_5_options          (Subsite 5)

Fünf Subsites und du hast bereits ~55 Tabellen. Fünfzig Subsites? Du schaust auf über 500 Tabellen in einer einzelnen MySQL-Datenbank. Fünfhundert Standorte? Über 5.000 Tabellen. In einer Datenbank. Teilen einen Verbindungspool.

Jede Tabelle hat ihre eigenen Indizes. Jede Abfrage zielt auf eine bestimmte Tabelle mit Präfix ab. Der Query-Planner muss sich damit auseinandersetzen. Und jede einzelne dieser Tabellen ist für jeden PHP-Prozess zugänglich, der auf diesem Server läuft, weil sie sich alle in der gleichen Datenbank mit den gleichen Anmeldedaten befinden.

Das ist keine Multi-Site-Architektur. Das ist eine Namenskonvention, die sich als Isolation ausgibt.

Die 7 Konsequenzen einer gefälschten Multi-Site-Architektur

1. Geteilte Sicherheitsrisiko-Oberfläche

Jede Subsite in einem WordPress Multisite-Netzwerk führt den gleichen WordPress-Core, die gleichen Plugins und die gleichen Themes aus. Eine Plugin-Sicherheitslücke gefährdet alle Subsites, weil sie die gleiche Codebasis nutzen.

Das ist nicht theoretisch. Im Februar 2026 hatte WPVivid — ein Backup-Plugin mit über 900.000 aktiven Installationen — eine RCE-Sicherheitslücke (Remote Code Execution) mit Severity 9.8 bekannt gegeben. Severity 9.8 von 10. Das ist "ein nicht authentifizierter Angreifer kann beliebigen Code auf deinem Server ausführen"-Territorium.

Auf einer eigenständigen WordPress-Seite ist das eine gefährdete Seite. Auf einem Multisite-Netzwerk mit 30 Subsites? Das sind 30 gefährdete Seiten. Gleicher Server. Gleiche Datenbank. Gleiches Dateisystem. Eine Sicherheitslücke, totales Netzwerk-Kompromiss.

Du kannst keine andere Version eines Plugins auf Subsite #12 als auf Subsite #13 installieren. Du kannst die Plugins eines Standorts nicht von einem anderen isolieren. Jede Seite bekommt die gleiche Angriffsfläche.

2. Plugin-Konflikt-Vervielfachung

Auf einer einzelnen WordPress-Seite bricht ein Plugin-Konflikt eine Seite. Du deaktivierst das Plugin, diagnostizierst, weiter gehts. Lästig aber überschaubar.

Auf Multisite bricht ein Netzwerk-aktiviertes Plugin-Konflikt jede Seite gleichzeitig. Ich habe ein WooCommerce-Update auf einem Multisite-Netzwerk gesehen, das 23 Standort-Seiten auf einmal zerstört hat, weil ein netzwerk-aktiviertes Caching-Plugin nicht für die neuen WooCommerce-Hooks aktualisiert worden war. Dreiundzwanzig Standorte mit defekten Seiten. Eine Grundursache, dreiundzwanzig verärgerte Standortmanager, die den gleichen Person anrufen.

Und hier ist der Hammer — einzelne Site-Admins können normalerweise Netzwerk-aktivierte Plugins nicht deaktivieren. Sie müssen auf den Super Admin warten, um es zu beheben.

3. Performance-Verschlechterung

Fünfzig Subsites, die sich eine MySQL-Instanz teilen. Jedes Laden der Seite auf Subsite #47 führt Abfragen wie diese aus:

SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);

Inzwischen führt Subsite #12 ihren eigenen Satz von Abfragen gegen wp_12_posts, wp_12_options und wp_12_postmeta aus. Und das tut jede andere Subsite auch, alle treffen auf die gleiche MySQL-Instanz.

Der MySQL-Query-Planner wird verwirrt. Table Cache füllt sich. Jede Tabelle mit Präfix behält ihre eigenen Indizes, aber der Buffer Pool wird geteilt. Die Performance verschlechtert sich nicht-linear, während du Subsites hinzufügst. Von 10 auf 20 Subsites zu gehen ist nicht doppelte Last — es kann drei- oder vierfache Last sein, je nach Verkehrsmuster, wegen Lock Contention und Buffer Pool Thrashing.

Ich habe ein 40-Subsite-Netzwerk einmal gemessen. Durchschnittliche Abfragezeit auf Subsite #1 war 45ms. Als wir Subsite #38 testeten, war die durchschnittliche Abfragezeit auf 380ms angestiegen. Gleiche Abfragestruktur. Gleiche Datenmenge pro Seite. Die Datenbank erstickte einfach in Tabellen.

4. Migration ist ein Albtraum

Versuch, Subsite #23 aus einem 50-Site-Netzwerk in eine eigenständige WordPress-Installation zu extrahieren. Hier ist, was du tun musst:

  1. Alle wp_23_ Präfix-Tabellen exportieren
  2. Jede Tabelle vom wp_23_ Präfix auf wp_ Präfix umleiten
  3. Alle Options- und Widget-Daten neu serialisieren (WordPress speichert serialisiertes PHP in der Datenbank, und Stringlängen ändern sich, wenn du Präfixe änderst)
  4. Media-Pfade von /uploads/sites/23/ auf /uploads/ umleiten
  5. Alle internen URLs suchen und ersetzen
  6. Benutzerkapazitäten von wp_23_capabilities zu wp_capabilities in wp_usermeta umleiten
  7. Benutzer aus der gemeinsamen wp_users-Tabelle extrahieren (nur die, die zu Subsite #23 gehören)
  8. Benutzer-zu-Site-Beziehungen neu erstellen

Ein Fehler in der Serialisierung und du bekommst beschädigte Daten. Widget-Einstellungen verschwinden. Theme-Customizer-Optionen brechen. Menüstrukturen verschwinden. Ich habe diesen Extraktionsprozess Dutzende Male durchgeführt, und es dauert 4-8 Stunden pro Subsite, auch mit Tools wie WP Migrate DB Pro. Multiplizieren Sie das mit 50 Subsites, wenn Sie ein Netzwerk stilllegen.

Das WordPress-Ökosystem hat Tools dafür, sicher. Aber die Tatsache, dass diese Tools existieren, sagt dir etwas über die Architektur.

5. Keine echte Datenisolation

Das ist die, die dich erschrecken sollte, wenn dir Sicherheit oder Compliance wichtig ist.

Eine SQL Injection-Sicherheitslücke auf Subsite #2 exponiert nicht nur wp_2_posts. Der Datenbankbenutzer, der sich mit MySQL verbindet, hat Zugriff auf jede Tabelle in der Datenbank. Das bedeutet wp_posts (Hauptseite), wp_3_posts (Subsite 3), wp_users (alle Benutzer über alle Seiten) und jede andere Tabelle.

Es gibt keine Datenbankebenige-Isolation. Keine Row-Level Security. Keine Schema-Separation. WordPress Multisite ist eine Datenbank, ein Satz Anmeldedaten und eine Namenskonvention. Das ist alles.

Für Unternehmen, die Kundendaten über Standorte verwalten — medizinische Büros, Rechtsanwaltskanzleien, Finanzdienstleistungen — das ist ein Compliance-Problem. HIPAA, SOC 2 und PCI DSS alle haben Anforderungen an Datenisolation. "Wir haben unterschiedliche Tabellenpräfixe verwendet" wird einen Auditor nicht zufriedenstellen.

6. Super Admin-Engpass

WordPress Multisite hat eine Rolle namens Super Admin. Nur der Super Admin kann:

  • Plugins installieren oder löschen
  • Themes installieren oder löschen
  • Plugins netzweit aktivieren
  • Neue Seiten zum Netzwerk hinzufügen
  • Netzwerk-Einstellungen verwalten

Individuelle Site-Administratoren haben begrenzte Fähigkeiten. Sie können ihre eigenen Plugins nicht installieren. Sie können ihre eigenen Themes nicht hinzufügen. Jede Änderung, die die gemeinsame Infrastruktur berührt, leitet durch eine Person (oder ein kleines Team).

Für ein 3-Site-Netzwerk ist das OK. Für ein 50-Location-Franchise, wo jeder Standortmanager sein eigenes Reservierungs-Widget oder Menu-PDF-Plugin hinzufügen möchte? Das ist ein Engpass, der Ressentiments und Shadow IT züchtet.

7. Domain-Mapping Fragilität

Möchtest du, dass jeder Standort seine eigene Domain hat? denver.yourbrand.com oder yourbrand-denver.com? WordPress Multisite handhabt das nicht nativ auf zuverlässige Weise. Du brauchst eine Domain-Mapping-Lösung, und der eingebaute sunrise.php Dropin-Ansatz ist notorisch zerbrechlich.

SSL-Zertifikate für gemappte Domains fügen eine weitere Ebene hinzu. DNS-Konfiguration fügt eine weitere hinzu. Jede gemappte Domain ist ein weiterer potenzieller Ausfallpunkt, den dein Super Admin verwalten muss. Eine DNS-Änderung, ein abgelaufenes Zertifikat, ein fehlerhaft konfigurierter Mapping-Eintrag, und die Seite eines Standorts geht offline.

Wann WordPress Multisite funktioniert (ehrlich)

Ich werde nicht so tun, als wäre es nutzlos. WordPress Multisite funktioniert gut in spezifischen Szenarien:

  • Kleine Netzwerke (unter 10 Seiten), wo alle Seiten vom gleichen Team verwaltet werden
  • Universität Department Seiten, wo zentrale Kontrolle tatsächlich gewünscht ist
  • Dev/Staging/Production Mirrors für das gleiche Projekt
  • Blog Netzwerke, wo Content-Isolation nicht kritisch ist

Wenn du 5-8 Seiten hast, einen kompetenten Sysadmin, und du brauchst keine Datenisolation zwischen Seiten — Multisite ist OK. Die Probleme beginnen, wenn du es auf Dutzende oder Hunderte von Standorten skalieren versuchst.

WordPress Multisite ist keine Multi-Site: Architektur, die auf 500 Standorte skaliert - Architektur

Die Architektur, die tatsächlich auf 500 Standorte skaliert

Hier ist der alternative Ansatz, den wir bei Social Animal für Multi-Location-Unternehmen verwenden: eine Headless-Architektur mit Next.js auf dem Frontend und Supabase (PostgreSQL) auf dem Backend, mit Row-Level Security (RLS) für echte Datenisolation.

Die Kernidee: Anstatt Tabellen für jeden Standort zu duplizieren, hast du einen Satz Tabellen mit einer location_id-Spalte. Datenbanksicherheitsrichtlinien stellen sicher, dass Abfragen nur Daten für den autorisierten Standort zurückgeben. Und anstatt 500 separate WordPress-Installationen, die Unabhängigkeit vortäuschen, hast du ein einzelnes Application-Deployment, wo /locations/[slug] dynamisch jede Standort-Seite aus einer Datenbankzeile rendert.

Wie Row-Level Security tatsächlich funktioniert

-- Erstelle die locations-Tabelle
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  address TEXT,
  phone TEXT,
  hours JSONB,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Erstelle die pages-Tabelle mit Location-Isolation
CREATE TABLE pages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  location_id UUID REFERENCES locations(id),
  title TEXT NOT NULL,
  content JSONB,
  slug TEXT NOT NULL,
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Aktiviere RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Richtlinie: Location-Manager können nur die Seiten ihres eigenen Standorts sehen
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Richtlinie: Öffentlich kann veröffentlichte Seiten für jeden Standort lesen
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Mit dieser Einrichtung kann ein Location-Manager in Denver, der irgendwie eine bösartige Abfrage handwerkt, physikalisch nicht auf Austins Daten zugreifen. Die Datenbank setzt es durch. Nicht die Anwendungsschicht. Nicht eine Namenskonvention. Die Datenbank selbst.

Architekturvergleich: Prefixed Tables vs Row-Level Security

Hier ist eine visuelle Darstellung der beiden Architekturen:

WordPress Multisite Architektur:

┌─────────────────────────────────────────────┐
│           Einzelne MySQL-Datenbank           │
│                                             │
│  wp_posts          (Hauptseite)             │
│  wp_options        (Hauptseite)             │
│  wp_2_posts        (Denver)                 │
│  wp_2_options      (Denver)                 │
│  wp_3_posts        (Austin)                 │
│  wp_3_options      (Austin)                 │
│  wp_4_posts        (Seattle)                │
│  wp_4_options      (Seattle)                │
│  ... x 500 Standorte = 5.000+ Tabellen     │
│                                             │
│  ⚠️  EIN Satz DB-Anmeldedaten               │
│  ⚠️  EIN PHP-Prozess greift auf ALLE Tabellen zu│
│  ⚠️  KEINE Datenbankebenige-Isolation       │
└─────────────────────────────────────────────┘

Next.js + Supabase Architektur:

┌─────────────────────────────────────────────┐
│      Einzelne PostgreSQL-Datenbank           │
│                                             │
│  locations    (500 Zeilen, eine pro Standort)│
│  pages        (Content pro Standort)        │
│  media        (Bilder pro Standort)         │
│  staff        (Team pro Standort)           │
│  reviews      (Bewertungen pro Standort)    │
│                                             │
│  ✅  RLS-Richtlinien setzt Isolation durch  │
│  ✅  Denver-Benutzer KANN NICHT Austin-Daten abfragen│
│  ✅  5 Tabellen insgesamt, nicht 5.000      │
│  ✅  Standard-Indizes, optimale Query-Pläne │
└─────────────────────────────────────────────┘

Eine Datenbank in beiden Fällen. Aber das Isolationsmodell ist fundamental unterschiedlich. RLS wird auf der PostgreSQL-Engine-Ebene durchgesetzt — es ist nicht etwas, das die Anwendung umgehen kann.

Faktor WordPress Multisite Next.js + Supabase
Tabellen bei 500 Standorten ~5.500+ ~5-15
Datenisolation Keine (nur Namenskonvention) Datenbankebenig durchgesetzt RLS
Sicherheitsrisiko-Oberfläche Eine Sicherheitslücke = alle Seiten Pro-Location Auth Isolation
Plugin-Konflikte Netzweit Ausfall N/A (keine Plugin-Architektur)
Einen Standort hinzufügen Subsite erstellen + konfigurieren Datenbankzeile einfügen
Einen Standort entfernen Komplexer Extraktionsprozess Zeilen mit CASCADE löschen
Domain-Mapping Plugin erforderlich, zerbrechlich Middleware-Umschreiben, nativ
Build/Deploy-Zeit N/A (Runtime PHP) ~30s inkrementeller Build
TTFB (Durchschnitt, unkached) 800ms-2s+ 50-150ms (edge)
Monatliches Hosting (500 Seiten) $200-800/mo (managed WP) $25-75/mo (Supabase + Vercel)
Wiederherstellung nach Kompromiss Vollständige Netzwerk-Sanierung Schlüssel rotieren, neu bereitstellen

Implementierung: Next.js + Supabase für Multi-Location-Seiten

Hier ist, wie das Routing in der Praxis mit Next.js funktioniert:

// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: locations } = await supabase
    .from('locations')
    .select('slug');
  
  return locations?.map(({ slug }) => ({ slug })) ?? [];
}

export default async function LocationPage({ 
  params 
}: { 
  params: { slug: string } 
}) {
  const supabase = createClient();
  
  const { data: location } = await supabase
    .from('locations')
    .select(`
      *,
      pages(*),
      staff(*),
      reviews(*, rating)
    `)
    .eq('slug', params.slug)
    .single();
  
  if (!location) notFound();
  
  return (
    <div>
      <h1>{location.name}</h1>
      <LocationHero location={location} />
      <LocationServices pages={location.pages} />
      <LocationTeam staff={location.staff} />
      <LocationReviews reviews={location.reviews} />
    </div>
  );
}

Einen neuen Standort hinzufügen? Eine Zeile einfügen:

INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
  'portland-or',
  'Portland, OR',
  '123 Burnside St, Portland, OR 97209',
  '(503) 555-0142',
  '{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);

Das ist alles. Der nächste Build nimmt es auf. Oder wenn du ISR (Incremental Static Regeneration) verwendest, wird es ohne einen Build in deinem Revalidierungsfenster angezeigt.

Einen Standort entfernen? DELETE FROM locations WHERE slug = 'portland-or'; Cascading Deletes behandeln den Rest. Kein 4-8-Stunden-Extraktionsprozess.

Für benutzerdefinierte Domains pro Standort, Next.js Middleware behandelt es sauber:

// middleware.ts
import { NextResponse } from 'next/server';

const DOMAIN_MAP: Record<string, string> = {
  'yourbrand-denver.com': '/locations/denver-co',
  'yourbrand-austin.com': '/locations/austin-tx',
  // ... von Edge Config in Produktion geladen
};

export function middleware(request: Request) {
  const hostname = new URL(request.url).hostname;
  const rewritePath = DOMAIN_MAP[hostname];
  
  if (rewritePath) {
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }
  
  return NextResponse.next();
}

Keine Plugins. Kein sunrise.php Dropin. Keine zerbrechlichen Mapping-Tabellen. Nur eine Umschreiberegel am Edge.

Migrationspfad: Weg von WordPress Multisite

Wenn du derzeit auf WordPress Multisite mit 20+ Standorten bist, hier ist der realistische Migrationspfad:

Phase 1: Datenexport (1-2 Wochen)

Extrahiere Inhalte von jeder Subsite mit der WordPress REST API oder WP-CLI. Versuche nicht, manuell Präfix-Tabellen umzuleiten. Verwende die API — sie abstrahiert den Präfix-Albtraum.

# Alle Posts von Subsite 23 exportieren
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Alle Media exportieren
wp media list --url=example.com/location-23 --format=json > location-23-media.json

Phase 2: Schema-Design (1 Woche)

Entwerfe dein Supabase-Schema um dein tatsächliches Inhaltsmodell, nicht WordPress's Post/Postmeta-Modell. Das ist der Moment, um Jahre von angesammelten Datenmodell-Schulden zu beheben.

Phase 3: Inhalts-Migration (1-2 Wochen)

Schreibe Migrations-Skripte, die WordPress-Inhalte in dein neues Schema transformieren. Verarbeite serialisierte Daten, Shortcodes und Gutenberg-Blöcke.

Phase 4: Frontend-Build (3-4 Wochen)

Baue das Next.js Frontend. Das ist, wo du die echten Performance-Gewinne siehst. Seiten, die 1,5 Sekunden auf WordPress dauerten, laden jetzt in unter 200ms.

Phase 5: DNS-Umstellung (1 Tag)

Zeige deine Domains auf die neue Infrastruktur. Halte das alte Netzwerk als schreibgeschützte Sicherung für 30 Tage am Laufen.

Für Unternehmen, die bei diesem Migrationsprozess Hilfe benötigen, haben wir unseren Ansatz auf unserer Seite zur Headless CMS-Entwicklung dokumentiert. Wir haben genug dieser Migrationen durchgeführt, um zu wissen, wo die Leichen begraben sind.

Echte Zahlen: Leistungs- und Kostenvergleich

Hier sind Daten aus einer tatsächlichen Migration, die wir im Q1 2025 abgeschlossen haben — ein Zahnarzt-Praxisnetzwerk mit 34 Standorten:

Metrik WordPress Multisite (Vorher) Next.js + Supabase (Nachher)
Durchschnittlicher TTFB 1.240ms 89ms
Größter Contentful Paint 3,8s 1,1s
Monatliche Hosting-Kosten $347/mo (WP Engine) $45/mo (Vercel Pro + Supabase Pro)
Zeit, einen neuen Standort hinzuzufügen 2-3 Stunden (manuelles Setup) 15 Minuten (Zeile einfügen + Inhalt)
Zeit, alle Standorte zu aktualisieren Plugin-Update + Gebet git push
Core Web Vitals bestanden Quote 12 von 34 Standorten 34 von 34 Standorten
Sicherheitsvorfälle (12 Monate) 3 0

Die Hosting-Kostenreduktion allein amortisierte die Migration in 8 Monaten. Die Performance-Verbesserungen führten zu messbaren Verbesserungen der lokalen Suchrangfolgen für 28 der 34 Standorte innerhalb von 90 Tagen.

Wenn du Kosten für dein eigenes Netzwerk evaluierst, hat unsere Preisseite transparente Aufschlüsselungen für Multi-Location-Projekte.

FAQ

Ist WordPress Multisite gut für die Verwaltung mehrerer Standorte? Für eine kleine Anzahl von Standorten (unter 10) mit zentraler Verwaltung kann WordPress Multisite funktionieren. Aber es war nicht für Multi-Location-Unternehmen konzipiert, die unabhängige Operation, Datenisolation oder hohe Performance im Maßstab benötigen. Die gemeinsame Datenbankarchitektur erzeugt Sicherheits-, Leistungs- und Betriebsprobleme, die sich mit jedem hinzugefügten Standort verschärfen.

Was sind die größten Probleme mit WordPress Multisite? Die sieben Hauptprobleme sind: geteilte Sicherheitsrisiko-Oberfläche (eine Sicherheitslücke trifft alle Seiten), Plugin-Konflikt-Vervielfachung (ein Konflikt nimmt jede Seite mit sich), nicht-lineare Performance-Verschlechterung, Albtraum-Migrations-/Extraktionsprozesse, Null Datenbankebenige-Datenisolation, Super Admin-Engpass für alle administrativen Änderungen und zerbrechliches Domain-Mapping. Diese Probleme sind architektonisch — sie können nicht mit Plugins oder besserem Hosting behoben werden.

Kann WordPress Multisite 100+ Seiten handhaben? Technisch ja. Praktisch wird es sehr schmerzhaft jenseits von 30-50 Seiten. Bei 100 Seiten hast du 1.100+ Datenbanktabellen in einer einzelnen MySQL-Instanz, schwere Query-Planner-Verschlechterung und operative Komplexität, die dediziertes DevOps-Personal erfordert. Bei 500 Seiten ist es für die meisten Hosting-Umgebungen nicht machbar.

Was ist die beste Alternative zu WordPress Multisite für mehrere Standorte? Eine Headless-Architektur mit Next.js oder Astro für das Frontend mit einer PostgreSQL-Datenbank (wie Supabase) unter Verwendung von Row-Level Security bietet echte Datenisolation, dramatisch bessere Performance, niedrigere Hosting-Kosten und triviale Standort-Verwaltung. Jeder Standort ist eine Datenbankzeile, keine ganze WordPress-Installation.

Wie migrierst du von WordPress Multisite zu einer Headless-Architektur? Der sicherste Ansatz ist, Inhalte über die WordPress REST API oder WP-CLI zu extrahieren, anstatt zu versuchen, Präfix-Datenbanktabellen manuell umzuleiten. Exportiere Inhalte pro Subsite, entwerfe ein sauberes Schema in deiner Zieldatenbank, schreibe Transformations-Skripte, baue das neue Frontend und schalte DNS um. Plane für 6-10 Wochen insgesamt für ein Netzwerk mit 20+ Seiten.

Beeinflusst WordPress Multisite die SEO? Indirekt ja. Die Performance-Verschlechterung von WordPress Multisite führt zu langsameren Seiten-Ladungen, die Core Web Vitals Scores schädigen. Google hat bestätigt, dass Page Experience Signals Rankings beeinflussen. In unseren Migrations-Daten sahen 82% der Standorte verbesserte lokale Suchrangfolgen innerhalb von 90 Tagen nach dem Wechsel zu einer Headless-Architektur mit Sub-200ms TTFB.

Ist WordPress Multisite sicher für Geschäftsdaten? Nein, wenn du Sicherheit definierst, um Datenisolation zwischen Standorten einzuschließen. WordPress Multisite verwendet eine Datenbank mit einem Satz Anmeldedaten. Ein SQL Injection auf einer Subsite kann auf die Daten jeder anderen Subsite zugreifen. Für Unternehmen, die HIPAA, SOC 2, PCI DSS oder ähnlichen Compliance-Anforderungen unterliegen, ist der Mangel an Datenbankebeniger Isolation eine signifikante Haftung.

Wie viel kostet es, WordPress Multisite im Vergleich zu einer Headless-Alternative zu betreiben? Managed WordPress Hosting für Multisite läuft typischerweise $200-800/Monat je nach Anzahl der Seiten und Verkehrsniveaus (WP Engines Multisite-Pläne beginnen mit $240/mo für ihr Growth Tier 2025). Ein vergleichbarer Headless-Aufbau auf Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) handhabt den gleichen Traffic für einen Bruchteil der Kosten. Die initiale Build-Investition ist höher für den Headless-Ansatz, aber monatliche Betriebskosten sind signifikant niedriger. Sprich uns gerne an, wenn du einen spezifischen Kostenvergleich für deine Netzwerk-Größe möchtest.