Je klant mailt om 21:00 uur: "Kunnen we volgende kwartaal Japans toevoegen?" Je maag valt in. Het Multisite-netwerk strompelt al onder 12 talen. De WPML-update heeft je Poolse lay-outs vorige maand verbroken. De gedeelde wp_options-tabel bereikt 840 MB en je staging-omgeving kost elf minuten om te klonen. Je hebt deze architectuur drie keer gerepareerd, en elk herstel maakt de volgende taalintroductie moeilijker. We draaiden deze exact setup — 91.000+ pagina's, 30 talen, bedrijfsbelasting — en hebben zowel Multisite als WPML volledig geschrapt. Geen plugin-verlengingen. Geen gedeelde tabellen. Geen kruistaalvermenging. De nieuwe stack wordt sneller verzonden, kost 40% minder te hosten, en schaalt zonder de angst. Hier is de architectuur die we echt hebben ingezet, wat kapotging bij migratie, en de vier besluiten die het werkend maken.

Dus we stopten met die manier. Vandaag bedient ons productiesysteem 30 talen over 118+ pagina's per landinstelling — dat zijn in totaal 91.000+ dynamische pagina's — zonder WordPress Multisite, zonder WPML, en zonder de jaarlijkse licensieringsangst die met beide komt. Een nieuwe taal toevoegen duurt ongeveer 45 minuten en kost ruwweg $22 in API-tokens.

Dit artikel is de volledige uitsplitsing. Architectuur, tooling, kosten, en het migratiepad dat we hebben verfijnd over meerdere bedrijfsprojecten.

Inhoudsopgave

Waarom WordPress Multisite uiteenvalt op schaal

WordPress Multisite werd in 2010 ontworpen voor het draaien van meerdere blogs op één installatie. Het was nooit ontworpen voor echte meertalige bedrijfsimplementaties. Hier is wat gebeurt wanneer je het onder druk zet:

Gedeelde database, gedeelde problemen. Elke site in een Multisite-netwerk deelt dezelfde wp_-database met vooraf ingestelde tabellen (wp_2_posts, wp_3_posts, enz.). Cross-site inhoudsdeling is fragiel. Een plugin-update op één site kan cascadestoringen veroorzaken in het hele netwerk. Ik heb gezien hoe één verkeerd geformatteerd migratescript 12 tailvarianten tegelijk platlegde.

Admin-complexiteit neemt toe. Elke subsite heeft zijn eigen admin-dashboard, maar ze zijn niet echt geïsoleerd. Super-admins zien alles. Site-admins zien te weinig. Er is geen schone manier om een Duitse content-team alleen toegang te geven tot hun inhoud zonder aangepaste rolbeheer dat bij elke grote WordPress-update breekt.

Plugin-compatibiliteit is een mijnenveld. Niet elke plugin is Multisite-compatibel. Wanneer je Spaanse site een formulierplugin nodig heeft die niet goed werkt met Multisite, moet je kiezen tussen functionaliteit en stabiliteit. Vermenigvuldig die beslissing met 10+ talen.

Geen echte API-first-architectuur. Ja, WP REST API bestaat. Maar het was niet ontworpen voor het soort locale-aware, edge-geïmplementeerde, CDN-gecachete contentlevering die moderne meertalige sites eisen. Je eindigt met het toevoegen van lagen caching en aangepaste endpoints die hun eigen onderhoudslast worden.

De werkelijke kosten van WPML en WordPress meertalige plugins

Laten we over getallen praten, want hier wordt het WordPress meertalige verhaal oncomfortabel.

WPML-licentieverlening: $199/jaar voor het Multilingual Agency-plan. Dat is het instappunt voor serieus meertalig werk. En het is per site — of per netwerk in Multisite, wat beter klinkt totdat je realiseert dat je voor altijd in hun verlengingscyclus bent vastgelopen.

Prestatiesimpact: 20-40% tragere paginawaarden. Ik heb dit gemeten op meerdere clientsites. WPML voegt databasequery's toe op elke paginaload om vertalingen op te lossen, talen om te schakelen, en stringvertalingen te beheren. Op een inhoudszware pagina zijn dat tientallen extra query's. Je LCP-scores leiden. Je gebruikers merken het op.

Vertaalbeheersingskosten zijn de echte moordenaar. Professionele vertalingsbureaus rekenen $0,10-$0,20 per woord. Voor een bedrijfssite met 50.000 woorden inhoud over 10 talen:

  • Lage schatting: 50.000 × $0,10 × 10 = $50.000/jaar
  • Hoge schatting: 50.000 × $0,20 × 10 = $100.000/jaar

En dat is alleen de eerste vertaling. Elke content-update, elke nieuwe pagina, elke blogpost — het gaat allemaal terug naar de vertaalpijplijn.

Er is een beter pad.

De moderne architectuur: Next.js + next-intl + Headless CMS

Hier is de stack die we hebben gebouwd en in echte bedrijfsimplementaties hebben beproefd:

┌─────────────────────────────────────────────┐
│              Edge / CDN Layer                │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Next.js Application               │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (i18n routing)     │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         Headless CMS / Supabase             │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  Content  │  │  Translation     │      │
│    │  Models   │  │  Tables (i18n)   │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        AI Translation Pipeline              │
│    (Claude API → Review → Publish)          │
└─────────────────────────────────────────────┘

De sleutelinzicht: gescheiden inhoudsbeheer van vertaalbeheer van presentatie. Elke laag kan onafhankelijk evolueren. Wissel de CMS uit zonder vertalingen aan te raken. Wijzig je frontend-framework zonder content te migreren. Voeg talen toe zonder code aan te raken.

next-intl-configuratie

Hier ziet onze routingopstelling er in de praktijk uit:

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'pt', 'it', 'nl', 'sv', 'no', 'da',
    'fi', 'pl', 'cs', 'ro', 'tr', 'ar', 'hi', 'ja', 'ko',
    'zh-CN', 'zh-TW', 'th', 'vi', 'id', 'ms', 'ru', 'uk'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|...)/:path*']
};

Dit geeft je schone URL-structuren: /en/services, /de/dienstleistungen, /ja/サービス. Elke landinstelling krijgt zijn eigen statisch gegenereerde pagina's, geserveerd vanaf de edge. Geen databasequery's bij runtime voor taalresolutie.

Supabase vertaaltabellen

We slaan vertalingen in Supabase op met een eenvoudig maar effectief schema:

CREATE TABLE translations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  namespace TEXT NOT NULL,
  key TEXT NOT NULL,
  locale TEXT NOT NULL,
  value TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(namespace, key, locale)
);

CREATE INDEX idx_translations_locale ON translations(locale);
CREATE INDEX idx_translations_namespace ON translations(namespace, locale);

Dit schema handelt 30 talen × duizenden vertaalsleutels zonder zweten af. Query's zijn eenvoudig, cacheable en snel.

De vertaalpijplijn instellen

De vertaalpijplijn is waar deze architectuur echt gaat schitteren. Hier is onze werkstroom:

  1. Inhoud wordt in Engels geschreven in de headless CMS
  2. Een buildscript extraheert alle vertaalbare tekenreeksen in JSON-bestanden
  3. Claude API vertaalt elk JSON-bestand per doeltaal
  4. Een beoordelingsstap (optioneel, voor kritieke inhoud) stelt menselijke editors in staat vertalingen goed te keuren
  5. Vertalingen worden vastgelegd in de repository of naar Supabase gepusht
  6. Next.js opnieuw bouwen de beïnvloede pagina's via ISR of volledige opbouw
// scripts/translate.ts
import Anthropic from '@anthropic-ai/sdk';
import { readFileSync, writeFileSync } from 'fs';

const anthropic = new Anthropic();

async function translateFile(sourcePath: string, targetLocale: string) {
  const source = JSON.parse(readFileSync(sourcePath, 'utf-8'));
  
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 4096,
    messages: [{
      role: 'user',
      content: `Vertaal de volgende JSON-waarden (niet sleutels) naar ${targetLocale}. 
      Behoud de exacte JSON-structuur. Gebruik natuurlijke, professionele taal 
      geschikt voor een bedrijfswebsite. Behoud alle HTML-tags of 
      interpolatievariabelen zoals {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

Dit is vereenvoudigd, maar het vat de kernidee samen. In productie batchen we verzoeken, verwerken we snelheidslimieten, valideren we uitvoerstructuur, en voeren we geautomatiseerde kwaliteitschecks uit.

AI-vertaling: de economie die alles veranderde

Hier wordt het wiskundig leuk.

Traditionale vertaling voor onze site (118+ pagina's, ongeveer 50.000 woorden per taal):

  • Per taal: $5.000-$10.000 (bureautarieven)
  • 30 talen: $150.000-$300.000
  • Jaarlijkse updates: $50.000-$100.000

AI-vertaling met Claude:

  • Per taal: ~$22 in API-tokens
  • Tijd per taal: ~45 minuten
  • 30 talen: ~$660 totaal, ~22,5 uur
  • Een nieuwe taal toevoegen: 45 minuten, $22

Dat is geen typfout. Tweeëntwintig dollar per taal.

Nu wil ik eerlijk zijn. AI-vertaling in 2026 is niet perfect voor elk gebruiksscenario. Juridische documenten, medische inhoud, zeer genuanceerde marketingcopy — deze profiteren nog steeds van menselijke beoordeling. Maar voor bedrijfswebsites, productbeschrijvingen, documentatie en bloginhoud? De kwaliteit is opmerkelijk goed. We hebben native speakers onze AI-vertaalde inhoud in Japans, Arabisch en Duits laten beoordelen, en de feedback landt consistent op "professionele kwaliteit met af en toe formuleringsvoorkeuren."

Het echte voordeel is niet alleen kosten — het is snelheid. Wanneer je een nieuwe Engelse pagina publiceert en deze beschikbaar wilt in 30 talen, kijk je naar uren, niet weken. Geen agentuurcoördinatie. Geen vertaalgeheugen beheer. Geen heen en weer over terminologie.

Headless CMS-opties voor meertalige inhoud

Je hebt hier opties, en de juiste keuze hangt af van je team en schaal. Hier is wat we hebben geëvalueerd:

Platform i18n Support Self-Hosted Pricing (2026) Best For
Sanity Native field-level Cloud + self-host Free tier, $15+/mo pro Structured content, real-time collab
Payload CMS Native, TypeScript Yes Free / OSS Developer teams wanting full control
Strapi Plugin-based i18n Yes Free / OSS Teams already in the Strapi ecosystem
Storyblok Native field-level Cloud only $106+/mo Visual editing, marketing teams
Supabase (raw) Custom schema Yes Free tier, $25+/mo Maximum flexibility, developer-heavy teams

Voor onze headless CMS-ontwikkelingsprojecten raden we meestal Sanity of Payload aan voor inhoudszware sites en Supabase direct wanneer het team maximale controle over de vertaalpijplijn wilt.

Het belangrijke onderscheid: bij een headless-benadering handelt de CMS inhoudopslag en redactionele workflow af. Vertaalbeheer leeft in je applicatielaag. Deze scheiding betekent dat je nooit vastzit aan het idee van een CMS-leverancier over hoe meertalige inhoud zou moeten werken.

Stap voor stap: Een website met 30 talen bouwen

Hier is het werkelijke proces dat we volgen:

Stap 1: Definieer je landinstelling-strategie

Alvorens code te schrijven, beslis:

  • Welke talen heb je werkelijk nodig? (Controleer je analytics)
  • Zul je gesloten URLs gebruiken (/de/kontakt) of subdomeinen (de.example.com)?
  • Heb je regio-varianten nodig (en-US vs en-GB) of alleen taalcodes?
  • Welke inhoud wordt vertaald vs. welke is localespecifiek?

We gebruiken standaard op pad gebaseerde routing (/de/, /ja/) omdat het eenvoudiger is voor SEO, gemakkelijker te implementeren op één domein, en natuurlijk werkt met Next.js middleware.

Stap 2: Installeer Next.js met next-intl

Installeer en configureer:

npm install next-intl

Structureer je berichtendirectory:

messages/
├── en.json
├── de.json
├── ja.json
├── ar.json
└── ... (30 landinstellingsbestanden)

Elk bestand bevat naamgeruimte vertalingen:

{
  "navigation": {
    "home": "Startpagina",
    "about": "Over ons",
    "services": "Diensten",
    "contact": "Contact"
  },
  "hero": {
    "title": "Bedrijfsontwikkeling op het web",
    "subtitle": "Gebouwd voor prestaties, ontworpen voor schaal"
  }
}

Stap 3: Bouw de vertaalpijplijn

Maak een script dat:

  1. Je Engelse bronbestanden leest
  2. Ze naar Claude API voor vertaling stuurt
  3. De JSON-structuur van de uitvoer valideert
  4. Landinstellingsbestanden schrijft
  5. Geautomatiseerde kwaliteitschecks uitvoert (ontbrekende sleutels, verbroken interpolatievariabelen)

Stap 4: Implementeer hreflang en SEO

Hier vallen veel meertalige implementaties tekort. Elke pagina heeft de juiste hreflang-tags nodig:

// src/components/LocaleHead.tsx
export function LocaleHead({ currentLocale, path }: Props) {
  const locales = routing.locales;
  
  return (
    <>
      {locales.map((locale) => (
        <link
          key={locale}
          rel="alternate"
          hrefLang={locale}
          href={`https://example.com/${locale}${path}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${path}`}
      />
    </>
  );
}

Stap 5: Verwerk RTL-talen

Als je Arabisch, Hebreeuws of andere RTL-talen ondersteunt, heb je directionele CSS nodig:

// src/app/[locale]/layout.tsx
export default function LocaleLayout({ children, params: { locale } }) {
  const direction = ['ar', 'he', 'fa'].includes(locale) ? 'rtl' : 'ltr';
  
  return (
    <html lang={locale} dir={direction}>
      <body className={direction === 'rtl' ? 'font-arabic' : 'font-sans'}>
        {children}
      </body>
    </html>
  );
}

Tailwind CSS v4 ondersteunt rtl:-varianten inheems, wat directionele styling beheersbaar maakt.

Stap 6: Implementeer en bewaak

Met Next.js op Vercel worden de pagina's van elke landinstelling statisch gegenereerd en bediend vanaf edge-knooppunten die het dichtst bij gebruikers zijn. Een Duitse gebruiker die /de/dienstleistungen aanslaat, krijgt een respons van een Frankfurt edge-knooppunt in minder dan 100 ms. Geen databasequery. Geen WPML-opzoeken. Alleen statische HTML.

Migratiepad: WordPress naar Headless Meertalig

Als je momenteel op WordPress Multisite met WPML bent, hier is het migratiepad dat we hebben verfijnd over meerdere clientprojecten.

Week 1-2: Content Export en Audit

  • Exporteer alle inhoud via WP REST API (inclusief WPML-vertalingen)
  • Wijs content-types toe aan headless CMS-modellen
  • Identificeer zwerfvertalingen en inhoudsgaten
  • Documenteer alle URL-patronen voor 301-omleidingen

Week 2-4: Headless CMS Setup en Content Import

  • Configureer content-modellen in je gekozen headless CMS
  • Importeer Engelse broncontent
  • Stel Supabase vertaaltabellen in
  • Voer AI-vertaalpijplijn uit voor alle doeltalen

Week 4-6: Frontend Build

  • Bouw Next.js-applicatie met next-intl
  • Implementeer alle paginasjablonen
  • Configureer hreflang-tags en sitemap-generatie
  • Stel geautomatiseerde vertaalpijplijn in voor nieuwe inhoud

Week 6-8: Testen, omleidingen en lancering

  • Cross-browser en cross-locale testen
  • Implementeer 301-omleidingen van oude URL-patronen
  • Dien bijgewerkte sitemaps in bij Google Search Console
  • Controleer indexering en verkeerspatronen na lancering

Totale tijdlijn: 4-8 weken afhankelijk van inhoudvolume en complexiteit.

Kostenvergeking: WordPress Multisite vs. Headless Meertalig

Hier is de eerlijke kostenopbrengst voor een website met 10 talen over 3 jaar:

Cost Category WordPress Multisite + WPML Next.js + Headless + AI Translation
CMS licensing (3 years) $0 (WP is free) $0-$540 (Sanity pro) or $0 (Payload OSS)
WPML licensing (3 years) $597 $0
Professional translation (initial) $50,000-$100,000 $220 (AI, 10 langs × $22)
Translation updates (3 years) $30,000-$60,000 $500 (estimated AI costs)
Hosting (3 years) $3,600-$7,200 (managed WP) $0-$720 (Vercel free-pro tier)
Development (initial build) $30,000-$60,000 $40,000-$70,000
Maintenance (3 years) $18,000-$36,000 $6,000-$12,000
Total 3-Year Cost $132,197-$263,797 $46,720-$83,460

De ontwikkelingskost voor de headless-benadering is iets hoger vooraf — je bouwt aangepaste infrastructuur in plaats van plugins te configureren. Maar de voortdurende besparingen zijn dramatisch. Geen WPML-verlengingen. Geen vertalingsbureaurekeningen. Geen Multisite-onderhoudspijn.

Prestatieonderzoeken

We hebben Lighthouse-audits uitgevoerd op onze productie meertalige site en vergeleken met equivalente WordPress Multisite + WPML-implementaties:

Metric WordPress + WPML Next.js + next-intl
LCP (Largest Contentful Paint) 2.8-4.2s 0.8-1.2s
FID (First Input Delay) 120-280ms 10-40ms
CLS (Cumulative Layout Shift) 0.12-0.25 0.01-0.05
Time to First Byte (TTFB) 800-1,400ms 50-150ms
Lighthouse Performance Score 45-65 95-100
Pages per language ~118 ~118
Total indexed pages ~1,180 (10 langs) ~91,000+ (30 langs)

Het TTFB-verschil alleen is de migratie waard. Wanneer je pagina's statisch worden gegenereerd en bediend vanaf edge CDN's, wacht je niet op PHP-opstart van WordPress, WPML laden, de database opvragen, vertalingen oplossen, en een sjabloon renderen. De HTML is gewoon... daar.

Veelgestelde vragen

Is AI-vertaling goed genoeg voor bedrijfswebsites? Voor meeste bedrijfsinhoud — ja. In 2026 produceren Claude en GPT-4 vertalingen die native speakers als professionele kwaliteit voor bedrijfsinhoud, productbeschrijvingen en documentatie waarderen. We hebben AI-vertalingen in 30 talen met inbegrip van Japans, Arabisch, Koreaans en Chinees (zowel vereenvoudigd als traditioneel) ingezet met positieve feedback van native-speaking reviewers. Juridische, medische of sterk gereglementeerde inhoud kan nog steeds menselijke beoordeling rechtvaardigen, maar zelfs daar is AI + menselijke beoordeling veel goedkoper dan pure menselijke vertaling.

Hoeveel kost het om een nieuwe taal aan een headless meertalige site toe te voegen? Met onze pijplijn kost het toevoegen van een nieuwe taal ongeveer $22 in Claude API-tokens en duurt ongeveer 45 minuten engineeringtijd. Dat omvat het vertalen van alle pagina-inhoud, navigatie, metadata en UI-tekenreeksen. Vergelijk dat met WPML's per-site licentie plus $5.000-$10.000 in professionele vertaalkosten voor een typische bedrijfssite.

Wat is het beste WordPress Multisite-alternatief voor meertalige sites? Voor bedrijfsimplementaties biedt een headless CMS (Sanity, Payload of Strapi) gekoppeld aan Next.js en next-intl de meest flexibele en performante architectuur. Je krijgt echte inhoud/presentatiescheiding, edge-ingezette pagina's, en de mogelijkheid om vertalingen onafhankelijk van je CMS te beheren. Voor eenvoudiger sites met minder dan 50 pagina's kan Webflow met zijn localiseringsfuncties werken, maar je zult snel op bedrijfsschaal op grenzen stuiten.

Hoe ga je om met SEO voor 30+ taalvarianten? Elke pagina genereert juiste hreflang-tags die naar alle tailvarianten plus een x-default-tag wijzen. We genereren per-locale XML-sitemaps en dienen ze in bij Google Search Console. Elke landinstelling krijgt zijn eigen set meta-titels, beschrijvingen en Open Graph-tags — allemaal vertaald via de AI-pijplijn. Google heeft meer dan 91.000 pagina's over onze 30 tailvarianten geïndexeerd.

Kun je zonder SEO-ranking-verlies van WordPress Multisite naar headless migreren? Ja, maar het vereist voorzichtige planning. De kritieke stappen zijn: uitgebreide 301-omleiding toewijzing van oude URLs naar nieuwe localeingestelde URLs, juiste hreflang-implementatie vanaf dag één, en het indienen van bijgewerkte sitemaps onmiddellijk na lancering. We zien meestal een 1-3 weken indexeringsovergangsperiode, gevolgd door ranginingsverbeteringen vanwege betere Core Web Vitals-scores.

Wat is het beste WPML-alternatief in 2026? next-intl voor Next.js-applicaties, of nuxt-i18n voor Nuxt-applicaties. Beide handelen locale routing, berichtopmaak en SEO-metadata inheems in de frameworklaag af — zonder de prestatiesoverhead van een WordPress-plugin. In tegenstelling tot WPML is er geen jaarlijkse licentievergoeding, geen database-overhead, en geen compatibiliteitsproblemen met andere plugins. De i18n-logica leeft in je toepassingscode waar het hoort.

Hoe beheer je vertaalkwaliteit over 30 talen? We gebruiken een multi-layer-benadering: AI-vertaling als basislaag, geautomatiseerde kwaliteitschecks (JSON-structuurvalidatie, behoud van interpolatievariabelen, lengtevergelijking), en optionele menselijke beoordeling voor inhoud met hoge zichtbaarheid zoals homepage-koppen en CTA's. We behouden ook een terminologiewoordenboek per taal dat als context aan de AI wordt doorgegeven, waarbij verzorgd dat merktermen, productnamen en technische woordenschat consistent worden afgehandeld.

Is deze benadering haalbaar voor sites met frequente content-updates? Absoluut — het is eigenlijk beter voor frequente updates dan WPML. Wanneer je een Engelse pagina publiceert of bijwerkt, kan de vertaalpijplijn automatisch via een webhook draaien. Nieuwe vertalingen worden in minuten gegenereerd, niet dagen. Met ISR (Incremental Static Regeneration) in Next.js gaan bijgewerkte pagina's zonder volledige siteopbouw live. We hebben clients gehad die dagelijks blogposts publiceren die in 30 talen binnen het uur verschijnen, volledig geïndexeerd door zoekmachines dezelfde dag.