SEO-checklist voor sitemigratie

Een sitemigratie is een gecontroleerde wijziging van het platform, domein, protocol, de informatiearchitectuur, URL-structuur of het rendersysteem van een site. De migratie is pas voltooid wanneer gebruikers, crawlers en analytics de beoogde content via stabiele routes kunnen bereiken en het team kan bewijzen dat waardevolle zichtbaarheid behouden is gebleven.

Checklist: SEO voor sitemigratie. Tijdsbox: begin 6–12 weken vóór de lancering voor een middelgrote site; reserveer de laatste 5 werkdagen voor een wijzigingsbevriezing, de lanceringsdag voor bemande validatie en minimaal 4 weken voor actieve monitoring. Eigenaar: één migratieverantwoordelijke die aansprakelijk is voor de gehele release, ondersteund door benoemde eigenaren voor engineering, SEO, analytics, content en infrastructuur.

Waarom deze checklist bestaat en waarom hij hier wordt uitgevoerd

Deze releasecontrolelaag in het SEO-proces gebruikt crawl- en indexbewijs uit de technische basislijnaudit , bewaar/samenvoeg/verwijder-beslissingen uit de contentinventaris en -audit en de bestemmingshiërarchie uit de topische kaart en informatiearchitectuur . Deze uitkomsten moeten bestaan voordat redirects of staging beoordeeld kunnen worden.

Voer de checklist uit nadat de bestemmingsstructuur is goedgekeurd, maar vóórdat productieroutes worden bevroren. Als het eerder wordt uitgevoerd, wijst het team redirects toe aan bestemmingen die nog kunnen wijzigen. Als het later wordt uitgevoerd, zijn routering, sjablonen, analytics of lanceringscommunicatie mogelijk al te kostbaar om veilig te corrigeren.

De redirectmap is het artefact met het hoogste risico, omdat het oude routes aan nieuwe koppelt. Elke waardevolle oude URL moet één-op-één gaan naar de dichtstbijzijnde bestemming die het doel ervan behoudt. Gebruik nooit de homepage als verzamelbak: dit frustreert bezoekers en verbergt ontbrekende bestemmingen.

Inputs en outputs

Outputs zijn het contract met de lanceringsoperaties. Een spreadsheet zonder eigenaren, bewijs of acceptatievoorwaarden is geen overdracht.

De checklist

Elk item vermeldt wat, waarom, hoe, tool en een waarneembare gereed-voorwaarde. Vervang een drempel alleen door een strengere regel of een gedocumenteerde, op de basislijn gebaseerde regel.

Fase 1: pre-migratie inventarisatie

1. Stel de geünificeerde URL-inventaris samen. Wat: combineer elke vindbare oude URL uit crawls, XML-sitemaps, analytics, Search Console, backlinkexports, CMS-records, betaalde campagnes en serverlogs. Waarom: geen enkele bron bevat elke waardevolle of aangevraagde URL; een pagina die afwezig is in navigatie kan nog steeds links, verkeer of contractueel belang hebben. Hoe: normaliseer protocol, host, hoofdlettergebruik, trailing slash, parameters en gecodeerde karakters terwijl de ruwe bronwaarde behouden blijft. Dedupliceer pas nadat is vastgelegd waar elke URL is gevonden. Tool: crawler, CMS-export, analytics, Search Console, backlinkgegevens en logs. Gereed wanneer: elke bron is gedateerd, elke rij heeft een genormaliseerde URL en ontdekkingsbron, duplicaten zijn opgelost en brontotalen komen overeen met de uiteindelijke inventaris.

2. Classificeer de bestemming van elke URL. Wat: label elke URL als behouden, verplaatsen, samenvoegen, verwijderen of onderzoeken. Waarom: redirects kunnen pas correct worden toegewezen als de contentbeslissing expliciet is. Hoe: combineer verkeer, conversies, backlinks, indexstatus, contentkwaliteit, bedrijfsbehoefte en intentie; leg het bewijs en de goedkeurende eigenaar vast. Tool: inventariswerkmap en contentaudit. Gereed wanneer: 100% van de relevante URL’s heeft één bestemming, een eigenaar, een bestemming of verwijderingsreden, en er is geen onopgeloste ‘onderzoeken’-rij over op het moment van bevriezing.

3. Leg de ondertekende basislijn vast. Wat: bewaar pre-lancerings organische sessies, klikken, vertoningen, conversies, omzet, geïndexeerde URL’s, crawlfouten, responscodes, uptime en prestaties voor prioriteitssjablonen en -directories. Waarom: zonder een gedateerd vergelijkingspunt lijken normale variatie en migratieschade op elkaar. Hoe: exporteer minimaal 28 vergelijkbare dagen, annoteer campagnes en seizoensgebondenheid, en identificeer prioriteits-URL’s die dagelijkse beoordeling vereisen. Tool: analytics, Search Console, crawler, positiegegevens en monitoring. Gereed wanneer: de basislijn alleen-lezen, reproduceerbaar, gesegmenteerd, voorzien van tijdstempel en goedgekeurd is door SEO- en analytics-eigenaren.

Fase 2: redirectmapping

4. Wijs bronnen waar mogelijk één-op-één toe. Wat: wijs elke verplaatste of samengevoegde oude URL toe aan de dichtstbijzijnde nieuwe URL met dezelfde primaire intentie. Waarom: een precieze bestemming behoudt continuïteit voor de bezoeker en geeft crawlers een coherent vervangingssignaal. Hoe: vergelijk onderwerp, product, geografie, taal en taak; wijs samenvoegingen toe aan de overlevende pagina en documenteer bewuste verwijderingen. Wijs nooit niet-overeenkomende URL’s toe aan de homepage. Tool: redirectmap-werkmap, inventaris en bestemmingscrawl. Gereed wanneer: elke wijzigende bron heeft precies één goedgekeurde uitkomst, elke bestemming is relevant en binnen het bereik, en het aantal homepage-verzamelbaktoewijzingen is nul.

5. Valideer redirectmechanismen vóór de lancering. Wat: test statuscodes, bestemmingen, querygedrag, case-varianten, protocol, subdomeinen, trailing slashes, bestanden en campagne-URL’s. Waarom: een correct uitziende spreadsheet kan nog steeds loops, ketens, wildcards die geldige pagina’s opslokken, of bestemmingen die fouten retourneren, produceren. Hoe: genereer de staging- of proxyregels, vraag elke bron op, volg hops en vergelijk de uiteindelijke URL met de goedgekeurde map. Tool: geautomatiseerde HTTP-test, crawler en serverconfiguratiebeoordeling. Gereed wanneer: 100% van de in kaart gebrachte bronnen de goedgekeurde 200-bestemming bereiken in één permanente redirect-hop; loops, ketens, tijdelijke redirects en foutbestemmingen zijn nul.

6. Stem canonical’s, links en sitemaps af met redirects. Wat: zorg dat de canonical URL , interne links, hreflang-referenties, gestructureerde data, feeds en XML-sitemaps direct naar uiteindelijke URL’s verwijzen. Waarom: het doorverwijzen van oude URL’s terwijl deze nog worden gepubliceerd, creëert tegenstrijdige migratiesignalen en verspilt crawlerverzoeken. Hoe: crawl elke referentiebron en vergelijk genormaliseerde doelen met de redirectmap. Tool: crawler, gerenderde HTML, sitemapparser en configuratiediff. Gereed wanneer: eindpagina’s zelf-canonicaliseren tenzij een goedgekeurde uitzondering anders zegt, interne verwijzingen naar doorverwezen URL’s zijn nul en nieuwe sitemaps bevatten alleen canonical 200-URL’s.

Fase 3: stagingvalidatie

7. Test staging zonder het publiekelijk indexeerbaar te maken. Wat: crawl de volledige staging-release terwijl zoekmachines worden verhinderd de omgeving te indexeren. Waarom: het team heeft crawler-niveau bewijs nodig zonder een dubbele site in zoekresultaten toe te staan. Hoe: gebruik toegangscontrole voor externe crawlers, voer vervolgens een geverifieerde interne crawl uit met JavaScript-rendering waar de productiesite ervan afhankelijk is. Behandel een staging-blokkade als tijdelijke releaseconfiguratie, niet als iets dat blindelings naar productie moet worden gekopieerd. Tool: geverifieerde crawler, browser en response-header-inspectie. Gereed wanneer: de verwachte staging-inventaris crawlbaar is door het testteam, ongeautoriseerde publieke indexering is geblokkeerd en de productielanceringschecklist verwijdert expliciet staging-specifieke controles.

8. Verifieer sjablonen en prioritaire gebruikerstrajecten. Wat: test representatieve pagina’s van elk sjabloon plus navigatie, zoeken, formulieren, aanmelding, afrekenen, lokalisatie, paginering, filters en foutpagina’s. Waarom: een homepage die slaagt, kan geen canonical-bug op productpagina’s of een verbroken consentstatus die analytics onderdrukt, onthullen. Hoe: maak een apparaat-en-sjabloonmatrix, test schone en terugkerende sessies en leg screenshots of response-bewijs vast voor elk resultaat. Tool: browser, toegankelijkheidscontrole, gestructureerde-data-validator, analyticsdebugger en transactietests. Gereed wanneer: elk relevant sjabloon en primair gebruikerstraject slaagt op de overeengekomen browsers en apparaten, met nul kritieke openstaande defecten.

9. Vergelijk staging met de goedgekeurde contracten. Wat: vergelijk titels, beschrijvingen, koppen, canonical’s, robots-directieven, gestructureerde data, interne links, responscodes, content en analyticstags met de oude site en de bestemmingsspecificatie. Waarom: platformmigraties verliezen vaak metadata of wijzigen rendering, zelfs wanneer de zichtbare tekst intact lijkt. Hoe: crawl oude productie en staging met overeenkomende instellingen, segmenteer verschillen per sjabloon en keur alleen bedoelde wijzigingen goed. Tool: crawl-diff-rapport en broninspectie. Gereed wanneer: elk materieel verschil is gecorrigeerd of vermeld als een goedgekeurde wijziging met eigenaar en reden; accidentele noindex-, canonical-, content- en trackingwijzigingen zijn nul.

10. Vries de releasekandidaat in. Wat: vries de URL-inventaris, redirectmap, routedefinities, canonical- en robotsregels, sitemapgeneratie, analytics- en consentconfiguratie, DNS/CDN-plan en ongewijzigde productie-implementaties in. Waarom: een testresultaat is alleen van toepassing op de geteste versie. Hoe: tag de release-artefacten, beperk wijzigingen tot het incidentpad en vereis hertesten van alles wat door een noodbewerking is getroffen. Tool: implementatiesysteem, wijzigingslogboek en goedkeuringsregistratie. Gereed wanneer: één onveranderlijke kandidaat is benoemd, de toegang is beperkt, alle uitzonderingen hebben een eigenaar en elke wijziging na bevriezing heeft een testresultaat.

Fase 4: lanceringsdag

11. Voer één beheerd runbook uit. Wat: implementeer routering, applicatie, DNS/CDN, analytics, sitemaps en monitors in de goedgekeurde volgorde. Waarom: parallelle, niet-gesequentiëerde wijzigingen maken storingen moeilijk te isoleren en terugdraaien onveilig. Hoe: één migratieverantwoordelijke roept elke stap op, de toegewezen operator registreert voltooiing en validatoren testen het bewijs vóór de volgende afhankelijke stap. Tool: runbook, implementatielogs, DNS-checks en gedeeld incidentkanaal. Gereed wanneer: elke regel heeft een werkelijke tijd, operator, resultaat en bewijslink, en geen afhankelijkheid is als voltooid gemarkeerd op basis van alleen mondelinge verzekering.

12. Voer de lancerings-smoaktest uit. Wat: test de homepage, robots.txt, sitemaps, minimaal één URL per sjabloon, elk prioriteitstraject, analytics-ontvangst en een gestratificeerde steekproef van redirectbronnen. Waarom: de snelste veilige respons komt van het detecteren van een brede storing voordat caches en crawlers deze verspreiden. Hoe: test van buiten het productienetwerk, gebruik desktop en mobiel, verifieer zowel server-geleverde HTML als gerenderde output en vergelijk met de bevroren verwachtingen. Tool: crawler, browser, HTTP-client, realtime analytics-weergave en transactiemonitor. Gereed wanneer: kritieke pagina’s de beoogde status en content retourneren, prioriteitsredirects hun exacte bestemmingen bereiken, analytics-gebeurtenissen met correcte URL’s aankomen en alle lanceringsblokkerende controles slagen.

13. Dien ontdekkingssignalen in en verifieer deze. Wat: publiceer de definitieve sitemaps, bevestig robots- en canonical-gedrag en vraag inspectie aan voor een klein aantal prioriteits-URL’s. Waarom: schone ontdekkingssignalen helpen crawlers de bestemmingsset tegen te komen zonder indiening als garantie voor indexering te beschouwen. Hoe: dien elke productiesitemap één keer in, inspecteer representatieve nieuwe URL’s en leg de door Google gerapporteerde canonical- en indexstatus vast. Tool: Sitemaps en Indexering en URL-inspectie . Gereed wanneer: sitemaps bereikbaar zijn en de bevroren canonical-inventaris bevatten, representatieve inspecties geen productieblokkade of verkeerde canonical tonen en elke waarschuwing een eigenaar heeft.

Fase 5: post-lanceringsmonitoring

14. Beschouw de eerste 72 uur als een incidentvenster. Wat: monitor uptime, 5xx, 4xx, redirectfouten, latentie, crawlvolume, analytics-ontvangst, conversies, sitemapverwerking en prioriteitstrajecten continu of met het kortst mogelijke interval. Waarom: infrastructuur- en routeringsfouten komen snel aan de oppervlakte, terwijl zoekprestaties langer duren en niet als enige lanceringsalarm moeten worden gebruikt. Hoe: vergelijk met de ondertekende basislijn, segmenteer per sjabloon en directory en stuur meldingen naar een piket-eigenaar. Tool: logs, analytics, crawler, Uptimemonitors en incidentdashboard. Gereed wanneer: het dashboard heeft geen onverklaard lanceringskritiek alarm, elk incident heeft een eigenaar en tijdstempel, en 24-, 48- en 72-uursbeoordelingen zijn ondertekend.

15. Ga door met zoek- en indexmonitoring na stabiliteit. Wat: volg paginaklikken, vertoningen, indexstatus, geselecteerde canonical’s, crawlfouten, directoryprestaties en conversieresultaten gedurende minimaal vier weken. Waarom: crawlen, canonical-selectie en indexvervanging lopen achter op infrastructuurvalidatie. Hoe: vergelijk gelijkwaardige vensters, scheid verplaatste URL’s van ongewijzigde controles en onderzoek clusters in plaats van te reageren op één dag totaal. Tool: Google Search-pagina’s , Directoryweergave , URL-inspectie, analytics en logs. Gereed wanneer: prioriteitsbestemmingen vindbaar en indexeerbaar zijn, oude URL’s consistent naar goedgekeurde bestemmingen verwijzen, onverklaarde verliezen tickets hebben en het eigenaarschap overgaat naar het normale rapportagecadans.

Tools in AmICited

AmICited biedt lanceringsbewijs en monitoringoppervlakken; de goedgekeurde redirectmap en implementatielogs blijven de operationele bron van waarheid.

Beslissingsregels

Dit zijn release-veiligheidsrails, geen universele zoekmachinedrempels. Spreek ze af vóór de lancering en scherp ze aan waar risico dit vereist.

Terugdraaien herstelt een bekende goede servicetoestand; het keert geen gewone zoekfluctuatie om. De lanceringsautoriteit past de overeengekomen regels toe en legt het bewijs vast.

Opleverbaar product

Draag één versiebeheerd migratiecontrolepakket over dat toegankelijk is voor engineering en SEO. Gebruik een werkmap of database voor recordgegevens op rijniveau, een runbook voor lanceringsacties en een dashboard voor live metingen.

Het moet bevatten: de bevroren inventaris en bronafstemming; goedgekeurde redirectmap met eigenaren en tests; overeenkomende oude, staging en nieuwe crawls; metadata-, canonical-, robots-, sitemap-, hreflang-, gestructureerde-data-, link- en analytics-diffs; ondertekende basislijn en prioriteitscohorten; lanceringsrunbook en herstelprocedure; numerieke terugdraairegels en beslissingsverantwoordelijke; en het 24-, 48- en 72-uurs bewijs met monitoringeigenaarschap voor vier weken.

De migratieverantwoordelijke moet in staat zijn de exacte release te identificeren, elke kritieke test te bewijzen, elke routeringsbeslissing te reconstrueren en elke uitzondering toe te wijzen. Anders is het pakket onvolledig.

Wat er misgaat

De redirectmap gebruikt alleen de huidige sitemap. Wezen, campagne-URL’s, backlinks en eerder geïndexeerde routes verdwijnen, waardoor elke spreadsheetregel slaagt terwijl echte verzoeken mislukken.

De homepage wordt de standaardbestemming. Gebruikers komen op een irrelevante plek terecht, crawlersignalen worden dubbelzinnig en ontbrekende content wordt vermomd als implementatievoortgang.

Redirects werken, maar referenties blijven oud. Navigatie, hreflang, canonical’s, gestructureerde data en sitemaps blijven crawlers door onnodige hops en tegenstrijdige bestemmingen sturen.

Stagingbescherming bereikt productie. Een gekopieerde noindex, authenticatieregel, robots-blokkade of CDN-beleid vernietigt indexeerbaarheid . Eis een expliciete verwijderingsstap en externe test.

Het team valideert alleen de homepage. Een gedeeld sjabloon kan duizenden pagina’s verkeerd configureren terwijl de homepage slaagt. Bemonster elk sjabloon en crawl regels op schaal.

Niet-gerelateerde releases worden samen uitgebracht. Wanneer platform-, analytics-, consent-, navigatie-, afreken- en CDN-wijzigingen een venster delen, worden storingen moeilijk te isoleren of terug te draaien.

Zoekprestaties worden te vroeg of te algemeen beoordeeld. Sitetotalen verbergen gebroken directories en één volatiele dag leidt tot onnodige reparaties. Vergelijk verplaatste cohorten, ongewijzigde controles, directories en overeenkomende vensters.

Terugdraaien wordt tijdens de uitval bediscussieerd. Een goed plan benoemt drempels, beslisser, hersteltijd, commando’s, datagevolgen en validatievolgorde vóór de lancering.

Volgende fase

Zodra de eerste 72 uur stabiel zijn, is de volgende stap continue vernieuwing en iteratie . Het heeft de ondertekende basislijn, definitieve URL-mapping, lanceringsannotaties, directorycohorten, bekende uitzonderingen, incidentgeschiedenis en benoemde eigenaren uit deze checklist nodig. Zonder deze inputs kan een later verkeersverlies niet betrouwbaar worden gescheiden in migratieschade, normale vraagverandering, contentverval of meetfalen.

Bewaar de redirectmap en migratieannotatie permanent. Verplaats niet-kritieke bevindingen naar het normale rapportagecadans met een ernst, hypothese, eigenaar, vervaldatum en verificatiemethode.

Veelgestelde vragen

Wanneer moet het SEO-team deelnemen aan een sitemigratie?

Voordat routes, sjablonen en platformbeperkingen zijn vastgesteld. SEO heeft voldoende tijd nodig om huidige URL’s te inventariseren, waardevolle bestemmingen te behouden, de nieuwe informatiearchitectuur te beïnvloeden, redirectgedrag te definiëren en meetbare lanceer- en terugdraairegels overeen te komen.

Moeten oude URL’s doorverwijzen naar de homepage wanneer er geen directe vervanging is?

Nee. Stuur een oude URL door naar de dichtstbijzijnde pagina die dezelfde gebruikersintentie vervult. Als er geen relevante bestemming bestaat en de content niet behouden moet worden, retourneer dan een eerlijke 404 of 410 in plaats van gebruikers en crawlers naar een ongerelateerde homepage te sturen.

Hoe lang moeten migratieredirects blijven staan?

Bewaar permanente redirects zolang oude URL’s nog bezoeken, links, bladwijzers of crawlerverzoeken kunnen ontvangen. Behandel ze als duurzame routeringsinfrastructuur, niet als lanceringssteigerwerk dat na een paar weken verwijderd moet worden.

Wat moet worden bevroren vóór de migratielancering?

Bevries de goedgekeurde URL-inventaris, redirectmap, canonical- en robotsregels, sitemapgeneratie, analytics- en consentconfiguratie, DNS- en CDN-wijzigingen en ongewijzigde productiereleases. Noodreparaties volgen het benoemde wijzigingscontrolepad.

Wanneer moet een migratie worden teruggedraaid?

Gebruik criteria die vóór de lancering zijn overeengekomen. Draai terug bij storingen zoals aanhoudende onbeschikbaarheid, wijdverbreide 5xx-reacties, kapotte primaire gebruikerstrajecten, ontbrekende analytics of routeringsfouten die een wezenlijk deel van de prioriteits-URL’s treffen en niet veilig kunnen worden gecorrigeerd binnen de overeengekomen hersteltermijn.