Website verhuizen zonder SEO-verlies: redirects, canonicals en DNS stap voor stap

Bij een redesign wordt vaak eerst gekeken naar welke pagina’s de nieuwe site nodig heeft. Voor een migratie moet je daarnaast weten welke URL’s de oude site werkelijk heeft opgebouwd. Dat zijn niet alleen pagina’s in het menu, maar ook blogposts, landingspagina’s, oude categorieën, productroutes en URL’s waar externe links of zoekverkeer op binnenkomen.

Maak vóór de verhuizing een export van de huidige sitemap, Search Console-pagina’s, belangrijke analyticsroutes en waar mogelijk externe linkdata. Combineer die bronnen, want geen enkele lijst is altijd volledig. Een oude pagina die niet meer in de sitemap staat kan nog steeds backlinks of zoekimpressies hebben.

Geef iedere oude URL daarna een bestemming: behouden, inhoudelijk samenvoegen, gericht doorsturen of bewust verwijderen. Daarmee voorkom je de bekende migratiefout waarbij tientallen oude pagina’s na livegang simpelweg 404 worden.

Een 301 is bedoeld voor een permanente verhuizing. Google gebruikt permanente redirects als signaal dat het doel de nieuwe canonical kan worden. Dat past bijvoorbeeld wanneer een oud artikel is samengevoegd met een betere gids of wanneer een dienst een nieuwe URL krijgt.

Stuur niet iedere verdwenen pagina naar de homepage. Een redirect hoort inhoudelijk logisch te zijn. Een oud artikel over WordPress-onderhoud kan naar een nieuwe onderhoudsgids, maar een volledig verdwenen evenement zonder opvolger heeft misschien geen relevante bestemming.

Voorkom redirectketens. Als /oude-pagina ooit naar /tussenpagina ging en de nieuwe site /nieuwe-pagina gebruikt, laat /oude-pagina dan direct naar /nieuwe-pagina gaan. Iedere extra stap maakt beheer lastiger en kan voor bots en bezoekers vertraging geven.

Een canonical-link geeft aan welke URL als voorkeursversie van vergelijkbare inhoud bedoeld is. Na een migratie wil je dat de nieuwe pagina naar zichzelf canonicaliseert en dat interne links, sitemap en redirects dezelfde URL gebruiken.

Een veelgemaakte fout is dat een stagingdomein, oude hostnaam of oude /home-route in canonicals achterblijft. Controleer daarom niet alleen de browser-URL maar ook de HTML. Google kan een andere canonical kiezen als technische signalen tegenstrijdig zijn.

Gebruik canonicals niet als vervanging voor redirects wanneer een oude URL permanent verhuisd is. Een bezoeker en crawler moeten direct naar de nieuwe bestemming kunnen.

Een migratie kan technisch correcte 301’s hebben terwijl de nieuwe site intern nog overal naar oude URL’s linkt. Dat werkt, maar maakt crawlen onnodig omslachtig en houdt oude paden kunstmatig in leven.

Crawl daarom de nieuwe site en zoek naar interne links die 301, 404 of andere onverwachte statussen geven. Werk menu, buttons, breadcrumbs, footer en contentlinks bij naar de uiteindelijke canonical URL.

Controleer daarnaast orphan pages: pagina’s die wel in de sitemap staan maar nergens vanuit normale content of navigatie bereikbaar zijn. Een sitemap helpt bij ontdekking, maar een logische interne linkstructuur helpt zoekmachines en bezoekers begrijpen welke pagina’s belangrijk zijn.

Een stagingwebsite hoort meestal niet geïndexeerd te worden. Dat betekent vaak noindex of andere afscherming. Bij livegang moet die blokkade juist bewust worden verwijderd. Een perfecte nieuwe site die op noindex blijft staan kan niet normaal in de zoekresultaten komen.

Controleer robots.txt én de robots-meta-tag op echte productiepagina’s. Kijk ook of een beveiligingsplugin, onderhoudsmodus of hostinginstelling crawlers blokkeert. Doe dit na de domeinwissel nogmaals, omdat caching of domeinspecifieke instellingen pas dan zichtbaar kunnen worden.

Zet staging niet publiek indexeerbaar om Google “alvast te laten wennen”. Dat kan duplicate content en verkeerde canonicals veroorzaken. Houd staging afgeschermd en maak productie in één gecontroleerde stap indexeerbaar.

DNS bepaalt waar het domein naartoe wijst, maar een domeinwissel is pas bruikbaar wanneer HTTPS op de nieuwe bestemming correct werkt. Controleer certificaten voor zowel het hoofddomein als www wanneer beide bereikbaar zijn en bepaal welke variant de canonical wordt.

Verander alleen de webrecords die nodig zijn. Mailrecords zoals MX, SPF, DKIM en DMARC staan los van de website en moeten tijdens een normale webmigratie meestal blijven staan. Een onnodige DNS-schoonmaak tijdens dezelfde cutover vergroot het risico dat e-mail tegelijk stukgaat.

Leg oude DNS-waarden vooraf vast zodat terugrollen mogelijk blijft. Verwijder de oude website niet direct; houd die tijdens de eerste controleperiode beschikbaar als snelle fallback.

Zoekmachines hebben tijd nodig om redirects te verwerken en nieuwe URL’s opnieuw te crawlen. Posities en zichtbaarheid kunnen daardoor tijdelijk bewegen, ook als de technische migratie goed is uitgevoerd.

Let vooral op patronen: verdwijnen belangrijke pagina’s uit de index zonder nieuwe equivalenten, ontstaan er massaal soft 404’s, kiest Google onverwachte canonicals of blijven crawlers oude URL’s bezoeken zonder goede redirect? Dat zijn signalen om in te grijpen.

Een migratie is daarom geen eenmalige knop. De technische cutover is het begin van een korte controlefase waarin Search Console, serverstatussen en belangrijkste zoekpagina’s extra aandacht krijgen.