WordPress Multisite naar Next.js Migratie

WordPress Multisite Was een Goed Idee in 2012

WordPress Multisite had in 2012 veel zin. In 2026 maakt elke subsite die je toevoegt de migratie die je uiteindelijk nodig hebt alleen maar moeilijker. De vooraf gegeven tabellen groeien. De geserialiseerde gegevens stapelen op. De domeinmappingplugin voegt een extra afhankelijkheid toe. Elk jaar op Multisite is een jaar technische schuld die je terug betaalt tijdens migratie.

De vraag is niet of je zult migreren. Het is wanneer.

We hebben Multisite-netwerken met 5 subsites gemigreerd en netwerken met 80+. Het technische patroon is elke keer hetzelfde: voorgegeven tabellen extraheren, jaren verzamelde opties-gegevens deserialiseren, gedeelde gebruikers toewijzen aan een modern authentificatiesysteem, en een multi-tenant architectuur bouwen die daadwerkelijk schaalt. Het verschil is omvang, niet complexiteit.

Waarom WordPress Multisite Verlaten

Multisite-netwerken verzamelen specifieke categorieën technische schuld die in de loop van de tijd samenhangen.

Voorgelegen Tabellen Proliferatie

Elke subsite maakt een eigen set tabellen: wp_2_posts, wp_2_postmeta, wp_2_options, wp_3_posts, enzovoort. Een netwerk met 25 sites heeft 250+ tabellen. Het opvragen van gegevens over subsites heen vereist unions over allemaal. Er is geen native cross-site zoeken, geen uniforme content API, geen manier om te aggregeren zonder aangepaste SQL.

Geserialiseerde Gegevens Overal

WordPress slaat complexe gegevens op als PHP geserialiseerde strings. ACF-veldgroepen, widget-instellingen, site-URL's, plugin-instellingen — allemaal geserialiseerd. Deze strings coderen stringlengtes (s:23:"https://old-domain.com"), wat betekent dat je geen eenvoudige zoeken-en-vervangen op URL's kunt doen zonder de serialisatie te verbreken. Elke migratie die geserialiseerde gegevens aanraakt, vereist juiste deserialisatie, transformatie en re-serialisatie. Geen snelkoppelingen.

Gedeelde Gebruikers, Gefragmenteerde Rollen

De wp_users tabel is netwerkwijd. Een gebruiker kan een beheerder zijn op subsite 2, een editor op subsite 5 en een abonnee op subsite 12. Die rollen leven als geserialiseerde arrays in wp_usermeta onder sleutels zoals wp_2_capabilities. Dit extraheren in een zinvol verificatiemodel betekent het parseren van de rol van elke gebruiker per subsite — wat net zo vervelend is als het klinkt.

Plugin- en Update-Kwetsbaarheid

Netwerkgeactiveerde plugins beïnvloeden alle subsites tegelijk. Een plugin-update die één subsite breekt, breekt het beheerdersgedeelte voor alle subsites. Site-specifieke plugins creëren versieconflicten. De gedeelde codebase betekent dat elke wijziging een potentieel netwerkwijd uitval is.

Prestatievermindering op Schaal

Multisite-netwerken met 10+ subsites zien 40-60% langzamere paginalaadtijden in vergelijking met zelfstandige WordPress-installaties. Geserialiseerde gegevensparsering, gedeelde databaseverbindingen en plugin-overhead stapelen allemaal op. Lighthouse mobiele scores landen doorgaans tussen 35-55. Niet geweldig.

Wat Je Krijgt: Next.js + Supabase Multi-Tenant Architectuur

De doelarchitectuur vervangt het volledige Multisite-netwerk door een enkele Next.js-toepassing ondersteund door Supabase, met behulp van Row Level Security voor tenant-isolatie.

Routegebaseerde Multi-Tenancy

In plaats van subdomeinen of submappen beheerd door WordPress, krijgt elke locatie een schone route: /locations/[slug]. Gedeelde componenten (navbar, footer, merkelementen) worden weergegeven vanuit een enkele layout. Locatiespecifieke inhoud haalt gegevens uit Supabase gefilterd op location_id. Één codebase, één implementatie, onbeperkte locaties.

Supabase RLS voor Gegevensisolatie

Row Level Security-beleid zorgt ervoor dat locatiebeheerders alleen hun eigen gegevens zien, terwijl netwerkbeheerders alles zien. Geen hacks op toepassingsniveau filteren. De database zelf dwingt toegang af:

CREATE POLICY "location_isolation" ON posts
  FOR ALL USING (
    auth.uid() IN (
      SELECT user_id FROM user_locations
      WHERE location_id = posts.location_id
    )
  );

Dit elimineert een hele klasse autorisatiebugs die multi-tenant WordPress-setups teisteren.

Modern Beheerdashboard

Locatiebeheerders krijgen een speciaal gebouwd dashboard: locaties toevoegen, inhoud per locatie bewerken, media beheren. Niet meer klikken via WordPress's netwerkbeheerderswisselaar. Niet meer "Super Admin" versus "Site Admin" verwarring.

Ons 7-Fase Migratieproces

Fase 1: Netwerkaudit (1-2 Weken)

We brengen elke subsite in uw netwerk in kaart — URL-structuur, inhoudvolume, gebruikte plugins, aangepaste inhoudstypen, aangepaste velden, domeinmappingconfiguratie. We vragen wp_blogs op om subsites op te sommen, vervolgens crawlen we elk via REST API en directe databasequery's.

We identificeren gedeelde inhoud (netwerkwijd) versus site-specifieke inhoud. Gedeelde plugins versus site-specifieke plugins. Aangepaste code in onderliggende thema's, mu-plugins en netwerkgeactiveerde plugins met aangepaste functionaliteit.

De uitvoer is een migratiespecificatiedocument met een subsite-voor-subsite-inhoudsinventaris.

Fase 2: Architectuurontwerp (1 Week)

We ontwerpen het Supabase-schema: locations tabel, inhoudsdata met location_id buitenlandse sleutels, RLS-beleid per tabel. We ontwerpen de Next.js-routestructuur en wijzen elke oude URL toe aan het equivalente nieuwe voor 301-omleidingen.

Het beheerdashboard wordt geschetst: locatiebeheer, per-locatie inhoudbewerking, op rollen gebaseerde toegang. Elke beslissing wordt gedocumenteerd voordat we een regel code schrijven.

Fase 3: Inhoudexport (1-2 Weken)

Dit is waar Multisite-migraties technisch worden. We extraheren inhoud via twee kanalen:

WP REST API voor standaardinhoud — geverifieerde aanvragen per subsite, paginering over duizenden berichten.

Directe databasequery's voor alles wat de API niet kan weergeven: ACF-velden opgeslagen in wp_2_postmeta, aangepaste tabellen gemaakt door plugins, geserialiseerde opties met kritieke configuratie.

Geserialiseerde gegevens worden verwerkt via PHP's unserialize() of Python's phpserialize bibliotheek. Domeinverwijzingen ingebed in geserialiseerde opties (siteurl, home) worden bijgewerkt voordat ze opnieuw wordt geserialiseerd. Een naïeve zoeken-en-vervangen op geserialiseerde strings beschadigt de lengtevoorvoegsels en breekt alles — we hebben dit fout zien gaan, en het opruimen is verschrikkelijk.

Mediabestanden worden gedownload door /wp-content/uploads/sites/[id]/ per subsite te doorlopen. Gebruikers worden geëxporteerd uit de netwerkwijde wp_users tabel met per-site mogelijkheden geparst uit geserialiseerde wp_usermeta vermeldingen.

Uitvoer: JSON- en CSV-bestanden per subsite met alle inhoud, gebruikers en media geïnventariseerd.

Fase 4: Bouwen (2-6 Weken)

De Next.js-toepassing neemt vorm aan met routegebaseerde multi-tenancy. Supabase-tabellen worden gemaakt met RLS-beleid afgedwongen. Gedeelde layoutcomponenten handhaven merksamenhang. Per-locatie paginasjablonen renderen gelokaliseerde inhoudszones.

Het beheerdashboard ondersteunt het toevoegen van locaties, het bewerken van locatie-inhoud en het weergeven van samengevoegde gegevens op alle locaties. Contactformulieren, boeking-integraties en inbeddingen van derden worden opnieuw gebouwd of gemigreerd.

De tijdlijn hangt af van complexiteit: een netwerk met 5 subsites met standaardpagina's duurt 2 weken. Een netwerk met 40 subsites met aangepaste boekingssystemen, ledengebieden en complexe ACF-layouts duurt 6 weken.

Fase 5: Inhoudimport (1-2 Weken)

Alle inhoud wordt batch-geïmporteerd in Supabase met location_id toewijzing. Elke wp_2_ voorgelegen tabel wijst toe aan location ID 2. Media-URL's worden herschreven van /uploads/sites/23/image.jpg naar Supabase Storage-paden of nieuwe CDN-URL's met behulp van regex-transformaties over alle inhoudsvelden.

WordPress-gebruikers worden toegewezen aan Supabase Auth. Wachtwoord-hashes worden bewaard — bcrypt-rehashing vindt plaats bij eerste login, dus gebruikers hoeven hun wachtwoord niet opnieuw in te stellen.

We valideren door 10% van de inhoud per subsite tegen het origineel te controleren.

Fase 6: Omleidingstoewijzing (1 Week)

Elke oude URL over alle subsites heen krijgt een toewijzing naar zijn nieuwe URL. Voor domeinkaart-subsites wordt het oude domein omgeleid naar het nieuwe /locations/[slug] pad met een 301. Oude subdomeinen (site2.example.com) worden omgeleid naar /locations/site2.

We crawlen elke oude sitemap en verifiëren dat voor elke URL een 301 bestaat. Nieuwe sitemaps worden per vorig domein ingediend bij Google Search Console.

Fase 7: Start en Controle

DNS-cutover gebeurt per domein. SSL-certificaten worden automatisch ingericht via Vercel. Google Search Console krijgt nieuwe domeineigenschappen met verse sitemaps. We controleren 30 dagen: indexeringsvoortgang, Core Web Vitals basislijnen, 404-tracking.

De oude WordPress-database wordt gearchiveerd. Hosting wordt geannuleerd na een 60-daagse controleperiode bevestigt dat alles stabiel is.

SEO-behoudstrategie

Multisite-migraties dragen echt SEO-risico — je wijzigt mogelijk URL's over tientallen domeinen tegelijk. Onze aanpak:

• Uitputtende 301-toewijzing — elke URL, elke subsite, elk domein. Geen 404's.
• Sitemap-indiening per domein — elk vorig domein krijgt een eigen sitemap ingediend bij GSC.
• Canonieke tag consistentie — nieuwe pagina's dragen juiste canonicals van dag één.
• Inhoudpariteitsverificatie — automatische diffing zorgt ervoor dat geen inhoud tijdens import verloren gaat of wordt afgekapt.
• Backlink-behoud — we auditen backlinks per subsite en zorgen ervoor dat 301's alle binnenkomende linkequity vastleggen.

Klanten zien doorgaans 25-50% organische verkeerverbetering binnen 90 dagen, grotendeels door Core Web Vitals-winsten alleen.

Tijdlijn en Prijzen

Netwerkgrootte	Subsites	Tijdlijn	Investering
Klein	5-10	4-6 weken	€15.000 - €30.000
Gemiddeld	10-25	6-8 weken	€30.000 - €60.000
Groot	25-50	8-12 weken	€60.000 - €100.000
Enterprise	50+	10-16 weken	€80.000 - €150.000+

Prijzen schalen met het volume geserialiseerde gegevens, aangepaste inhoudstypen, gebruikersrolcomplexiteit en integraties van derden per subsite. Netwerken met zware ACF-gebruik of aangepaste plugin-functionaliteit neigen naar de hogere kant.

Elk engagement begint met een gratis migratieaudit. We brengen uw netwerk in kaart, schatten omvang, en geven u een vast-prijsvoorstel voordat werk begint.