Van WordPress naar headless migreren: wanneer en hoe?

Van WordPress naar headless migreren loont alleen met een concrete reden.

Drie redenen tellen: je toont dezelfde content op meerdere kanalen, je site is structureel te traag, of je hebt maatwerk nodig dat een thema niet aankan.

Het verdict: herken je geen van die drie, blijf dan bij WordPress en los je probleem daarbinnen op. Dat is meestal sneller en goedkoper.

Heb je wél een trigger, dan is headless WordPress vaak het slimste tussenpad.

Hieronder: welke triggers de overstap rechtvaardigen, waarom dat tussenpad werkt, en hoe je de migratie stap voor stap aanpakt zonder je vindbaarheid te slopen.

Wat betekent migreren van WordPress naar headless?

Je ontkoppelt de voorkant van WordPress en bouwt die opnieuw als een aparte laag die je content via een API ophaalt.

WordPress blijft, maar alleen als achterkant

WordPress blijft bestaan, maar enkel als achterkant: het systeem waar je teksten, afbeeldingen en pagina’s beheert.

De pagina die de bezoeker ziet, wordt voortaan los gebouwd, bijvoorbeeld in een modern JavaScript-framework.

Een API is daarbij de koppeling waarlangs twee systemen data uitwisselen. Meer daarover in API-integraties op je website.

Opsplitsen, niet verhuizen

Dat is een fundamenteel andere keuze dan een gewone website-migratie naar een nieuw platform.

Je verhuist niet weg van WordPress, je splitst het op. De redactie blijft in de vertrouwde wp-admin werken.

Ontwikkelaars bouwen ondertussen de voorkant volledig op maat, voor snelheid en flexibiliteit.

Wil je eerst begrijpen wat een ontkoppelde architectuur precies inhoudt, lees dan onze uitleg over headless CMS.

Geen klein technisch klusje

Dit is geen klein technisch klusje. Je vervangt een compleet, geïntegreerd systeem door losse onderdelen die je zelf laat samenwerken.

Dat geeft controle, maar het brengt ook werk en onderhoud met zich mee.

De vraag is dus niet of het kan, maar of het je genoeg oplevert.

Wanneer is migreren naar headless terecht?

Migreer pas als je een concrete trigger herkent, niet omdat headless modern klinkt.

Deze situaties rechtvaardigen de overstap echt:

• Je toont dezelfde content op meerdere kanalen. Heb je naast je website ook een app, een klantenportaal of schermen op locatie? Dan wil je je content op één plek beheren en overal tegelijk uitleveren. Dat is precies waar een ontkoppelde opzet voor gemaakt is.
• Snelheid is een hardnekkig, structureel probleem. Je hebt je afbeeldingen al gecomprimeerd, je plugins opgeschoond en je hosting verbeterd, en toch blijft je site traag. Een op maat gebouwde voorkant kan dan winst opleveren op je Core Web Vitals, de prestatiematen die mee je vindbaarheid bepalen.
• Je hebt maatwerk nodig dat een thema niet aankan. Heel specifieke interacties, complexe datavisualisaties of een unieke gebruikerservaring die binnen de grenzen van een themabuilder niet lukt.
• Je hebt een vast of intern ontwikkelteam. Iemand moet die losse voorkant bouwen en blijven onderhouden. Zonder die capaciteit wordt headless een dure afhankelijkheid.
• Beveiliging en schaal wegen zwaar. Omdat bezoekers nooit rechtstreeks bij wp-admin komen, verklein je het aanvalsoppervlak. Voor sites met veel verkeer en strenge eisen kan dat doorslaggevend zijn.

Herken je niets van dit lijstje, dan blijf je waarschijnlijk beter waar je bent.

Meet eerst of snelheid echt het probleem is

“Onze site is traag” is een gevoel. Meet het eerst met veldgegevens van echte bezoekers.

Zo zien de mobiele veldgegevens van onze eigen site eruit in PageSpeed Insights:

Onze eigen mobiele veldgegevens, oktober 2026: LCP is goed met 1,9 s, maar de beoordeling faalt omdat CLS op 0,13 ligt.

Eén zwakke waarde volstaat om de beoordeling te laten falen. Kijk dus welke waarde faalt voor je een architectuur vervangt.

Een layoutverschuiving (CLS) los je vaak op in je thema, zonder migratie.

Test je eigen pagina’s met onze website-snelheidstest.

Search Console toont waar het zit

Search Console groepeert je URL’s per probleem. Zo zie je of het om een handvol templates gaat of om de hele site:

In onze eigen Search Console houdt niet LCP maar CLS boven 0,1 349 mobiele URL’s uit het groen, oktober 2026.

Vuistregel: zit het probleem in één template, repareer dat template. Een migratie lost geen ontwerpfout op.

Meer oplossingen lees je in Core Web Vitals verbeteren.

Wanneer kun je beter bij gewoon WordPress blijven?

Voor de meeste Belgische kmo’s met één B2B-website is een headless migratie overkill.

Je betaalt voor flexibiliteit die je nooit gebruikt. En je marketingteam wordt afhankelijk van ontwikkelaars voor wijzigingen die in een standaard WordPress in twee minuten klaar zijn.

Drie signalen om te blijven

Blijf bij een traditionele opzet als:

• je site één kanaal bedient
• je geen eigen ontwikkelteam hebt
• je snelheidsprobleem nog niet ten gronde is aangepakt

Het verlies zit vaak elders

Vaak zit het verlies niet in WordPress zelf. Het zit in te zware afbeeldingen, een wildgroei aan plugins of een rommelige opzet.

Dat los je binnen WordPress op, tegen een fractie van de kosten. Begin bij een trage WordPress-site sneller maken en te veel WordPress-plugins.

Een schone, goed opgezette installatie scoort op het vlak van WordPress en SEO prima.

WordPress.org, oktober 2026. Het platform blijft bij een headless opzet gewoon je redactieomgeving.

Waar je budget dan wel naartoe gaat

Geef je budget liever uit aan dingen die direct leads opleveren:

• een scherpere boodschap
• een sterkere structuur
• concrete conversiestappen

Dat heeft op de meeste B2B-sites veel meer impact dan de techniek eronder.

Waarom is headless WordPress vaak het slimste tussenpad?

Het geeft je de snelheid en flexibiliteit van een ontkoppelde voorkant, terwijl je redactie in de vertrouwde WordPress-omgeving blijft werken.

Je hoeft dus geen nieuw contentsysteem te leren: editors blijven in wp-admin, ontwikkelaars bouwen de voorkant los.

REST API of WPGraphQL?

Die voorkant haalt de content op uit WordPress via een API. Daar zijn twee gangbare manieren voor.

De REST API werkt zonder extra installatie (sinds WordPress 4.7, uitgebracht in december 2016). Die versie kwam met endpoints voor berichten, reacties, termen, gebruikers, meta en instellingen. Voor veel projecten is dat ruim voldoende.

De plugin WPGraphQL laat de voorkant precies de velden opvragen die hij nodig heeft. Dat kan de hoeveelheid data per pagina flink verkleinen.

Wat het verschil in de praktijk betekent

WPGraphQL illustreert dat zelf met een voorbeeld. Wil je vijf berichten met de naam en avatar van de auteur, dan heb je via REST zes verzoeken nodig: één voor de berichten en één per auteur.

Met GraphQL doe je dat in één query. Voor 100 berichten meet WPGraphQL het verschil zo:

Datavolume en laadtijd voor 100 berichten via REST en via WPGraphQL, volgens de documentatie van WPGraphQL. Grafiek: Customer Impact, november 2026.

Let op: dit zijn cijfers van de makers van WPGraphQL zelf. Ze tonen de richting, niet wat jouw site zal halen.

Het framework voor de voorkant

Voor de voorkant zelf grijpen teams meestal naar een modern framework zoals Next.js of Astro.

Er bestaan ook gespecialiseerde toolkits, zoals Faust.js, die typische WordPress-functies als preview en authenticatie makkelijker maken.

Kies daarbij voor een framework dat je pagina’s op de server of vooraf rendert. Waarom dat voor SEO telt, lees je in server-side vs client-side rendering.

Onze ervaring: WordPress, Drupal en Webflow waren allemaal heel goede keuzes; vandaag hangt het af van het bedrijf. AI- en digital-native bedrijven stappen vaker over op agentic websites: geen plugin-updates en geen beveiligingswaarschuwingen.

Voor- en nadelen van het tussenpad

Het voordeel: je risico blijft beperkt. Je gooit niet je hele contentbeheer overhoop, je vernieuwt enkel de laag die de bezoeker ziet.

Het nadeel: je hebt nu twee systemen om te onderhouden. Functies die in WordPress vanzelf meekwamen, moet je bewust opnieuw inrichten:

• formulieren
• SEO-instellingen en sitemaps
• previews voor de redactie

Onderschat dat werk niet.

Welke headless systemen er naast WordPress bestaan, vergelijken we in Sanity, Contentful en Storyblok vergeleken.

Hoe verloopt een migratie naar headless stap voor stap?

Een goede migratie is vooral een kwestie van planning, niet van techniek alleen.

Dit is de aanpak die je vindbaarheid intact houdt:

1. Bepaal je doel en je trigger. Schrijf concreet op welk probleem je oplost en hoe headless je meer leads of omzet oplevert. Geen helder antwoord? Stop hier.
2. Leg je content en URL-structuur vast. Breng al je pagina’s, content-types en URL’s in kaart. Je nieuwe voorkant moet exact dezelfde URL’s serveren, want daar hangen je rankings aan.
3. Kies je API en je framework. Beslis tussen de REST API en WPGraphQL, en kies de techniek voor de voorkant op basis van je team en je eisen, niet op basis van de hype.
4. Bouw de voorkant en richt de gemiste functies opnieuw in. Denk aan formulieren, analytics, sitemaps, schema-markup en previews. Alles wat een plugin vroeger regelde, koppel je nu bewust aan elkaar.
5. Test in een staging-omgeving. Vergelijk pagina voor pagina met de live site: inhoud, metadata, snelheid en interne links. Een nette interne structuur blijft de basis van je website-architectuur voor SEO.
6. Zet redirects klaar en ga live op een rustig moment. Zorg dat elke oude URL netjes naar de juiste nieuwe plek wijst en dat je sitemap klopt.
7. Monitor je rankings en snelheid na livegang. Volg je posities en je indexering op de voet, zodat je problemen vroeg ziet. Lees vooraf hoe je rankings behoudt na een ingrijpende wijziging.

Sla je stap 2 of 6 over, dan riskeer je een verlies in vindbaarheid dat maanden kan duren om te herstellen.

Een migratie is technisch zelden het probleem. Het mislopen ervan zit bijna altijd in vergeten redirects en gewijzigde URL’s.

Wat Google zegt over redirects bij een migratie

Wijzigen je URL’s toch, volg dan Googles eigen advies voor een site-verhuizing met URL-wijzigingen:

• maak een volledige mapping van elke oude URL naar de nieuwe
• gebruik permanente redirects (301 of 308), zonder ketens
• laat die redirects minstens een jaar staan
• dien een sitemap met de nieuwe URL’s in via Search Console

Google waarschuwt ook: “Expect temporary fluctuation in site ranking during the move.”

Een middelgrote site doet er volgens Google enkele weken over voor de nieuwe URL’s de oude vervangen.

Hoe je zo’n plan opstelt, lees je in het redirectplan bij een herlancering en het bredere CMS-migratie stappenplan.

Liever begeleid? Onze SEO-migratie bewaakt je rankings van mapping tot monitoring.

De korte samenvatting

Van WordPress naar headless migreren is een sterke zet voor het juiste bedrijf, en weggegooid geld voor de rest.

Heb je meerdere kanalen, een echt snelheidsprobleem of complexe maatwerkeisen, én een team om de voorkant te onderhouden? Dan kan de overstap zich terugbetalen.

Headless WordPress is daarbij vaak de veiligste route, omdat je redactie gewoon blijft werken.

Voor de meeste B2B-sites met één website levert een schone, snelle WordPress-installatie meer op dan een ingrijpende verbouwing.

Kies op basis van je doel, niet van de trend. Weeg af of de migratie je meer klanten oplevert.

Veelgestelde vragen over WordPress naar headless

Verlies ik mijn rankings als ik naar headless migreer?

Niet als je URL’s gelijk blijven en je redirects, metadata en interne links kloppen. Google verwacht wel tijdelijke schommelingen bij elke verhuizing.

Monitor daarom je posities in de weken na livegang.

Kan mijn redactie in WordPress blijven werken?

Ja. Bij headless WordPress blijven editors in wp-admin. Alleen de voorkant die de bezoeker ziet, wordt opnieuw gebouwd.

Heb ik WPGraphQL nodig?

Niet per se. De ingebouwde REST API volstaat voor veel projecten.

WPGraphQL loont vooral als je voorkant veel gerelateerde data per pagina ophaalt.

Is headless sneller dan gewoon WordPress?

Het kan, maar niet automatisch. Een schone WordPress-site met lichte afbeeldingen en weinig plugins is vaak al snel genoeg.

Meet eerst waar je vertraging zit.

Twijfel je over de overstap?

Twijfel je of jouw site toe is aan een headless-opzet of dat de winst elders ligt? Wij kijken eerst naar je doel en pas daarna naar de techniek.

Bekijk hoe we werken als webdesigner, of hoe we agentic websites bouwen. Het volledige plaatje staat in de B2B-website gids.

Meer over de keuze zelf lees je in wanneer een headless CMS kiezen.

Neem contact op