Skip to content

Headless CMS
Headless, maar niet vanzelfsprekend

Een headless CMS scheidt het beheren van content van het tonen ervan. Dat klinkt technisch, en dat is het ook. Toch is het vooral een keuze met gevolgen voor je kosten, je beheer en de manier waarop je redactie werkt.

Hieronder lees je wat een headless CMS is, wanneer het je echt iets oplevert en wanneer je er beter vanaf kunt zien. En als het wel het juiste antwoord is, waarom je er meestal geen apart systeem voor nodig hebt.

Illustratie van een oranje Umbraco-logo met gekleurde pijlen die alle kanten op wijzen, content naar meerdere kanalen

Wat is een headless CMS?

Een headless CMS is een content management systeem dat de contentbeheer-backend (de "body") scheidt van de presentatie-frontend (de "head"). Traditionele CMS combineren deze lagen, waardoor content en presentatie nauw met elkaar verweven zijn. Een headless CMS daarentegen maakt content toegankelijk via een API (zoals RESTful of GraphQL), waardoor de presentatie flexibel kan worden beheerd. Dit betekent dat ontwikkelaars content kunnen leveren aan verschillende kanalen zoals websites, mobiele apps en meer, zonder beperkt te zijn door een specifieke frontend-technologie.

In plaats van één vaste presentatievorm levert het systeem de content uit als gegevens. Wat daarmee gebeurt, bepaal je per kanaal. Dezelfde productomschrijving kan zo op je website staan, in een app en op een scherm in de showroom, zonder dat iemand hem drie keer invoert.

Traditioneel of headless

Bij een traditioneel CMS zitten content en presentatie aan elkaar vast. Een redacteur ziet tijdens het schrijven hoe de pagina eruit komt te zien, publiceert, en klaar. Eén systeem, één plek waar iets kan misgaan.

Bij headless laat je die koppeling los. Je wint er flexibiliteit mee, want elk kanaal haalt op wat het nodig heeft. Je levert er eenvoud voor in, want de voorvertoning komt niet meer vanzelf mee en je hebt twee onderdelen om te onderhouden in plaats van één.

Die ruil is de hele afweging. Bedien je meerdere kanalen met dezelfde content, dan betaalt de flexibiliteit zich terug. Heb je één website, dan betaal je voor flexibiliteit die je niet gebruikt.

Wanneer headless niet het antwoord is

Headless wordt vaker gekozen dan het nodig is. In veel gevallen komt de vraag voort uit iets anders dan de architectuur, en dan los je het probleem niet op door het CMS los te koppelen.

  • Je wilt een snellere site.
    Snelheid komt zelden door de koppeling tussen content en presentatie. Hosting, beeldverwerking en caching leveren meestal meer op, en kosten een fractie.

  • Je redactie vindt het huidige systeem onhandig.
    Dat is een inrichtingsvraag. Headless maakt het werk van redacteuren in de praktijk juist zwaarder, omdat de voorvertoning van een pagina niet vanzelf meekomt.

  • Je hebt één website.
    Dan betaal je voor flexibiliteit tussen kanalen die je niet hebt. Je krijgt twee systemen om te onderhouden in plaats van één.

  • Een developer heeft het voorgesteld.
    Vraag dan welke concrete beperking hiermee wegvalt. Als het antwoord gaat over de voorkeur voor een framework en niet over een probleem dat je nu hebt, is het geen architectuurkeuze.

Headless wordt interessant op het moment dat je dezelfde content echt op meerdere plekken nodig hebt, en die plekken niet hetzelfde kunnen delen. Dan is het de goedkoopste oplossing die er is. Daarvoor niet.

Voordelen van een headless CMS

  • Flexibiliteit en schaalbaarheid 
    Een headless CMS maakt het mogelijk om content op verschillende platforms te delen, van websites tot mobiele apps en zelfs IoT-apparaten. Dit zorgt voor een bredere bereikbaarheid en efficiënt beheer van je content.

  • Snellere ontwikkeling - Ontwikkelaars kunnen moderne technologieën gebruiken zonder de beperkingen van een gekoppelde frontend. Dit betekent dat ze sneller kunnen innoveren en nieuwe functies kunnen implementeren zonder vast te zitten aan verouderde systemen.

  • Verbeterde beveiliging
    De redactieomgeving hoeft niet publiek bereikbaar te zijn, wat één aanvalsroute wegneemt. Daar staat tegenover dat je een API en een tweede applicatie bijhoudt.

  • Toekomstbestendig
    Een API-first benadering zorgt ervoor dat je eenvoudig nieuwe technologieën kunt integreren zonder grote herstructureringen. Je kunt een kanaal vervangen zonder de content opnieuw op te bouwen. Een nieuwe website betekent dan niet opnieuw alles invoeren.

Deze voordelen gelden op het moment dat je meerdere kanalen bedient. Bij één website blijven ze theoretisch, en betaal je alleen de kosten van de ruil.

Wanneer het wel loont

  • Je content moet naar een app of een systeem buiten je website.
    Een productcatalogus die zowel op de site als in een buitendienst-app moet staan, bijvoorbeeld.

  • Je bouwt een frontend die geen pagina's heeft.
    Een configurator, een rekentool of een portaal waar de inhoud afhangt van wie er inlogt.

  • Je levert content aan partijen buiten je eigen organisatie.
    Partners of leden die jouw informatie op hun eigen site tonen, zonder dat iemand hem overtypt.

Umbraco case studies

In verreweg de meeste trajecten komt de vraag naar headless ter sprake en kiezen we er samen niet voor, omdat het probleem ergens anders bleek te zitten. Bij Landstede ging het om 25 websites in één omgeving, en dat kon gewoon op Umbraco Cloud.

Headless op het platform dat je al hebt

Je hoeft voor headless niet naar een apart systeem. Umbraco levert content ook via een API uit het reguliere CMS, en dat draait gewoon op Umbraco Cloud. Je houdt daarmee één omgeving, één beheercontract en één plek waar redacteuren werken, en je levert content uit naar alles wat erom vraagt.

Dat betekent ook dat je de keuze niet vooraf hoeft te maken. Je begint met een site die gewoon werkt, en als er later een app of een tweede kanaal bijkomt, zit de API er al.

Een losse headless-oplossing zoals Umbraco Heartcore blijft zinvol wanneer je helemaal geen website in het midden hebt staan. Dat is in de praktijk de uitzondering.

Veelgestelde vragen over headless CMS

Twijfel je of headless bij je past?

Dan plannen we een gesprek van een uur. Daarin bepalen we of de koppeling tussen content en presentatie echt je probleem is, of dat het ergens anders zit.

Contact met Webwonders