De meest gemaakte fouten bij een website-migratie

Belangrijkste conclusies

• De meeste schade bij een migratie ontstaat niet door de nieuwe website zelf, maar door wat er onderweg wordt vergeten: redirects, certificaten, DNS-instellingen en trackingdata.
• Elk van deze fouten is op zichzelf makkelijk te vermijden, maar ze worden zelden structureel gecontroleerd omdat ze "onzichtbaar" zijn tot het te laat is.
• Een vaste controlelijst vóór livegang voorkomt het grootste deel van de schade.

Een migratie mislukt zelden omdat de nieuwe website slecht is. Ze mislukt omdat er ergens tussen "de oude site uit" en "de nieuwe site aan" iets over het hoofd is gezien. Hieronder staan de fouten die we bij Waligoo het vaakst tegenkomen wanneer we een migratie overnemen of achteraf herstellen, en wat er in de praktijk aan te doen is.

Fout 1: redirects vergeten of onvolledig maken

De meest voorkomende en meest kostbare fout is een onvolledige redirect-map. Bedrijven redirecten vaak alleen de pagina's die ze zelf nog kennen, en vergeten de oudere URL's die nog ergens in Google's index staan, in oude backlinks worden gebruikt, of in e-mails en offline materiaal circuleren.

Het gevolg: bezoekers en zoekmachines botsen op een 404, en de opgebouwde autoriteit van die pagina verdwijnt in het niets. Voorkom dit door vóór de migratie een volledige lijst te maken van alle bestaande URL's, niet alleen de pagina's die je in de navigatie ziet. Gebruik daarvoor je Search Console-data, je huidige sitemap én een crawl van de live site, en koppel elke URL één-op-één aan de meest relevante nieuwe bestemming. Een redirect naar de homepage is een noodoplossing, geen strategie.

Fout 2: SSL-mismatch na de overstap

Bij een hosting- of domeinwissel gaat het geregeld mis met het SSL-certificaat. Het certificaat is bijvoorbeeld nog gekoppeld aan de oude server, dekt het nieuwe subdomein niet, of wordt simpelweg vergeten te vernieuwen tijdens de overgang. Het resultaat is een browserwaarschuwing die bezoekers meteen wegjaagt, en een website die door Google als onveilig wordt gemarkeerd.

Controleer voor livegang expliciet of het certificaat geldig is voor élke variant van je domein (met en zonder www, http én https), en test dit niet alleen vanaf je eigen kantoor, maar ook via een externe check, omdat lokale DNS-caches een verkeerd beeld kunnen geven.

Fout 3: DNS-timing verkeerd inschatten

DNS-wijzigingen verspreiden zich niet direct. Afhankelijk van de TTL-instelling (time to live) van je huidige DNS-records kan het uren tot dagen duren voordat alle bezoekers en zoekmachines de nieuwe server zien. Wie de DNS pas op het laatste moment omzet, of de TTL niet vooraf verlaagt, loopt het risico dat een deel van het verkeer tijdelijk op een kapotte of verouderde versie van de site belandt.

De oplossing is simpel maar wordt vaak overgeslagen: verlaag de TTL van je DNS-records enkele dagen vóór de migratie, zodat wijzigingen sneller doorkomen. Plan de daadwerkelijke omzetting bovendien nooit vlak voor een weekend, zodat er tijd is om bij te sturen als er iets misgaat.

Fout 4: analytics-historiek kwijtraken

Een nieuwe website betekent voor veel bedrijven ook een nieuw CMS, en soms een nieuwe implementatie van Google Analytics of Tag Manager. Als die overstap niet zorgvuldig gebeurt, raak je niet je historische data kwijt (die blijft in principe bewaard in je bestaande property), maar wel de continuïteit van je meting: conversiedoelen die niet meer werken, events die niet meer vuren, of een volledig nieuwe property zonder koppeling aan de oude.

Zorg dat alle bestaande doelen, events en koppelingen (zoals Google Ads en Search Console) vóór livegang zijn gecontroleerd en opnieuw ingesteld in de nieuwe omgeving, en test ze met een testtransactie voordat je live gaat.

Fout 5: de oude noindex-tag mee migreren

Tijdens de bouwfase staat een testomgeving vaak terecht op noindex, zodat Google de onafgewerkte versie niet oppikt. De fout die daarna vaak volgt: die instelling wordt bij de livegang niet verwijderd, waardoor de gloednieuwe, volledig werkende website onzichtbaar blijft voor zoekmachines. Dit is een van de meest genante fouten omdat alles er normaal uitziet, behalve dat er geen enkele pagina meer geïndexeerd wordt. Controleer dit expliciet in de robots-meta-tag en in robots.txt vlak na livegang.

Snelle controlelijst voor je volgende migratie

• Volledige redirect-map op basis van Search Console, sitemap én live crawl.
• SSL-certificaat gecontroleerd voor alle domeinvarianten.
• DNS TTL tijdig verlaagd, migratie niet gepland vlak voor een weekend.
• Analytics, Tag Manager en conversiedoelen getest vóór livegang.
• Noindex-tags en teststatus verwijderd na livegang, gecontroleerd in robots.txt.

Deze vijf punten dekken niet alles, maar wel het grootste deel van de schade die we in de praktijk zien. Wil je weten hoe je vooraf de juiste aanpak kiest voor jouw situatie, of het nu om een hostingwissel, een domeinwissel of een volledige herbouw gaat? Lees dan onze gids over hoe je de juiste migratie-aanpak kiest, waarin we dieper ingaan op de verschillende soorten migraties en wanneer je welke aanpak kiest.

Sta je op het punt om live te gaan? Werk de bovenstaande punten dan af met onze website launch checklist voordat je op de knop drukt.

Migreren zonder gedoe

Een migratie zonder verlies is geen kwestie van geluk, maar van een vaste, herhaalbare aanpak. Bij Waligoo bouwen en begeleiden we migraties op deze manier, met een sluitende redirect-strategie, technische controles en monitoring na livegang. Meer weten over hoe wij dat aanpakken voor jouw webontwikkelingsproject?