applatenmaken.com/kennisbank/headless cms of traditioneel

Headless CMS of traditioneel

U heeft een site die op WordPress of een vergelijkbaar systeem draait en u hoort van meerdere kanten dat headless moderner zou zijn. Het verschil zit niet in de kwaliteit van het systeem, maar in de vraag of uw inhoud vastzit aan één presentatie. Deze pagina legt uit wat die scheiding oplevert, wat u ervoor inlevert en aan welke kant u waarschijnlijk hoort uit te komen.

Wat headless werkelijk betekent

Een traditioneel CMS bewaart uw inhoud en bepaalt ook hoe die op het scherm komt. Een redacteur typt een tekst, het systeem zet die in een sjabloon en de bezoeker krijgt een pagina. Beheer en presentatie zitten in hetzelfde systeem.

Een headless CMS doet alleen het eerste deel. Het bewaart de inhoud gestructureerd en levert die uit als gegevens via een API, meestal in JSON. Wat er daarna mee gebeurt, bepaalt een losse voorkant die u zelf laat bouwen. Vandaar de naam: het systeem is zijn hoofd kwijt, de laag die van inhoud een pagina maakte.

Het gevolg is groter dan het klinkt. Uw inhoud is niet langer een pagina maar een verzameling velden. Een vacature is geen opgemaakte tekst meer, maar een functietitel, een standplaats, een urenaantal en een omschrijving. Diezelfde velden kunnen daarna op uw site staan, in een app en op een scherm in de hal, zonder dat iemand ze overtypt.

Traditioneel CMS: Inhoud en presentatie in één systeem. De redacteur ziet meteen hoe de pagina eruit komt te zien. WordPress, Drupal en Umbraco werken van oorsprong zo.
Headless CMS: Alleen inhoudsbeheer. De inhoud wordt via een API opgehaald en door een losse voorkant getoond. Contentful, Sanity, Storyblok, Strapi, Directus, Payload en Hygraph horen hier, deels als dienst en deels als software die u zelf draait.
API-modus of hybride: Een traditioneel systeem dat zijn inhoud ook via een API aanbiedt, zodat u er een losse voorkant op kunt zetten zonder de redactieomgeving te vervangen.

Wat de scheiding oplevert

Het sterkste argument is meervoud. Zodra dezelfde inhoud op meer dan één plek moet landen, wordt een systeem dat alleen pagina's kent een rem. Zonder scheiding gaat iemand kopiëren, en dan lopen de versies uiteen zodra er iets verandert.

Meertaligheid is daarvan de scherpste variant. In veel traditionele opzetten is een tweede taal in de praktijk een tweede site die ernaast meeloopt, met een eigen menu en een eigen achterstand. Headless systemen behandelen taal meestal als eigenschap van een veld, waardoor u per onderdeel ziet wat vertaald is en wat niet. Wat daar verder bij komt kijken staat in software in meerdere talen.

Het tweede voordeel is dat de voorkant vervangbaar wordt. Een nieuw ontwerp vraagt dan geen migratie van de inhoud, omdat de inhoud nooit in het ontwerp zat.

Het derde is dat uw inhoud een gewone bron wordt naast uw andere systemen: uw teksten zijn net zo opvraagbaar als uw voorraad of uw urenregistratie, met dezelfde soort verbinding. Wat dat vraagt leest u in systemen koppelen met een API.

Al deze voordelen gaan over meervoud. Heeft u één site, in één taal, voor één publiek, dan lost u een probleem op dat u niet heeft.

Wat u ervoor inlevert

Het eerste dat verdwijnt, is de directe voorbeeldweergave. In een traditioneel systeem klikt u op voorbeeld en ziet u de pagina. Een headless CMS weet niet hoe uw voorkant eruitziet, dus moet die weergave apart worden gebouwd en daarna bijgehouden. Verschillende aanbieders leveren hier inmiddels iets voor, maar reken het niet stilzwijgend tot de standaard: staat het niet in de opdracht, dan is het er niet.

Het tweede is de manier van werken van uw redactie. Denken in velden in plaats van in pagina's vraagt gewenning, en er komt een grens bij die er eerst niet was. Er even een kolom bij zetten kan niet meer, want wat niet als veld bestaat, bestaat niet. Dat is precies de kracht van de opzet en tegelijk de meest gehoorde klacht erover. In onze ervaring is dat de belangrijkste reden dat een headless traject achteraf tegenvalt, niet de techniek.

Het derde is bouwwerk. In een traditioneel systeem krijgt u zoekfunctie, formulieren, sitemap, doorverwijzingen en een bibliotheek aan uitbreidingen min of meer cadeau. In een headless opzet kiest of bouwt u die zelf, en daarna houdt u twee onderdelen in de lucht in plaats van één. Leg dus vast wie waarvoor aan de lat staat, zoals beschreven in het onderhoudscontract.

Wordt het headless CMS als dienst geleverd, dan staat uw inhoud bovendien bij een externe partij. Dat hoeft geen bezwaar te zijn, maar beantwoord die vraag vooraf. Zie waar staat uw data.

De scheiding is minder scherp dan hij lijkt

De keuze wordt vaak gepresenteerd als twee kampen, terwijl de systemen naar elkaar toe zijn gegroeid. De grote traditionele pakketten bieden hun inhoud allang zelf via een API aan. WordPress heeft een REST API in de kern, die ook de basis vormt onder de blokeditor. Drupal levert JSON:API standaard mee sinds versie 8.7. Umbraco heeft een Content Delivery API ingebouwd die inhoud als JSON uitlevert.

Daarmee ligt er een tussenweg die zelden wordt genoemd: zet een losse voorkant op het systeem dat u al heeft. Uw redactie houdt haar vertrouwde omgeving en u vervangt niets wat het nog doet. Andersom bouwen de headless aanbieders juist voorbeeldweergave en visuele bewerking terug, omdat redacteuren er anders niet mee uit de voeten kunnen.

Let ook op wie het systeem over een paar jaar in handen heeft. Deze markt beweegt: Figma nam Payload in juni 2025 over en Salesforce tekende in juni 2026 een overeenkomst om Contentful over te nemen. Dat is niet per se slecht nieuws, maar het verandert wel de koers en soms de voorwaarden. Neem het mee in dezelfde afweging die u maakt bij het kiezen van een softwareleverancier.

Uw situatie	Waar u waarschijnlijk uitkomt	Waar u op let
Eén site, één taal, redactie doet het zelf	✓Traditioneel systeem, eventueel met de API aangezet voor later	!Dat u geen architectuur koopt voor een probleem dat u niet heeft
Site plus app, of meerdere merken en talen	✓Headless, of uw huidige systeem in API-modus met een nieuwe voorkant	!Wie de voorkant bouwt en onderhoudt, en of voorbeeldweergave meegaat
Inhoud moet ook naar schermen, partners of andere systemen	✓Headless, met de inhoud als bron naast uw overige systemen	!Wie eigenaar is van het model achter de velden

De vragen die de keuze bepalen

De beslissing valt zelden op techniek. Zes vragen brengen hem meestal binnen één gesprek terug tot een antwoord dat u kunt verdedigen.

Op hoeveel plekken moet dezelfde inhoud terechtkomen, nu en in de plannen die er al liggen? Wie beheert de inhoud, en hoe vaak wijkt die van het vaste stramien af? Hoe zwaar weegt het dat een redacteur ziet wat hij maakt voordat hij publiceert? Heeft u een partij die de voorkant bouwt en daarna blijft onderhouden? Speelt meertaligheid, en dan echt meer dan een vertaalde beginpagina? Krijgt u uw inhoud er weer uit als u later van systeem wilt wisselen?

Wijzen de eerste twee antwoorden naar één plek en een vast stramien, dan bedient een traditioneel systeem u vrijwel zeker beter. Wijst het merendeel naar meervoud, dan verdient headless een serieuze vergelijking.

Wilt u geen kant-en-klaar systeem maar een redactieomgeving die op uw eigen werkwijze is toegesneden, dan zit u beter op de pagina over een maatwerk-CMS. Stapt u over, houd er dan rekening mee dat het overzetten van bestaande inhoud een project op zichzelf is; zie datamigratie naar een nieuw systeem.

Veelgestelde vragen

Is een headless CMS sneller dan een traditioneel systeem?

Vaak wel, maar die winst komt van de voorkant en niet van het CMS. Een losse voorkant kan pagina's vooraf klaarzetten. Een goed ingericht traditioneel systeem met verstandige caching komt in de buurt. Snelheid alleen is zelden een goede reden om van architectuur te wisselen.

Kan ik WordPress headless gebruiken?

Ja. WordPress heeft een REST API in de kern, waarmee u de inhoud ophaalt en in een losse voorkant toont. Uw redactie houdt de omgeving die zij kent en u levert de directe voorbeeldweergave in, tenzij die apart wordt gebouwd. Voor wie al op WordPress zit is dit meestal de rustigste tussenstap.

Wat betekent dit voor onze vindbaarheid?

De scheiding zelf zegt daar niets over; de voorkant bepaalt het. Zorg dat pagina's aan de serverkant worden opgebouwd of vooraf klaargezet, dat titels, beschrijvingen en gestructureerde gegevens beheerbaar blijven, en dat oude adressen naar nieuwe verwijzen. Dat laatste wordt bij een overstap het vaakst vergeten.

Kunnen redacteuren nog zelf pagina's samenstellen?

Ja, mits het inhoudsmodel dat toelaat. Veel headless systemen werken met blokken die een redacteur kan stapelen en herschikken. Het verschil is dat iemand die blokken eerst moet bedenken en bouwen. Vrijheid is hier een ontwerpkeuze, geen eigenschap die er vanzelf in zit.

Hoe voorkom ik dat ik vastzit aan één aanbieder?

Vraag voordat u tekent hoe u uw inhoud er weer uit krijgt, in welk formaat dat gebeurt en of het zonder medewerking van de leverancier kan. Leg vast dat het inhoudsmodel van u is. Omdat aanbieders in deze markt worden overgenomen, is dat geen theoretische vraag.