Website migratie: het stappenplan zonder verlies van bezoekers

Een website migratie gaat zelden mis tijdens de bouw. Het gaat mis op de dag dat de nieuwe site live staat en Google je oude adressen niet meer vindt. Dan zakt je verkeer, komen er minder aanvragen binnen en weet niemand waarom. Dit stappenplan helpt je dat te voorkomen. Tien stappen, verdeeld over de weken voor de livegang, de dag zelf en de weken erna.

Ik schrijf het ook niet alleen als bouwer. We verhuisden in 2026 namelijk onze eigen site, yourtechclub.nl, van WordPress naar een maatwerk-site in Next.js, met redirects voor de oude adressen. En ook bij ons vond een controle weken na de livegang nog oude adressen die op een 404 uitkwamen. Wat we daarvan leerden, staat verderop.

Wat is een website migratie?

Een website migratie is elke grote verandering waarbij de adressen, het platform of de plek van je website wijzigen. Denk aan een nieuw CMS, een nieuw domein, een nieuwe URL-structuur of een andere hosting. Hoe meer van die dingen tegelijk veranderen, hoe groter het risico dat je bezoekers en posities in Google verliest.

Een overstap van WordPress naar een maatwerk-site is bijvoorbeeld een platformmigratie. Daarbij veranderen de URL's bijna altijd een beetje, al is het maar een schuine streep aan het eind.

Wanneer is een migratie het risico waard?

Een migratie is het waard als de nieuwe site meer oplevert dan de tijdelijke onrust kost. Bijvoorbeeld omdat je redactie eindelijk zelf kan publiceren, omdat formulieren rechtstreeks in je CRM landen of omdat je oude platform niet meer veilig te houden is. Migreer je alleen voor een frisser uiterlijk, dan is een nieuw ontwerp op dezelfde basis vaak verstandiger.

Dat klinkt streng, maar een migratie kost altijd iets. Ook als alles goed gaat, schommelen je posities een paar weken. Zorg dus dat je weet waarvoor je dat doet.

Wat gaat er het vaakst mis bij een migratie website?

Het vaakst gaat het mis bij de redirects. Oude adressen wijzen nergens heen, of allemaal naar de homepage. Daarnaast zien we vergeten pdf's en afbeeldingen, formulieren die na de livegang niet meer mailen, tracking die ontbreekt en een testomgeving die per ongeluk op "niet indexeren" blijft staan.

Over die homepage-redirect is Google overigens duidelijk. Stuur je veel oude URL's naar één pagina die er niet bij past, zoals je nieuwe homepage, dan kan Google dat behandelen als een pagina die niet bestaat (Google Search Central, Site moves with URL changes, bijgewerkt augustus 2026). Je redirect telt dan dus niet, en je posities gaan verloren.

De andere fouten zijn minder bekend, maar net zo duur:

• Een pdf-brochure die in 2019 in een nieuwsbrief stond, en nog steeds verkeer trekt.
• Een contactformulier dat in de testomgeving naar de developer mailde, en dat na de livegang nog steeds doet.
• Een analytics-code die niet is meegenomen, waardoor je twee weken blind vliegt.

Een veelvoorkomend scenario: honderden oude blogartikelen gaan in één keer naar de homepage, omdat dat sneller is dan een redirectlijst maken. In Search Console zie je daarna 'soft 404'-meldingen, en de posities van die artikelen zijn weg.

Wat doe je in de weken vóór de migratie?

Je maakt een volledige lijst van je oude URL's, legt vast hoe je site nu presteert en koppelt elke oude URL aan een nieuwe. Daarna bouw je de nieuwe site in een testomgeving die Google niet mag indexeren. Deze vijf stappen kosten de meeste tijd, en ze bepalen of de livegang rustig verloopt.

1. Inventariseer alle oude URL's. Haal ze uit je sitemap, je analytics, Google Search Console en je serverlogs. Vergeet afbeeldingen en pdf's niet.
2. Doe een nulmeting. Noteer je best bezochte pagina's, je posities op belangrijke zoekwoorden, het aantal aanvragen per maand en de laadtijd.
3. Maak een redirectlijst. Elke oude URL krijgt één nieuwe URL: de pagina die er inhoudelijk het meest op lijkt. Geen kettingen, geen verzamelpagina.
4. Verhuis de inhoud. Teksten, afbeeldingen, metatitels en alt-teksten gaan mee. Pagina's zonder bezoek en zonder waarde mag je schrappen, maar dan wel met een redirect.
5. Bouw en test in een afgeschermde omgeving. Zet de testomgeving op "niet indexeren", en schrijf op dat je dat later weer moet uitzetten.

Bij een overstap van WordPress naar maatwerk houden we de URL's daarom waar het kan gelijk. Want elke URL die niet verandert, is een redirect minder. Een kleine moeite die later veel scheelt.

Wat doe je op de dag van de livegang?

Op de dag zelf zet je de redirects live, haal je de blokkade voor zoekmachines weg en stuur je je nieuwe sitemap in bij Google Search Console. Daarna test je de formulieren, de tracking en een steekproef van oude URL's. Kies een rustige dag, nooit vrijdag, en zorg dat er iemand is die snel kan ingrijpen.

6. Zet de redirects live. Permanent, dus 301 of 308. Google adviseert die redirects zo lang mogelijk te laten staan, en in elk geval minstens een jaar.
7. Open de site voor zoekmachines. Haal "niet indexeren" weg, controleer je canonical-tags en stuur de nieuwe sitemap in.
8. Test wat geld oplevert. Verstuur elk formulier, controleer of de aanvraag in je CRM of mailbox aankomt, en kijk of je analytics meetelt.

Een tip die ik graag meegeef: test dan niet alleen je nieuwe pagina's, maar juist je oude adressen. Neem bijvoorbeeld twintig URL's uit je nulmeting en plak ze één voor één in je browser. Komt elke URL op de juiste pagina uit? Dan zit je goed.

Wat doe je in de weken na de migratie?

Je houdt Google Search Console en je verkeer een paar weken dagelijks in de gaten. Daar zie je 404-fouten, pagina's die uit de index vallen en dalingen per pagina. Herstel wat je vindt meteen. Pas je interne links en belangrijke externe links aan naar de nieuwe adressen, zodat bezoekers niet steeds via een redirect lopen.

9. Monitor vier tot acht weken. Vergelijk met je nulmeting: bezoek per pagina, posities en aanvragen. Kijk ook of je nog genoemd wordt in AI-antwoorden; hoe dat werkt, lees je bij vindbaar in AI-zoekmachines.
10. Ruim op, maar laat de redirects staan. Werk interne links bij en vraag partners met veel verkeer om hun link aan te passen. De redirects zelf laat je staan.

Hoe lang duurt het voordat Google alles opnieuw kent? Volgens Google kan het bij een middelgrote site een paar weken of langer duren voordat de nieuwe adressen gaan meetellen. Grotere sites duren langer. Schommelingen in die periode zijn daarom normaal. Een daling die na zes weken nog steeds groeit, is dat niet.

Wat leerden we van onze eigen website migratie?

Onze eigen site, yourtechclub.nl, ging in 2026 van WordPress naar een maatwerk-site in Next.js. Volgens de sitemap van de oude site, van 19 september 2026, had die 168 geïndexeerde URL's. Van 115 daarvan was er op de nieuwe site geen pagina meer. Elk van die adressen kreeg een redirect naar de pagina die er inhoudelijk het dichtst bij ligt. Blogs zonder opvolger gingen naar de dienst waar ze over gingen, dus niet blind naar de homepage.

De lijst was langer dan alleen pagina's en blogs. Er stonden ook pdf's in, oude categoriepagina's en de Engelse pagina's van de oude site. Ook die kregen een redirect.

Toch was het niet in één keer goed. Eind oktober 2026, weken na de livegang, liet een controle in Ahrefs nog drie oude adressen zien die op een 404 uitkwamen. Bovendien bleek dat bijna elk oud adres met een schuine streep aan het eind in twee sprongen bij het doel kwam: eerst ging de schuine streep eraf, pas daarna volgde onze redirect. Dat hebben we aangepast. Nu komt elk oud adres in één redirect op de nieuwe pagina uit, en we hebben alle regels getest, met en zonder schuine streep.

De les: test na de livegang opnieuw, met een externe tool en niet alleen met je eigen lijst. En vergeet de links die je team zelf gebruikt niet, zoals e-mailhandtekeningen, offertesjablonen en presentaties. Die lopen via de redirects, dus er gaat niets stuk. Pas ze daarna toch aan, want een redirect blijft een omweg.

Verder is een migratie een goed moment om op te ruimen. Niet elke oude pagina hoeft mee. Maar elke pagina die je schrapt, krijgt wel een redirect naar iets wat er inhoudelijk op lijkt.

Moet je migratie en vernieuwing tegelijk doen?

Een nieuw platform en een nieuw ontwerp gaan vaak samen, en dat is prima. Een nieuw domein erbij doen raad ik af. Hoe minder er tegelijk verandert, hoe makkelijker je ziet waar een daling vandaan komt. Wil je van naam veranderen, doe dat dan als aparte stap, een paar maanden later.

Bij een overstap van WordPress naar maatwerk is het logisch om meteen ook de site zelf te verbeteren. Je bouwt immers toch al een nieuwe basis. Vaak hoort daar een headless CMS bij; lees eerst wat een headless CMS is als dat nieuw voor je is. Neem de migratie dan wel vanaf dag één mee in het ontwerp. Zo deden we het bij de website van een leasemaatschappij: bestaande pagina's, URL-structuren en posities eerst in kaart, en een redirect waar een adres veranderde. Bij de WordPress-overstap krijg je zo een maatwerk-site met Next.js en Strapi, redirects voor elke oude URL en formulieren die rechtstreeks in je CRM landen. Lees meer bij je WordPress website vernieuwen.

Voor webshops gelden dezelfde regels. Bij twee overstappen van WooCommerce naar Shopify namen we producten, klantgegevens en de URL-structuur mee, bij één ervan alleen al meer dan honderd blogartikelen. Je leest erover in de case van WooCommerce naar Shopify en in de case over een Shopify Plus-webshop na een migratie. Twijfel je nog over het platform, lees dan Shopify of WooCommerce.

Wat ik níet zou doen: migreren omdat het contract met je hosting afloopt, zonder plan. Dan wordt de deadline van je hosting de deadline van je project. Neem liever eerst het onderhoud over, bijvoorbeeld via ons WordPress onderhoud, en plan de migratie daarna in rust.