Deel 18 van 22

SEO-migratie: overstappen naar Next.js zonder verkeer te verliezen

SEO-migratie: overstappen naar Next.js zonder verkeer te verliezen

De meeste verkeersrampen komen niet van een update van Google. Teams veroorzaken ze zelf bij een platformwissel. Een migratie op de gok kan 30–70% van het organische verkeer kosten, en herstel duurt maanden. Volgens het boekje uitgevoerd geeft ze een kleine, korte dip, vaak gevolgd door groei (Next.js wint meestal op rendering en snelheid).

Regel nul: verander één variabele tegelijk

De risicovolste migraties veranderen platform, URL-structuur, ontwerp en content tegelijk. Als het verkeer daalt, kan niemand aanwijzen welke verandering het neerhaalde. Spreid het uit in de tijd: migreer het platform met bevroren URL's en content, bevestig enkele weken stabiliteit en werk daarna ontwerp en content op de nieuwe stack uit.

Ervoor: bouw een inventaris

Wat je niet hebt gemeten, behoud je niet. Verzamel per URL:

  • Een volledige crawl van de oude site (Screaming Frog of een script over de oude sitemap).
  • Toppagina's uit Search Console (12 maanden aan klikken) en topconversiepagina's uit analytics: die krijgen handmatige aandacht.
  • De meest gelinkte pagina's (GSC → Links of Ahrefs): een gemiste redirect op een pagina met 200 verwijzende domeinen verbrandt jaren aan autoriteit.
  • Huidige title, description, canonicals, hreflang, gestructureerde data: de basis voor pariteit.

De redirectmap is de migratie

Veranderen URL's überhaupt, dan krijgt elke oude URL een 308/301 in één stap naar het exacte nieuwe equivalent, niet naar de homepage (massale redirects naar de homepage behandelt Google als soft 404):

// next.config.mjs — eerst patroonregels, een expliciete map voor uitzonderingen
async redirects() {
  return [
    { source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
    ...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
  ];
}

Ketens zijn verboden: had de oude site al redirects, wijs dan ook hun bronnen rechtstreeks naar de uiteindelijke URL's. Alles uit het onderwerp over redirects geldt hier dubbel.

Staging: pariteitscontrole, geen "op het oog"

  • Houd staging buiten de index: HTTP-auth vereist niet dat je vertrouwt op een noindex-instelling die per ongeluk in productie kan belanden.
  • Diff oud tegen nieuw voor de toppagina's met een script: title, description, canonical, hreflang, H1, JSON-LD, responscode. Ook de renderpariteit: curl op de HTML van staging en bevestig dat de content op de server wordt gerenderd.
  • Test de redirectmap vóór de lancering op de volledige inventaris van oude URL's, niet op een steekproef.

Lanceerdag en de weken erna

  • Dien de nieuwe sitemap in bij Search Console; laat redirects van oude URL's onbeperkt staan (jaren, geen weken).
  • Volg de serverlogs op 404's van Googlebot: elke is een gat in de redirectmap; herstel ze in de eerste week dagelijks.
  • Verwacht een piek in crawling en schommelingen in posities gedurende 2–6 weken: Google beoordeelt de site opnieuw; draai niet in paniek terug.
  • Alarmdrempels: een aanhoudende daling van >20% op omzetpagina's na de derde week verdient onderzoek (monitoring opzetten), geen hoop.

Checklist:

  • URL-inventaris met gemarkeerde top-GSC-pagina's en meest gelinkte pagina's
  • Redirectmap in één stap die 100% van de oude URL's dekt, vóór de lancering getest
  • Staging achter autorisatie; pariteit van meta/schema/rendering per toppagina gediffed
  • Platform gemigreerd met bevroren URL's en content; ontwerp later
  • Na de lancering: dagelijkse review van 404's van Googlebot, redirects blijven jaren leven

Laat je dit liever door iemand anders doen?

Ik audit en herstel technische SEO op Next.js-websites — indexering, snelheid, hreflang en zichtbaarheid in AI-zoekmachines.

Dienst technische SEO