Een headless CMS is een contentmanagementsysteem zonder eigen presentatielaag: je beheert content in het CMS, en een losse front-end haalt die op via een API. Bekende voorbeelden zijn Contentful, Strapi, Sanity en Storyblok. Cube bouwt zowel headless als traditioneel, en de keuze hangt af van waar je content naartoe moet.
Hoe werkt een headless CMS?
Een headless CMS slaat content op als gestructureerde data en levert die via een API aan elk kanaal dat erom vraagt. De "head" is de presentatielaag: de website of app die de bezoeker ziet. Bij een headless CMS ontbreekt die laag in het systeem zelf. Een redacteur vult in het headless CMS velden in, zoals een titel, een samenvatting, een afbeelding en een prijs. Het CMS bepaalt niet hoe dat eruitziet. Een aparte front-end, bijvoorbeeld een website in Vue.js met Nuxt of een mobiele app, vraagt de content op via een REST API of GraphQL en bouwt daar de pagina mee op. Content en presentatie zijn zo twee losse systemen die met elkaar praten. Dat onderscheid tussen beheer en weergave sluit aan op het verschil tussen front-end en back-end: het headless CMS is de back-end, de site of app is de front-end. Hoe systemen via een API gegevens uitwisselen, lees je in wat een API-koppeling is.
Wat is het verschil tussen een headless, een traditioneel en een decoupled CMS?
Het verschil zit in hoe het CMS content presenteert. Een traditioneel CMS toont content als website, een headless CMS levert die alleen via een API. Een decoupled CMS combineert beide: je bouwt een gewone website en stelt later content beschikbaar voor bijvoorbeeld een app of portaal, zonder het CMS te vervangen. Dat maakt het een praktische middenweg, bijvoorbeeld met Statamic of Craft CMS.
Traditioneel CMS
• Presentatielaag ingebouwd
• Preview voor redacteuren standaard
• Minste developmentcapaciteit nodig
• Beperkt geschikt voor meerdere kanalen
• Voorbeeld: WordPress, klassiek gebruikt
Decoupled CMS
• Eigen presentatielaag, plus een API
• Preview standaard voor de website
• Content via de API naar app of portaal
• Voorbeelden: Statamic, Craft CMS en WordPress met REST API
Headless CMS
• Geen presentatielaag, aparte front-end
• Gemaakt voor meerdere kanalen tegelijk
• Preview moet apart gebouwd worden
• Twee systemen om te bouwen en beheren
• Voorbeelden: Contentful, Strapi, Sanity, Storyblok
Wat zijn de voordelen van een headless CMS?
Het belangrijkste voordeel van een headless CMS is dat één bron van content meerdere kanalen tegelijk bedient. Dezelfde productinformatie verschijnt op je website, in je app en in een dealerportaal, en je past die op één plek aan. Dat heet omnichannel publiceren.
Andere voordelen van een headless CMS:
Vrije keuze in front-endtechnologie. Je bouwt de front-end in het framework dat bij het project past, en vervangt die later zonder het CMS aan te raken.
Snelheid en cachebaarheid. Pagina's kunnen vooraf worden gegenereerd (static site generation) en via een CDN worden geserveerd.
Kleiner aanvalsoppervlak. De beheeromgeving hoeft niet op hetzelfde domein te draaien als de publieke site.
Composable architecture. Een headless CMS combineert goed met andere losse bouwstenen, zoals een PIM-systeem of een commerceplatform als commercetools.
Wat zijn de nadelen van een headless CMS?
Het grootste nadeel van een headless CMS is dat je twee systemen bouwt en beheert in plaats van één. Dat betekent meer development bij de start en meer beheer daarna. Veel functies die een traditioneel CMS standaard meelevert, moeten bij headless in de front-end worden gebouwd.
Concreet gaat het om:
Preview en paginabouw. Redacteuren zien niet automatisch hoe hun pagina eruitziet. Een live preview moet apart worden ingericht.
SEO-basis. Sitemaps, canonical tags, meta-velden, redirects en structured data regelt de front-end, niet het CMS.
Afhankelijkheid van developers. Een nieuw paginatype of blok vraagt vaak een aanpassing in de front-end.
Doorlopende kosten. Bij SaaS-varianten betaal je vaak per gebruiker, per omgeving of naar API-gebruik, bovenop hosting en beheer van de front-end.
Deze nadelen zijn geen reden om headless af te wijzen, maar ze horen wel in de afweging. Ons standpunt: voor de meeste corporate websites is headless niet nodig. Een CMS als Statamic levert een snelle, server-rendered website op en laat de deur open voor een API als er later een app of portaal bij komt.
Wanneer kies je wel en wanneer niet voor headless?
Kies voor een headless CMS als dezelfde content naar meerdere kanalen moet of als de front-end eigenlijk een applicatie is. Kies voor een traditioneel of decoupled CMS als je vooral een website hebt die redacteuren zelf willen beheren.
Headless bij meerdere kanalen
• Content gaat naar website, app en portaal
• De front-end draait op veel live data
• Er is een team voor de front-end
• Front-end en CMS vernieuw je los van elkaar
Traditioneel of decoupled bij één website
• De website is je belangrijkste kanaal
• Redacteuren bouwen zelf pagina's met preview
• Beheer en kosten blijven beperkt
• Een API kan later alsnog worden geopend
Headless en vindbaarheid: wat betekent het voor SEO en AI-zoekmachines?
Een headless CMS is voor SEO en AI-zoekmachines neutraal; wat telt is hoe de front-end de pagina rendert. Bij server-side rendering of static site generation staat de content direct in de HTML. Bij client-side rendering komt er eerst een vrijwel lege pagina binnen, en bouwt JavaScript de inhoud pas in de browser op. Google kan JavaScript renderen, maar doet dat in een aparte stap na het crawlen, zo staat in de JavaScript SEO-documentatie van Google Search Central. Voor de crawlers van AI-zoekmachines is minder bekend. Er wordt breed aangenomen dat veel van die crawlers geen JavaScript uitvoeren, maar geen enkele aanbieder heeft dat officieel bevestigd of ontkend.
Een volledig client-side gerenderde headless website is daarom een risico voor je vindbaarheid in AI-antwoorden, en dat risico dek je goedkoop af. Frameworks als Nuxt (Vue.js) en Next.js (React) renderen pagina's op de server. Bij Vista Hypotheken bouwde Cube een headless front-end in Nuxt met server-side rendering, met DatoCMS als CMS en een GraphQL-API ertussen. Lees meer in de case van Vista Hypotheken.
Een headless CMS kan voor GEO, generative engine optimization, juist een voordeel zijn. GEO is het optimaliseren van content zodat AI-zoekmachines als ChatGPT, Perplexity en Google AI Overviews die gebruiken en citeren. Omdat content in een headless CMS in velden is opgeslagen, kun je afdwingen dat elke pagina een kort antwoord bovenaan heeft, een FAQ en een zichtbare auteur.
Welke SEO-basis heeft een headless front-end nodig?
Bij een headless CMS bepaalt de front-end de SEO-basis. Wat een traditioneel CMS vaak meelevert, moet je bij headless expliciet laten bouwen. Neem deze drie onderdelen op in je eisen.
Rendering
• Server-side rendering of static generation
• Content direct in de HTML
• Snelle laadtijd, ook op mobiel
Technische SEO
• Meta title en description beheerbaar
• Sitemaps, canonicals en redirects
• Hreflang bij een meertalige site
GEO en structuur
• Structured data vanuit de contentvelden
• Vaste velden voor kort antwoord en FAQ
• Auteur en datum zichtbaar op de pagina
Hoe bouw je een headless website met AI?
Een headless website bouw je met AI door AI-agents in te zetten als versnellers in het ontwikkelproces, terwijl specialisten de keuzes maken en het resultaat beoordelen. Een headless architectuur leent zich daar goed voor: het contentmodel en de API leggen precies vast welke data er is, en dat geeft een AI-agent een duidelijk kader om in te werken. Bij Cube werken engineers en AI-agents samen in één werkwijze. De agents draaien op Cube's eigen kennis, werkwijze, context en skills, en helpen bij codegeneratie, het opzetten van tests, documentatie, refactoring en automatische kwaliteitschecks. Onze specialisten bepalen de technische keuzes, beoordelen het resultaat en nemen de verantwoordelijkheid. AI-gegenereerde code gaat dus altijd door dezelfde review en tests als code die een developer zelf schrijft.
Waar AI en headless elkaar versterken.
AI speelt bij headless ook een rol na de livegang. Content die via een API beschikbaar is, kan een AI-toepassing voeden, zoals een chatbot of een AI-agent die vragen beantwoordt op basis van je eigen content.
AI in het bouwproces
• Componenten en koppelingen sneller opgezet
• Tests en documentatie meegegenereerd
• Automatische kwaliteitschecks
• Specialisten reviewen al het werk
AI bovenop je content
• Eén contentbron voor site, app en AI
• Een chatbot die antwoordt uit je content
• Een MCP-server voor AI-agents
• Beheer blijft bij je redacteuren
Twijfel je tussen headless en traditioneel? Bespreek het in 30 minuten met Jarno.
Websites en platformen die we bouwden.
Vista Hypotheken
Van start-up naar scale-up: een stevige technische basis voor Vista Hypotheken.
-
Website
Infotopics
Hoe Infotopics haar merk versterkte met een website die meegroeit met de business.
-
Website
Dit sluit mooi aan...
Wat is het verschil tussen front-end en back-end?
Ontdek in heldere taal wat de front-end en back-end van software doen, hoe ze samenwerken en wat jouw project nodig heeft.
Wat is een API-koppeling?
Het verschil met een API en een webhook, en wat een koppeling in de praktijk vraagt.
Front-end development met JavaScript: frameworks en keuzes.
Leer wat JavaScript doet in de front-end en welke frameworks (React, Vue, Angular of Alpine.js) bij jouw project passen.
Vragen over headless CMS? Geen probleem.
Een headless CMS heeft geen eigen presentatielaag en levert content alleen via een API. Een decoupled CMS heeft wel een eigen website-weergave en biedt daarnaast een API voor andere kanalen, zoals een app of portaal.
WordPress is van origine een traditioneel CMS, maar kan via de ingebouwde REST API ook headless worden gebruikt. In die opzet beheer je content in WordPress en bouwt een aparte front-end de website.
Een headless website kan sneller zijn, vooral met static site generation en een CDN, maar dat komt door de front-end en niet door het CMS zelf. Een goed gebouwde server-rendered website op een traditioneel CMS kan net zo snel zijn.
Voor het invullen van content niet: dat doen redacteuren in de beheeromgeving. Voor nieuwe paginatypen, blokken of een live preview is bij een headless CMS wel vaker een developer nodig dan bij een traditioneel CMS.
Statamic is geen puur headless CMS, maar kan wel headless worden ingezet. Standaard bouwt Statamic zelf de website, en daarnaast kan het content via een API leveren. Daarmee valt het in de categorie decoupled.
Een headless CMS is niet vanzelf beter of slechter voor SEO; de front-end bepaalt het resultaat. Met server-side rendering en goed gebouwde meta-velden, sitemaps en structured data scoort een headless website net zo goed als een traditionele.
Ja, AI-agents versnellen het bouwen van componenten, koppelingen, tests en documentatie. Bij Cube bepalen specialisten de technische keuzes en reviewen ze al het werk, zodat AI-gegenereerde code dezelfde kwaliteitscontrole doorloopt als andere code.
Een headless website kost doorgaans meer dan een traditionele website, omdat je twee systemen bouwt en beheert. Wat de prijs bepaalt, zijn vooral het aantal kanalen, de koppelingen en de preview- en SEO-functies die in de front-end gebouwd moeten worden. Hoe de prijs van maatwerk is opgebouwd, lees je in wat maatwerk software kost.