Headless website laten maken: wanneer het slim is (en wanneer niet)

“Headless” klinkt als een techniek die je gewoon moet willen. Dat zie je ook in de zoektermen: mensen zoeken op headless website laten maken en headless wordpress website laten maken omdat ze een nieuwe site willen en ergens lazen dat headless beter is. De vraag is dan niet meer “wat is het”, maar “is het iets voor mij”. Wil je eerst de twee soorten systemen naast elkaar zien, lees dan headless CMS of klassiek CMS.

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 afraad om headless te laten maken. Ben je er al uit en zoek je iemand die het bouwt, dan staat onze aanpak voor een headless website op een eigen pagina.

Wanneer headless slim is

Headless loont wanneer content en vorm gescheiden móéten 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; die metingen tonen de scores van onze sites, geen gecontroleerde vergelijking met 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 een stuk overzichtelijker.

Een voorbeeld uit onze eigen praktijk is de webshop van Verhuurwinkel. Daar zijn twee bronnen losgekoppeld van de frontend: Storyblok levert alle content en het ERP van de klant levert producten en voorraad, elk via een eigen API. Astro rendert de winkel grotendeels als statische HTML. Bij de meting van 17 september 2026 haalde de site 99/100 voor PageSpeed mobiel, en de LCP bij Chrome-gebruikers (p75) was 0,7 seconden. Die cijfers zeggen iets over deze implementatie, niet over headless in het algemeen.

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. En voor de vraag vóór die vraag — of je site überhaupt zoveel omvang nodig heeft — is eenvoudige website laten maken het vertrekpunt.

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:

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. WordPress noemt dat zelf een legitiem gebruik van die API:

Technisch kan het dus prima. Alleen behoud je daarmee ook de WordPress-onderhoudslast: updates, plugins, hosting, veiligheid. Je ruilt één systeem voor twee. Hetzelfde REST API Handbook zegt trouwens dat je je niet verplicht hoeft te voelen om de API te gebruiken als je site al werkt zoals je wil. Wil je wél definitief van WordPress af en alleen een snelle frontend behouden, dan is een Astro-website laten maken de directere route.

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. Permanente redirects helpen voorkomen dat je opgebouwde zichtbaarheid verloren gaat. Google raadt in zijn handleiding voor een sitemigratie aan om redirects zo lang mogelijk te laten staan, in het algemeen minstens één jaar.
• 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 een offerte maakt, heeft je project nog niet begrepen.

Wat je van een bureau mag verwachten

Dan 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 gemeten, 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 regelmaat 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.

Vier vragen om zelf te beslissen

Twijfel je nog? Beantwoord deze vier vragen eerlijk, liefst met de mensen die straks met de site werken:

1. Werken er twee of meer mensen tegelijk aan je content? Ja wijst richting headless met een editor en rollen. Nee betekent dat een klassiek CMS of een statische site meestal volstaat.
2. Moet dezelfde content naar twee of meer kanalen? Een site plus een app, klantportaal of nieuwsbrief vraagt om één centrale bron. Eén website heeft die scheiding zelden nodig.
3. Hoeveel moet je migreren, en zit je vast aan plugins? Honderden pagina’s of een boekingsmodule die diep in je huidige CMS zit, maken de overstap duur. Reken die migratie mee voor je beslist.
4. Kun je twee helften onderhouden? Headless betekent een frontend én een contentbron, met elk eigen updates. Past dat niet in je budget of je team, dan is een eenvoudiger opzet de betere keuze.

Twee keer ja op de eerste twee vragen en een behapbare migratie? Dan is headless een serieuze optie. Vooral nee? Dan levert een eenvoudigere opzet je meestal meer op voor minder geld.

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.