Website migratie checklist voor SEO, data en aanvragen

Een website migratie is het gecontroleerd verplaatsen of vervangen van een website zonder belangrijke URL's, content, meetdata en commerciële routes onnodig te verliezen. Breng vóór de livegang in kaart wat verandert, koppel iedere waardevolle oude URL aan een relevante nieuwe bestemming en test ook formulieren, CRM-verwerking, analytics, toestemming en opvolging.

Redirects vangen veranderde URL's op. De rest van de migratie moet voorkomen dat aanvragen hun eigenaar verliezen, campagnebronnen verdwijnen of het nieuwe CMS essentiële metadata overschrijft.

Deze checklist behandelt daarom vier lagen samen:

• vindbaarheid: URL's, content, metadata, canonicals, interne links en sitemap;
• werking: formulieren, integraties, foutstaten en redirects;
• meting: analytics, campagneparameters, conversies en CRM-context;
• eigenaarschap: besluitvorming, toegang, terugvalplan, monitoring en herstel.

Wat valt onder een website migratie?

De impact hangt af van de veranderingen die tegelijk plaatsvinden:

• CMS- of platformmigratie. De website verhuist naar een ander CMS of een nieuwe technische architectuur. URL's kunnen gelijk blijven, terwijl templates, metadata, formulieren, gestructureerde gegevens, tracking en redactionele werkafspraken veranderen.
• Domeinmigratie. De website verhuist naar een ander domein of subdomein. Alle publieke URL's veranderen en zoekmachines moeten de relatie tussen oud en nieuw verwerken.
• Structuur- of URL-migratie. Navigatie, mappen, talen of slugs worden opnieuw ingericht. Iedere veranderde URL vraagt om een relevante bestemming en controleerbare redirect.
• Redesign met inhoudelijke opschoning. Pagina's worden samengevoegd, verwijderd of herschreven. Bestaande zoekresultaten, links en commerciële routes moeten naar de juiste nieuwe inhoud worden geleid.
• Hosting- of infrastructuurmigratie. Domein en URL's blijven mogelijk gelijk, maar DNS, certificaten, caching, headers, laadtijden, logging en beschikbaarheid veranderen. De SEO-impact kan klein zijn terwijl het operationele risico groot blijft.

Verander bij voorkeur één grote laag tegelijk. Google adviseert bij een verhuizing met URL-wijzigingen om domein, CMS en ontwerp niet zonder noodzaak tegelijk te veranderen. Zo blijven fouten en herstel beter te isoleren. Zie Google Search Central over site moves.

Website migratie in twaalf stappen

1. 01

   Benoem scope, eigenaar en stopcriteria

   Schrijf op wat verandert en wat aantoonbaar stabiel moet blijven. Benoem één beslisser voor de livegang en eigenaren voor SEO, content, techniek, formulieren, CRM en analytics. Leg vast wie kan besluiten om terug te vallen op de vorige situatie.

   Maak stopcriteria concreet. Bijvoorbeeld:

   • kritieke URL's geven geen onverwachte 404;
   • redirects eindigen op de bedoelde pagina zonder keten;
   • formulieren leveren een bevestiging én correct CRM-record op;
   • een eigenaar ontvangt de aanvraag met bron en onderwerp;
   • analytics registreert de afgesproken testgebeurtenissen;
   • domein, DNS, certificaat en productiecredentials zijn beschikbaar;
   • monitoring en escalatie zijn actief.

   Koppel het go/no-go-besluit aan deze criteria en wijs vooraf aan wie bij een defecte kritieke route uitstel of terugval beslist.

2. 02

   Maak een nulmeting

   Leg vóór wijzigingen vast wat de huidige omgeving doet. Gebruik meerdere bronnen, omdat geen enkele bron compleet is.

   • Crawl de bestaande site en exporteer indexeerbare URL's, statuscodes, titels, beschrijvingen, canonicals, koppen en interne links.
   • Exporteer XML-sitemaps en CMS-URL's.
   • Verzamel relevante landingspagina's en zoekopdrachten uit Search Console.
   • Noteer pagina's met verkeer, backlinks, campagnes of zakelijke waarde.
   • Leg de huidige formulieren, CTA's, conversies en CRM-velden vast.
   • Bewaar voorbeelden van bevestigingen, notificaties en foutmeldingen.
   • Noteer DNS, redirects, robotsregels, analyticsconfiguratie en externe scripts.

   Search Console toont niet iedere geanonimiseerde zoekopdracht en providerdata blijft een schatting. Noteer daarom per bron welke informatie ontbreekt of begrensd is.

3. 03

   Maak één bronlijst van oude URL's

   Combineer crawl, sitemap, CMS, Search Console, analytics, backlinkdata en serverlogs waar beschikbaar. Verwijder duplicaten pas nadat herkomst en parameters zijn begrepen.

   Classificeer iedere URL:

   • behouden op dezelfde URL;
   • verhuizen naar een nieuwe equivalente URL;
   • samenvoegen met een betere eigenaar;
   • verwijderen zonder equivalent;
   • tijdelijk buiten scope, met expliciet besluit.

   Vergeet bestanden, afbeeldingen, campagnepagina's, taalvarianten en oude URL-patronen niet. Een CMS-export alleen mist vaak historische of handmatig ingestelde routes.

4. 04

   Maak de oud-naar-nieuw redirectmap

   Koppel iedere veranderde waardevolle URL aan de inhoudelijk meest relevante nieuwe bestemming. Stuur verwijderde pagina's niet allemaal naar de homepage. Dat helpt de gebruiker niet en maakt de inhoudelijke relatie onduidelijk.

   Gebruik voor permanente verhuizingen waar mogelijk server-side 301- of 308-redirects. Google noemt deze permanente redirects de voorkeursmethode. Controleer de Google-richtlijnen voor redirects.

   Controleer per URL-koppeling:

   • oude URL;
   • verwachte nieuwe URL;
   • reden voor behoud, samenvoeging of verwijdering;
   • huidige statuscode;
   • uiteindelijke statuscode;
   • geen lus of onnodige keten;
   • queryparameters die wel of niet behouden moeten blijven;
   • taal- en canonicalrelatie.

   Houd permanente redirects lang genoeg actief. Google adviseert voor site moves doorgaans minstens een jaar, zodat signalen kunnen worden overgedragen en gebruikers oude links blijven bereiken.

5. 05

   Migreer content, metadata en gestructureerde gegevens bewust

   Controleer naast de tekst ook wat het template rendert. Een nieuw template kan titelvelden, canonicals, koppen, alt-tekst of gestructureerde gegevens anders behandelen.

   Vergelijk voor iedere belangrijke pagina:

   • paginatitel en meta description;
   • één duidelijke H1;
   • hoofdcontent, tabellen, lijsten en links;
   • afbeeldingen en betekenisvolle alt-tekst;
   • canonical URL;
   • robotsinstelling;
   • hreflang of taalrelaties;
   • relevante gestructureerde gegevens;
   • publicatie- en wijzigingsdatum bij artikelen;
   • auteur en bronverwijzingen waar relevant.

   Beoordeel verouderde content op de vraag die de URL aantrok. Bij een samenvoeging moet de nieuwe eigenaar die relevante vraag werkelijk beantwoorden.

6. 06

   Bouw interne links en navigatie opnieuw op

   Werk interne links direct bij naar de definitieve nieuwe URL. Bewaar redirects voor inkomende oude links. Controleer header, footer, breadcrumbs, gerelateerde content, CTA's, sitemap en links in rijke tekstvelden.

   Geef belangrijke commerciële en inhoudelijke eigenaren genoeg interne context. Een nieuwe pagina zonder inkomende route kan technisch indexeerbaar zijn en toch moeilijk gevonden worden door bezoekers en crawlers.

   Test ook ankerlinks, filters, paginatie en taalwissels. Een wijziging in componentstructuur kan anchors breken terwijl de pagina zelf een status 200 houdt.

7. 07

   Inventariseer formulieren en CRM-overdrachten

   Leg per bedrijfskritiek formulier vast wat verhuist en welk testbewijs nodig is. Gebruik de migratiematrix na het stappenplan.

   Controleer dubbele contacten, ontbrekende bedrijfsgegevens, spamfiltering en een tijdelijk onbereikbaar CRM. Een succesvolle bedankpagina bewijst niet dat de aanvraag intern is aangekomen.

   Lees de gids over CRM-integratie voor brondata, leidende systemen en foutafhandeling.

8. 08

   Herstel analytics, campagnes en conversiedefinities

   Inventariseer welke tags, gebeurtenissen, consentregels en conversies in de oude site bestaan. Bepaal welke nog nodig zijn en migreer niet automatisch iedere historische tag.

   Test minimaal:

   • paginaweergaven op de juiste productiehostname;
   • CTA- en formuliergebeurtenissen zonder dubbele telling;
   • toestemming voordat niet-noodzakelijke tracking start;
   • behoud van relevante campagneparameters;
   • broncontext van website naar CRM;
   • uitsluiting van voorvertonings-, staging- en intern verkeer volgens het meetontwerp;
   • dashboards en rapportages die gewijzigde URL's of eventnamen gebruiken.

   Leg oude en nieuwe definities naast elkaar. Een nieuwe gebeurtenis met dezelfde naam kan inhoudelijk iets anders meten. Markeer de migratiedatum in rapportages, zodat een meetbreuk niet voor marktverandering wordt aangezien.

9. 09

   Test staging zonder productie te blokkeren

   Een stagingomgeving hoort niet indexeerbaar te zijn. De blokkade mag niet onbedoeld meegaan naar productie. Controleer daarom zowel vóór als na de omschakeling robotsregels, noindex, authenticatie en canonicalhost.

   Crawl de stagingomgeving met de definitieve URL- en templateconfiguratie. Test:

   • statuscodes en redirectregels;
   • canonicals, hreflang en gestructureerde gegevens;
   • interne links en assets;
   • formulieren, integraties en e-mail;
   • rollen en toegangsrechten;
   • toetsenbordbediening, labels en foutfeedback;
   • mobiel en relevante browsers;
   • laadtijden en caching;
   • beveiligingsheaders en certificaatketen;
   • eigen 404- en serverfoutpagina's.

   Gebruik representatieve accounts en testdata. Verwijder of anonimiseer persoonsgegevens volgens de afgesproken werkwijze.

10. 10

    Maak een uitvoerbaar livegang- en terugvalplan

    Beschrijf de volgorde en de verantwoordelijke per handeling:

    1. contentfreeze en laatste datasynchronisatie;
    2. backup of herstelpunt;
    3. productieconfiguratie en toegangsgegevens;
    4. release of platformomschakeling;
    5. DNS- of domeinwijziging indien nodig;
    6. redirects activeren;
    7. robots, canonicals en sitemap controleren;
    8. kritieke pagina's en formulieren testen;
    9. monitoring en meldingen bevestigen;
    10. go/no-go- of terugvalbesluit.

    Een uitvoerbaar terugvalplan beschrijft ook data, formulieren, DNS en externe integraties die intussen kunnen zijn veranderd. Leg vast welke onderdelen terug kunnen, binnen welk tijdvenster en welke gegevens handmatig moeten worden hersteld.

11. 11

    Controleer direct na livegang

    Voer na de omschakeling een beperkte kritieke check uit voordat bredere controles volgen:

    • homepage en belangrijkste landingspagina's laden op de canonicalhost;
    • HTTPS en certificaat werken;
    • robots blokkeren productie niet;
    • oude kritieke URL's redirecten direct naar de juiste nieuwe URL;
    • nieuwe pagina's geven de verwachte status en canonical;
    • sitemap bevat volledige canonical URL's;
    • formulieren bereiken CRM, eigenaar en bevestiging;
    • analytics en foutmonitoring ontvangen gegevens;
    • 404's, 5xx-fouten en mislukte integraties zijn zichtbaar.

    Dien de nieuwe sitemap in via Search Console. Een sitemap is een hint voor ontdekking en geen garantie dat URL's worden gecrawld of geïndexeerd. Zie Google over het bouwen en indienen van een sitemap.

    Gebruik bij een domeinverhuizing ook de relevante verhuisfuncties en verifieer zowel de oude als de nieuwe site volgens de actuele Google-documentatie.

12. 12

    Monitor zoekgedrag én de commerciële route

    Volg in de eerste dagen technische fouten en kritieke aanvragen intensief. Beoordeel daarna over langere vensters:

    • crawl- en indexeringssignalen;
    • oude URL's die nog verkeer of 404's krijgen;
    • redirectketens en soft 404's;
    • impressies, dekking van zoekopdrachten, positie en klikken;
    • organische landingspagina's;
    • formulierstarts, successen en fouten;
    • CRM-records zonder bron, onderwerp of eigenaar;
    • tijd tot opvolging en geaccepteerde aanvragen;
    • ontbrekende gebeurtenissen of trendbreuken in rapportages.

    Zoekzichtbaarheid kan tijdelijk schommelen terwijl zoekmachines de verhuizing verwerken. Een garantie op nul SEO-verlies is daarom niet geloofwaardig. Zorg dat vermijdbare fouten en afwijkingen snel zichtbaar worden.

Werkblad: redirectmap en formuliermigratie

Kopieer deze tabellen naar je projectdocument of spreadsheet. De URL-rijen zijn fictieve voorbeelden; vervang ze door de eigen inventaris en noteer per rij de werkelijke controle.

Go/no-go-werkblad voor de livegang

Wijs voor iedere controle een eigenaar aan en vul de uitkomst en het bewijs in. Beslis vooraf welke ontbrekende controles de livegang blokkeren.