Headless CMS of klassiek CMS: welk past bij jouw website?

Welke CMS-architectuur bij je past, hangt af van je team, je kanalen en hoeveel onderhoud je zelf wilt doen.

Wat is het verschil tussen headless en klassiek CMS?

Het verschil zit in waar de vormgeving gebeurt. Een klassiek CMS als WordPress in de standaardopzet doet alles zelf: content opslaan, pagina’s renderen, thema’s en plugins beheren. Je vult iets in in het dashboard en het systeem bepaalt mee hoe het eruitziet. Dat is precies waarom het zo’n lage drempel heeft.

Een headless CMS laat dat laatste los. Het beheert je teksten, beelden en structuur, maar levert die als gestructureerde content via een API aan welke frontend je maar wilt. Wil je het hele begrip rustiger tot je laten doordringen? Lees eerst wat een headless CMS precies is. In dit artikel vergelijk ik beide architecturen op de criteria die voor de meeste bedrijfswebsites doorslaggevend zijn.

Klassiek, decoupled of headless: drie architecturen

De meeste vergelijkingen springen van twee naar nul opties. Er bestaat een tussenvorm die in de praktijk vaak voorkomt: het decoupled CMS. De verwarring is terecht, dus hier de drie naast elkaar:

• Klassiek (coupled): backend en frontend zijn één systeem. Contentbeheer en weergave zitten in hetzelfde pakket.
• Decoupled: contentbeheer en presentatie zijn gescheiden, maar het CMS biedt vaak nog een eigen presentatielaag naast API-toegang. Je hebt twee onderdelen, wel elk met hun eigen logica.
• Headless: het CMS is puur een contentbron met een API. De frontend is volledig vrij en weet van het CMS alleen wat de API vertelt.

Het praktische verschil tussen decoupled en headless is subtiel maar echt: een decoupled CMS denkt nog mee als webpagina-server, een headless CMS denkt in content die overal kan verschijnen. Wie vandaag een moderne site bouwt met Astro of een andere statische frontend en de content uit een API haalt, werkt feitelijk headless — ook al noemt de leverancier het decoupled.

Klassiek CMS en headless CMS naast elkaar

De belangrijkste verschillen op een rij. Geen winnaar, wel een patroon: hoe meer kanalen, groei en structuur je planningshorizon heeft, hoe meer architectuur telt.

Twijfel je welke architectuur past bij jouw plannen? Vraag een gesprek; ik bekijk eerlijk wat de moeite loont.

Bekijk de headless CMS-dienst

Wanneer klassiek CMS nog steeds slimmer is

Laten we eerlijk beginnen: headless is geen doel op zich, het is een architectuur. In deze situaties is klassiek nog steeds de verstandigste keuze:

• Je hebt één eenvoudige website die snel live moet, zonder aparte frontend-ontwikkeling.
• Er is geen developer in je team en je wilt zelf alles kunnen beheren met een vertrouwd dashboard.
• Je leunt bewust op het plugin-ecosysteem: functionaliteit die bij headless maatwerk is, installeer je hier kant-en-klaar.
• Je wilt zelf hosten en tegelijk een ingebouwde presentatielaag behouden; self-hosted headless is ook mogelijk.

De keerzijde ken je misschien: plugins die updates eisen, thema’s die elkaar in de weg zitten, en een snelheid die vanzelf achteruitloopt als je site groeit. Klassiek is geen slechte keuze, wel een keuze voor onderhoudsdiscipline.

Wanneer headless CMS sterker is

Headless wint zodra één van deze dingen speelt:

• Meerdere kanalen of talen die dezelfde content hergebruiken: website, app, platform.
• Hoge eisen aan snelheid en Core Web Vitals, waar statisch renderen en een CDN het verschil maken.
• Een redactieteam dat veilig moet kunnen werken binnen afgebakende componenten, zonder per pagina een ontwikkelaar nodig te hebben.
• Wens om content te structureren als hergebruikbare bouwstenen in plaats van losse pagina’s.

De zekerheid dat een component overal hetzelfde werkt, is voor groeiende organisaties vaak de doorslaggevende winst: één keer definiëren wat een pagina mag bevatten, overal hergebruiken.

Contentworkflow: componenten in plaats van pagina’s

In een klassiek CMS denk je in pagina’s: elke pagina is een eigen document met eigen onderdelen. In een headless CMS denk je in componenten: een hero, een sectie met kaarten, een FAQ-blok. Die componenten zet je samen tot pagina’s, en dezelfde bouwstenen verschijnen later ook in je app of op een volgend kanaal.

Die omschakeling voelt in het begin als extra werk, maar is precies wat governance mogelijk maakt: je definieert welke content bestaat, wie die beheert en waar die mag verschijnen. In plaats van dat elke pagina zijn eigen losgeslagen ecosysteem vormt, houden componenten de lijn vast.

Hoe ik dat zelf aanpak: bij een CMS-traject laat ik AI-agents op Hermes de content-inventaris en de eerste aanzet van het componentmodel voorbereiden — bestaande pagina’s analyseren, terugkerende patronen clusteren en een voorstel maken van bouwstenen. Ik beoordeel dat voorstel, schuur het componentmodel bij samen met de klant en bouw de frontend. Zo blijft de beslissing over wat content is en hoe die structuur krijgt, bij de mens; het agentwerk zit in het voorbereiden en structureren. Voor zo’n traject kun je terecht op de headless CMS-dienstpagina.

SEO en performance: de eerlijke nuances

Hier moet een mythe de wereld uit: een headless CMS maakt je website niet automatisch sneller, en een klassiek CMS maakt hem niet automatisch langzaam. Snelheid wordt behaald in de frontend: statisch renderen, goede caching, scherpe afbeeldingen en een CDN. Een moderne headless-setup maakt dat makkelijker, maar een slecht gebouwde frontend op een headless CMS is gewoon een trage site.

Wat wél verschilt: bij headless heb je volledige controle over de gegenereerde HTML — semantische opmaak, structured data, laadvolgorde. En gestructureerde content helpt om consistent te publiceren: dezelfde component rendert altijd dezelfde correcte markup. Dat is geen ranking-truc, wel een discipline die bijdraagt.

Kosten: twee rekenmodellen

Klassiek start laagdrempelig: hosting, een thema en veel gratis plugins. De kosten verschuiven naar later, richting premium-plugins, onderhoudsuren en de prijs van update-discipline. Headless start met een CMS-abonnement plus investering in frontend-ontwikkeling, en is daarna voorspelbaarder per maand. Welk model gunstiger uitpakt, hangt af van hoeveel je site doet en hoe lang je hem houdt. Ik publiceer hier bewust geen bedragen, want het eerlijke antwoord hangt af van jouw situatie; daarvoor kun je altijd een gesprek aanvragen.

Onderhoud en veiligheid

Klassiek betekent eigen verantwoordelijkheid: core-, thema- en plugin-updates, back-ups en serverbeveiliging. De meeste inbraken die ik tegenkom komen van vergeten plugin-updates, niet van het CMS zelf. Bij een headless SaaS-CMS onderhoudt de leverancier het platform; bij een self-hosted CMS doe je dat zelf. De frontend kan statisch zijn, maar ook dynamisch. API-rechten, accounts, frontend-dependencies en eventuele servers blijven beveiliging en onderhoud vragen. Ook dat kun je uitbesteden via website-onderhoud.

Zo kies je: vier vragen

Vier vragen brengen je snel bij een richting:

• Hoeveel kanalen en talen moet je nu en over twee jaar bedienen?
• Wie werkt er dagelijks in het systeem, en hoe technisch is dat team?
• Hoe belangrijk zijn snelheid en veiligheid voor je omzet?
• Wil je zelf beheren met een laagdrempelig dashboard, of structuur bouwen die meegroeit?

Eén kanaal, weinig techniek, snel live: klassiek is prima. Meerdere kanalen, groeiende ambities, een redactieteam: headless verdient de investering. En als je tussen twee antwoorden zit, is dat precies het soort afweging waar een kort gesprek meer oplevert dan een artikel.

Conclusie

Klassiek en headless zijn twee gereedschappen voor verschillende klussen. Klassiek is compleet, laagdrempelig en bewezen; headless geeft meer vrijheid en structuur en houdt groei over kanalen heen vol. De vergelijking zelf is het begin; daarna komt de concrete systeemkeuze. Vergelijk Storyblok en WordPress als concrete systemen, of ga rechtstreeks na wat een nieuwe website voor jouw situatie betekent.