Het bouwen van een nieuwe website, ook wel migreren van een site genoemd, is voor veel bedrijven een uitdagende opdracht. Zeker als je daarvoor al actief met de optimalisatie van de ‘oude’ website bezig bent geweest. Designkeuzes, functionaliteiten zelf ontwikkelen of via plugins erin zetten, content overnemen, herschrijven of juist schrappen; allemaal activiteiten waar je goed over moet nadenken en waar meerdere mensen hun eigen belangen hebben.
Voor SEO-specialisten is het belangrijkste van een nieuwe website laten maken dat de opgebouwde waarde van de URL’s goed meegaat zodra de nieuwe site live staat. Dit is vooral om het voor Google zo makkelijk mogelijk te maken en een dip in rankings minimaliseren. Een verhuisbestand is hier een belangrijk middel voor.
Maar hoe stel je zoiets op? In dit artikel leggen we dat uit.
In de meest eenvoudige vorm is een verhuisbestand niets meer dan een Excel-bestand met de oude URL en de nieuwe URL. Daarbij staat in de kolom ‘Oude URL’ het pad zoals dit nu op de website staat. In de kolom ‘Nieuwe URL’ geef je de volledige URL op van wat de nieuwe bestemming wordt. Met andere woorden; waar je de oude URL naartoe moet redirecten.
Je kunt eventueel nog twee extra kolommen toevoegen. De eerste extra kolom is vaak het type redirect dat je wil doorvoeren, al is dit meestal een ‘301 – permanent redirect’. De tweede extra kolom is voor opmerkingen. Dit is vooral handig als je het eerst gebruikt als werkdocument waarin je redenen of nog uit te voeren acties zet.
Het kan zijn dat je in een keer een hele set URL’s wil redirecten, en daar Regex-regels voor gebruikt. Deze zul je apart moeten noteren en aanleveren bij de developer die het verwerkt.
Een verhuisbestand is om twee redenen belangrijk;
Voor het behoud van de waarde van de URL’s. Wat vooral neerkomt op een continuïteit in het beoordelen van je site door zoekmachines en andere bots die je site uitlezen. Als deze bots niet duidelijk doorverwezen worden, gaan ze de content die ze wel kunnen vinden opnieuw beoordelen. Je verliest daarmee historische waarde en zult een grotere en/of langere dip ervaren in organische zichtbaarheid.
Voor de gebruikerservaring. Als URL’s wijzigen en niet worden doorverwezen, kunnen gebruikers op 404’s uitkomen. Dit kan zowel bij on-site navigatie zijn, als bij off-site verwijzingen naar je website. Gebruikers die niet ergens uitkomen waar ze verwachten of hopen uit te komen, zonder goed alternatief zullen minder snel overgaan tot conversies.
Gebruikers zullen al moeten wennen aan een nieuwe site, ook al is het wellicht een stuk beter. En zeker als je duizenden euro’s hebt geïnvesteerd in de oude én nieuwe website wil je direct doorpakken.
Vanuit SEO-perspectief wil je dat alle URL’s met waarde doorverwijzen. Vanuit gebruikersperspectief wil je alle URL’s doorverwijzen waar mogelijk verkeer op komt. De conclusie is dat je voor de zekerheid alle URL’s die nu een status 200 OK geven wil doorverwijzen (bij een goed geconfigureerde site).
Dus de inventarisatie start met op zoek gaan naar alle URL’s die nu een status 200 geven. Als je een uitdraai via Screaming Frog maakt, waarbij je de xml-sitemap koppelt om orphan pages mee te nemen, kom je al een heel eind.
Vergeet niet dat afbeeldingen, video’s en andere indexeerbare bestanden (PDF’s etc.) ook onder deze groep vallen!
Alles wat een 404 geeft is verstandig om op te lossen (zeker als het nog een tijdje duurt voordat de site live gaat). Alles wat nu een 301 geeft kun je apart houden om later te controleren of je geen redirect chains maakt.
Om de dekkingsgraad van je inventarisatie nog groter te maken, kun je in Analytics en Search Console kijken of daar nog URL’s staan die een 404 geven en je meteen mee wil nemen in het verhuisbestand.
Als je alle ‘oude’ URL’s hebt verzameld, kun je controleren hoe het ervoor staat op de staging. Idealiter heb je vooraf al een beeld van welke URL’s wijzigen en waarom, maar soms loopt dat iets anders. Doe dit dan ook op het moment dat de site bijna klaar is voor livegang en je niet verwacht dat er nog URL’s gaan wijzigen of pagina’s gaan bijkomen, tenzij er uit deze check actiepunten komen.
Een tip is om in Excel met zoek-en-vervangen het domein van alle URL’s aan te passen naar de staging. Plak daarna de hele lijst in Screaming Frog en draai de crawl opnieuw.
Een uitzondering is als letterlijk de site naar een ander domein migreert, dan zijn álle URL’s onderdeel van een verhuisbestand. Maar hoe om te gaan met een domeinwijziging is een ander artikel.
Bij websitemigraties mag je als SEO-specialist, content-specialist en developer één vuistregel aanhouden; Laat alle URL’s exact hetzelfde, tenzij een duidelijke verbetering mogelijk is, of je écht niet anders kan.
Beide situaties waarin URL’s wel wijzigen zijn vaak het gevolg van een verandering van CMS of site-architectuur. De eerste situatie is bijvoorbeeld wanneer je ineens de mogelijkheid krijgt om wél gelaagdheid in je categorieën toe te voegen. De tweede situatie is bijvoorbeeld wanneer je wisselt van CMS en de afbeeldingspaden wijzigen.
Zodra je alle ‘oude’ URL’s hebt die op de staging een 404 geven, ga je aan de slag met de controle. Crawl de staging op de natuurlijke manier en bekijk waar de verschillen zitten.
Als duidelijk is dat de inhoud van de ‘oude’ URL een nieuwe bestemming heeft gekregen. Vul je de bestemming in bij je verhuisbestand. Bekijk hier wel altijd of de wijziging in URL wenselijk of noodzakelijk is. Zo niet; pas het nog aan op de staging.
Lijkt content niet overgenomen? Dan moet je een keuze maken of je dit alsnog gaat doen of je een nieuwe bestemming gaat vinden voor die oude URL’s. Het liefst kies je een URL die inhoudelijk het dichtst bij de content zit op de pagina die verdwijnt. Een van de methodes om dit te doen is door een analyse te maken met behulp van vector embeddings.
Zodra de hele lijst compleet is, moet je de redirects nog verwerken. Vaak gebeurt dit door de developer. Als de site draait op een Apache webserver is het iets eenvoudiger voor non-developers om dit door te voeren in een .haccess-bestand. Met een NGINX webserver wordt het iets complexer.
Zoals eerder aangegeven kun je bij een Apache server ook door middel van RegEx-regels hele secties redirecten met één regel. Veelvoorkomende voorbeelden waarbij je dit inzet zijn;
Het verwerken van een verhuisbestand kan zorgen dat er op de site een aantal URL’s na livegang een 301 geven. Het is netjes om te zorgen dat een nieuwe site bij livegang alleen maar interne (en externe) links bevat die een statuscode 200 geven. Dit aanpassen kan heel tijdrovend zijn, maar draagt bij aan de laadtijd voor gebruikers en crawlbaarheid voor bots.
Zodra de site is gemigreerd moet je een controle uitvoeren. Is de overkoepelende URL-structuur nog hetzelfde als op de ‘oude’ site? Dus maak je nog steeds gebruik van www. en een trailing slash (of juist niet)?
Naast die check crawl je nogmaals alle ‘oude’ URL’s uit je verhuisbestand. Alle URL’s zouden een statuscode 301 moeten (of een andere die je zelf gedefinieerd hebt). Daarna check je alle URL’s die je als nieuwe bestemming hebt opgegeven. Geven die allemaal een statuscode 200? Dan zit je goed.
In de periode erna moet je in ieder geval de crawlstatistieken vanuit Google monitoren en schommelingen in de zichtbaarheid. Check ook of je Robots.txt niet aangepast moet worden n.a.v. de migratie.
Een site is continu in ontwikkeling. Het is goed om af te stemmen met alle betrokkenen hoe je qua redirects omgaat met het vervallen van URL’s.
Heb je bijvoorbeeld een vacaturesectie waarbij vacatures vaak inactief worden? Zet 302-redirects op die URL’s naar het vacatureoverzicht. Of bij een webshop waar het assortiment soms (permanent) veranderd, is creeër je automatisch enkele 404’s. Je kunt afstemmen dat deze URL’s altijd naar een bovenliggende categorie worden omgeleid.
Automatisering van een verhuisbestand is voor veel SEO-specialisten iets dat hun leven makkelijker kan maken. Met behulp van AI is dit zeker te automatiseren, al wordt het al gauw complex om een goede validatie in te bouwen.
Je zou moeten beginnen met een agent waar je de URL’s van de ‘oude’ site en de staging invult. Vanuit daar wordt een crawl gedaan van beide sites, inclusief een check op inhoud. Het is verstandig om een check op URL, content match (van de body) en een vector embedding in te bouwen. Als je dat combineert met contextuele regels voor het mappen, kom je al een heel eind.
Het wordt lastiger zodra je een check wil inbouwen om aan te geven of een ‘match’ als redirect moet blijven bestaan of dat de bestemming toch moet veranderen. Dit geldt ook voor de meest efficiënte oplossing om de redirectregels op te stellen.
Afsluiter; Je kunt dit artikel bijvoorbeeld als input gebruiken voor een LLM of vibe coding tool om een opzet te maken voor de automatisering! Wil je een controle of dit uitbesteden? Neem dan contact met ons op.
Onze blogartikelen
Met zo’n groot team aan specialisten en vakidioten verzamelen we veel tips. Deze zetten we graag voor je op een rij in onze blogartikelen. Lees ze hier.
Volg ons op