Korte versie
Kort antwoord: headless is slim wanneer meerdere mensen of systemen met je content werken, wanneer je dezelfde content naar meerdere kanalen stuurt of wanneer AI-agenten content voorbereiden. Bij een eenvoudige site met één beheerder die af en toe een tekst aanpast, is een klassieke of volledig statische site meestal slimmer en goedkoper. Deze gids helpt je de beslissing eerlijk maken — met de vragen die je een bureau moet stellen vóór je iets laat bouwen.
“Headless” klinkt als een techniek die je zomaar moet willen. In zoektermen zie je het ook zoeken: mensen zoeken op headless website laten maken en headless wordpress website laten maken omdat ze ergens een website willen laten bouwen en ergens hebben gelezen dat headless beter is. Sindsdien is de vraag niet meer “wat is het”, maar “is het iets voor mij”.
Het eerlijke antwoord: soms wel, soms echt niet. En het verschil zit zelden in de techniek zelf — die is inmiddels volwassen. Het verschil zit in jouw team, jouw content en hoe vaak je publiceert.
Ik bouw zelf beide varianten: headless met een CMS zoals Storyblok voor teams met redacteuren, en volledig zonder CMS met content in Git voor technische teams. Deze gids is de beslissingshulp die ik ook aan tafel geef — inclusief de gevallen waarin ik klanten afradt om headless te laten maken.
Wanneer headless slim is
Headless loont zich wanneer content en vorm gescheiden móeten zijn. Herken je één van deze situaties, dan is het een serieus gesprek waard:
- Meerdere kanalen. Je stuurt dezelfde content naar een website, een app of een klantportaal. Eén bron, meerdere frontends: dat is precies wat een headless CMS doet.
- Een team publiceert samen. Redacteuren, marketeers en developers werken tegelijk aan content. Een visuele editor met rollen en workflows houdt dat beheersbaar zonder dat elke wijziging door een developer moet.
- Je wilt de frontend later vervangen. Een herdesign zonder contentmigratie: bij een headless architectuur blijft de bron staan en bouw je alleen de presentatielaag opnieuw.
- AI-agenten bereiden content voor. Gestructureerde content die machineleesbaar is — via een API of als getypeerde bestanden — kunnen agenten lezen, voorbereiden en controleren, waarna een mens de diff keurt. Wij werken zelf zo; de agent bereidt voor, het team beslist.
- Performance is een harde eis. Een statische frontend die vooraf gerenderde HTML serveert, meten we in onze cases maandelijks; lichte architecturen halen daar structureel betere scores dan plugin-zware klassieke sites — zo bouwen wij een headless website.
Die laatste twee zijn overigens geen headless-argumenten op zich. Je kunt ook met een klassiek CMS snel zijn. Maar in combinatie met een gescheiden contentbron maken ze de architectuur wel totaal overzichtelijker.
Wanneer headless niet slim is
Even eerlijk in de andere richting, want hier schieten bureaus vaak te kort:
- Eén beheerder, weinig wijzigingen. Pas je af en toe een tekst of foto aan? Dan is de grafische editor van een klassiek CMS of een kleine statische site eenvoudiger en goedkoper — zowel in bouw als in onderhoud.
- Klein budget, korte levensduur. Een headless traject betekent contentmodel, frontend én koppeling. Voor een tijdelijke site of een eenmalige campagne is dat drijfzand.
- Geen redactie, geen kanalen. Zonder tweede kanaal en zonder team dat samenwerkt, koop je flexibiliteit die je nooit gebruikt. Je betaalt wél voor de complexiteit.
- Alles draait om één gevestigd ecosysteem. Een klant met een boekingstool of betalingsmodule die diep in het oude CMS verweven is, verliest die integratie bij een headless wissel — of betaalt dubbel om haar te herbouwen. Zulke verweven plugins zijn een dure reden om te blijven.
Twijfel je tussen headless en klassiek? De volledige afweging staat in headless CMS vs klassiek CMS, inclusief de eerlijke nuances over SEO en onderhoud.
Wat de prijs van een headless website bepaalt
Ik publiceer geen tarieven — die hangen te veel van je project af — maar ik kan wél eerlijk uitleggen wat het verschil maakt tussen offertes die je krijgt:
| Factor | Houdt de prijs laag | Drijft de prijs op |
|---|---|---|
| Paginatypes | Een handvol templates die hergebruikt worden | Elke pagina een eigen ontwerp en blokkenstructuur |
| Contentmodel | Overzichtelijke types die je team zelf beheert | Veel geneste blokken, rollen en workflows per afdeling |
| Migratie | Weinig content of nette exportmogelijkheid | Honderden pagina's, inconsistente structures, gebroken media |
| Koppelingen | Standaard-koppelingen of geen | Koppelingen met boekingstools, ERP of maatwerk-API's |
| Talen | Eén taal | Meertalig met per-taal redactie en hreflang |
Let op de derde rij: migratie is vaak de grootste verborgen kostenpost. Meer daarover bij de WordPress-vraag hieronder.
Headless WordPress-website laten maken: de specifieke val
De zoekterm headless wordpress website laten maken verdient een eigen paragraaf, omdat hier de verwachting vaak scheef zit. Het idee: “we houden WordPress, maar halen de snelle frontend erbij”. De realiteit:
Je WordPress-inhoud wordt via de REST-API uitgelezen en de volledige frontend wordt opnieuw gebouwd in een framework zoals Astro of Next.js. Dat kan prima — maar je behoudt daarmee ook de WordPress-onderhoudslast: updates, plugins, hosting, veiligheid. Je ruilt één systeem voor twee.
Vraag je dus af wat je eigenlijk wil oplossen:
- Wil je sneller zijn? Een lichte frontend lost dat op; de vraag is of je WordPress als bron moet houden. Vaak is content exporteren naar een statische site of een modern CMS efficiënter dan een API-laag over WordPress leggen.
- Wil je beter beheer? Dan lost een nieuwe frontend je beheerprobleem niet op; kijk naar het CMS zelf.
- Wil je behouden wat werkt? Als je site goed loopt en je thema is maatwerk, weeg dan wat de wissel je oplevert tegen maanden migratiewerk en dubbel onderhoud.
Wat jij als klant aanlevert vóór de bouw
Een headless traject verloopt soepel naarmate jij drie dingen helder hebt liggen vóór de eerste schets:
- Contenttypes. Wat voor pagina’s heb je — home, dienst, case, blog, begrip? Welke blokken komen daarop voor? Dit wordt het contentmodel, en het is de ruggengraat van alles wat volgt.
- URL-plan en redirects. Welke oude URL’s bestaan en waar moeten ze naartoe? Een migratie is hét moment om je URL-structuur te herstellen; redirects voorkomen dat je rankings verliezen.
- Media en rechten. Waar leven je beelden en video’s, wie bezit ze en in welke kwaliteit? Media verhuizen is saaier dan je denkt en stopt veel migraties.
Een bureau dat deze vragen niet stelt vóór het citeert, heeft je project nog niet begrepen.
Wat je van een bureau mag verwachten
Tot slot de tegenvraag: als je een headless website laat maken, waar mag je op rekenen? Dit zijn de vier punten die ik zelf aan elk gesprek toevoeg:
- Een contentmodel dat jouw team aankan, niet het bureau. Je moet na oplevering zelf pagina’s kunnen samenstellen zonder developer.
- Een migratieplan met redirects en een nulmeting. Oude routes worden netjes doorgestuurd en vóór de switch wordt de huidige snelheid en vindbaarheid gemeteld, zodat je achteraf eerlijk kunt vergelijken.
- Maandelijkse metingen na oplevering. Laat je een headless site bouwen voor snelheid, vraag dan om PageSpeed- en Search Console-rapportages per maand. Wij meten onze eigen cases zo; die regelmaad is het verschil tussen beweren en weten.
- Een onderhoudsregeling die de twee helften dekt. Headless betekent frontend én bron onderhouden. Vraag expliciet wat de regeling dekt: updates aan de frontend, het CMS, de koppeling en de hosting.
Herkent een bureau deze vragen niet, of komt er meteen een platformaanbeveling vóór er naar je team is gevraagd — dan weet je genoeg.
Wil je een headless site laten bouwen met die vragen al beantwoord? Bekijk headless website laten maken voor onze aanpak, of lees eerst hoe wij deze site zonder CMS bouwden als je team technisch is ingesteld. Voor het volledige traject vanaf ontwerp is website laten maken het startpunt.