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

Een headless CMS levert content via een API aan losse frontends, in plaats van zelf de pagina’s te tonen. Dat loont als dezelfde content naar meerdere kanalen gaat en een developer de frontend onderhoudt. Voor een MKB-site met één website en een klein team is een gekoppeld CMS of een git-gebaseerde stack met content collections meestal goedkoper en eenvoudiger.

Wat is een headless CMS?

Een klassiek CMS zoals WordPress doet twee dingen tegelijk: het beheert content en rendert de pagina’s. Een headless CMS doet alleen het eerste. De content staat in een database met een API ervoor, en de frontend (een Astro- of Next.js-site, een app, een kiosk) haalt hem daar op en bepaalt zelf hoe hij eruitziet.

Het idee is aantrekkelijk: één bron, meerdere uitingen, en een frontend die je kunt vervangen zonder de content aan te raken. Bekende aanbieders zijn Contentful, Sanity, Storyblok en Strapi. De prijs zit deels in het abonnement en vooral in de frontend: elke pagina die het CMS vroeger zelf toonde, moet nu iemand bouwen en blijven onderhouden.

Hoe groot is headless eigenlijk?

De cijfers geven een dubbel beeld. In het enterprise-segment is headless de norm geworden: in het State of Headless-onderzoek van WP Engine uit 2024, onder 1.015 beslissers bij organisaties met gemiddeld circa 800 miljoen dollar omzet, zei 73 procent headless te gebruiken (WP Engine, 2024). Dat is dus een onderzoek onder grote bedrijven, uitgevoerd door een partij die zelf headless WordPress verkoopt.

Op het open web ziet het anders uit. Van alle websites draait 40,7 procent op WordPress, goed voor 58,9 procent van alle sites met een herkenbaar CMS (W3Techs, september 2026). Headless-aanbieders komen in die lijst niet in de buurt van de top. De Web Almanac van HTTP Archive telde in 2024 op 51 procent van de onderzochte pagina’s een detecteerbaar CMS (HTTP Archive, 2024). Headless is dus groot bij wie meerdere kanalen en een developmentteam heeft, en klein daarbuiten.

Welke vijf vragen stel je vooraf?

1. Hoeveel frontends tonen dezelfde content? Bij één website is er niets om te ontkoppelen. Headless begint pas te renderen bij een site plus app, meerdere merken op één bron, of schermen in de winkel.
2. Hoeveel redacteuren werken er dagelijks in? Een headless CMS levert een invoerscherm zonder voorvertoning van de echte pagina. Redacteuren die veel publiceren, missen dat snel.
3. Wie onderhoudt de frontend? Zonder developer in dienst of onder contract heb je met headless een site die niemand kan aanpassen als het CMS zijn API wijzigt.
4. Hoe vaak verandert de structuur? Nieuwe paginatypes en velden vragen bij headless altijd twee kanten werk: schema in het CMS en component in de frontend.
5. Is de content echt gestructureerd? Producten, specificaties en events met vaste velden passen bij een API. Vrije tekst met beeld, zoals een blog of dienstenpagina, wint er niets bij.

Zeg je bij vraag 1 “één” en bij vraag 3 “niemand”, dan is het antwoord al gegeven, ongeacht de rest.

Wat is het alternatief?

Voor de meeste MKB-sites zit het antwoord tussen de uitersten in. Een static site generator met content collections, zoals Astro, houdt de content als markdown-bestanden in git: versiebeheer gratis, geen database die kan uitvallen, geen serverkosten voor het CMS (Astro docs). Een dunne bewerkingslaag zoals Sveltia CMS geeft niet-technische collega’s een invoerscherm dat rechtstreeks naar diezelfde bestanden schrijft (Sveltia CMS).

Je krijgt daarmee de snelheid en stabiliteit van een gebouwde site zonder een tweede systeem om te onderhouden. Onze eigen site werkt zo, inclusief de blog die je nu leest. Voor wie liever in een vertrouwde omgeving werkt en veel redacteuren heeft, blijft WordPress met een goed thema een verdedigbare keuze. De afweging maken we per project onder Webdesign & Development.

Drie stacks naast elkaar

	WordPress (gekoppeld)	Astro met content collections	Headless CMS met eigen frontend
Content staat in	Database op de server	Markdown in git	Database van de CMS-leverancier
Redacteursscherm	Volledig, met voorvertoning	Via Sveltia of rechtstreeks in git	Volledig, zonder pagina-voorvertoning
Runtime nodig	PHP en MySQL	Geen, statische bestanden	API van het CMS plus frontend-hosting
Meerdere frontends	Moeizaam	Beperkt	De kernbelofte
Onderhoud	Updates van core, thema, plugins	Dependencies van de build	CMS-abonnement plus frontend-code
Past bij	Veel redacteuren, bekende workflow	Eén site, klein team, snelheid	Meerdere kanalen, eigen developers

Veelgestelde vragen

Is een headless CMS sneller dan WordPress?

Het CMS zelf bepaalt de snelheid niet; de frontend doet dat. Een statisch gebouwde Astro-site is snel omdat er geen server iets berekent bij een bezoek, en dat geldt of de content nu uit git of uit een headless API komt. Een slecht gebouwde headless frontend is net zo traag als een slecht WordPress-thema. Waar je die snelheid aan meet, staat in Core Web Vitals in 2026.

Kan ik later alsnog headless gaan?

Ja, en dat is het sterkste argument om er niet mee te beginnen. Content in markdown of in een WordPress-database is te exporteren naar een headless CMS zodra er een tweede kanaal komt. Andersom, van headless terug naar simpel, kost meer werk omdat de frontend dan al gebouwd is.

Ik heb al WordPress, moet ik herbouwen?

Niet per se. Draait de site stabiel en zijn de redacteuren tevreden, dan is opknappen goedkoper dan vervangen. Loopt de site vast op updates, plugins of snelheid, dan is dat het moment voor de vergelijking in WordPress vs Webflow vs Astro. Voor beide routes kun je terecht bij WordPress beheer en overname of WordPress website laten maken.

Bronnen

1. Demand for Headless Increases, Finds Latest Report by WP Engine, WP Engine, 2024
2. Usage statistics and market share of content management systems, W3Techs, september 2026
3. Web Almanac 2024: CMS, HTTP Archive, 2024
4. Content collections, Astro Docs, geraadpleegd 2026
5. Sveltia CMS, GitHub, geraadpleegd 2026