We hebben in de afgelopen drie jaar meer dan 40 sites van WordPress naar headless architecturen gemigreerd. Sommige verliepen perfect. Een paar waren pijnlijke lessen. Het verschil tussen een migratie die elk druppeltje organisch verkeer behoudt en één die je rankings zes maanden lang vernielt, komt neer op voorbereiding, niet op geluk.

Dit is het speelboek dat we werkelijk gebruiken bij Social Animal wanneer een klant zegt "we willen naar headless gaan." Het is niet theoretisch. Elk checklist item, elke omleidingsstrategie, elke monitoringstap komt voort uit echte migraties die we hebben uitgevoerd — meestal WordPress naar Next.js, maar de principes gelden voor elke CMS-naar-CMS verhuizing.

Als je een migratie in 2026 plant, voeg dit toe aan je bladwijzers. Je zult het nodig hebben.

Inhoudsopgave

CMS-migratie zonder SEO-verlies: 2026 Volledige gids

Waarom CMS-migraties rankings vernietigen

Google geeft niet om welk CMS je gebruikt. Het gaat om URL's, inhoud, paginasnelheid, interne links en gestructureerde gegevens. Wanneer je je CMS verandert, riskeer je al deze zaken tegelijk te verbreken.

Dit gaat meestal fout:

  • URL-structuren veranderen — WordPress gebruikt /2024/03/mijn-post/ of /categorie/subcategorie/postnaam/. Jouw nieuwe systeem gebruikt waarschijnlijk /blog/postnaam. Dat zijn honderden of duizenden verbroken URL's.
  • Interne links breken — Elke link van de ene pagina naar de andere binnen je site was gebouwd voor de oude URL-structuur.
  • Metadata verdwijnt — Je Yoast of RankMath SEO-titels, meta-beschrijvingen en OG-tags worden niet magisch naar een headless CMS overgedragen.
  • Gestructureerde gegevens verdwijnen — Schema-markup van plugins bestaat niet in je nieuwe frontend.
  • Paginasnelheid verandert — Soms beter (hallo, Next.js), soms slechter als je niet voorzichtig bent met client-side rendering.

Volgens een onderzoek van Ahrefs uit 2025 ondervindt 34% van de sites die een CMS-migratie ondergaan een verkeersval van 10% of meer die langer dan drie maanden aanhoudt. De sites die dit voorkomen hebben geen geluk — ze zijn voorbereidt.

Pre-migratie audit: Het fundament

Voordat je een enkele regel code op je nieuwe platform schrijft, heb je een volledige momentopname van je huidige SEO-status nodig. Dit is niet optioneel. Sla dit over en je vliegt blind.

Crawl alles

Gebruik Screaming Frog, Sitebulb of Ahrefs Site Audit om een volledige crawl van je bestaande site uit te voeren. Je hebt nodig:

  • Elke URL (inclusief gepagineerde pagina's, tag-pagina's, auteurspagina's)
  • HTTP-statuscodes voor elke URL
  • Alle interne links en hun anker-tekst
  • Meta-titels en beschrijvingen voor elke pagina
  • Canonical tags op elke pagina
  • Hreflang-tags als je meertalige inhoud hebt
  • Gestructureerde gegevens per pagina
  • Afbeelding-URL's en alt-tekst

Exporteer dit naar een spreadsheet. Dit is je migratiebijbel.

Documenteer je toppresteerders

Haal je Google Search Console-gegevens op van de afgelopen 16 maanden. Identificeer:

  • Top 100 pagina's op organische klikken
  • Top 100 pagina's op impressies
  • Pagina's die rangschikken in posities 1-10 voor waardevolle sleutelwoorden
  • Pagina's met de meeste backlinks (gebruik Ahrefs of Semrush)

Dit zijn je VIP-pagina's. Ze worden eerst getest, eerst gemonitord, en als er iets fout gaat, worden ze eerst gerepareerd.

Bepaal je basislijnwaarden

Noteer deze getallen de week vóór de migratie:

Metriek Tool Waarom het belangrijk is
Totaal geïndexeerde pagina's Google Search Console Deïndexering snel opvangen
Organische sessies/week GA4 Primaire succesmaatstaf
Gemiddelde positie GSC Ranking drops detecteren
Core Web Vitals PageSpeed Insights Prestatievergelijking
Totaal verwijzende domeinen Ahrefs/Semrush Zorg dat backlinks nog steeds omgeleid worden
Crawlfouten GSC Basislijn voor vergelijking
Sitemap-pagina's ingediend versus geïndexeerd GSC Indexeringsgezondheid volgen

301 omleidingsstrategie die werkelijk werkt

Dit is waar migraties slagen of falen. Ik heb bureaus gezien die omleidingen als een bijzaak behandelden — iets om "na de lancering uit te zoeken." Zo verlies je 's nachts 40% van je verkeer.

Map elke URL voordat je bouwt

Maak een omleiding map-spreadsheet met deze kolommen:

Oude URL | Nieuwe URL | Statuscode | Prioriteit | Notities

Elke enkele URL van je crawl heeft een bestemming nodig. Ja, ook die tag-pagina's en auteursenarchieven die je bent vergeten.

Het omleidings-beslissingskader

Oud paginatype Aanbevolen actie Omleiding naar
Blogbericht (inhoud behouden) 301-omleiding Nieuwe URL voor dezelfde inhoud
Blogbericht (inhoud verwijderen) 301 naar relevantste pagina Gerelateerd blogbericht of categorie
Categoriepagina 301-omleiding Equivalente nieuwe categorie/tag-pagina
Tag-pagina (lage waarde) 301 naar categorie Bovenliggende categoriepagina
Auteurspagina 301 naar over/team-pagina Team-pagina of homepage
Gepagineerde pagina's (/page/2/) 301 naar hoofdpagina Bovenliggende pagina (pagina 1)
Media/attachmentpagina's 301 naar bovenliggende bericht Bericht met de media
Oude WordPress-pagina's (/wp-admin, /xmlrpc.php) 410 Gone N/A
Feed-URL's (/feed/, /rss/) 301 of opnieuw maken Nieuwe feed-URL indien van toepassing

Implementeer omleidingen op de juiste laag

Voor Next.js-migraties heb je opties waar omleidingen zich bevinden:

// next.config.js - Goed voor bekende, statische omleidingen
module.exports = {
  async redirects() {
    return [
      {
        source: '/2024/03/mijn-oude-post/',
        destination: '/blog/mijn-oude-post',
        permanent: true, // 301
      },
      // Op patroon gebaseerde omleidingen
      {
        source: '/categorie/:slug',
        destination: '/blog/categorie/:slug',
        permanent: true,
      },
    ]
  },
}

Voor grootschalige migraties (500+ omleidingen) gebruiken we typisch middleware of edge-functies:

// middleware.ts - Beter voor grote omleidingskaarten
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import redirectMap from './redirects.json'

export function middleware(request: NextRequest) {
  const path = request.nextUrl.pathname
  const redirect = redirectMap[path]
  
  if (redirect) {
    return NextResponse.redirect(
      new URL(redirect.destination, request.url),
      redirect.permanent ? 301 : 302
    )
  }
}

export const config = {
  matcher: [
    // Match oude WordPress URL-patronen
    '/:year(\\d{4})/:month(\\d{2})/:slug*',
    '/categorie/:path*',
    '/tag/:path*',
    '/author/:path*',
  ],
}

Voor sites met duizenden omleidingen kunt u ze op CDN/edge-niveau verwerken (Vercel Edge Config, Cloudflare Workers of Netlify redirects-bestand) om te voorkomen dat je toepassingscode opzwelt.

Test elke omleidering

Ik meen het. Elke één. We gebruiken een eenvoudig script:

# test-omleidingen.sh
while IFS=, read -r oude_url nieuwe_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$oude_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$oude_url")
  echo "$status | $oude_url -> $final"
done < omleidingen.csv

Voer dit uit tegen je staging-omgeving voordat je live gaat. Voer het dan onmiddellijk na de lancering opnieuw uit in productie.

CMS-migratie zonder SEO-verlies: 2026 Volledige gids - architectuur

Canonical tags: Het verkeerd begrepen veiligheidsnet

Canonical tags zijn geen vervanging voor omleidingen. Maar ze vormen een kritieke verdedigingslaag tijdens migratie.

Zelf-referentiële canonicals op elke pagina

Elke pagina op je nieuwe site moet een zelf-referentiële canonical tag hebben:

<link rel="canonical" href="https://jouwdomein.com/blog/exacte-huidige-url" />

In Next.js met de App Router:

// app/blog/[slug]/page.tsx
import { Metadata } from 'next'

export async function generateMetadata({ params }): Promise<Metadata> {
  const post = await getPost(params.slug)
  return {
    alternates: {
      canonical: `https://jouwdomein.com/blog/${params.slug}`,
    },
  }
}

Veelgemaakte canonical fouten tijdens migratie

  • Inconsistentie van schuine streep — /blog/post en /blog/post/ zijn verschillende URL's voor Google. Kies één, redirect de ander, en zorg ervoor dat je canonical overeenkomt.
  • HTTP versus HTTPS in canonicals — Gebruik altijd HTTPS. Dat klinkt vanzelfsprekend maar ik heb het fout zien gaan.
  • Staging-URL's die in productie terechtkomen — Als je canonical tags naar staging.jouwdomein.com verwijzen, zeg je Google je staging-site te indexeren. We hebben dit meer keer dan ik graag wil in QA onderschept.
  • Ontbrekende canonicals op gepagineerde inhoud — Als je bloglijsten pagineert, moet elke pagina zijn eigen canonical hebben, geen canonical die teruggaat naar pagina 1.

Sitemap-behoud en indiening

Genereer onmiddellijk een nieuwe sitemap

Je nieuwe sitemap moet op dag één klaar zijn. Voor Next.js-projecten genereren we sitemaps dynamisch:

// app/sitemap.ts (Next.js 14+/15)
import { MetadataRoute } from 'next'

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts() // Uit je headless CMS
  
  const blogEntries = posts.map((post) => ({
    url: `https://jouwdomein.com/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt),
    changeFrequency: 'weekly' as const,
    priority: 0.8,
  }))

  const staticPages = [
    {
      url: 'https://jouwdomein.com',
      lastModified: new Date(),
      changeFrequency: 'daily' as const,
      priority: 1,
    },
    // ... andere statische pagina's
  ]

  return [...staticPages, ...blogEntries]
}

Indieningsstrategie

  1. Vóór migratie: Download je oude sitemap en sla deze op
  2. Na migratie: Dien de nieuwe sitemap onmiddellijk in Google Search Console in
  3. Behoud de oude sitemap tijdelijk: Voor de eerste 30 dagen, zorg ervoor dat je oude sitemap-URL's correct omgeleid worden zodat Google de keten kan volgen
  4. Gebruik Googles URL-inspectietool: Vraag handmatig indexering voor je top 50 VIP-pagina's
  5. Monitor het Index Coverage report dagelijks voor de eerste twee weken

Vergeet robots.txt niet

Je nieuwe robots.txt moet:

  • Googlebot toestaan alles wat daarvoor mogelijk was te crawlen
  • Verwijzen naar je nieuwe sitemap-locatie
  • Niet per ongeluk JS/CSS-bestanden blokkeren die Next.js nodig heeft voor rendering
User-agent: *
Allow: /

Sitemap: https://jouwdomein.com/sitemap.xml

Technische migratiechecklist

Dit is de werkelijke checklist die we gebruiken. Print het uit, lamineer het, tatoeeer het op je arm — wat maar werkt.

Pre-lancering (2-4 weken van tevoren)

  • Volledige site crawl van bestaande site geëxporteerd naar spreadsheet
  • Topp-agina's per verkeer en backlinks geïdentificeerd
  • Volledige omleidings-kaart gemaakt en beoordeeld
  • Nieuwe URL-structuur definitief vastgesteld (geen wijzigingen na dit punt)
  • Meta-titels en beschrijvingen gemigreerd naar nieuwe CMS
  • Gestructureerde gegevens (JSON-LD) geïmplementeerd op nieuwe site
  • Open Graph en Twitter Card tags geïmplementeerd
  • Interne links bijgewerkt om nieuwe URL-structuur te gebruiken
  • Alt-tekst van afbeelding gemigreerd
  • Canonical tags geverifieerd op elke template
  • Hreflang-tags geïmplementeerd (indien meertalig)
  • robots.txt beoordeeld
  • Nieuwe sitemap genereert correct
  • 404-pagina gemaakt met nuttige navigatie
  • Core Web Vitals slaagt op staging
  • Analytics- en trackeringscodes geïnstalleerd
  • GSC geverifieerd voor nieuw domein/subdomein (indien gewijzigd)

Lanceringdag

  • DNS-wijzigingen doorgegeven
  • SSL-certificaat actief
  • Alle omleidingen getest en geverifieerd
  • Nieuwe sitemap ingediend bij GSC
  • Handmatig indexeringsverzoek voor top 20 pagina's
  • Smoke test: controleer willekeurig 50 oude URL's op juiste omleidingen
  • Verifieer geen staging-URL's in canonical tags
  • Verifieer geen noindex-tags op productiepagina's
  • Controleer serverresponstijden (moet onder 200ms TTFB zijn)

Na lancering (Eerste 30 dagen)

  • Dagelijkse GSC-monitoring op crawlfouten
  • Wekelijkse vergelijking van organisch verkeer versus baseline
  • Monitor index coverage report op dalingen
  • Controleer op soft 404's in GSC
  • Verifieer backlinks worden correct omgeleid (spot check top 20)
  • Monitor Core Web Vitals in veldgegevens
  • Los alle nieuwe 404's op die in GSC verschijnen

WordPress naar Headless Next.js: Stap voor stap

Dit is ons meestgecommuniceerde migratiepad. Hier is hoe we het aanpakken wanneer we aan headless CMS-ontwikkelingprojecten werken.

Kies je Headless CMS

Je verlaat WordPress-de-monoliet, maar je mag WordPress-de-CMS als headless backend behouden, of je stapt over op iets anders.

CMS Best voor Inpanning voor inhoudmigratie Prijzen (2026)
WordPress (headless via WPGraphQL) Teams die WordPress kennen Minimaal — inhoud blijft op zijn plaats Alleen hostingkosten
Sanity Gestructureerde inhoud, ontwikkelaars teams Gemiddeld — export/import nodig Gratis tier, dan $99+/mnd
Contentful Enterprise, multi-channel Gemiddeld-hoog Gratis tier, dan $300+/mnd
Strapi Zelf-gehoste controle Gemiddeld Gratis (zelf-gehost) of $29+/mnd cloud
Payload CMS Next.js native, TypeScript teams Gemiddeld Gratis (zelf-gehost) of $35+/mnd cloud

Als je WordPress als headless backend gebruikt, vermijd je het inhoudmigratieprobleem volledig. We hebben verschillende sites op deze manier gebouwd met behulp van onze Next.js-ontwikkelingsexpertise — het redactionele team houdt zijn WordPress-admin, en de frontend is een snelle Next.js-app.

Content migratiescript

Als je naar een nieuwe CMS gaat, heb je een migratiescript nodig. Hier is een vereenvoudigde versie van wat we gebruiken om inhoud uit WordPress te halen:

// scripts/migrate-wp-to-sanity.ts
import WPAPI from 'wpapi'
import { createClient } from '@sanity/client'

const wp = new WPAPI({ endpoint: 'https://oude-site.com/wp-json' })
const sanity = createClient({
  projectId: 'jouw-project',
  dataset: 'production',
  token: process.env.SANITY_TOKEN,
  apiVersion: '2026-01-01',
})

async function migratePosts() {
  let page = 1
  let hasMore = true

  while (hasMore) {
    const posts = await wp.posts().page(page).perPage(100)
    
    for (const post of posts) {
      await sanity.create({
        _type: 'post',
        title: post.title.rendered,
        slug: { current: post.slug },
        // Converteer WP HTML naar Portable Text of MDX
        body: convertHtmlToPortableText(post.content.rendered),
        publishedAt: post.date,
        // Behoud de oude URL voor omleidings-mapping
        legacyUrl: new URL(post.link).pathname,
        seo: {
          metaTitle: post.yoast_head_json?.title || post.title.rendered,
          metaDescription: post.yoast_head_json?.description || '',
        },
      })
    }

    hasMore = posts._paging?.totalPages > page
    page++
  }
}

Het sleuteldetail dat de meeste migratiegidsen missen: bewaar de oude URL als een veld in je nieuwe CMS. Dit maakt het genereren van omleidingen triviaal en geeft je een permanent record van waar inhoud vandaan komt.

Gestructureerde gegevens migratie

WordPress-plugins zoals Yoast genereren gestructureerde gegevens automatisch. In Next.js moet je het zelf implementeren:

// components/ArticleSchema.tsx
export function ArticleSchema({ post }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
    },
    publisher: {
      '@type': 'Organization',
      name: 'Jouw bedrijf',
      logo: {
        '@type': 'ImageObject',
        url: 'https://jouwdomein.com/logo.png',
      },
    },
    image: post.featuredImage?.url,
    description: post.excerpt,
  }

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  )
}

Vergeet BreadcrumbList, FAQPage en alle andere schema-types die je WordPress-site genereerde niet. Controleer met Googles Rich Results Test voor en na migratie.

Monitoring na migratie

De eerste 48 uur na migratie zijn kritiek. Dit is wat je moet bekijken:

De eerste 48 uur

  • Bekijk serverlogboeken in real-time op 404's. Elke 404 is een gemiste omleiding.
  • Controleer GSC's URL-inspectietool voor je VIP-pagina's — worden ze opnieuw gecrawld?
  • Monitor je CDN/hosting op onverwachte verkeersspikes of -dalingen.

De eerste 2 weken

Enige rangschikkingsfluctuatie is normaal. Google moet je hele site opnieuw crawlen en verwerken. Wat niet normaal is:

  • Meer dan 15% verkeursval die langer dan 5 dagen aanhoudt
  • VIP-pagina's verliezen meer dan 3 posities
  • Index coverage daalt meer dan 10%

Als je een van deze ziet, controleer eerst je omleidingen. Controleer dan op onopzettelijke noindex-tags. Controleer dan of je inhoud werkelijk gerenderd is (SSR-problemen in Next.js kunnen lege pagina's aan Googlebot serveren).

De eerste 3 maanden

Stel wekelijkse geautomatiseerde rapporten in om te vergelijken:

  • Organisch verkeer week-over-week
  • Gemiddelde positie voor je top 50 sleutelwoorden
  • Aantal geïndexeerde pagina's
  • Core Web Vitals-scores

In onze ervaring zien goed uitgevoerde migraties het verkeer zich herstellen naar basislijn binnen 2-4 weken, en vaak eraan voorbij gaan binnen 8 weken dankzij verbeterde Core Web Vitals van Next.js-prestatieeffecten.

Veelgemaakte fouten die we hebben gezien (en gemaakt)

Wijzig URL-structuur EN inhoud tegelijktijdig. Dat doe je niet. Migreer je inhoud as-is, lanceer, laat Google tot rust komen, optimaliseer inhoud later. Te veel signalen tegelijk veranderen maakt het onmogelijk om problemen op te sporen.

Vergeet niet over afbeeldingen. Als je afbeeldingen werd bediend vanaf jouwdomein.com/wp-content/uploads/ en nu bevinden ze zich op een CDN met verschillende URL's, verbroken elke afbeeldingslink in elke externe site die naar je afbeeldingen wijst. Redirect ook die paden.

Niet consistent omgaan met schuine streepjes. Next.js heeft een trailingSlash-configuratieoptie. Kies true of false en zorg ervoor dat elke omleiding, canonical en sitemap-ingang overeenkomt.

Lancering op een vrijdag. Doe het gewoon niet. Lanceer dinsdag of woensdagmorgen zodat je de hele week hebt om problemen te monitoren en op te lossen.

Google niet op de hoogte stellen van de migratie. Als je van domeinen verandert, gebruik je GSC's Change of Address-tool. Zelfs als je op hetzelfde domein blijft, dien je sitemap opnieuw in en gebruik je het Removals-hulpmiddel om oude URL's die niet geïndexeerd zouden moeten worden op te schonen.

Als je je overweldigd voelt door dit alles, is dat begrijpelijk — het is werkelijk complex werk. Ons team voert deze migraties regelmatig uit en we spreken graag met je over je specifieke situatie.

Veelgestelde vragen

Hoelang duurt het voordat Google 301-omleidingen herkent? Google ontdekt en verwerkt doorgaans 301-omleidingen binnen enkele dagen tot twee weken, afhankelijk van hoe frequent Googlebot je site crawlt. Pagina's met hoge autoriteit en veel backlinks worden doorgaans sneller opnieuw gecrawld. Je kunt dit versnellen door je bijgewerkte sitemap in te dienen en het URL-inspectietool te gebruiken om herbemiddeling van sleutelpagina's aan te vragen.

Verlies ik link equity (link juice) van 301-omleidingen? Google heeft bevestigd dat 301-omleidingen sinds 2016 volledige link equity doorgeven. Er is niet langer sprake van een "PageRank-belasting" voor omleidingen. Omleidingsketens (A → B → C) kunnen de overdracht echter vertragen en crawl budget-problemen veroorzaken. Houd het waar mogelijk op single-hop-omleidingen.

Kan ik in plaats daarvan 302-omleidingen gebruiken tijdens migratie? Nee. Gebruik 301 (permanente) omleidingen voor migratie. Een 302 zegt tegen Google dat het verhuizen tijdelijk is en het moet de oude URL in zijn index houden. Dit tegensprekendireect wat je wilt tijdens een CMS-migratie. De enige uitzondering is als je werkelijk van plan bent terug te keren — maar als je je CMS migreert, ga je niet terug.

Hoeveel 301-omleidingen zijn te veel voor Next.js? Next.js verwerkt omleidingen in next.config.js goed tot ongeveer 1.000 inzendingen. Daarbuiten wil je middleware, edge-functies of omleidingen op CDN-niveau gebruiken. Vercel's Edge Config kan tienduizenden omleidingen aan met sub-milliseconde opzoektijden. Voor zelf-gehoste Next.js kunt u overwegende een Redis-backed omleidings-opzoeking in middleware te gebruiken.

Moet ik WordPress tag en auteurspagina's omleiden? Ja, maar strategisch. Als je tag-pagina's aanzienlijk verkeer of backlinks hadden, redirect ze naar de meest relevante equivalente pagina op je nieuwe site. Als het dunne inhoudspagina's waren zonder verkeer (wat voor de meeste WordPress tag-pagina's geldt), redirect ze naar de bovenliggende categorie of blogindex. Auteurspagina's zouden typisch naar een about- of teampagina omgeleid moeten worden.

Wat gebeurt er met mijn Google Business Profile en andere vermeldingen na migratie? Als je domein hetzelfde blijft, zullen de meeste vermeldingen en je Google Business Profile niet beïnvloed worden. Als echter specifieke URL's werden vermeld (zoals een dienstenpagina), zorg ervoor dat die correct omgeleid worden. Werk URL's in je Google Business Profile, sociale mediaprofielen en grote directorylijsten bij binnen de eerste week na migratie.

Is het beter om naar headless WordPress of een ander headless CMS te migreren? Het hangt af van je team. Als je content editors houden van WordPress en je contentmodel past goed bij WordPress, voorkomen ze het inhoudmigratierisico volledig door WordPress als headless backend met WPGraphQL te gebruiken. Als je WordPress aan grenzen stuit op content modellering of je wilt een moderner bewerkingserlebnis, zijn Sanity, Payload CMS of Contentful sterke alternatieven. We gaan verder in op de opties op onze headless CMS development pagina.

Hoe ga ik met meertalige inhoud om tijdens een CMS-migratie? Meertalige migraties voegen nog een laag complexiteit toe. Je moet hreflang-tags exact behouden zoals ze waren, elke taalversie omleiden naar zijn corresponderende nieuwe URL, en ervoor zorgen dat je nieuwe CMS dezelfde taal/regio-structuur ondersteunt. Als je wisselt van submappen (/es/, /fr/) naar subdomeinen of vice versa, is dat in wezen een domeinverandering voor elke taal en vereist extra zorg met omleidingen en GSC-configuratie.