Ik heb het afgelopen jaar drie bedrijven zien migreren naar headless CMS-platforms. Twee daarvan verloren binnen een paar weken meer dan 40% van hun organische verkeer. Niet omdat headless slecht is -- maar omdat ze aannamen dat hun SEO-standaarden vanzelf mee zouden verhuizen. Dat doen ze 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 van zichzelf ondersteunt. Meta tags, sitemaps, canonical URL's -- alles was meegenomen in het migratieplan. Ze deden het werk vooraf.
Het tweede bedrijf, een e-commerce merk, ging van Shopify naar Strapi + een React-frontend op maat. Het verkeer daalde 43% in drie weken. Het probleem: pure client-side rendering. Google crawlde hun pagina's en zag lege HTML-omhulsels. 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 kunnen redden.
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 er gratis bij krijgt. Met WordPress of Shopify worden SEO-basiszaken -- meta tags, 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.
Risico op verlies van rankings. Google gebruikt consistente signalen om je site te crawlen en te ranken. 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 de bestaande URL-structuur op de nieuwe headless frontend te spiegelen. 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 primaire versie 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 meta tags automatisch genereert, moet je dit in een headless CMS zelf implementeren via API-calls of eigen frontendcode.
Dit is wat het verkeer van het e-commerce merk om zeep hielp. 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 allebei beide standaard. Vooraf gerenderde content wordt direct aan crawlers geserveerd, terwijl JavaScript de ervaring voor gebruikers verder verbetert.
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 maken interne links niet altijd automatisch aan. Schrijf eigen code 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 geen SEO-waarde door. 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.
| 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 meta tags, canonicals, 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 |
| 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.
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 canonicals. Verlies ontstaat wanneer deze stappen worden overgeslagen.
Het CMS is minder belangrijk dan het framework van je frontend. 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.
