Wat is een headless CMS?
Een headless CMS is een systeem waarin je inhoud beheert zonder dat het bepaalt hoe die inhoud eruitziet. Je vult velden in, en het systeem stelt die gegevens beschikbaar via een API. Wat er vervolgens mee gebeurt, bepaalt een aparte toepassing: een website, een app, een informatiescherm of alle drie tegelijk. De presentatielaag ontbreekt bewust, vandaar de term.
Dat is een wezenlijk andere opzet dan bij WordPress of Drupal, waar het beheren en het tonen van inhoud in hetzelfde systeem zitten. Het voordeel is hergebruik: één keer schrijven, overal tonen. Het nadeel is dat er iets moet worden gebouwd dat die inhoud toont, want het CMS doet dat niet meer voor je.
In de Nederlandse markt kom je onder meer Contentful, Storyblok, Sanity en Statamic tegen. Ze verschillen sterk in prijsmodel, in hoe prettig het redigeren is en in hoeveel ze zelf regelen. De keuze wordt in de praktijk vaak bepaald door waar het bureau ervaring mee heeft, wat een reden is om er zelf ook naar te vragen.
Wat valt er precies onder?
Het inrichten van een headless CMS draait om het modelleren van inhoud en om de redactionele werkwijze eromheen.
- Inhoudsmodel: het vastleggen van de soorten inhoud en hun velden, los van hoe ze getoond worden.
- Componentgerichte inhoud: pagina’s samenstellen uit herbruikbare blokken in plaats van uit vrije tekst.
- API-configuratie: bepalen hoe inhoud wordt opgevraagd, met REST of GraphQL, en hoe die wordt gefilterd.
- Voorbeeldweergave: een omgeving waarin redacteuren zien hoe hun wijziging eruitziet voordat die live gaat.
- Rechten en werkstromen: wie mag wat bewerken en publiceren, en of er een controlestap tussen zit.
- Meertaligheid: vertaalde varianten van inhoud, met een werkwijze voor vertalers.
- Mediabeheer: het beheren van afbeeldingen en bestanden, meestal met automatische formaten en uitsnedes.
- Publicatiemechanisme: wat er gebeurt bij publicatie, van meteen doorgeven tot het opnieuw genereren van pagina’s.
Hoe verloopt de inrichting van een headless CMS?
De volgorde draait om het inhoudsmodel: dat bepaalt zowel wat redacteuren kunnen als wat de voorkant kan tonen.
- Systeemkeuze. Er wordt een CMS gekozen op basis van redactionele wensen, prijsmodel bij groei en de ervaring van het bureau.
- Inhoud modelleren. De soorten inhoud en hun velden worden vastgelegd, met aandacht voor hergebruik over kanalen heen.
- Blokken definiëren. Er wordt bepaald uit welke herbruikbare onderdelen pagina’s kunnen worden samengesteld en hoeveel vrijheid redacteuren krijgen.
- Voorkant koppelen. De website of app wordt gebouwd tegen de API, inclusief gedrag bij ontbrekende of onvolledige inhoud.
- Voorbeeldweergave inrichten. Redacteuren krijgen een manier om hun wijziging te zien voordat die wordt gepubliceerd.
- Migreren en overdragen. Bestaande inhoud wordt overgezet naar het nieuwe model en de redactie wordt ingewerkt in de nieuwe manier van werken.
Wanneer heb je dit nodig?
De sterkste aanleiding is meerdere kanalen. Als dezelfde inhoud in een website, een app en bijvoorbeeld schermen op locatie moet verschijnen, is een centrale bron aanzienlijk efficiënter dan drie plekken bijhouden.
Een tweede aanleiding is een eigen ontwikkelteam dat de voorkant zelf bouwt en wil kunnen kiezen met welke techniek. De scheiding geeft die vrijheid zonder dat het CMS in de weg zit.
Ook inhoud die als gegevens moet worden behandeld pleit ervoor: productinformatie, locaties, evenementen of tarieven die op veel plekken in verschillende vormen terugkomen. Waar het minder past, is bij een enkele inhoudsgerichte website met een redactie die gewend is aan visueel bewerken. Daar levert het vooral kosten en gemis op.
Wat levert het op?
De opbrengst zit in hergebruik en in vrijheid. Inhoud wordt eenmaal onderhouden en overal gebruikt, en de presentatielaag kan worden vernieuwd zonder dat er aan het CMS iets verandert. Voor organisaties die hun website eens in de vier jaar vernieuwen, betekent dat een aanzienlijk lichtere vernieuwing, omdat de inhoud en het model blijven staan. Ook maakt de gestructureerde opzet inhoud beter herbruikbaar dan wanneer opmaak en tekst verweven zijn.
De prijs daarvoor is complexiteit en gemis aan de redactiekant. Er moet een voorkant worden gebouwd en onderhouden die er anders al was, en de abonnementskosten groeien mee met gebruik. Redacteuren verliezen het directe verband tussen bewerken en zien, tenzij daar apart in wordt geïnvesteerd, en dat is de meest gehoorde klacht na oplevering. Bureaus die een headless CMS aanbevelen zonder te vragen hoeveel kanalen er zijn en hoe de redactie werkt, slaan de twee vragen over die de keuze zouden moeten bepalen.
Waar let je op als je dit uitbesteedt?
Vraag hoeveel kanalen er daadwerkelijk worden gevoed. Bij één website is het voordeel beperkt en wegen de kosten zwaarder. Vraag vervolgens om een demonstratie van de redactieomgeving met echte inhoud: laat zien hoe iemand een pagina samenstelt en hoe hij het resultaat vooraf ziet. Dat is het punt waarop de meeste ontevredenheid ontstaat.
Breng daarnaast de doorlopende kosten in kaart voor een realistisch scenario over meerdere jaren, inclusief groei in redacteuren, inhoud en verkeer. Sommige prijsmodellen schalen onaangenaam. Vraag ook hoe een volledige export eruitziet, zodat je weet wat je meeneemt bij een overstap. Vraag ten slotte hoe pagina’s worden gegenereerd en wat dat betekent voor zoekmachines, want een voorkant die volledig in de browser wordt opgebouwd, kan vindbaarheid schaden.
Veelgemaakte fouten
De fouten komen vrijwel altijd voort uit het kiezen van de architectuur voordat de behoefte is vastgesteld.
- Headless kiezen voor één kanaal. Zonder tweede kanaal blijft het voordeel klein terwijl de kosten en de complexiteit onverkort gelden.
- De voorbeeldweergave overslaan. Redacteuren die blind publiceren maken fouten en raken ontevreden over een site die verder prima werkt.
- Prijsmodel niet doorrekenen. Abonnementen die meegroeien met API-aanroepen of redacteuren kunnen bij succes onverwacht hoog uitvallen.
- Het inhoudsmodel te vrij maken. Als redacteuren elk blok overal kunnen plaatsen, valt de consistentie van de site alsnog uit elkaar.
Wat bepaalt de prijs?
De kosten bestaan uit inrichting, het bouwen van de voorkant en een doorlopend abonnement. Die laatste post weegt bij dit type systeem zwaarder dan gebruikelijk.
| Wat de prijs opdrijft | Waarom het meetelt |
|---|---|
| Omvang van het inhoudsmodel | Meer inhoudstypen en blokken vragen meer inrichting en meer werk aan de presentatiekant. |
| Bouwen van de voorkant | De presentatielaag die een klassiek CMS zelf verzorgt, moet hier volledig worden ontwikkeld. |
| Maatwerk in de redactieomgeving | Een goede voorbeeldweergave en prettige bewerkervaring zijn extra bouwwerk. |
| Abonnement bij groei | Kosten die meelopen met redacteuren, inhoud of API-verkeer kunnen bij succes fors oplopen. |
De inrichting en de voorkant worden op projectbasis begroot; het CMS zelf is doorgaans een maandelijks abonnement dat je rechtstreeks of via het bureau afneemt. Neem dat abonnement rechtstreeks af waar dat kan, zodat je de zeggenschap houdt. Vraag om een kostenraming voor jaar een tot en met drie bij verwachte groei, want dat is het punt waarop headless-projecten achteraf duurder uitpakken dan begroot.
Headless CMS en aanverwante diensten
Een headless CMS is de inhoudskant van een bredere architectuurkeuze. Headless en Jamstack beschrijft de opzet waar dit systeem de helft van vormt; de andere helft is de presentatielaag. Frontend-development weegt hier zwaarder dan bij klassieke platformen, omdat de complete voorkant zelf wordt gebouwd. Koppelingen en API’s vormen de verbinding met andere systemen en zijn bij deze opzet vanzelfsprekend aanwezig. Informatiearchitectuur raakt eraan via het inhoudsmodel, dat hier explicieter moet worden vastgelegd dan elders. En app-development is de meest voorkomende reden om voor deze opzet te kiezen, omdat website en app dan uit dezelfde bron putten. In Nederland bieden vooral bureaus met eigen ontwikkelcapaciteit dit aan.