“Moeten wij niet naar headless?” is een vraag die we regelmatig krijgen van klanten die het begrip hebben opgepikt op een congres of van een concurrent. Het eerlijke antwoord: soms wel, vaak niet. Beide architecturen hebben een duidelijk profiel, en de verkeerde keuze kost geld: bij aanschaf én in beheer, jarenlang.
De architectuurkeuze is geen technische discussie, maar een businessbeslissing. Wie gaat de site beheren, hoe vaak verandert hij, en wat moet hij over drie jaar kunnen?
Wat headless eigenlijk betekent
Bij een klassieke WordPress-site doet WordPress alles: content beheren én de pagina’s renderen die de bezoeker ziet. Bij een headless opzet wordt WordPress teruggebracht tot puur een content-API. De voorkant is een aparte applicatie (meestal gebouwd in een framework als Next.js of Astro) die de content via de REST API of GraphQL ophaalt en zelf de pagina’s opbouwt.
Die scheiding levert echte voordelen op. De frontend kan statisch worden gegenereerd en wereldwijd via een CDN worden geserveerd, wat extreem snelle laadtijden geeft. Dezelfde content-API kan meerdere kanalen voeden: de website, een app, narrowcasting-schermen. En de aanvalsoppervlakte wordt kleiner, omdat WordPress zelf achter slot en grendel kan draaien.
Wat het kost
Tegenover die voordelen staat een prijs die in verkoopgesprekken nogal eens wordt weggemoffeld:
- Twee systemen in plaats van één. Je onderhoudt een WordPress-installatie én een frontend-applicatie, elk met eigen hosting, eigen updates en eigen deployments.
- De preview breekt. Redacteuren die op “Voorbeeld” klikken, verwachten hun wijziging direct te zien. In een headless opzet moet die functionaliteit apart worden gebouwd — en dat wordt vaak vergeten.
- Plugins werken niet meer vanzelf. Formulieren, zoekfunctie, meertaligheid: functionaliteit die in klassiek WordPress een middag kost, moet headless aan de frontend-kant opnieuw worden opgelost.
- Je hebt een ander soort beheerpartij nodig. Een klassieke WordPress-site kan door vrijwel elk bureau worden overgenomen. Een headless stack vraagt om ontwikkelaars die beide werelden beheersen.
De vergelijking op een rij
| Situatie | Beste keuze |
|---|---|
| Marketingsite, redactie beheert veel zelf, budget is afgebakend | Klassiek maatwerk |
| Content moet naar meerdere kanalen (site, app, schermen) | Headless of Hybrid |
| Internationaal platform met zeer hoge bezoekersaantallen | Headless of Hybrid |
| Site verandert vaak van structuur en campagnepagina’s | Klassiek maatwerk |
| Complexe webapplicatie met WordPress alleen als content-bron | Headless |
Klassiek is niet hetzelfde als traag
Het belangrijkste misverstand in deze discussie: dat je headless “nodig hebt” voor snelheid. Een klassieke WordPress-site met een maatwerk thema, zonder pagebuilder-ballast en met goede server-level caching haalt PageSpeed-scores van 98+ daar schreven we eerder al uitgebreid over. Voor negen van de tien marketingsites is de performancewinst van headless daarmee verwaarloosbaar, terwijl de beheerkosten wél structureel hoger liggen.
Bij Digital Dreamers bouwen we beide. Juist daardoor kunnen we vrij adviseren: we verdienen aan een goed project, niet aan een specifieke stack. Onze vuistregel is simpel. Kies headless als er een concrete, aanwijsbare reden voor is: meerdere kanalen, extreme schaal, een applicatie in plaats van een site. Is die reden er niet, dan is een strak gebouwde klassieke WordPress-site sneller opgeleverd, goedkoper in beheer en prettiger voor de redactie.
De duurste architectuur is de architectuur die je niet nodig had.
