Een headless website die snel blijft

Een headless website past wanneer je het ontwerp en de techniek wilt vernieuwen zonder de contentbron telkens te vervangen. We bekijken welke informatie je publiceert, waar je die nog meer gebruikt en wie wijzigingen goedkeurt. Een aparte frontend kan die vrijheid geven, maar vraagt ook afspraken over de verbinding met de bron.

Voor een kleine site die zelden verandert, kan een eenvoudiger oplossing voldoende zijn. We vergelijken daarom de bouw én het beheer: een CMS-licentie, hosting, koppelingen en technische updates blijven afzonderlijke onderdelen. Je krijgt een afgebakend voorstel op basis van wat nodig is. Wil je ontwerp, teksten en bouw als één traject aanpakken, bekijk dan een website laten maken.

Astro leest gestructureerde content en rendert die naar snelle pagina’s. We kunnen de frontend daarom koppelen aan een headless CMS of aan bestanden in Git. Een redactie die visueel wil bewerken kan in Storyblok werken; een technisch team dat al met versiebeheer werkt kan voor lokale content kiezen.

Die structuur maakt ook AI-ondersteuning mogelijk. Via een API of bestanden kunnen agenten inhoud voorbereiden en controleren. We richten de workflow zo in dat een mens wijzigingen beoordeelt voordat ze live gaan. De agent bereidt voor, het team beslist; een leesbare bron is geen toestemming om zelfstandig te publiceren.

Onze eigen site gebruikt getypeerde bestanden in Git en controleert die bij elke build. In onze ervaring zonder CMS lees je hoe dat werkt. Wij bouwen beide routes en kiezen de bron aan de hand van de mensen die ermee gaan werken.

Een headless frontend hoeft niet alle gegevens uit hetzelfde systeem te halen. We brengen in kaart welke inhoud uit het CMS komt en welke functies een andere bron nodig hebben, bijvoorbeeld een formulier of productcatalogus. Voor elke koppeling bepalen we welke gegevens leidend zijn en hoe actueel ze op de website moeten zijn. Bij Verhuurwinkel.nl beheert Storyblok de content en komt de productdata rechtstreeks uit het ERP van de klant, elk via een eigen API.

Inhoud die weinig verandert, bouwen we vooraf op. Voor gegevens die tijdens het bezoek actueel moeten zijn, kiezen we bewust een aanvullende oplossing. We testen ook ontbrekende gegevens en tijdelijke API-storingen, zodat een fout niet ongemerkt doorwerkt. Bij webdevelopment hoort daarom ook vastleggen wie een storing opvolgt en hoe de website zich gedraagt terwijl een bron onbereikbaar is.

Voor een headless website met veel artikelen of diensten kan een zoekfunctie bezoekers helpen sneller de juiste pagina te vinden. We bepalen welke inhoud doorzoekbaar is en welke informatie elk resultaat toont. Denk aan een titel, korte omschrijving en paginatype. Concepten en afgeschermde inhoud houden we buiten de openbare zoekindex.

We stemmen het bijwerken van die index af op de publicatie van de website. Een verwijderde pagina mag niet als bruikbaar resultaat blijven staan; een gewijzigde titel moet ook in de zoekresultaten terugkomen. We testen met woorden die je klanten gebruiken en bekijken wat er gebeurt bij een typefout of zonder resultaten. Voor een kleine verzameling kan zoeken in de browser volstaan. Bij meer inhoud beoordelen we of een aparte zoekdienst nodig is.

We beginnen een headless migratie met een lijst van huidige URL’s, paginatypes, beelden en functies. Samen bepalen we wat meegaat, wat beter kan en wat niet meer nodig is. Daarna bouwen we de Astro-frontend met enkele representatieve pagina’s. Zo kun je de nieuwe opmaak en het beheer beoordelen voordat we alle inhoud overzetten.

We behouden bestaande adressen waar mogelijk en maken redirects voor gewijzigde routes. Ook metadata, interne links en formulieren gaan mee in de controle. Voor de omschakeling spreken we af hoe we recente wijzigingen uit de oude site verwerken en hoe we teruggaan als de uitrol mislukt. Zo is de livegang een geteste overstap, niet alleen een verandering van hosting.

Je team moet weten wanneer een opgeslagen wijziging op de website verschijnt. We testen de route van bron naar preview en liveversie, inclusief meldingen bij een mislukte build. We leggen ook vast wie technische updates uitvoert en hoe we een eerdere versie terugzetten. Een losse frontend maakt die verantwoordelijkheden niet vanzelf overbodig.

Na de lancering volgen we snelheid en zoekverkeer met maandelijkse PageSpeed- en Search Console-metingen. Die maandreeks voor deze site zie je in onze eigen case. We bespreken wat de gegevens wel en niet aantonen; een technische verandering is geen garantie op meer aanvragen. Via websiteonderhoud kunnen we updates en controles opvolgen. Nieuwe pagina’s, talen of koppelingen krijgen een duidelijke afbakening, zodat je de gevolgen voor beheer vooraf kunt beoordelen.