Migratie van WordPress naar een Headless CMS in 2026

Ik heb meer migraties weg van WordPress geleid dan ik kan tellen op dit moment. Sommige waren schoon — goed gestructureerde content, verstandige URL-patronen, editors die klaar waren voor een verandering. De meeste waren dat niet. De meeste waren gepaard met de ontdekking dat de helft van de site-content in Elementor shortcodes zat, dat iemand absolute URLs in 400 blogposts had hardcoded, en dat de "simpele" WooCommerce-integratie eigenlijk drie plugins met duct tape aan elkaar waren.

Deze gids is het canonieke resource dat we naar clients verwijzen wanneer zij een verhuizing weg van WordPress overwegen. Het verwijst naar onze specifieke speelboeken voor individuele platforms, maar hier behandelen we het volledige plaatje: welke headless CMS je moet kiezen, hoe de migratie werkelijk werkt, en hoe je de SEO-valkuilen vermijdt die verkeer tijdens een replatforming doden.

Inhoudsopgave

Wat is een Headless CMS Vervanging voor WordPress?

Een headless CMS rendert je website niet. Het slaat en structureert je content op, stelt deze beschikbaar via APIs (REST of GraphQL), en gaat uit de weg. Je frontend — gebouwd met iets als Next.js, Astro of Nuxt — haalt die content op build time of runtime en verzorgt alle rendering.

WordPress daarentegen is een gekoppelde CMS. De backend (PHP, MySQL, het admin panel) en de frontend (je thema, je templates, de HTML die het uitspuwt) zijn één verwarde eenheid. Ja, je kunt WordPress headless draaien via de REST API of WPGraphQL, maar je draait nog steeds WordPress. Je hebt nog steeds de plugin overhead, de PHP execution layer, en het attack surface dat ermee komt.

Wanneer we over een "headless CMS vervanging voor WordPress" spreken, bedoelen we WordPress volledig opgeven — zowel als backend als frontend — en het vervangen met een speciaal gebouwde content API.

Waarom niet gewoon WordPress Headless gebruiken?

Dat is een terechte vraag. Veel teams gebruiken WordPress + WPGraphQL + Next.js, en het werkt. Maar er zijn echte trade-offs:

Je onderhoudt nog steeds WordPress. Plugin updates, PHP versie bumps, database onderhoud, security patches. Allemaal.

Content modeling is beperkt. WordPress custom post types en ACF velden werken, maar ze zijn retrofit op een blogplatform. Native headless CMSs zijn vanaf dag één gebouwd voor gestructureerde content.

Performance overhead. Zelfs als headless backend draagt WordPress onnodig gewicht. Teams rapporteren regelmatig 500ms+ API response times van WordPress REST endpoints onder gemiddelde belasting.

Editor ervaring. Gutenberg is krachtig maar opvattelijk. Headless CMS editors zoals Sanity Studio of Storyblok's visuele editor zijn vaak een betere fit voor content teams die gestructureerde, multi-channel content bouwen.

Als je team diep ingebed is in WordPress, honderden bestaande posts heeft, en editors die weigeren een nieuw tool te leren, zou headless WordPress een redelijk tussenstation kunnen zijn. Maar voor de meeste teams die een ground-up migratie doen? Een native headless CMS is de betere long-term keuze.

De 5 Beste Headless CMS voor WordPress Migratie in 2026

We hebben production sites met al deze vijf gebouwd. Hier volgt hoe ze vergelijken voor teams die specifiek weg van WordPress migreren.

CMS Hosting Startprijs Geschikt voor Content API Visueel Bewerken
Sanity Cloud (gehosted) $0–99/mnd Content teams GROQ + GraphQL Ja (Presentation)
Payload CMS Zelf gehosted $0 (open source) Developers REST + GraphQL Ja (Live Preview)
Contentful Cloud (gehosted) $300+/mnd Enterprise REST + GraphQL Ja (Live Preview)
Strapi Zelf gehosted $0 (open source) Volledige Node.js teams REST + GraphQL Community plugins
Storyblok Cloud (gehosted) $0–150/mnd Visueel bewerken REST + GraphQL Ja (native)

1. Sanity ($0–99/mnd) — Beste voor Content Teams

Sanity is de CMS die ik het meest aanbeveel voor WordPress migraties, en het is de CMS die we het meest gebruiken voor headless CMS projecten.

De content modeling is ongelooflijk flexibel. De real-time editing experience is best-in-class. En GROQ (Sanity's querytaal) is werkelijk een genot om mee te werken als je het eenmaal leert.

Voor WordPress migrants speciaal is Sanity's Portable Text format een enorme upgrade ten opzichte van WordPress's block-gebaseerde HTML blobs. In plaats van geformatteerde HTML op te slaan, wordt je content opgeslagen als gestructureerde data — wat betekent dat je dezelfde blogpost kunt renderen als een webpagina, een mobiel app scherm, een email nieuwsbrief, of wat er volgende komt.

De gratis tier is genereus: 3 users, 500K API requests/maand, 20GB bandbreedte. Dat is genoeg voor de meeste kleine tot middelgrote sites. Het Team plan op $99/maand voegt meer users en hogere limieten toe.

Migratiepad: Export WordPress content via REST API of WP-CLI, transformeer het in Sanity documenten met een migratiescript (we gebruiken typisch Node.js), en importeer via Sanity's mutation API. Er is een community wordpress-to-sanity migratietool die het basale afhandelt, hoewel je altijd custom werk nodig hebt voor ACF velden en custom post types.

2. Payload CMS (Zelf Gehosted, $0) — Beste voor Developers

Payload is de CMS die ik zou kiezen als ik voor een team van developers bouw die volledige controle willen. Het is open-source, draait op Node.js, en slaat data op in MongoDB of Postgres (ze voegden Postgres support in 2024 toe, en het is nu solid). Je definieert je content schema in TypeScript — geen GUI config files, geen YAML, gewoon code.

Dit is het dichtste wat er is aan een "developer's WordPress vervanging" omdat je alles bezit. De data, de hosting, de deployment pipeline. Geen vendor lock-in, geen API rate limits, geen verassingswijzigingen in prijzen.

Payload 3.0 (de huidige versie) draait natively op Next.js, wat betekent dat je CMS admin panel en je frontend dezelfde Next.js app kunnen delen als je dat wilt. Dat is een wilde architecturale optie die geen ander CMS aanbiedt.

Migratiepad: Schrijf een migratiescript dat leest van WordPress's REST API (of rechtstreeks van de MySQL database) en schrijft naar Payload's Local API. Payload's TypeScript config maakt schema mapping rechttoe rechtaan — je weet precies welke vorm je data in moet zijn omdat het in code is gedefinieerd.

We hebben een volledige walkthrough op onze Next.js development capability pagina's.

3. Contentful ($300+/mnd) — Beste voor Enterprise

Contentful is de headless CMS waarop enterprises standaard uitkomen, en terecht: het is battle-tested op schaal, heeft uitstekende uptime SLAs, en de content modeling UI is volwassen. Als je goedkeuring nodig hebt van procurement en legal, voldoet Contentful aan alle vereisten.

Het nadeel? Kostprijs.

De gratis tier (Community plan) is beperkt tot 5 users en één space. Als je meer nodig hebt, spring je naar het Team plan op $300/maand. Enterprise prijzen gaan van daaruit — ik heb contracten gezien in de $2,000–5,000/maand range voor grotere organisaties. Dat gezegd hebbende, wanneer je de operationele kosten van zelf hosten en onderhouden van iets als Strapi of Payload meeneemt, kan Contentful's prijzen werkelijk redelijk zijn voor teams die waarde stellen op geen infrastructuur beheren.

Contentful's gestructureerde content model is goed in kaart gebracht voor WordPress migraties. Posts worden entries van een "Blog Post" content type, categorieën worden entries van een "Category" type met references, en media worden geüpload naar Contentful's CDN-gestuurde asset pipeline.

Migratiepad: Contentful biedt een contentful-migration CLI tool voor het definiëren van content models als code, plus een robuuste Management API voor het importeren van content. Er zijn community WordPress-to-Contentful migratiescripts op GitHub, hoewel de meeste aanpassingen nodig hebben.

4. Strapi (Zelf Gehosted, $0) — Beste voor Volledige Node.js Teams

Strapi is de populairste open-source headless CMS per GitHub stars, en het is een solide keuze als je team comfortabel Node.js in production draait. Het admin panel is schoon, de content type builder laat je schemas via de UI definiëren (wat niet-developers waarderen), en het plugin ecosysteem is aanzienlijk gegroeid.

Strapi v5 (gelanceerd in laat 2024) bracht een nieuwe document service API, verbeterde TypeScript support, en betere performance. Het is een echte stap vooruit van v4.

De belangrijkste zorg met Strapi is operationeel. Je host het zelf, wat betekent dat je verantwoordelijk bent voor database backups, server security, deployments, en scaling. Voor teams die al Node.js services in production draaien, is dit geen probleem. Voor teams afkomstig van managed WordPress hosting die verwachtten "gewoon niet meer met servers om te gaan", kan het een pijnlijk moment zijn.

Migratiepad: Export content van WordPress via REST API, map het naar Strapi content types, en importeer met Strapi's Content API. Het proces is vergelijkbaar met andere API-gebaseerde CMSs. Strapi's admin UI maakt het gemakkelijk om content types te definiëren die je WordPress post types spiegelen.

5. Storyblok ($0–150/mnd) — Beste voor Visueel Bewerken

Als je editors' belangrijkste klacht over het verlaten van WordPress het verliezen van de mogelijkheid om page content visueel in te delen is, is Storyblok je antwoord. Haar visuele editor is werkelijk uitstekend — editors kunnen componenten slepen en neerzetten, real-time previews zien, en pagina's bouwen zonder code aan te raken. Het is de dichtste ervaring aan een page builder zoals Elementor, maar ondersteund door een juiste headless architectuur.

Storyblok's component-gebaseerde content model is een ander paradigma dan WordPress's posts-and-pages aanpak. In plaats van flat content types bouw je pagina's uit nestbare "bloks" (componenten). Dit is krachtig voor marketing teams die landing page flexibiliteit nodig hebben, maar het vereist meer upfront schema design.

Het gratis plan omvat 1 space met 1 user. Het Starter plan op $106/maand geeft je 5 users, wat de meeste kleine teams dekt. Het Business plan op ~$550/maand voegt geavanceerde features toe zoals custom workflows en roles.

Migratiepad: Storyblok biedt een WordPress importer plugin die basale posts en pagina's afhandelt. Voor complexere content (custom velden, page builder layouts) heb je een custom migratiescript nodig dat je content aan Storyblok's componentstructuur toewijst.

Migratiespeelboek: Data Export → Import → Frontend Rebuild

Hier is het werkelijke proces, stap voor stap. Ik zal specifiek zijn omdat de generieke adviezen daar buiten ("plan je migratie zorgvuldig!") nutteloos zijn.

Fase 1: Content Audit en Schema Design (1–2 Weken)

Voordat je een enkel post exporteert, moet je begrijpen wat je hebt.

# Krijg een telling van alle content types via WP-CLI
wp post list --post_type=post --format=count
wp post list --post_type=page --format=count
wp post list --post_type=product --format=count  # WooCommerce

# Export alle custom field keys (ACF)
wp db query "SELECT DISTINCT meta_key FROM wp_postmeta WHERE meta_key NOT LIKE '\_%'" --skip-column-names

Bouw een spreadsheet die elke WordPress content type en haar velden toewijst aan het target CMS schema. Dit is het meest belangrijke document van de gehele migratie. Sla het niet over.

WordPress Target CMS Opmerkingen
post (Blog) blogPost entry type Map post_content aan rich text veld
page page entry type Controleer op page builder content
category category reference Taxonomie → reference veld
tag tag reference Taxonomie → reference veld
featured_image heroImage asset Herupload naar nieuwe CDN
ACF author_bio author.bio veld Custom veld migratie

Fase 2: Data Export en Transformatie (1–2 Weken)

Export je content met de WordPress REST API. Gebruik niet de ingebouwde XML export — het is verliesgevend en moeilijk om programmatisch te ontleden.

// migrate.mjs — WordPress naar headless CMS migratiescript
import fetch from 'node-fetch';
import fs from 'fs/promises';

const WP_URL = 'https://your-wordpress-site.com/wp-json/wp/v2';

async function fetchAllPosts(type = 'posts', perPage = 100) {
  let page = 1;
  let allPosts = [];

  while (true) {
    const res = await fetch(
      `${WP_URL}/${type}?per_page=${perPage}&page=${page}&_embed`
    );
    if (!res.ok) break;

    const posts = await res.json();
    if (posts.length === 0) break;

    allPosts = allPosts.concat(posts);
    page++;
  }

  return allPosts;
}

async function main() {
  const posts = await fetchAllPosts('posts');
  const pages = await fetchAllPosts('pages');

  // Transformeer WordPress data naar target CMS format
  const transformed = posts.map(post => ({
    title: post.title.rendered,
    slug: post.slug,
    body: post.content.rendered, // Je moet HTML naar je CMS's format converteren
    publishedAt: post.date,
    excerpt: post.excerpt.rendered,
    featuredImage: post._embedded?.['wp:featuredmedia']?.[0]?.source_url,
    categories: post._embedded?.['wp:term']?.[0]?.map(t => t.name),
  }));

  await fs.writeFile('export.json', JSON.stringify(transformed, null, 2));
  console.log(`Exported ${transformed.length} posts`);
}

main();

Het moeilijke deel is niet de export — het is de transformatie.

WordPress slaat content op als HTML (of erger, als shortcode-rijke HTML). De meeste headless CMSs gebruiken gestructureerde content formaten:

  • Sanity gebruikt Portable Text (een JSON-gebaseerde rich text format)
  • Payload gebruikt Slate of Lexical JSON
  • Contentful gebruikt haar eigen Rich Text JSON format

Je zult HTML naar deze formaten moeten converteren. Libraries zoals @sanity/block-tools (voor Sanity) of html-to-lexical (voor Payload) handelen de algemene gevallen af, maar je zult tijd spenderen aan het repareren van edge cases — embedded iframes, WordPress gallery shortcodes, custom Gutenberg blokken.

Fase 3: Media Migratie (3–5 Dagen)

Vergeet je media niet. WordPress slaat bestanden op in /wp-content/uploads/ met een op datum gebaseerde mapstructuur. Je moet:

  1. Elk mediabestand downloaden (of pullen van het WordPress REST API's media endpoint)
  2. Uploaden naar je nieuwe CMS's asset storage (of een externe CDN als Cloudinary/imgix)
  3. Alle references in je content bijwerken om naar de nieuwe URLs te wijzen

Dit is vermoeiend maar kritiek. Gebroken afbeeldingen zijn het zichtbaarste teken van een mislukte migratie.

Fase 4: Frontend Rebuild (2–6 Weken)

Dit is waar het echte werk gebeurt. Je migreert geen thema — je bouwt een volledig nieuwe frontend van nul af aan met een modern framework.

Voor de meeste WordPress migraties raden we aan:

  • Next.js voor dynamische sites die ISR (Incremental Static Regeneration), server componenten, en React ecosysteem toegang nodig hebben
  • Astro voor content-zware sites waar performance paramount is en je minimale client-side JavaScript wilt
  • Nuxt voor teams al geïnvesteerd in het Vue ecosysteem

De frontend rebuild is ook je kans om de performance problemen op te lossen die waarschijnlijk deze migratie motiveerden. Een goed gebouwde Next.js of Astro site moet 90+ op Core Web Vitals raken zonder enige optimalisatietrucs — gewoon door niet 15 jQuery plugins en een page builder framework te laden.

Fase 5: Testen en Launch (1–2 Weken)

Draai de oude en nieuwe sites naast elkaar. Crawl beide met Screaming Frog of een soortgelikt tool en vergelijk:

  • URL telling (missen er pagina's?)
  • Title tags en meta descriptions
  • Interne linkstructuur
  • Afbeeldingsreferenties
  • Canonical tags

Snijd alleen over als je zeker bent dat de nieuwe site volledige content pariteit heeft.

SEO Behoud Checklist

Dit is waar migraties fout gaan. Ik heb teams 40-60% van hun organisch verkeer zien verliezen omdat zij URL-redirects als een nadenken na-activiteit hebben behandeld. Volgens Storyblok's 2025 State of CMS report rapporteren 58% van headless CMS gebruikers betere site performance — maar alleen als de migratie hun rankings niet onderuit haalt in het proces.

Hier is de checklist die we voor elke migratie gebruiken:

  • Export alle geïndexeerde URLs van Google Search Console (Performance → Pages) voor migratie
  • Maak een 1:1 redirect map voor elke URL die verandert. Geen uitzonderingen. Gebruik 301 redirects.
  • Behoud title tags en meta descriptions — "verbeter" ze niet tijdens migratie. Verander ze nadat verkeer is gestabiliseerd.
  • Behoud dezelfde URL structuur als mogelijk. Als WordPress /blog/post-slug/ gebruikte, je nieuwe site moet ook.
  • Implementeer canonical tags op elke pagina
  • Dien de nieuwe sitemap in naar Google Search Console onmiddellijk na launch
  • Monitor Search Console dagelijks voor de eerste 30 dagen. Zoek naar crawl errors, coverage drops, en indexing issues.
  • Verander je domein niet. Als je ook een domain migratie doet, doe het apart. Één variable tegelijk.
  • Behoud gestructureerde data (Schema.org markup). Als WordPress article schema genereerde via Yoast, je nieuwe frontend moet het repliceren.
  • Houd de oude site draaiend (password-beveiligd) voor minstens 90 dagen als referentie.
# Voorbeeld nginx redirect map voor WordPress naar headless migratie
map $uri $new_uri {
  /2023/05/old-post-slug/    /blog/old-post-slug;
  /category/news/             /blog/category/news;
  /about-us/                  /about;
  # ... honderden meer
}

server {
  # Redirect oude WordPress URLs
  if ($new_uri) {
    return 301 $new_uri;
  }
}

Kostenopstelling: Wat kost Headless CMS Migratie Eigenlijk?

Laten we eerlijk over prijsstelling spreken. De CMS zelf is vaak het goedkoopste onderdeel.

Component DIY Kosten Agency Kosten
CMS abonnement (jaarlijks) $0–3,600 $0–3,600
Content migratie scripting 40–80 dev uren $8,000–16,000
Frontend rebuild (Next.js/Astro) 80–200 dev uren $16,000–40,000
SEO redirect mapping 10–20 uren $2,000–4,000
QA en testen 20–40 uren $4,000–8,000
Totaal 150–340 uren $30,000–70,000

Kleinere sites (onder de 100 pagina's, simpele blog + pagina's) landen aan de onderkant. Sites met duizenden posts, complexe custom post types, WooCommerce, meertalige content, of zwaar ACF gebruik push naar het bovenste eind.

Als je specifiek voor je project wilt spreken, controleer onze pricing pagina of neem rechtstreeks contact op. We hebben genoeg van deze gedaan om je snel een realistisch raming te geven.

Veelgestelde Vragen

Waarom migreren van WordPress naar een headless CMS?

De meest gemeenschappelijke redenen die we horen zijn performance, security, en developer experience. WordPress sites met 15+ plugins raken routinematig 3-5 seconde laadtijden. Plugin conflicten breken dingen in production. Security kwetsbaarheden in plugins zijn een constant risico — WordPress biedt macht aan ~40% van het web, wat het een massaal target maakt.

Een headless CMS met een statische of server-rendered frontend elimineert de meeste van deze problemen. Volgens Storyblok's 2025 State of CMS report rapporteren 69% van headless CMS gebruikers verbeterde time-to-market en 58% ziet betere site performance.

Welke headless CMS lijkt het meest op WordPress?

Als je bedoelt "welke zal het meest vertrouwd voelen voor WordPress editors," het antwoord is waarschijnlijk Storyblok of Strapi. Storyblok's visuele editor geeft niet-technische gebruikers een sleep-en-zet ervaring soortgelijk aan WordPress page builders. Strapi's admin panel heeft een soortgelijk gevoel voor het WordPress dashboard — je klikt in content types, vult velden in, en hit publish.

Als je bedoelt "welke geeft me de meeste controle als developer," dat is Payload CMS, wat code-first is en je volledige eigendom van je stack geeft.

Hoeveel kost headless CMS migratie?

Voor een typische kleine-tot-medium WordPress site (50–500 pagina's, standaard blog + pagina's), verwacht $30,000–$50,000 met een agency of 150–200 dev uren als je het zelf doet. Complexe sites met WooCommerce, meertalige content, of duizenden posts kunnen $50,000–$100,000+ lopen.

De CMS abonnement zelf is vaak het kleinste line item — het is het content migratie, frontend rebuild, en SEO behoud werk dat de tijd en geld neemt.

Hoe lang duurt een WordPress naar headless CMS migratie?

De meeste migraties duren 6–12 weken van kickoff tot launch. De uitsplitsing is ongeveer: 1–2 weken voor content audit en schema design, 1–2 weken voor data migratie scripting, 2–6 weken voor de frontend rebuild, en 1–2 weken voor QA en launch.

De grootste variabele is de frontend — als je een complexe marketing site met dozijn pagina templates bouwt, duurt het langer dan een rechttoe rechtaan blog.

Kan ik van WordPress naar headless CMS migreren zonder SEO verkeer te verliezen?

Ja, maar alleen als je erover waakt.

De sleutels zijn: handhaaf je URL structuur (of zet juiste 301 redirects op voor elke veranderde URL), behoud je title tags en meta descriptions, houd gestructureerde data intact, en dien je nieuwe sitemap onmiddellijk in. Monitor Google Search Console dagelijks voor 30–60 dagen na launch.

Enige tijdelijke ranking fluctuatie is normaal, maar als je de redirect mapping correct hebt gedaan, moet verkeer binnen 2–4 weken herstellen.

Zou ik WordPress als headless CMS moeten gebruiken in plaats van migreren?

Het hangt af van je constraints. Als je editors absoluut weigeren een nieuwe CMS te leren en je hebt jaren van WordPress-specifieke aanpassingen, WordPress headless draaien (met WPGraphQL en een Next.js frontend) is een geldig tussenstation.

Maar je onderhoudt nog steeds WordPress — de plugins, de security updates, de PHP runtime. Voor de meeste teams die een schone migratie doen, een speciaal gebouwde headless CMS zoals Sanity of Payload is de betere long-term keuze omdat je niet WordPress's architecturale bagage draagt.

Wat gebeurt er met mijn WordPress plugins na migratie?

Ze verdwijnen. Dit is zowel het beste als het eng deel van een headless migratie.

Yoast SEO? Je zult meta tags in je frontend framework afhandelen. Contact Form 7? Vervang het met een form service zoals Formspree of bouw je eigen. WooCommerce? Je zult een speciaal e-commerce oplossing nodig hebben zoals Shopify (headless), Saleor, of Medusa.

Ga door je actieve plugins en map elke één naar een vervanging voor je migratie start. De meeste functionaliteit die een WordPress plugin vereiste is ofwel ingebouwd in moderne frameworks of beschikbaar als een SaaS API.

Heb ik een agency nodig voor WordPress headless CMS migratie?

Niet noodzakelijk, maar het hangt af van je team's vaardigheidsverzameling. Als je developers hebt die comfortabel zijn met React/Next.js, API integraties, en DevOps, je kunt absoluut een migratie zelf afhandelen.

Waar agencies zoals de onze de meeste waarde toevoegen is in ervaring — we hebben dozijnen van deze migraties gedaan en weten waar de landmijnen zijn (content transformatie edge cases, SEO redirect mapping op schaal, performance optimalisatie). Voor bedrijfsklare sites waar downtime of verkeersverlies echte revenue impact heeft, de investering in ervaren hulp betaalt zich typisch zelf terug.