Headless CMS laten implementeren

We ontwerpen het contentmodel aan de hand van bestaande en geplande pagina’s. Een dienst, case of auteur krijgt eigen velden en duidelijke relaties. Zo kun je bijvoorbeeld één auteursprofiel op meerdere artikelen gebruiken zonder de naam en foto overal apart te onderhouden. We beperken vrije opmaakkeuzes tot wat je team werkelijk nodig heeft.

Voor de volledige inrichting testen we het model met lastige voorbeelden: lange titels, ontbrekende beelden of een pagina met meerdere diensten. Verplichte velden en herkenbare namen helpen redacteurs fouten vóór publicatie opmerken. Het doel van een headless CMS-implementatie is een werkbare structuur, niet een dashboard met alle denkbare opties. Je team beoordeelt daarom mee welke velden bruikbaar zijn.

Redacteurs moeten begrijpen waar hun tekst verschijnt en wat een wijziging beïnvloedt. We richten de editor daarom in met duidelijke veldnamen, uitleg waar nodig en een preview van de website. We spreken af wie concepten maakt, wie controleert en wie mag publiceren. Die rollen volgen je werkproces, niet een willekeurige standaardinstelling.

Tijdens de overdracht oefent je team met echte taken, zoals een case toevoegen of een vertaling controleren. We bekijken ook wat er gebeurt als gedeelde inhoud verandert op meerdere pagina’s. Wil je visueel bewerken, dan kan Storyblok een passende optie zijn. Bij CLW Antwerpen beheert het schoolteam elke opleiding zelf in Storyblok, zonder developer. We beoordelen de editor op dagelijkse handelingen en laten zien welke veranderingen nog hulp van een developer vragen.

Bij een meertalig headless CMS bepalen we welke velden een vertaling krijgen en welke gegevens gedeeld blijven. Een productcode hoeft meestal niet per taal opnieuw ingevuld te worden; een paginatitel, beschrijving of beeldbijschrift wel. We koppelen taalversies aan dezelfde inhoud, zodat redacteurs zien welke vertaling bij welke pagina hoort. In Storyblok kan dat per veld, per map of met een aparte werkruimte per taalteam. De Storyblok-documentatie over internationalisatie legt die drie routes uit.

We spreken af wat er gebeurt als een vertaling ontbreekt of achterloopt op de brontekst. Een andere taal tonen is een bewuste keuze, geen stille standaardinstelling. Per taal controleren we de publicatiestatus en laten we zien welke inhoud nog een controle nodig heeft. Ook testen we langere teksten in de preview en geven we taalrelaties door aan de frontend. Zo kan de taalwissel naar de juiste tegenhanger leiden in plaats van steeds naar de homepage.

We koppelen het CMS aan de frontend met duidelijke afspraken over welke gegevens de website nodig heeft. De publieke site krijgt alleen goedgekeurde content; concepten horen in een afgeschermde preview. We beperken toegangsrechten tot de benodigde taken en houden geheime sleutels buiten de browser. Zo blijft contentbeheer gescheiden van de openbare website. Bij Verhuurwinkel.nl komen Storyblok-content en productdata uit het ERP van de klant via aparte API’s in dezelfde Astro-frontend.

We testen wat publiceren concreet doet: welke pagina opnieuw wordt opgebouwd, wanneer een wijziging zichtbaar is en wat er gebeurt als gegevens ontbreken. Bij een fout in de bron krijg je een duidelijke melding, geen onvolledige pagina die ongemerkt live gaat. Heb je ook een nieuwe headless website nodig, dan nemen we de frontend en publicatieketen samen mee in het traject.

Bij een headless CMS-migratie brengen we bestaande teksten, media, relaties en URL’s eerst in kaart. We vertalen die naar het nieuwe model en doen een proefimport met representatieve pagina’s. Je team controleert de inhoud in de editor, terwijl wij nagaan of beelden, links en metadata op de frontend goed terechtkomen. Pas daarna zetten we de overige content over.

We leggen vast hoe we wijzigingen tijdens de overstap meenemen en wanneer de oude editor stopt. Na livegang stellen we het model bij als redacteurs telkens dezelfde omweg nodig hebben. Zulke aanpassingen testen we op bestaande content én de website. Ook een beheerd CMS neemt het onderhoud van je frontend en koppelingen niet automatisch over.

Headless past wanneer je veel maatwerk nodig hebt, content op meerdere plekken gebruikt of je frontend los wil kunnen vernieuwen. Voor een eenvoudige site met weinig wijzigingen kan een klassiek CMS of websitebuilder sneller en goedkoper zijn. We wegen de extra technische onderdelen af tegen het werk dat je team ermee bespaart.

De belangrijkste vragen gaan over wie publiceert, welke content terugkomt, welke talen en relaties nodig zijn en wie de techniek onderhoudt. Pas daarna kiezen we een platform. Neem enkele terugkerende redactietaken mee; die maken de afweging concreet. Vergelijk beide opties in headless CMS versus klassiek CMS.