Ihr Franchise-Kunde startet Subsite 247. WordPress erstellt wp_247_posts, wp_247_postmeta, wp_247_options — die gleichen 12 Tabellen, die es für die Subsites 1 bis 246 erstellt hat. Jetzt haben Sie 2.964 Tabellen in einer einzigen Datenbank. Ein Plugin-Update berührt alle. Eine Abfrage auf Seite 118 konkurriert mit Abfragen auf den Seiten 12, 95 und 203. Ihr Monitoring-Dashboard zeigt um 11:00 Uhr jeden Dienstag Erschöpfung des Verbindungspools. Dies ist keine Multi-Site-Architektur. Dies ist eine WordPress-Installation mit nummerierten Kopien desselben Schemas, und es hat sieben Skalierungsfolgen, die bei vorhersehbaren Schwellwerten brechen — die erste kommt um die Website 40 herum.

Ich habe Netzwerke mit 15, 40 und einmal 87 Subsites von WordPress Multisite migriert. Jedes Mal dachten die Kunden, sie würden unabhängige Websites bekommen. Jedes Mal entdeckten sie die schwere Weise, dass sie es nicht waren. Wenn Sie ein Franchise, ein Multi-Location-Unternehmen oder ein Universitätsdepartementsystem auf WordPress Multisite betreiben, wird dieser Artikel ein wenig weh tun. Aber es ist besser, jetzt zu wissen, als nachdem Subsite #47 alle 46 anderen zum Absturz bringt.

Inhaltsverzeichnis

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

Was WordPress Multisite unter der Haube wirklich tut

Schauen wir uns an, was passiert, wenn Sie Multisite in WordPress aktivieren. Sie fügen 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 netzwerkweite Tabellen (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) und beginnt, Ihre Kerntabellenstruktur für jeden neuen 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 Sie haben bereits ~55 Tabellen. Fünfzig Subsites? Sie schauen auf über 500 Tabellen in einer einzelnen MySQL-Datenbank. Fünfhundert Standorte? Über 5.000 Tabellen. In einer Datenbank. Mit einem gemeinsamen Verbindungspool.

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

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

Die 7 Folgen der gefälschten Multi-Site-Architektur

1. Gemeinsame Schwachstellenfläche

Jeder Subsite in einem WordPress Multisite-Netzwerk läuft den gleichen WordPress-Core, die gleichen Plugins und die gleichen Themes. Ein Plugin-Exploit kompromittiert alle Subsites, da sie die gleiche Codebasis teilen.

Dies ist nicht theoretisch. Im Februar 2025 hatte WPVivid — ein Backup-Plugin mit über 900.000 aktiven Installationen — eine Schweregrad 9.8 RCE-Sicherheitslücke (Remote Code Execution). Schweregrad 9,8 von 10. Das ist ein Gebiet von "ein nicht authentifizierter Angreifer kann beliebigen Code auf Ihrem Server ausführen".

Auf einer eigenständigen WordPress-Website ist das eine kompromittierte Website. In einem Multisite-Netzwerk mit 30 Subsites? Das sind 30 kompromittierte Seiten. Gleicher Server. Gleiche Datenbank. Gleiches Dateisystem. Ein Exploit, totale Netzwerk-Kompromittierung.

Sie können nicht eine andere Version eines Plugins auf Subsite #12 installieren als auf Subsite #13. Sie können Plugins einer Seite nicht von einer anderen isolieren. Jede Website erhält die gleiche Angriffsfläche.

2. Plugin-Konflikt-Multiplikation

Auf einer einzelnen WordPress-Website bricht ein Plugin-Konflikt eine Website. Sie deaktivieren das Plugin, diagnostizieren, und es geht weiter. Lästig, aber handhabbar.

Bei Multisite bricht ein netzwerkaktiviertes Plugin-Konflikt alle Websites gleichzeitig. Ich habe gesehen, wie ein WooCommerce-Update in einem Multisite-Netzwerk 23 Standort-Seiten zum Absturz brachte, da ein netzwerkaktiviertes Caching-Plugin nicht für die neuen WooCommerce-Hooks aktualisiert worden war. Dreiundzwanzig Standorte mit kaputten Seiten. Eine Grundursache, dreiundzwanzig wütende Standortmanager, die die gleiche Person anrufen.

Und hier ist der Haken — einzelne Seitenadministratoren können netzwerkaktivierte Plugins normalerweise nicht deaktivieren. Sie müssen auf den Super Admin warten, um es zu beheben.

3. Leistungsabbau

Fünfzig Subsites teilen sich eine MySQL-Instanz. Jedes Seitenload 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 seinen eigenen Satz von Abfragen gegen wp_12_posts, wp_12_options und wp_12_postmeta aus. Und so macht es jeder andere Subsite, alle treffen die gleiche MySQL-Instanz.

MySQLs Query Planner wird verwirrt. Table Cache füllt sich. Jede Tabelle mit Präfix behält ihre eigenen Indizes bei, aber der Buffer Pool wird geteilt. Die Leistung verschlechtert sich nicht-linear, wenn Sie Subsites hinzufügen. Von 10 auf 20 Subsites zu gehen ist nicht die doppelte Last — es kann dreimal oder viermal die Last sein, abhängig von Verkehrsmuster, wegen Lock Contention und Buffer Pool Thrashing.

Ich habe ein 40-Subsite-Netzwerk einmal gemessen. Die durchschnittliche Abfragezeit auf Subsite #1 betrug 45ms. Bis wir Subsite #38 testeten, war die durchschnittliche Abfragezeit auf 380ms gestiegen. Gleiche Abfragestruktur. Gleiches Datenvolumen pro Seite. Die Datenbank ertrank einfach in Tabellen.

4. Migration ist ein Albtraum

Versuchen Sie, Subsite #23 aus einem 50-Website-Netzwerk in eine eigenständige WordPress-Installation zu extrahieren. Hier ist, was Sie tun müssen:

  1. Exportieren Sie alle wp_23_ präfizierten Tabellen
  2. Bilden Sie jede Tabelle von wp_23_ Präfix auf wp_ Präfix um
  3. Serialisieren Sie alle Optionen und Widget-Daten neu (WordPress speichert serialisiertes PHP in der Datenbank, und die String-Längen ändern sich, wenn Sie Präfixe ändern)
  4. Bilden Sie Medienpfade von /uploads/sites/23/ auf /uploads/ um
  5. Suchen und ersetzen Sie alle internen URLs
  6. Bilden Sie Benutzerfunktionen von wp_23_capabilities auf wp_capabilities in wp_usermeta um
  7. Extrahieren Sie Benutzer aus der gemeinsamen wp_users-Tabelle (nur diejenigen, die zu Subsite #23 gehören)
  8. Erstellen Sie Benutzer-zu-Seiten-Beziehungen neu

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

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

5. Keine echte Datenisolation

Dies ist das Thema, das Sie erschrecken sollte, wenn Sie sich um Sicherheit oder Compliance kümmern.

Eine SQL-Injection-Schwachstelle auf Subsite #2 setzt nicht nur wp_2_posts frei. 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 Websites) und jede andere Tabelle.

Es gibt keine Datenbank-Isolierung. Keine Sicherheit auf Zeilenebene. Keine Schema-Trennung. WordPress Multisite ist eine Datenbank, ein Satz von Anmeldedaten und eine Namenskonvention. Das ist alles.

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

6. Super Admin Bottleneck

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 Websites zum Netzwerk hinzufügen
  • Netzwerkeinstellungen verwalten

Individuelle Seitenadministratoren haben eingeschränkte Fähigkeiten. Sie können nicht ihre eigenen Plugins installieren. Sie können nicht ihre eigenen Themes hinzufügen. Jede Änderung, die die gemeinsame Infrastruktur berührt, wird durch eine Person geleitet (oder ein kleines Team).

Für ein 3-Website-Netzwerk ist das in Ordnung. Für ein 50-Standort-Franchise, bei dem jeder Standortmanager sein eigenes Buchungs-Widget oder Menu-PDF-Plugin hinzufügen möchte? Es ist ein Engpass, der Ressentiments und Shadow IT züchtet.

7. Domain Mapping Fragilität

Möchten Sie, dass jeder Standort seine eigene Domain hat? denver.yourbrand.com oder yourbrand-denver.com? WordPress Multisite behandelt dies nicht nativ auf zuverlässige Weise. Sie benötigen eine Domain Mapping Lösung, und der integrierte sunrise.php dropin Ansatz ist notorisch zickig.

SSL-Zertifikate für gemappte Domains fügen eine weitere Schicht hinzu. DNS-Konfiguration fügt eine weitere hinzu. Jede gemappte Domain ist ein weiterer möglicher Fehlerpunkt, den Ihr Super Admin verwalten muss. Eine DNS-Änderung, ein abgelaufenes Zertifikat, ein fehlkonfigurierter Mapping-Eintrag, und die Website eines Standorts geht runter.

Wenn 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 Websites) wo alle Websites vom gleichen Team verwaltet werden
  • Universitätsdepartementsseiten wo zentrale Kontrolle tatsächlich gewünscht ist
  • Dev/Staging/Production Spiegelungen für das gleiche Projekt
  • Blog-Netzwerke wo Inhalts-Isolierung nicht kritisch ist

Wenn Sie 5-8 Websites haben, einen kompetenten Sysadmin, und Sie benötigen keine Datenisolierung zwischen Websites — Multisite ist in Ordnung. Die Probleme beginnen, wenn Sie versuchen, es auf Dutzende oder Hunderte von Standorten zu skalieren.

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

Die Architektur, die wirklich auf 500 Standorte skaliert

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

Die Grundidee: Anstatt Tabellen für jeden Standort zu duplizieren, haben Sie ein Satz von Tabellen mit einer location_id Spalte. Datenbank-Sicherheitsrichtlinien stellen sicher, dass Abfragen nur Daten für den autorisierten Standort zurückgeben. Und anstatt 500 separate WordPress-Installationen, die vorgeben unabhängig zu sein, haben Sie eine Anwendungs-Bereitstellung, bei der /locations/[slug] dynamisch die Seite eines jeden Standorts aus einer Datenbankzeile rendern.

Wie Row-Level Security wirklich funktioniert

-- Erstellen Sie 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()
);

-- Erstellen Sie die Pages-Tabelle mit Standort-Isolierung
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()
);

-- Aktivieren Sie RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Richtlinie: Standortmanager 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: Das Publikum kann veröffentlichte Seiten für jeden Standort lesen
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Mit diesem Setup kann ein Standortmanager in Denver, der versehentlich eine böswillige Abfrage verfasst, physisch nicht auf Austins Daten zugreifen. Die Datenbank erzwingt dies. Nicht die Anwendungsschicht. Nicht eine Namenskonvention. Die Datenbank selbst.

Architekturvergleich: Präfixierte Tabellen vs. Sicherheit auf Zeilenebene

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 zugreift auf ALLE      │
│  ⚠️  KEINE Datenbank-Isolierung             │
└─────────────────────────────────────────────┘

Next.js + Supabase-Architektur:

┌─────────────────────────────────────────────┐
│      Einzelne PostgreSQL-Datenbank          │
│                                             │
│  locations    (500 Zeilen, eins pro)        │
│  pages        (Inhalt pro Standort)         │
│  media        (Bilder pro Standort)         │
│  staff        (Team pro Standort)           │
│  reviews      (Bewertungen pro Standort)    │
│                                             │
│  ✅  RLS-Richtlinien erzwingen Isolierung   │
│  ✅  Denver-Benutzer kann NICHT Austin      │
│  ✅  5 Tabellen insgesamt, nicht 5.000      │
│  ✅  Standardindizes, optimale Query-Pläne  │
└─────────────────────────────────────────────┘

Eine Datenbank in beiden Fällen. Aber das Isolierungsmodell ist grundlegend 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 (Namenskonvention nur) Von Datenbank durchgesetzte RLS
Schwachstellenfläche Ein Exploit = alle Seiten Pro-Standort Auth-Isolierung
Plugin-Konflikte Netzwerk-weit Ausfall N/A (keine Plugin-Architektur)
Standort hinzufügen Subsite erstellen + konfigurieren Datenbankzeile einfügen
Standort entfernen Komplexes Extraktionsverfahren Zeilen mit CASCADE löschen
Domain Mapping Plugin erforderlich, fragil Middleware Rewrite, nativ
Build/Deploy-Zeit N/A (Runtime PHP) ~30s inkrementeller Build
TTFB (durchschn., uncached) 800ms-2s+ 50-150ms (Edge)
Monatliches Hosting (500 Seiten) $200-800/mo (verwaltetes WP) $25-75/mo (Supabase + Vercel)
Genesung nach Kompromittierung Vollständige Netzwerk-Sanierung Schlüssel rotieren, neu einsetzen

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

So funktioniert das Routing in der Praxis mit Next.js:

// 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? 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 Sie ISR (Incremental Static Regeneration) verwenden, wird es innerhalb Ihres Revalidierungsfensters ohne Build angezeigt.

Einen Standort entfernen? DELETE FROM locations WHERE slug = 'portland-or'; Kaskadierende Löschungen kümmern sich um den Rest. Kein 4-8-Stunden-Extraktionsprozess.

Für benutzerdefinierte Domains pro Standort behandelt Next.js Middleware 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',
  // ... in der Produktion von Edge Config 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 fragile Mapping-Tabellen. Nur eine Rewrite-Regel am Edge.

Migrationspfad: Weg von WordPress Multisite

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

Phase 1: Datenexport (1-2 Wochen)

Extrahuieren Sie Inhalte aus jedem Subsite mit der WordPress REST API oder WP-CLI. Versuchen Sie nicht, Tabellen mit Präfix manuell neu zu mappieren. Verwenden Sie die API — sie abstrahiert das Präfix-Albtraum.

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

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

Phase 2: Schema-Design (1 Woche)

Designen Sie Ihr Supabase-Schema um Ihr tatsächliches Inhaltsmodell, nicht um WordPresss Post/Postmeta-Modell. Dies ist der Moment, um Jahre angesammelter Schulden im Datenmodell zu beheben.

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

Schreiben Sie Migrations-Scripts, die WordPress-Inhalte in Ihr neues Schema umwandeln. Handhaben Sie serialisierte Daten, Shortcodes und Gutenberg-Blöcke.

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

Bauen Sie das Next.js Frontend. Hier sehen Sie die tatsächlichen Leistungsgewinne. Seiten, die 1,5 Sekunden in WordPress dauerten, laden jetzt unter 200ms.

Phase 5: DNS-Umstellung (1 Tag)

Weisen Sie Ihre Domains auf die neue Infrastruktur. Behalten Sie das alte Netzwerk 30 Tage als schreibgeschützte Sicherung.

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

Echte Zahlen: Vergleich von Leistung und Kosten

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

Metrik WordPress Multisite (Vorher) Next.js + Supabase (Nachher)
Durchschnittliches TTFB 1.240ms 89ms
Largest Contentful Paint 3,8s 1,1s
Monatliche Hosting-Kosten $347/mo (WP Engine) $45/mo (Vercel Pro + Supabase Pro)
Zeit zum Hinzufügen eines neuen Standorts 2-3 Stunden (manuelles Setup) 15 Minuten (Zeile einfügen + Inhalt)
Zeit zum Aktualisieren aller Standorte Plugin-Update + Gebet git push
Core Web Vitals Bestehensquote 12 von 34 Standorten 34 von 34 Standorten
Sicherheitsvorfälle (12 Monate) 3 0

Allein die Hosting-Kostenreduktion bezahlte die Migration innerhalb von 8 Monaten. Die Leistungsverbesserungen führten zu messbaren Steigerungen der lokalen Suchrankings für 28 der 34 Standorte innerhalb von 90 Tagen.

Wenn Sie Kosten für Ihr eigenes Netzwerk bewerten, 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 wurde nicht für Multi-Location-Unternehmen konzipiert, die unabhängigen Betrieb, Datenisolation oder hohe Leistung im Maßstab benötigen. Die gemeinsame Datenbank-Architektur erzeugt Sicherheits-, Leistungs- und operative Probleme, die sich mit jedem Standort, den Sie hinzufügen, verschärfen.

Was sind die größten Probleme mit WordPress Multisite?

Die sieben großen Probleme sind: gemeinsame Schwachstellenfläche (ein Exploit trifft alle Seiten), Plugin-Konflikt-Multiplikation (ein Konflikt nimmt jede Seite runter), nicht-lineare Leistungsabbau, Albtraum-Migrations-/Extraktionsprozesse, Nulldaten-Isolierung auf Datenbank-Ebene, Super-Admin-Bottleneck für alle administrativen Änderungen und fragile Domain Mapping. Diese Probleme sind architektonisch — sie können nicht mit Plugins oder besserem Hosting behoben werden.

Kann WordPress Multisite 100+ Websites handhaben?

Technisch ja. Praktisch wird es sehr schmerzhaft nach 30-50 Websites. Bei 100 Websites befassen Sie sich mit 1.100+ Datenbanktabellen in einer einzelnen MySQL-Instanz, schwerem Query Planner Abbau, und operativer Komplexität, die dem dedizierten DevOps-Personal bedarf. Bei 500 Websites ist es ein Non-Starter für die meisten Hosting-Umgebungen.

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 Leistung, niedrigere Hosting-Kosten und triviale Standortverwaltung. Jeder Standort ist eine Datenbankzeile, nicht eine ganze WordPress-Installation.

Wie migrieren Sie 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, Tabellen mit Präfix manuell neu zu mappieren. Exportieren Sie Inhalte pro Subsite, entwerfen Sie ein sauberes Schema in Ihrer Zieldatenbank, schreiben Sie Transformations-Scripts, bauen Sie das neue Frontend, und schneiden Sie den DNS um. Planen Sie für 6-10 Wochen insgesamt für ein Netzwerk mit 20+ Websites.

Beeinflusst WordPress Multisite SEO?

Indirekt ja. WordPresss Multisite Leistungsabbau führt zu langsameren Seiten-Ladevorgängen, die Core Web Vitals Scores beeinträchtigen. Google hat bestätigt, dass Page Experience Signale Rankings beeinflussen. In unseren Migrations-Daten sahen 82% der Standorte verbesserte lokale Such-Rankings innerhalb von 90 Tagen nach dem Umzug zu einer Headless-Architektur mit unter-200ms TTFB.

Ist WordPress Multisite sicher für Geschäftsdaten?

Nein, wenn Sie Sicherheit als einschließlich Datenisolation zwischen Standorten definieren. WordPress Multisite nutzt eine Datenbank mit einem Satz von Anmeldedaten. Eine SQL-Injection auf einem Subsite kann auf jeden anderen Subsite Daten zugreifen. Für Unternehmen unterworfen HIPAA, SOC 2, PCI DSS oder ähnliche Compliance-Anforderungen, ist der Mangel an Datenbank-Isolierung eine signifikante Haftung.

Wie viel kostet es, WordPress Multisite gegenüber einer Headless-Alternative zu betreiben?

Verwaltetes WordPress-Hosting für Multisite kostet typisch $200-800/Monat abhängig von der Anzahl der Websites und Verkehrsniveaus (WP Engines Multisite-Pläne starten bei $240/mo für ihren Growth Tier in 2026). Eine vergleichbare Headless-Installation auf Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) handhabe den gleichen Verkehr für einen Bruchteil der Kosten. Die anfängliche Build-Investition ist höher für den Headless-Ansatz, aber monatliche Betriebskosten sind deutlich niedriger. Fühlen Sie sich frei, uns zu kontaktieren wenn Sie einen spezifischen Kostenvergleich für Ihre Netzwerkgröße möchten.