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

Kort antwoord: een klassiek CMS beheert je content én verzorgt zelf hoe die op je website verschijnt. Een headless CMS beheert alleen je content en levert die via een API aan je website, app of een ander kanaal. Klassiek is compleet uit de doos en makkelijk zelf te beheren; headless geeft meer vrijheid, snellere frontends en een schonere contentstructuur, maar vraagt meer techniek. Welke 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: de frontend wordt apart gebouwd, maar haalt zijn content nog steeds via de eigen renderlaag van het CMS op. 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 feitelijker headless — ook al noemt de leverancier het decoupled.

De vergelijking in één tabel

Eerst het overzicht. Daaronder licht ik de criteria toe die de meeste vragen oproepen.

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 niet afhankelijk zijn van een SaaS-leverancier voor je contentopslag.

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, onderhoudsuituren 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. Headless haalt die last grotendeels weg: het CMS is een SaaS-platform dat de leverancier onderhoudt, en je frontend is een statische site zonder database om te kraken. Wat overblijft is contentonderhoud en de frontend zelf. 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.