Headless CMS-migratie: wanneer overstappen en hoe je het zonder chaos doet

Je site is traag, elke kleine wijziging moet via een bureau, en je hebt inmiddels een webshop, een app en een nieuwsbrief die allemaal hun eigen versie van dezelfde teksten bijhouden. Op een gegeven moment valt het woord: misschien moeten we naar headless. En dan begint de twijfel. Is een headless CMS-migratie de oplossing, of jagen we onszelf een dure verbouwing in voor een probleem dat we ook anders hadden kunnen oplossen?

Allebei komt voor. Daarom hieronder geen verkooppraatje, maar de afweging zoals we die zelf maken voordat we iemand aan een migratie laten beginnen.

Wat headless eigenlijk betekent (en wat het niet is)

Een traditioneel CMS — denk WordPress in zijn standaardvorm — doet twee dingen tegelijk: het beheert je content én het bepaalt hoe die content eruitziet op je website. De inhoud en de presentatie zitten aan elkaar vastgeplakt.

Bij een headless CMS haal je die twee uit elkaar. Het CMS wordt een plek waar je content opslaat en beheert, en levert die via een API aan wat je er maar aan wilt hangen: een website, een app, een schermweergave in de winkel, een kassasysteem. De "kop" (de presentatielaag) is losgekoppeld van het "lijf" (de content). Vandaar headless.

Wat het niet is: een toverstaf voor snelheid. Een slecht gebouwde headless-frontend kan net zo traag zijn als een volgepropte WordPress-site. Het voordeel ontstaat pas als je de frontend bewust optimaliseert — en dat had je bij je oude stack soms ook gewoon kunnen doen.

Wanneer een migratie naar headless echt zinvol is

Een migratie naar headless verdient zichzelf terug in een aantal herkenbare situaties:

• Je publiceert dezelfde content op meerdere kanalen. Website, app, productschermen, een partnerportaal. Nu onderhoud je alles los en loopt het uit elkaar. Eén bron, meerdere uitvoeringen, is precies waar headless voor gebouwd is.
• Performance is een aantoonbaar probleem. Niet "het voelt traag", maar meetbaar: slechte Core Web Vitals, een laadtijd die je in Search Console terugziet, bezoekers die afhaken. Een losse, lichte frontend kan hier serieus winst opleveren.
• Je hebt veel koppelingen nodig. Voorraad uit je ERP, prijzen uit een ander systeem, klantdata uit je CRM. Een headless-opzet maakt het makkelijker om die data gestructureerd binnen te halen zonder een plugin-kerstboom.
• Je redactie en je ontwikkeling lopen elkaar in de weg. Marketing wil dagelijks publiceren, development wil rust om te bouwen. Door content en code te scheiden krijgt iedereen zijn eigen tempo.

Wanneer je het juist níet moet doen

Eerlijk is eerlijk: in een flink deel van de gevallen is een CMS-migratie naar headless overkill. Sla het over als:

• Je hebt één website en geen plannen voor meer kanalen. Dan betaal je voor flexibiliteit die je nooit gebruikt. Een goed ingerichte traditionele stack doet het prima.
• Je echte probleem is snelheid op één site. Begin dan met caching, beeldoptimalisatie en het opruimen van plugins. Dat is een paar dagen werk in plaats van een paar maanden.
• Je redactie is niet technisch. Headless betekent vaak een abstracter beheerscherm. Zonder een goed ingerichte editor-omgeving maak je het je eigen mensen moeilijker, niet makkelijker.
• Je doet het omdat het modern klinkt. "Headless" op een slide overtuigt niemand die de rekening betaalt. De vraag is wat het je in uren en grip oplevert.

De nuchtere check: schrijf op welk concreet probleem je oplost en wat het je kost als je niets doet. Als dat lijstje dun is, is een migratie het verkeerde antwoord.

Hoe je het gefaseerd aanpakt — zonder chaos

De grootste fout bij een migratie is de big bang: op een vrijdagavond de oude site eraf, de nieuwe erop, en maandag hopen dat het goed komt. Dat gaat zelden goed. Doe het in stappen.

• Begin met een content-inventarisatie. Wat heb je, wat is verouderd, wat kan weg. Een migratie is hét moment om niet je hele rommelzolder mee te verhuizen.
• Modelleer je content vóórdat je bouwt. Bepaal welke contenttypes je hebt en welke velden daarbij horen. Dit datamodel is het fundament — fouten hier kosten later het meeste.
• Migreer een deel als proef. Eén sectie of één contenttype eerst, naast de bestaande site. Zo leer je de valkuilen op kleine schaal in plaats van op je hele hebben en houden.
• Plan een meetpunt vóór de overstap. Leg je huidige laadtijden, rankings en verkeer vast. Anders weet je achteraf niet of de migratie iets heeft opgeleverd of juist verpest.

SEO behouden: de redirects en URL-structuur

Dit is waar de meeste migraties stilletjes mislukken. De site werkt, maar drie maanden later is het organisch verkeer gehalveerd omdat niemand de URL's heeft afgedekt. Voorkom dat zo:

• Houd je URL-structuur waar mogelijk identiek. Elke wijziging is een risico. Verander URL's alleen als daar een echte reden voor is, niet omdat het nieuwe systeem het net iets anders wil.
• Zet 301-redirects klaar voor élke URL die wél verandert. Maak een complete lijst van oud naar nieuw, inclusief oude landingspagina's en blogartikelen. Een permanente 301 geeft je opgebouwde positie door aan de nieuwe pagina.
• Controleer metadata, headings en gestructureerde data. Titles, meta-descriptions, canonicals en schema horen één-op-één mee te verhuizen. In een headless-opzet zit dit in je datamodel, dus regel het daar.
• Lever een nieuwe sitemap aan en hou Search Console in de gaten. Na livegang wil je crawl-fouten en wegvallende pagina's binnen dagen zien, niet pas als het verkeer al weg is.

Doe de overstap bij voorkeur in een rustige periode en lever de oude site niet meteen uit handen. Een week overlap kost bijna niets en bespaart je een hoop stress als er iets blijkt te missen.

Twijfel je of headless voor jou de juiste stap is, of wil je een migratie die je rankings heel laat? We rekenen liever eerst met je door wat het oplevert voordat er een regel code wordt geschreven. Kijk op maatwerk software laten ontwikkelen of plan direct een vrijblijvend gesprek in. Bekijk anders eerst onze cases om te zien hoe we zulke trajecten aanpakken.

De genoemde doorlooptijden en kostenindicaties zijn illustratief en verschillen per situatie.