WordPress Multisite klinkt alsof je meerdere sites krijgt. Wat je eigenlijk krijgt is één WordPress-installatie die doet alsof het meerdere sites zijn door een nummer voor databasetabelnamen te zetten. Je hoofdsite gebruikt wp_posts. Subsite 2 gebruikt wp_2_posts. Subsite 3 gebruikt wp_3_posts. Dat is geen multi-site architectuur. Dat is één database met genummerde kopieën van dezelfde tabellen. En dat heeft gevolgen.

Ik heb netwerken gemigreerd met 15, 40, en een keer 87 subsites weg van WordPress Multisite. Elke keer dacht de klant dat ze onafhankelijke sites kregen. Elke keer ontdekten ze op de harde manier dat dat niet het geval was. Als je een franchise, een bedrijf met meerdere locaties, of een universiteitsdeelnetwerk op WordPress Multisite runt, zal dit artikel wat pijn doen. Maar het is beter om het nu te weten dan nadat subsite #47 alle 46 andere sites nekt.

Inhoudsopgave

WordPress Multisite Is Not Multi-Site: Architectuur die tot 500 locaties scaalt

Wat WordPress Multisite werkelijk doet onder de motorkap

Laten we kijken wat er gebeurt wanneer je Multisite inschakelt in WordPress. Je voegt een paar regels toe aan wp-config.php:

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 maakt dan een paar netwerkbrede tabellen aan (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) en begint je kernstructuur van tabellen voor elke nieuwe subsite te dupliceren.

Zo ziet de database eruit na slechts 5 subsites:

wp_posts              (hoofdsite)
wp_postmeta           (hoofdsite)
wp_options            (hoofdsite)
wp_users              (gedeeld - alle sites)
wp_usermeta           (gedeeld - alle sites)
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)

Vijf subsites en je hebt al ongeveer 55 tabellen. Vijftig subsites? Dan kijk je aan tegen meer dan 500 tabellen in een enkele MySQL-database. Vijfhonderd locaties? Ruim 5.000 tabellen. In één database. Die één verbindingspool delen.

Elke tabel heeft zijn eigen indexen. Elke query richt zich op een specifieke voorgevoeegde tabel. De query planner moet hiermee omgaan. En elk van die tabellen is toegankelijk voor elk PHP-proces dat op die server draait, omdat ze allemaal in dezelfde database staan met dezelfde inloggegevens.

Dit is geen multi-site architectuur. Dit is een naamgevingsconventie die zich voordoet als isolatie.

De 7 gevolgen van valse multi-site architectuur

1. Gedeeld kwetsbaarheidsoppervlak

Elke subsite in een WordPress Multisite-netwerk runt dezelfde WordPress-kern, dezelfde plugins en dezelfde thema's. Een plug-in exploitatie compromitteert alle subsites omdat ze dezelfde codebase delen.

Dit is niet theoretisch. In februari 2026 had WPVivid — een backup-plugin met meer dan 900.000 actieve installaties — een RCE-kwetsbaarheid (Remote Code Execution) met ernst 9,8 openbaar gemaakt. Ernst 9,8 van de 10. Dat is "een niet-geverifieerde aanvaller kan willekeurige code op je server uitvoeren" terrein.

Op een zelfstandige WordPress-site is dat één gecompromitteerde site. Op een Multisite-netwerk met 30 subsites? Dat zijn 30 gecompromitteerde sites. Dezelfde server. Dezelfde database. Hetzelfde bestandssysteem. Eén exploit, volledig netwerkcompromis.

Je kunt niet een ander versie van een plugin op subsite #12 installeren dan op subsite #13. Je kunt plugins van één locatie niet isoleren van een ander. Elke site krijgt dezelfde aanvalsoppervlak.

2. Vermenigvuldigde plugin-conflicten

Op een enkele WordPress-site breekt een plugin conflict één site. Je deactiveert de plugin, diagnosticeert, en gaat verder. Vervelend maar beheersbaar.

Op Multisite breekt een geactiveerde netwerkplugin conflict elke site tegelijk. Ik heb gezien dat een WooCommerce update op een Multisite-netwerk 23 locatiepagina's tegelijk nekt omdat een geactiveerde cachingplugin niet was bijgewerkt voor de nieuwe WooCommerce hooks. Drieëntwintig locaties met verbroken pagina's. Eén hoofdoorzaak, drieëntwintig boze locatiebeheerders die dezelfde persoon bellen.

En hier is het grappige — individuele sitebeheerders kunnen meestal geactiveerde netwerkplugins niet deactiveren. Ze moeten wachten tot de Super Admin het opfixt.

3. Prestatievermindering

Vijftig subsites die één MySQL-instantie delen. Elke paginalaadbeurt op subsite #47 voert queries uit zoals:

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);

Ondertussen voert subsite #12 zijn eigen set queries uit tegen wp_12_posts, wp_12_options en wp_12_postmeta. En zo ook elke andere subsite, allemaal tegen dezelfde MySQL-instantie.

MySQLs query planner raakt in verwarring. Tabelcache loopt vol. Elke voorgevoeegde tabel onderhoudt zijn eigen indexen, maar de buffergroep is gedeeld. Prestaties verslechteren niet-lineair naarmate je subsites toevoegt. Van 10 naar 20 subsites gaan is niet twee keer zo veel belasting — het kan drie of vier keer zoveel belasting zijn, afhankelijk van verkeerspatronen, vanwege vergrendelingsconflicten en bufferggroepgijzeling.

Ik benchmarkde eens een 40-subsite netwerk. Gemiddelde querytijd op subsite #1 was 45ms. Tegen de tijd dat we subsite #38 testten, was de gemiddelde querytijd gestegen tot 380ms. Dezelfde querystructuur. Dezelfde gegevenshoeveelheid per site. De database verdronk gewoon in tabellen.

4. Migratie is een nachtmerrie

Probeer subsite #23 uit een 50-sites netwerk te extraheren in zijn eigen zelfstandige WordPress-installatie. Dit is wat je moet doen:

  1. Exporteer alle wp_23_ voorgevoeegde tabellen
  2. Map elke tabel opnieuw van wp_23_ voorvoegsel naar wp_ voorvoegsel
  3. Reserialiseer alle opties en widget gegevens (WordPress slaat geserialiseerde PHP in de database op, en stringlengten veranderen wanneer je voorvoegsels wijzigt)
  4. Map mediapaden opnieuw van /uploads/sites/23/ naar /uploads/
  5. Zoek en vervang alle interne URL's
  6. Map gebruikersmogelijkheden opnieuw van wp_23_capabilities naar wp_capabilities in wp_usermeta
  7. Extraheer gebruikers uit de gedeelde wp_users tabel (alleen de gebruikers die tot subsite #23 behoren)
  8. Recreëer gebruiker-naar-site relaties

Eén fout in serialisatie en je krijgt beschadigde gegevens. Widget instellingen verdwijnen. Thema customizer-opties breken. Menustructuren verdwijnen. Ik heb dit extractieproces tientallen keren gedaan, en het kost 4-8 uur per subsite, zelfs met tools zoals WP Migrate DB Pro. Vermenigvuldig dat met 50 subsites als je een netwerk buiten bedrijf stelt.

Het WordPress-ecosysteem heeft tools hiervoor, zeker. Maar het feit dat deze tools moeten bestaan zegt iets over de architectuur.

5. Geen echte gegevensafscherming

Dit is degene die je zou moeten verschrikken als je iets geeft om beveiliging of naleving.

Een SQL injection-kwetsbaarheid op subsite #2 stelt niet alleen wp_2_posts bloot. De databasegebruiker die verbinding maakt met MySQL heeft toegang tot elke tabel in de database. Dit betekent wp_posts (hoofdsite), wp_3_posts (subsite 3), wp_users (alle gebruikers op alle sites) en elke andere tabel.

Er is geen databaseniveauafscherming. Geen rij-niveau beveiliging. Geen schemaafscheiding. WordPress Multisite is één database, één set inloggegevens en een naamgevingsconventie. Dat is het.

Voor bedrijven die gegevens van klanten op meerdere locaties verwerken — medische praktijken, advocatenkantoren, financiële diensten — dit is een nalevingsprobleem. HIPAA, SOC 2 en PCI DSS hebben allemaal vereisten rond gegevensafscherming. "We gebruikten verschillende tabelvoorwoegels" zal een auditor niet tevredenstellen.

6. Super Admin-bottleneck

WordPress Multisite heeft een rol genaamd Super Admin. Alleen de Super Admin kan:

  • Plugins installeren of verwijderen
  • Thema's installeren of verwijderen
  • Plugins netwerkwijd activeren
  • Nieuwe sites aan het netwerk toevoegen
  • Netwerkinstellingen beheren

Individuele sitebeheerders hebben beperkte mogelijkheden. Ze kunnen hun eigen plugins niet installeren. Ze kunnen hun eigen thema's niet toevoegen. Elke wijziging die de gedeelde infrastructuur aanraakt, gaat via één persoon (of een klein team).

Voor een 3-sites netwerk is dit prima. Voor een 50-locatie franchise waarbij elke locatiebeheerder zijn eigen boekingswidget of menu-PDF-plugin wil toevoegen? Het is een bottleneck die ressentiment en schaduw-IT voortbrengt.

7. Domeinmappingbrosheid

Wil elke locatie zijn eigen domein? denver.yourbrand.com of yourbrand-denver.com? WordPress Multisite handelt dit niet native op een betrouwbare manier af. Je hebt een domeinmappingoplossing nodig, en de ingebouwde sunrise.php dropin-aanpak is beruchte wispelturig.

SSL-certificaten voor toegewezen domeinen voegen nog een laag toe. DNS-configuratie voegt nog een toe. Elk toegewezen domein is nog een potentieel storingspunt dat je Super Admin moet beheren. Eén DNS-wijziging, één verlopen certificaat, één verkeerd geconfigureerde mappingvermelding, en de site van een locatie gaat uit.

Wanneer WordPress Multisite werkt (eerlijk gezegd)

Ik ga niet pretenderen dat het nutteloos is. WordPress Multisite werkt goed in specifieke scenario's:

  • Kleine netwerken (onder 10 sites) waar alle sites door hetzelfde team worden beheerd
  • Universitaire deelsites waar gecentraliseerde controle werkelijk gewenst is
  • Dev/staging/production spiegels voor hetzelfde project
  • Blog netwerken waar content-afscheiding niet kritiek is

Als je 5-8 sites hebt, een deskundige systeemadministrator, en je hebt geen gegevensafscheiding tussen sites nodig — Multisite is prima. De problemen beginnen wanneer je het probeert te schalen naar tientallen of honderden locaties.

WordPress Multisite Is Not Multi-Site: Architectuur die tot 500 locaties scaalt - architectuur

De architectuur die werkelijk tot 500 locaties scaalt

Hier is de alternatieve aanpak die we bij Social Animal gebruiken voor bedrijven met meerdere locaties: een headless architectuur met Next.js op de frontend en Supabase (PostgreSQL) op de backend, met Row-Level Security (RLS) voor echte gegevensafscheiding.

Het kernidee: in plaats van tabellen voor elke locatie te dupliceren, heb je één set tabellen met een location_id kolom. Databaseniveaubeveiligingsbeleid zorgt ervoor dat queries alleen gegevens voor de geautoriseerde locatie retourneren. En in plaats van 500 afzonderlijke WordPress-installaties die doen alsof ze onafhankelijk zijn, heb je één toepassingsoplosting waarbij /locations/[slug] dynamisch de pagina van elke locatie uit een databaserij rendert.

Hoe Row-Level Security werkelijk werkt

-- Maak de locatietabel aan
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()
);

-- Maak de paginatabel aan met locatieafscheiding
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()
);

-- Schakel RLS in
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Beleid: locatiebeheerders kunnen alleen de pagina's van hun eigen locatie zien
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Beleid: publiek kan gepubliceerde pagina's voor elke locatie lezen
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Met deze opzet kan een locatiebeheerder in Denver die op de een of andere manier een kwaadaardig query opstelt fysiek niet de gegevens van Austin benaderen. De database dwingt het af. Niet de toepassingslaag. Niet een naamgevingsconventie. De database zelf.

Architectuurvergelijking: voorgevoeegde tabellen versus rij-niveau beveiliging

Hier is een visuele weergave van de twee architecturen:

WordPress Multisite architectuur:

┌─────────────────────────────────────────────┐
│           Enkele MySQL-database              │
│                                             │
│  wp_posts          (hoofdsite)              │
│  wp_options        (hoofdsite)              │
│  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 locaties = 5.000+ tabellen       │
│                                             │
│  ⚠️  EENS set databaseinloggegevens          │
│  ⚠️  EEN PHP-proces benadert ALLE tabellen   │
│  ⚠️  NULAFSCHEIDING op databaseniveau       │
└─────────────────────────────────────────────┘

Next.js + Supabase architectuur:

┌─────────────────────────────────────────────┐
│         Enkele PostgreSQL-database           │
│                                             │
│  locations    (500 rijen, één per locatie)  │
│  pages        (content per locatie)         │
│  media        (afbeeldingen per locatie)    │
│  staff        (team per locatie)            │
│  reviews      (reviews per locatie)         │
│                                             │
│  ✅  RLS-beleid dwingt afscheiding af       │
│  ✅  Denver-gebruiker KAN Austin gegevens NIET opvragen  │
│  ✅  5 tabellen totaal, niet 5.000          │
│  ✅  Standaardindexen, optimale queryplannen │
└─────────────────────────────────────────────┘

Eén database in beide gevallen. Maar het isolatiemodel is fundamenteel anders. RLS wordt afgedwongen op het PostgreSQL engineniveau — het is niet iets dat de toepassing kan omzeilen.

Factor WordPress Multisite Next.js + Supabase
Tabellen bij 500 locaties ~5.500+ ~5-15
Gegevensafscheiding Geen (alleen naamgevingsconventie) Op database afgedwongen RLS
Kwetsbaarheidsopp oppervlak Eén exploit = alle sites Per-locatie auth-afscheiding
Plugin-conflicten Netwerkwijd uitval N/B (geen plugin-architectuur)
Een locatie toevoegen Subsite maken + configureren Databaserij invoegen
Een locatie verwijderen Ingewikkeld extractieproces Rijen verwijderen met CASCADE
Domeinmapping Plugin vereist, broos Middleware herschrijven, native
Build/deploy-tijd N/B (runtime PHP) ~30s incrementele build
TTFB (gem., niet in cache) 800ms-2s+ 50-150ms (edge)
Maandelijkse hosting (500 sites) $200-800/mo (beheerde WP) $25-75/mo (Supabase + Vercel)
Herstel na compromis Volledige netwerkremediëring Sleutels roteren, opnieuw oplosten

Implementatie: Next.js + Supabase voor sites met meerdere locaties

Hier is hoe de routering in de praktijk werkt met 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>
  );
}

Een nieuwe locatie toevoegen? Voeg een rij in:

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"}'
);

Dat is het. De volgende build pikt het op. Of als je ISR (Incremental Static Regeneration) gebruikt, wordt het weergegeven binnen je hervalidatievenster zonder een build.

Een locatie verwijderen? DELETE FROM locations WHERE slug = 'portland-or'; Cascadedeletes handelen de rest af. Geen 4-8 uur extractieproces.

Voor aangepaste domeinen per locatie handelt Next.js middleware het netjes af:

// 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',
  // ... geladen van edge config in productie
};

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();
}

Geen plugins. Geen sunrise.php dropin. Geen broze mappingtabellen. Gewoon een herschrijfregel aan de edge.

Migratiepad: weg van WordPress Multisite

Als je momenteel op WordPress Multisite zit met 20+ locaties, hier is het realistische migratiepad:

Fase 1: Gegevensexport (1-2 weken)

Extraheer content uit elke subsite met behulp van de WordPress REST API of WP-CLI. Probeer niet handmatig voorgevoeegde tabellen opnieuw in te delen. Gebruik de API — deze abstraheert de voorvoegselnachtmerrie.

# Exporteer alle berichten van subsite 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Exporteer alle media
wp media list --url=example.com/location-23 --format=json > location-23-media.json

Fase 2: Schemaontwerp (1 week)

Ontwerp je Supabase-schema rond je werkelijke inhoudsmodel, niet het post/postmeta-model van WordPress. Dit is het moment om jaren van opgebouwde gegevensmodeldschuld op te ruimen.

Fase 3: Content-migratie (1-2 weken)

Schrijf migratiescripts die WordPress-content transformeren in je nieuwe schema. Behandel geserialiseerde gegevens, shortcodes en Gutenberg-blokken.

Fase 4: Frontend-build (3-4 weken)

Bouw de Next.js frontend. Dit is waar je de werkelijke prestatieverbesseringen ziet. Pagina's die 1,5 seconden op WordPress kostten, laden nu in onder 200ms.

Fase 5: DNS-overschakeling (1 dag)

Wijs je domeinen naar de nieuwe infrastructuur. Houd het oude netwerk 30 dagen als read-only backup actief.

Voor bedrijven die hulp bij dit migratieproces nodig hebben, hebben we onze aanpak gedocumenteerd op onze headless CMS-ontwikkelingspagina. We hebben genoeg van deze migraties gedaan om te weten waar de lijken zijn begraven.

Echte cijfers: prestaties en kostenvergelijking

Hier zijn gegevens van een werkelijke migratie die we in Q1 2025 hebben voltooid — een tandartspraktijknetwerk met 34 locaties:

Metriek WordPress Multisite (voor) Next.js + Supabase (na)
Gemiddelde TTFB 1.240ms 89ms
Grootste inhoudsvolle verf 3,8s 1,1s
Maandelijkse hostingkosten $347/mo (WP Engine) $45/mo (Vercel Pro + Supabase Pro)
Tijd om een nieuwe locatie toe te voegen 2-3 uur (handmatige setup) 15 minuten (rij invoegen + content)
Tijd om alle locaties bij te werken Plugin update + hoop git push
Core Web Vitals-slaagpercentage 12 van 34 locaties 34 van 34 locaties
Beveiligingsincidenten (12 maanden) 3 0

De verlaging van hostingkosten alleen betaalde de migratie binnen 8 maanden terug. De prestatieverbesseringen leidden tot meetbare stijgingen in lokale zoekrankings voor 28 van de 34 locaties binnen 90 dagen.

Als je kosten voor je eigen netwerk evalueert, heeft onze prijzingspagina transparante uitsplitsingen voor projecten op meerdere locaties.

Veelgestelde vragen

Is WordPress Multisite goed voor het beheren van meerdere locaties? Voor een klein aantal locaties (onder 10) met gecentraliseerd beheer kan WordPress Multisite werken. Maar het is niet ontworpen voor bedrijven met meerdere locaties die onafhankelijke werking, gegevensafscheiding of hoge prestaties op schaal nodig hebben. De gedeelde databasearchitectuur creëert beveiligings-, prestatie- en operationele problemen die verergeren met elke locatie die je toevoegt.

Wat zijn de grootste problemen met WordPress Multisite? De zeven belangrijkste problemen zijn: gedeeld kwetsbaarheidsopp oppervlak (één exploit raakt alle sites), plug-in conflictmultiplicatie (één conflict nekt elke site), niet-lineaire prestatievermindering, nachtmerrie migratie/extractieprocessen, nulgegevensafscheiding op databaseniveau, Super Admin-bottleneck voor alle administratieve wijzigingen en broze domeinmapping. Deze problemen zijn architectonisch — ze kunnen niet met plugins of beter hosten worden opgelost.

Kan WordPress Multisite 100+ sites aan? Technisch gezien ja. Praktisch wordt het zeer pijnlijk na 30-50 sites. Bij 100 sites heb je meer dan 1.100 databasetabellen in een enkele MySQL-instantie, ernstige queryplanner-degradatie en operationele complexiteit die speciale DevOps-medewerkers vereist. Bij 500 sites is het voor de meeste hostingomgevingen geen optie.

Wat is het beste alternatief voor WordPress Multisite voor meerdere locaties? Een headless architectuur met Next.js of Astro voor de frontend met een PostgreSQL-database (zoals Supabase) met Row-Level Security biedt echte gegevensafscheiding, dramatisch betere prestaties, lagere hostingkosten en triviaal locatiebeheer. Elke locatie is een databaserij, niet een hele WordPress-installatie.

Hoe migreer je van WordPress Multisite naar een headless architectuur? De veiligste aanpak is om content via de WordPress REST API of WP-CLI te extraheren in plaats van proberen handmatig voorgevoeegde databasetabellen opnieuw in te delen. Exporteer content per subsite, ontwerp een schoon schema in je doeldatabase, schrijf transformatiescripts, bouw de nieuwe frontend en schakel DNS over. Plan voor 6-10 weken totaal voor een netwerk met 20+ sites.

Beïnvloedt WordPress Multisite SEO? Indirect, ja. De prestatievermindering van WordPress Multisite leidt tot langzamere paginaladingen, wat Core Web Vitals scores raakt. Google heeft bevestigd dat seinalen van paginabeleving invloed hebben op rankings. In onze migratiegegevens zagen 82% van de locaties verbeterde lokale zoekrankings binnen 90 dagen na de verhuizing naar een headless architectuur met sub-200ms TTFB.

Is WordPress Multisite veilig voor bedrijfsgegevens? Nee, als je beveiliging definieert als inclusief gegevensafscheiding tussen locaties. WordPress Multisite gebruikt één database met één set inloggegevens. Een SQL-injectie op elke subsite kan de gegevens van elke andere subsite benaderen. Voor bedrijven onder HIPAA, SOC 2, PCI DSS of vergelijkbare nalevingsvereisten is het gebrek aan databaseniveauafscheiding een aanzienlijke aansprakelijkheid.

Hoeveel kost het om WordPress Multisite versus een headless alternatief te draaien? Beheerde WordPress-hosting voor Multisite wordt doorgaans $200-800/maand, afhankelijk van het aantal sites en verkeerniveaus (WP Engines Multisite-plannen beginnen in 2025 bij $240/mo voor hun Growth-tier). Een vergelijkbare headless-setup op Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) handelt hetzelfde verkeer voor een fractie van de kosten af. De initiële bouw-investering is hoger voor de headless-aanpak, maar maandelijkse operationele kosten zijn aanzienlijk lager. Voel je vrij om contact op te nemen als je een specifieke kostenvergelijking voor je netwerkgrootte wilt.