Website verhuizen: maak een URL- en redirectwerkblad

Bij een websiteverhuizing wil je niet alleen weten of de nieuwe homepage werkt. Een klant kan nog op een link in een oude offerte klikken, een opgeslagen productpagina openen of een handleiding downloaden. Maak daarom vóór livegang één gedeeld werkblad met oude adressen, de afgesproken bestemming en het bewijs van de controle. Hieronder staat een invulstructuur voor jou en je websitebouwer.

1. Verzamel ook de adressen buiten je menu

Begin met de pagina’s in je websitebeheer en sitemap. Vul aan met bezochte landingspagina’s, links uit Search Console en relevante serverlogs. Neem afbeeldingen en downloads mee. Deze bronnen kunnen verschillende delen van je website laten zien; één export is niet vanzelf een volledige inventaris.

Vraag daarnaast je verkoop- en serviceteam om de links die zij werkelijk gebruiken. Denk aan offertesjablonen, e-mailhandtekeningen, QR-codes op drukwerk, productdocumentatie en afspraaklinks. Laat iedere collega aangeven welke taak de ontvanger op die bestemming moet kunnen uitvoeren. Zo wordt een onbekend adres een concrete controleopdracht.

• Bewaar de volledige oude URL, inclusief domein en eventuele relevante parameters.
• Noteer de herkomst: bijvoorbeeld menupagina, brochure, klantmail of zoekverkeer.
• Markeer belangrijke routes zoals offerte aanvragen, contact opnemen en een document downloaden.
• Zet bij twijfel ‘uitzoeken’ met een verantwoordelijke; vul niet automatisch de homepage als bestemming in.

2. Maak één regel per oud adres

Gebruik een spreadsheet met de onderstaande kolommen. Houd ‘afgesproken’ en ‘getest’ uit elkaar: een ingevulde nieuwe URL bewijst nog niet dat de doorverwijzing is ingesteld. Bewaar de datum en degene die de uitkomst heeft gecontroleerd.

Drie fictieve regels om de afspraak scherp te maken

Deze voorbeelden zijn een oefening, geen klantcase. Vul in je eigen bestand volledige adressen in. Hier staan korte paden om het verschil tussen de beslissingen leesbaar te houden.

3. Laat de bouwer de technische uitkomst aantonen

Een redirect stuurt een bezoeker van het oude adres naar een ander adres. Voor een blijvende verhuizing ondersteunt Google onder meer de server-side statuscodes 301 en 308. Een 302 of 307 is bedoeld als tijdelijk signaal. Laat de bouwer daarom zowel de code als het eindadres controleren; alleen zien dat je ergens uitkomt, is niet genoeg.

Stuur oude URL’s waar mogelijk direct naar de uiteindelijke bestemming. Een reeks doorverwijzingen maakt controle en onderhoud lastiger. Een lus, waarbij adressen naar elkaar terugverwijzen, moet worden opgelost. Verwijs niet allerlei verdwenen pagina’s naar een ongerelateerde homepage: de bestemming moet inhoudelijk passen.

Een pagina die niet meer bestaat en geen passende vervanger heeft, kan correct een 404 of 410 teruggeven. Dat is iets anders dan een kapotte belangrijke dienstpagina. Een foutmelding met status 200 kan door Google als soft 404 worden behandeld. Andersom bewijst status 200 alleen een geslaagde HTTP-respons; daarmee zijn de inhoud, werking en indexatie nog niet bewezen.

4. Test oude ingangen, niet alleen nieuwe knoppen

Laat de bouwer de volledige mapping technisch controleren. Loop zelf de belangrijkste klanttaken door op telefoon en desktop, beginnend bij de oude link. Gebruik bijvoorbeeld een link uit een werkelijk gebruikt offertesjabloon. Kijk onderweg of de paginanaam, het aanbod en de vervolgstap nog bij de oorspronkelijke bedoeling passen.

1. 1Open het oude adres en vergelijk de uiteindelijke bestemming met je werkblad.
2. 2Lees de pagina als klant: is dezelfde dienst, productvariant of informatie aanwezig?
3. 3Voer de afgesproken taak uit. Test een formulier alleen met toestemming en herkenbare proefgegevens; controleer ook de ontvangst in het juiste systeem.
4. 4Open de belangrijkste download en controleer de inhoud. Test een afspraakroute tot het overeengekomen punt; maak geen onbedoelde echte boeking.
5. 5Leg de afwijking vast met datum, URL en verantwoordelijke. Test na herstel opnieuw dezelfde route.

Neem bij een verhuizing ook e-mail mee in de overdrachtsafspraak. Vraag wie controleert dat wijzigingen aan domein- of hostinginstellingen de maildienst intact laten. Een werkende website is geen ontvangstbewijs voor e-mail. Verander mailinstellingen niet als onderdeel van een standaard websitecheck zonder dat de verantwoordelijke weet wat er moet gebeuren.

5. Maak een expliciet besluit voor livegang en herstel

Spreek vóór de verhuizing af wie beslist over livegang en wie bereikbaar is bij een fout. Maak onderscheid tussen een verkeerd uitgelijnde afbeelding en een ontbrekende offerteaanvraag. Schrijf ook op hoe je een wijziging terugdraait en wat er met nieuwe aanvragen of bestellingen gebeurt als je teruggaat. Een oude kopie terugzetten zonder die recente gegevens te bekijken kan nieuwe problemen veroorzaken.

6. Bewaar het werkblad na de verhuizing

Herhaal de kritieke controles op het echte domein direct na livegang. Plan vervolgens een kort nazorgmoment met je bouwer. Bekijk nieuwe foutmeldingen, gemiste klanttaken en ontvangen aanvragen naast Search Console en Analytics. Een redirecttest, Google-indexatie en een ontvangen aanvraag zijn drie verschillende bewijzen; geef ze afzonderlijke kolommen of tabbladen.

Houd een wijzigingslog bij met datum en herstelactie. Vergelijk zoekprestaties over passende perioden en houd rekening met herverwerking door Google. Gebruik een daling als aanleiding om te onderzoeken, niet als reden om willekeurig alle URL’s opnieuw te veranderen. Google adviseert redirects bij een verhuizing minimaal een jaar te behouden; oude klantlinks kunnen ook daarna nog gebruikt worden.