Headless CMS is niet altijd het antwoord — 5 vragen die je vooraf moet stellen

Sinds 2020 is “headless CMS” een soort magisch woord geworden. Elk project wil het; elke developer pitcht het; elk recruiter-email gaat erover. Maar de realiteit is dat voor ~70% van de sites we bouwen, headless de verkeerde keuze is.

Waarom headless bestaat

Het idee is elegant: scheid de content (API) van de presentatie (frontend). Één content-source, meerdere frontends — web, mobile, smartwatch, POS. Dat is de droom.

Wanneer het werkt

Je publiceert dezelfde content naar 3+ frontends
Je hebt een team van 5+ developers
Je content-team werkt elke dag met gestructureerde data (SKU’s, specs, pricing tables)
Je hebt een budget van €60k+ voor de technische setup

Wanneer het niet werkt

Je hebt één website met 20 pagina’s en een blog
Je team is 2 mensen met WordPress-ervaring
Je verandert je content weinig en nooit in bulk
Je tijdslijn is onder 3 maanden

In die gevallen is een traditional CMS (WordPress, Statamic, Ghost) of een git-based flow (Astro + MDX) veel beter — simpeler te onderhouden, goedkoper, vaak sneller.

De vijf vragen

1. Hoeveel frontends publiceren dezelfde content? Onder 2: geen headless.

2. Hoeveel content-redacteuren heb je? Onder 3, waarbij 2+ dagelijks editen: geen headless.

3. Hoeveel developers onderhouden het? Onder 2 fulltime devs: geen headless.

4. Hoeveel release-deploys per week? Onder 2: waarschijnlijk geen headless nodig.

5. Is content écht gestructureerd? Als het vooral vrije tekst en beeld is: geen headless. Als het echte data is (producten, events, specs): ja, headless.

Het midden: content-collections

Voor de meeste sites is een static site generator met content-collections (Astro, Next.js) de sweet spot. Git is je CMS, je content is versie-gecontroleerd, je hebt geen runtime database, en non-devs kunnen editten via een CMS-laag als Sveltia. Kost bijna niets, schaalt prima, en crasht nooit op het verkeerde moment.

Dat is wat we 70% van de tijd bouwen. Het werkt.