SEO-migratiechecklist: van URL-register tot controle na livegang

Deze checklist is een operationeel werkdocument voor een lancering, niet een offerte voor redesign. Veranderen domein, protocol of paden? Dan heb je een URL-migratie. Blijven alle URL's gelijk en verandert alleen de host, dan is een andere technische controle nodig. Google behandelt die situaties in afzonderlijke documentatie. Een nieuw ontwerp kan ondertussen ook zonder URL-wijziging inhoudelijke SEO-risico's veroorzaken.

Wijs een eigenaar aan voor mapping, content, techniek en besluitvorming bij problemen. Leg een terugvalplan vast: wat kan terug, wie beslist en welke nieuwe gegevens moeten behouden blijven? Combineer niet zonder noodzaak een domeinwissel, CMS-wissel en complete herschrijving. Kleine afzonderlijk toetsbare stappen maken het eenvoudiger de oorzaak van een afwijking te vinden.

Exporteer een crawl van de bestaande website, de sitemap en relevante serverlogs. Voeg in Search Console pagina's en zoekopdracht-paginaparen toe, met de gekozen periode. Neem ook waardevolle URL's met externe links en belangrijke aanvraag- of bestelroutes mee. Alleen de huidige navigatie kopiëren mist oudere landingspagina's die nog bezoekers ontvangen.

Bewaar per pagina titel, H1, tekst, canonical, indexeringsinstructies, afbeeldingen en aanwezige structured data. Maak onderscheid tussen bewust verdwijnen en per ongeluk vergeten. Een nieuwe pagina die dezelfde zoekvraag niet meer beantwoordt, wordt niet equivalent doordat de URL erop lijkt. Beoordeel daarom de inhoud vóór je een bestemming aanwijst.

Gebruik een kopie van het register als auditlijst. Noteer bij wijzigingen de reden en laat belangrijke pagina's door een tweede persoon controleren. Search Console geeft nuttige historische signalen, maar geen volledige lijst van alle ooit gecrawlde URL's. Combineer bronnen en label ontbrekende informatie in plaats van een complete inventarisatie te veronderstellen.

Koppel oude URL's aan semantisch passende nieuwe pagina's. Wanneer een artikel gewoon blijft bestaan, serveer het als 200 met zijn eigen canonical. Voeg alleen een redirect toe wanneer het adres daadwerkelijk wijzigt of inhoud aantoonbaar wordt samengevoegd. Bestaat geen passend alternatief, dan kan een duidelijke 404 of 410 juister zijn dan een irrelevante bestemming.

Google waarschuwt voor redirects van veel oude URL's naar een irrelevante bestemming zoals de homepage: die kunnen als soft 404 worden behandeld. Gebruik permanente server-side redirects en wijs bij voorkeur direct naar de eindbestemming. Controleer protocol, domeinvariant en trailing slash gezamenlijk zodat een gebruiker niet door meerdere onnodige hops gaat.

Test iedere mapping met een echte HTTP-aanvraag, niet alleen door regels in een bestand te lezen. Controleer status, Location en eindpagina. Denk aan queryparameters die betekenis hebben, afbeeldingen en downloads met externe links. Gebruik geen brede catch-all voor onbekende adressen; die kan fouten verbergen en legitieme pagina's naar de verkeerde plek sturen.

Houd de testomgeving afgeschermd en voorkom dat staginggegevens naar productie lekken. Vergelijk belangrijke oude en nieuwe pagina's: één duidelijke H1, passende titel en beschrijving, bruikbare tekst, beelden, schema en interne links. De canonical moet straks naar de openbare eind-URL wijzen, niet naar het stagingdomein of standaard naar de homepage.

Plan expliciet welke bescherming bij livegang verdwijnt en welke bescherming op staging blijft. Een robots-blokkade en een noindex-instructie zijn niet hetzelfde. Een crawler die de pagina niet mag ophalen kan een noindex op die pagina niet lezen. Controleer zowel HTML als responseheaders, inclusief X-Robots-Tag, en test de uiteindelijke publieke omgeving.

Controleer de productie-URL's met redirects uitgeschakeld en volg daarna de hele keten. De eindpagina moet 200 geven, inhoudelijk kloppen en naar zichzelf canonicaliseren. Bekijk ook de server-gerenderde tekst: een lege shell met alleen scripts is geen inhoudelijke controle. Test de domeinvarianten en oude links die echte bezoekers gebruiken.

Werk interne links bij naar de schone eindadressen. Zet alleen canonical, indexeerbare 200-pagina's in de sitemap en behoud legitieme bestaande URL's. Gebruik geen dagelijks veranderende lastmod als versheidsclaim; voeg zo'n datum uitsluitend toe wanneer een significante, pagina-specifieke wijziging bekend is. Een sitemap helpt ontdekken, maar dwingt Google niet te indexeren.

Gebruik URL-inspectie in Search Console voor belangrijke eindpagina's en bekijk wat Google daadwerkelijk ziet. Volg indexeringsrapporten, crawlproblemen, serverlogs en oude URL's met onverwachte 404's. Registreer datum, voorbeeld-URL, fout, ernst en verantwoordelijke. Een totaal geïndexeerd aantal zonder URL-samples vertelt niet welke pagina's of oorzaken aandacht vragen.

Controleer dat GA4 op de productiepagina's aanwezig is en dat relevante gebeurtenissen niet dubbel worden verstuurd. Analyseer aanvragen in het bestaande beheerpaneel en onderscheid een browsermelding van een werkelijk opgeslagen aanvraag. Doe alleen afgesproken functionele tests; vermijd echte betalingen of ongewenste klantberichten tijdens de controle.

Google moet wijzigingen opnieuw crawlen en verwerken. Rankings kunnen schommelen en behoud is niet te garanderen. Een geslaagde technische lancering sluit inhoudelijke kwaliteitsproblemen of veranderde concurrentie niet uit. Bij verlies onderzoek je eerst concrete URL's, redirects, canonicals en verdwenen antwoorden voordat je veel nieuwe pagina's toevoegt of overal indexering aanvraagt.

Geef het URL-register en de nazorglijst mee aan iedereen die content of techniek beheert. Zo worden latere wijzigingen geen nieuwe, ongedocumenteerde migratie. De TextileGenesis-case hieronder laat een daadwerkelijke platformoverstap zien; gebruik die niet als bewijs dat een andere migratie dezelfde zoekresultaten krijgt.