Een websitemigratie is technisch SEO-klaar wanneer je vooraf beslist welke URLs veranderen, voor elke relevante oude URL een passende nieuwe bestemming vastlegt, definitieve verhuisbewegingen met een permanente server-side redirect behandelt en na de livegang oude én nieuwe URLs gericht opvolgt. Dat is belangrijk omdat Google een URL-wijziging per URL verwerkt; tijdens het opnieuw crawlen en indexeren kunnen tijdelijke rankingfluctuaties optreden. Er bestaat daarbij geen vaste crawlfrequentie. Lees de officiële werkwijze in Google Search Central over een site move met URL-wijzigingen.
Een migratie kan een nieuw domein, een aangepast URL-patroon, een ander platform of een nieuw ontwerp omvatten. De technische SEO-taak is niet om alles blind af te vinken, maar om voor elke wijziging een controleerbare beslissing te nemen: blijft de URL bestaan, verhuist de inhoud naar een overeenkomstige nieuwe URL, of is er geen passende opvolger? Dit artikel geeft daarvoor een praktische aanpak vóór, tijdens en na de lancering.
Welke wijzigingen vragen een URL-migratieplan?
Begin niet met redirects configureren, maar met het afbakenen van de verandering. De kernvraag is eenvoudig: verandert de bestaande URL voor een bezoeker of zoekmachine? Als het antwoord ja is, hoort die URL in je migratieplan thuis.
Maak per groep pagina’s een beslissing. Denk aan belangrijke inhoudspagina’s, product- of categoriepagina’s, contact- en formulierenpagina’s en andere pagina’s die je bewust wilt behouden. De bedoeling is een oude URL te koppelen aan de overeenstemmende nieuwe URL, zoals Google aanbeveelt bij URL-wijzigingen. Een redirect is dus geen vervanging voor inhoudelijke keuzes: eerst bepaal je de juiste bestemming, daarna leg je de technische verhuis vast.
Beslisboom voor elke oude URL
- Blijft de URL identiek? Noteer dat ze niet hoeft te verhuizen, maar neem ze wel op in je testset.
- Verandert de URL, maar blijft er overeenkomstige inhoud bestaan? Leg de oude URL naast de passende nieuwe URL in een mapping.
- Verandert de URL definitief? Plan een permanente server-side redirect van oud naar nieuw.
- Is er geen overeenkomstige nieuwe bestemming? Leg die beslissing expliciet vast in plaats van automatisch een willekeurige pagina te kiezen.
Deze aanpak voorkomt dat de redirectlijst losstaat van de inhoudelijke migratie. Ze maakt ook review mogelijk: iemand anders kan per regel nagaan of oude en nieuwe URL werkelijk bij elkaar passen.
Wat moet er vóór de livegang klaarstaan?
Vóór de lancering heb je vooral bewijsstukken en afspraken nodig. Google adviseert voorbereiding, mapping, redirects en monitoring rond een wijziging van URLs; bij een wijziging van bestaande URLs adviseert Google een mapping van oude naar overeenstemmende nieuwe URLs, het instellen van redirects en monitoring van verkeer op oude én nieuwe URLs. Zie Google Search Central over een site move met URL-wijzigingen. Een praktische migratieaanpak kan daarnaast een baseline-crawl, een beperkte set testpagina’s, afscherming van de stagingomgeving, een back-up en een rollbackplan omvatten. Die elementen worden beschreven in de onafhankelijke migratiegids van Ahrefs.
Checklist vóór de lancering
- Maak een overzicht van bestaande URLs die je bewust meeneemt in de beoordeling.
- Voer een baseline-crawl uit en bewaar die als vertrekpunt voor vergelijking.
- Maak een URL-mapping met minstens een kolom voor oude URL, nieuwe URL en de beslissing.
- Laat de redirectconfiguratie aansluiten op die mapping, niet op een losse lijst aannames.
- Kies een beperkte, representatieve testset van kritieke pagina’s.
- Scherm de stagingomgeving af zodat die niet als publieke versie wordt behandeld tijdens de voorbereiding.
- Voorzie een back-up en wijs één persoon aan die beslist en handelt wanneer rollback nodig is.
- Leg vast wie na livegang de oude en nieuwe URLs, redirects en opvolging controleert.
De eigenaar van rollback hoeft niet alle technische handelingen zelf uit te voeren. Wel moet vooraf duidelijk zijn wie de beslissing neemt wanneer de lancering moet worden teruggedraaid. Zonder die afspraak is een rollbackplan slechts een document.
Hoe maak je een bruikbare URL-mapping?
Een URL-mapping is de brug tussen de oude website, de nieuwe website en de redirectconfiguratie. Maak ze leesbaar voor zowel marketeers als ontwikkelaars. Eén rij vertegenwoordigt één controleerbare verhuisbeslissing.
Minimale opbouw van de mapping
- Oude URL: de bestaande pagina die verandert.
- Nieuwe URL: de overeenstemmende nieuwe bestemming, wanneer die bestaat.
- Beslissing: bijvoorbeeld URL blijft, verhuist definitief of geen passende opvolger.
- Teststatus: ruimte om vóór en na de livegang vast te leggen of de gekozen route is gecontroleerd.
- Eigenaar: wie de inhoudelijke keuze of technische uitvoering bevestigt.
Vermijd een mapping waarin alle oude URLs naar dezelfde algemene pagina worden gestuurd zonder inhoudelijke beoordeling. Het dossier ondersteunt geen algemene regel voor zulke gevallen; juist daarom is een expliciete beslissing per URL nuttig. Ze dwingt het team om onzekerheid zichtbaar te maken vóór die in productie belandt.
Praktijkvoorbeeld: een wijziging van URL-structuur
Hypothetisch voorbeeld. Een Belgische onderneming vernieuwt haar website en wijzigt de URL van een dienstenpagina. In de mapping staat de oude diensten-URL naast de nieuwe diensten-URL, met de notitie dat de inhoud op de nieuwe pagina overeenstemt. Omdat de wijziging definitief is, plant het team een permanente server-side redirect. De oude URL en de nieuwe URL komen beide in de testset. De stagingomgeving blijft afgeschermd, er is een back-up voorzien en één verantwoordelijke kan rollback laten uitvoeren.
Na de lancering controleert het team of de oude URL naar de gekozen nieuwe URL leidt en volgt het de oude én nieuwe URLs verder op. Dit voorbeeld voorspelt geen resultaat en garandeert geen stabiele positie: Google geeft aan dat tijdelijke fluctuaties mogelijk zijn terwijl URLs opnieuw worden gecrawld en geïndexeerd. Google beschrijft dat deze verwerking per URL gebeurt en geen vaste crawlfrequentie kent; zie Google Search Central over een site move met URL-wijzigingen.
Wanneer kies je voor een permanente server-side redirect?
Als een URL definitief wijzigt, beveelt Google waar mogelijk een permanente server-side redirect aan. HTTP-statuscodes 301 en 308 geven aan dat een pagina permanent verhuisd is. De officiële toelichting staat in Google Search Central over permanente redirects.
Het relevante onderscheid is dus niet of een redirect technisch gemakkelijk te plaatsen is, maar of de verhuizing definitief is. Een tijdelijke redirect past niet als je weet dat de oude URL niet terugkomt. Leg deze keuze vast in de mapping, zodat inhoudelijke intentie en servergedrag hetzelfde verhaal vertellen.
Controlepunten voor redirects
- Controleer of de oude URL naar de vooraf gekozen overeenkomstige nieuwe URL leidt.
- Controleer de kritieke testset zowel vóór als na de lancering.
- Vergelijk de uitgevoerde redirects met de goedgekeurde mapping.
- Behandel een definitieve URL-wijziging als een permanente verhuisbeweging op de server.
- Noteer afwijkingen en wijs een eigenaar toe voor herstel of rollbackbeslissing.
Hoe test je gecontroleerd vóór en tijdens de livegang?
Testen wordt sterker wanneer je het beperkt en doelgericht houdt. Een beperkte testset is geen volledige inventaris van de site, maar een vooraf gekozen verzameling kritieke pagina’s en verhuisbewegingen. Daardoor kan het team tijdens een drukke livegang nagaan of de belangrijkste afspraken werkelijk zijn uitgevoerd.
Gebruik je mapping als testschema. Controleer voor iedere geselecteerde oude URL de gekozen bestemming. Controleer voor iedere geselecteerde nieuwe URL of die beschikbaar is zoals afgesproken. Noteer niet alleen “in orde”, maar ook welke URL is getest, door wie en welke afwijking werd gezien. Dat maakt de oplevering controleerbaar zonder te doen alsof een kleine testset alle mogelijke problemen uitsluit.
Valkuilen die je vooraf kunt vermijden
- Een redirectlijst zonder mapping: dan ontbreekt de toets of de bestemming inhoudelijk overeenstemt.
- Staging niet afschermen: neem afscherming expliciet op in de voorbereiding.
- Geen back-up of rollbackafspraak: een probleem is dan wel herkenbaar, maar de herstelroute is niet afgesproken.
- Alles tegelijk willen controleren: begin met een beperkte kritieke testset en documenteer de resultaten.
- Rankingbewegingen direct als eindoordeel zien: Google beschrijft tijdelijke fluctuaties tijdens hercrawl en herindexering. Zie Google Search Central over een site move met URL-wijzigingen.
Wat volg je op na de lancering?
Na livegang begint de opvolging pas echt. Google adviseert monitoring van verkeer op oude én nieuwe URLs bij een URL-wijziging. Richt je opvolging daarom niet uitsluitend op de nieuwe website. Oude URLs tonen of de geplande verhuisbewegingen nog relevant zijn voor bezoekers en zoekmachines; nieuwe URLs tonen of de nieuwe bestemmingen worden opgevolgd.
Behandel de overgang als een proces per URL. Google verwerkt URLs individueel en noemt geen vaste crawlfrequentie. Een controle die vandaag geen definitief beeld geeft, is dus geen reden om de mapping of redirectkeuzes achteraf te negeren. Houd je registraties bij, onderzoek afwijkingen tegen de oorspronkelijke mapping en beslis op basis van dat bewijs of herstel of rollback nodig is. Zie Google Search Central over een site move met URL-wijzigingen.
Checklist voor de opvolging
- Controleer de gekozen oude URLs uit je testset opnieuw.
- Controleer de bijbehorende nieuwe URLs opnieuw.
- Vergelijk het waargenomen gedrag met de URL-mapping en redirectconfiguratie.
- Volg verkeer op oude én nieuwe URLs op, zoals Google adviseert.
- Documenteer afwijkingen, verantwoordelijke en beslissing.
- Gebruik het vooraf afgesproken rollbackplan wanneer het team beslist dat terugdraaien nodig is.
Wie moet welke beslissing nemen?
Een migratie is geen taak van één discipline. De inhoudelijke eigenaar beoordeelt of een nieuwe URL werkelijk overeenstemt met de oude pagina. De technische uitvoerder vertaalt de goedgekeurde mapping naar server-side redirects. De persoon die de livegang coördineert bewaakt testset, back-up, stagingafscherming en rollbackafspraak. Wie de opvolging doet, vergelijkt na lancering oude en nieuwe URLs met de gemaakte keuzes.
Voor Belgische KMO’s is deze verdeling vaak belangrijker dan een groot procesdocument. Zorg dat elke beslissing een naam heeft: wie bevestigt de bestemming, wie voert uit, wie test en wie beslist bij rollback. Zo wordt technische SEO bij een migratie een beheersbare reeks controles in plaats van een los eindpunt vlak voor de livegang.
Wil je de keuzes rond structuur, beheer en groeidoel eerst scherpstellen? Bespreek je website-aanpak met Converted. Voor een webshop met migratievragen kun je ook de e-commerce-aanpak van Converted bekijken.
Veelgestelde vragen over technische SEO bij een websitemigratie
Moet ik alle oude URLs naar de homepage redirecten?
Nee, vertrek van een mapping waarin een oude URL aan een overeenstemmende nieuwe URL wordt gekoppeld wanneer die bestaat. Leg voor URLs zonder passende opvolger een expliciete beslissing vast, in plaats van automatisch één algemene bestemming te kiezen.
Wanneer gebruik ik een 301- of 308-redirect?
Wanneer een URL definitief wijzigt, beveelt Google waar mogelijk een permanente server-side redirect aan. Zowel HTTP 301 als 308 geeft aan dat een pagina permanent verhuisd is. Laat die technische keuze aansluiten bij je goedgekeurde URL-mapping.
Waarom zie ik na de migratie schommelingen in rankings?
Google meldt dat tijdelijke rankingfluctuaties kunnen optreden terwijl gewijzigde URLs opnieuw worden gecrawld en geïndexeerd. Die verwerking gebeurt per URL en heeft geen vaste crawlfrequentie. Beoordeel afwijkingen daarom naast mapping, redirects en opvolging van oude en nieuwe URLs. Zie Google Search Central over een site move met URL-wijzigingen.
Welke pagina’s test ik het eerst bij een livegang?
Kies vooraf een beperkte set kritieke pagina’s en gebruik die als concrete testset vóór en na de lancering. Neem zowel oude URLs die verhuizen als hun nieuwe bestemmingen op. Documenteer telkens wat je controleerde en wie de afwijking opvolgt.
Waarom heb ik een rollbackplan nodig als redirects voorbereid zijn?
Redirects zijn slechts één onderdeel van de voorbereiding. Een praktische migratieaanpak omvat ook een back-up en een rollbackplan. Wijs vooraf een eigenaar aan die beslist en handelt wanneer terugdraaien nodig is, zodat die route niet pas tijdens een probleem wordt uitgevonden.
