Ik heb het afgelopen jaar drie bedrijven zien migreren naar headless CMS-platforms. Twee daarvan verloren binnen een paar weken 40%+ van hun organisch verkeer. Niet omdat headless slecht is -- maar omdat ze aannamen dat hun SEO-basis vanzelf mee zou verhuizen. Dat gebeurt niet.
Het eerste bedrijf, een middelgrote B2B SaaS-speler, migreerde van WordPress naar Contentful + Next.js. Hun verkeer bleef stabiel omdat Next.js server-side rendering standaard ondersteunt. Paginatitels, metabeschrijvingen, sitemaps, canonical URL's -- alles zat in het migratieplan. Ze deden het werk vooraf.
Het tweede bedrijf, een e-commerce merk, ging van Shopify naar Strapi + een custom React-frontend. Het verkeer daalde 43% in drie weken. Het probleem: pure client-side rendering. Google crawlde hun pagina's en zag lege HTML-hulzen. Hun productpagina's, categoriepagina's en blog -- allemaal onzichtbaar voor zoekmachines tot de tweede crawlronde, die Google minder prioriteit gaf omdat de eerste crawl niets bruikbaars opleverde.
Het derde bedrijf, een uitgever, migreerde van een custom PHP CMS naar Sanity + Gatsby. Het verkeer daalde 38%. De oorzaak: ze veranderden hun volledige URL-structuur zonder 301 redirects. Vijf jaar aan backlinkwaarde, van de ene op de andere dag weg.
Al deze uitkomsten waren te voorkomen. Hier is de checklist die twee van die migraties had gered.
Een headless CMS scheidt contentbeheer van de presentatielaag. Je beheert content in één systeem en toont die via een aparte frontend -- een website, mobiele app of elk ander kanaal -- via API. De ‘head’ (frontend) staat los van de ‘body’ (content).
De voordelen zijn echt:
De valkuil is denken dat je deze voordelen gratis krijgt. Met WordPress of Shopify worden SEO-basiszaken -- paginatitels, metabeschrijvingen, sitemaps, canonical URL's, server-gerenderde HTML -- door het platform geregeld. Met headless wordt elk van die onderdelen jouw verantwoordelijkheid.
Wanneer je content loskoppelt van presentatie, koppel je SEO ook los van het automatische vangnet dat veel traditionele CMS-platforms bieden.
Risico op verlies van rankings. Google gebruikt consistente signalen om je site te crawlen en te beoordelen. Verstoor je die tijdens een migratie, dan verdwijn je uit beeld. De uitgever die ik noemde verloor rankings voor 340 zoekwoorden in één week omdat hun URL-structuur veranderde zonder redirects.
Impact op verkeer en omzet. Voor het e-commerce merk vertaalde die daling van 43% in verkeer zich naar ongeveer $28,000 aan verloren maandelijkse omzet. Ze waren twee maanden bezig met herstel -- en kwamen voor hun categoriepagina's nooit meer volledig terug op het niveau van vóór de migratie.
Jaren aan SEO-werk behouden. Backlinks, domeinautoriteit, indexatiegeschiedenis -- je hebt maanden of jaren besteed aan het opbouwen van die basis. Een slordige migratie gooit dat allemaal weg.
(Kleine zijnoot: wat mij het meest verbaast, is hoeveel migratieplannen ik heb gezien waarin SEO helemaal niet genoemd wordt. Het engineeringteam is bezig met API-architectuur. Het designteam richt zich op de nieuwe frontend. Niemand denkt aan die 47.000 maandelijkse organische bezoeken die het project überhaupt financieren.)
Dit is veruit het belangrijkste punt. Je URL's zijn adressen waar zowel zoekmachines als gebruikers op vertrouwen. Elke onnodige wijziging veroorzaakt 404-fouten, kapotte backlinks en dalende rankings.
Werk tijdens de migratie samen met je developmentteam om dezelfde URL-structuur op de nieuwe headless front-end aan te houden. Als wijzigingen noodzakelijk zijn (bijvoorbeeld door nieuwe routing in het headless CMS), stel dan voor elke aangepaste URL 301 redirects in. Zonder uitzonderingen.
Canonical tags vertellen zoekmachines welke versie van een pagina de hoofdversie is. Tijdens een migratie, zeker bij architectuurwijzigingen, kan content op meerdere URL's terechtkomen. Zonder canonical tags krijg je duplicate content die met zichzelf concurreert.
In een headless CMS moeten canonical tags vaak handmatig worden toegevoegd of via API worden gegenereerd. Voer vóór de migratie een audit uit van je bestaande site om pagina's te vinden die duplicate-contentproblemen kunnen veroorzaken. Controleer na de migratie met Screaming Frog of Google Search Console of canonical tags op elke pagina correct zijn ingesteld.
Maak vóór de start van de migratie een gedetailleerde redirectmap: oude URL's naar nieuwe URL's, één-op-één. Gebruik een stagingomgeving om redirects te testen voordat je live gaat.
In tegenstelling tot WordPress, dat metadata vaak automatisch genereert, moet je dit in een headless CMS zelf implementeren via API-calls of eigen code in de frontend.
Dit is wat het verkeer van het e-commerce merk onderuit haalde. Als je zwaar leunt op client-side JavaScript, is de kans groot dat zoekmachines je content tijdens de eerste crawl niet zien.
De oplossing: implementeer server-side rendering (SSR) of static site generation (SSG). Next.js en Nuxt.js ondersteunen beide standaard deze aanpak. Vooraf gerenderde content wordt direct aan crawlers geserveerd, terwijl JavaScript de ervaring voor gebruikers verder verrijkt.
Optimaliseer de uitvoering van JavaScript door code op te splitsen in kleinere async chunks. Gebruik Google Lighthouse om te controleren of je Core Web Vitals op orde zijn.
Headless CMS-platforms zijn API-gedreven en regelen het aanmaken van interne links niet altijd automatisch. Daardoor ontstaan problemen sneller dan in een traditioneel CMS, zeker als URL's, slugs of domeinstructuren veranderen tijdens de migratie. Schrijf eigen logica die links dynamisch genereert op basis van je contentstructuur. Voeg daarnaast geautomatiseerde controles toe aan je CI/CD-pipeline om kapotte links vóór deployment te onderscheppen.
(Nog een zijstapje: die uitgever dacht dat hun interne links na de migratie "gewoon zouden werken" omdat de content hetzelfde bleef. Maar de link-URL's in hun CMS waren hardcoded naar de oude domeinstructuur. 2.300 interne links gingen stilletjes stuk. Ze merkten het pas na drie weken.)
Gebruik 301 redirects voor permanente URL-wijzigingen. Gebruik tijdens een migratie nooit 302 redirects -- die geven niet de SEO-waarde door die je wilt behouden. Implementeer redirectregels in je serverconfiguratie (Nginx of Apache) of CDN. Monitor op redirect chains en haal die eruit.
In een headless CMS moet je de sitemap mogelijk handmatig of via API genereren. Richt automatische generatie in die wordt bijgewerkt zodra content wordt aangemaakt of gewijzigd. Dien de sitemap in bij Google Search Console en sluit niet-canonical of dubbele pagina's uit.
Als je meerdere talen of regio's bedient, zijn hreflang-tags essentieel. In een headless setup moeten die vaak handmatig worden toegevoegd. Valideer de implementatie na de migratie met Screaming Frog of Ahrefs.
Deze fout zie ik vaker dan ik zou willen. Een stagingomgeving krijgt een noindex-tag of een geblokkeerde robots.txt, en iemand vergeet dat vóór livegang terug te draaien. Resultaat: de nieuwe site staat live, maar Google mag er nauwelijks in.
Controleer daarom op dag 0:
Het zijn kleine checks, maar ze kunnen het verschil maken tussen een nette migratie en een complete puinhoop.
| Fase | Acties | Tijdlijn |
|---|---|---|
| Vóór de migratie | URL-audit, redirectmap, export van nulmeting (verkeer, rankings, backlinks, CWV) | 2-4 weken vooraf |
| Staging | Bouw nieuwe frontend, implementeer SSR/SSG, configureer metadata, canonical tags, sitemaps. Test redirects | Parallel aan development |
| Livegang | Deploy, dien bijgewerkte sitemap in bij GSC, monitor crawl-fouten in real-time | Dag 1 |
| Na livegang (Week 1-2) | Monitor indexdekking, rankingverschillen, crawl-fouten. Los kapotte redirects en ontbrekende pagina's op | Dagelijkse monitoring |
| Na livegang (Maand 1-3) | Vergelijk verkeer en rankings met de nulmeting. Pak blijvende dalingen aan. Audit interne links | Wekelijkse reviews |
Staging is niet alleen om te kijken of de site "werkt". Het is de plek waar je controleert of zoekmachines dezelfde signalen krijgen als op de oude site -- of betere.
Als iets in staging al rommelig is, wordt het na livegang niet magisch beter. Dat klinkt voor de hand liggend, maar blijkbaar moet het toch gezegd worden.
| Aanpak | Voorbeelden van frameworks | SEO-vriendelijkheid | Beste voor |
|---|---|---|---|
| SSR (Server-Side Rendering) | Next.js, Nuxt.js | Uitstekend -- volledig gerenderde HTML bij het eerste verzoek | Dynamische content, gepersonaliseerde pagina's, e-commerce |
| SSG (Static Site Generation) | Gatsby, Astro, Next.js (static export) | Uitstekend -- vooraf gebouwde HTML-bestanden | Blogs, marketingsites, documentatie |
| CSR (Client-Side Rendering) | React SPA, Vue SPA | Zwak zonder pre-rendering of hydration | App-achtige interfaces waar SEO ondergeschikt is |
Als SEO belangrijk is voor je bedrijf -- en als je dit leest, is dat zo -- kies dan voor SSR of SSG. CSR is voor dashboards en interne tools, niet voor pagina's die je betrouwbaar door Google wilt laten indexeren.
Veel teams halen opgelucht adem zodra de site live staat. Begrijpelijk, maar dat is pas het begin. De eerste 14 dagen na een migratie vertellen je meestal heel snel of je setup gezond is.
Een kleine schommeling is normaal. Een brede daling op template-niveau is dat niet. Dan is er meestal iets structureels mis: rendering, redirects, canonical tags of interne links.
Migraties zijn stressvol, maar ook een kans. Het B2B SaaS-bedrijf dat het goed aanpakte eindigde met snellere pagina's, betere Core Web Vitals en uiteindelijk hogere rankings dan daarvoor. De sleutel was dat ze SEO behandelden als een volwaardige migratie-eis, niet als iets voor achteraf.
Plan vooruit. Breng elke URL in kaart. Test redirects in staging. Monitor dagelijks in de eerste twee weken. En in hemelsnaam, verander je URL-structuren niet zonder 301 redirects.
Niet als je goed plant. Behoud je URL-structuur, stel 301 redirects in, implementeer SSR of SSG, en controleer metadata, sitemaps en canonical tags. SEO-verlies ontstaat meestal wanneer deze stappen worden overgeslagen.
Het CMS is minder belangrijk dan het frontendframework. Contentful, Sanity, Strapi en Prismic zijn allemaal prima -- wat telt is of je frontend SSR/SSG gebruikt (Next.js, Nuxt.js, Gatsby) of pure CSR.
Als het goed gebeurt, zou het verkeersverlies minimaal moeten zijn. Herstel na een mislukte migratie duurt meestal 2-6 maanden, afhankelijk van hoe ernstig de kapotte redirects en indexatieproblemen zijn.
SSR of SSG wordt sterk aangeraden. Google kan CSR-pagina's indexeren, maar het is trager en minder betrouwbaar. Voor pagina's waar organisch verkeer belangrijk is, wil je de HTML vooraf renderen.
URL's veranderen zonder 301 redirects in te stellen. Alleen dat al verklaart het grootste deel van de verkeersverliezen die ik heb gezien.
Gerelateerde artikelen:
no credit card required
No related articles found.
