Hoe je een website migratie plant zonder verkeer te verliezen

Een website migratie is elk project dat een site naar een nieuw adres, een nieuw platform of een nieuwe structuur verhuist: een wissel van CMS, een wissel van domeinnaam, de overstap van HTTP naar HTTPS, of een redesign dat elke URL hernoemt. Het gaat hier over het verhuizen van een website, niet over migratierecht of verblijfsvergunningen, waar zoekmachines bij het losse woord vaak op uitkomen.

De inhoud overleeft de verhuizing. De adressen waar Google, andere websites en je eigen mailings naar wijzen, vaak niet. In dat gat ontstaat de schade. Volgens Google Search Central moeten de redirects bij een verhuizing met URL-wijzigingen minstens een jaar blijven staan, en schuiven posities zolang de wijziging verwerkt wordt. Alles wat in dat venster wordt overgeslagen kost verkeer waarvoor je al betaald hebt: één URL zonder bestemming, één robots.txt uit de testomgeving, één meet-tag die nooit in de nieuwe templates terechtkwam.

Deze gids is geschreven voor wie het project goedkeurt, niet voor wie de deploy draait. Hij behandelt de vier soorten migratie en hun risico, de inventarisatie vooraf, het redirectplan, de tests voor de livegang, het stappenplan op de dag zelf, de eerste 30 dagen en wat er in het contract hoort.

Migratie is één woord voor vier verschillende projecten, en ze dragen niet hetzelfde risico. De eerste vraag is dus wat er echt verandert: waar de bestanden vandaan komen, het systeem dat de pagina's maakt, de domeinnaam in de adresbalk, of de URL-paden zelf. Een platformwissel met ongewijzigde URL's is een rustig weekend. Een domeinwissel die daarbovenop elke pagina hernoemt, eindigt in een evaluatierapport.

In de praktijk is bijna elk project een mengvorm. Een bedrijf vervangt een verouderd CMS, marketing vraagt bij die gelegenheid om een andere navigatie, en juridische zaken wil van het landendomein af. Drie migraties worden tot één livegang gebundeld, en als het verkeer daalt kan niemand zeggen welke van de drie de oorzaak was.

Als je één beslissing uit deze gids meeneemt, neem dan deze: verander één variabele tegelijk zolang de planning dat toelaat. Eerst het platform verhuizen met de URL's ongemoeid, controleren of de cijfers standhielden, daarna de structuur in een tweede release hernoemen. Dat kost één extra deploy en levert je een antwoord op wanneer er iets misgaat.

Verkeer verdwijnt niet omdat een site verhuisd is. Het verdwijnt omdat een handvol verbindingen brak en niemand keek. In de praktijk herhalen zich vijf fouten bij projecten van elke omvang, en vier daarvan vindt een crawl van één middag.

URL's zonder bestemming. Elk oud adres dat 404 teruggeeft verliest zijn posities, zijn links en het campagneverkeer dat het droeg. De oplossing is weinig spannend: één regel per oude URL in een koppelbestand, nagelopen door een mens.

Redirects die op één pagina samenkomen. Een bulkregel die 400 uitgefaseerde productpagina's naar de homepage stuurt, vermijdt op papier de 404's en vernietigt tegelijk de relevantie. Google behandelt een redirect naar een niet-passende pagina ongeveer als een soft 404.

Ketens en lussen. Oude URL naar tussen-URL naar eind-URL verbrandt crawlbudget en vertraagt elke bezoeker die via een oude link binnenkomt. Eén sprong is het doel, en ketens controleer je voor de livegang, niet erna.

Blokkades uit de testomgeving. Testomgevingen staan met opzet dicht voor crawlers. De regel Disallow: / en de noindex-tag zijn de twee onderdelen die nooit in productie mogen belanden, en ze veroorzaken de zwaarste dalingen.

Interne links die nog naar de oude boom wijzen. Menu's, footers, links in de tekst en XML-sitemaps met oude paden dwingen elke crawler door de redirectlaag en verdunnen de interne linkstructuur die je jarenlang hebt opgebouwd.

Een migratie is haar risico waard als de huidige opzet iets blokkeert dat het bedrijf nodig heeft, niet als de site gedateerd oogt. Drie aanleidingen dragen het project alleen al: het platform kan niet meer aan wat je vandaag verkoopt, draaiend houden kost meer dan vervangen, of een juridische of merkwijziging dwingt het adres te verhuizen.

Het platformargument komt bijna altijd te laat. In de praktijk herken je het zo: een nieuw paginatype vraagt een developer in plaats van een redacteur, elke koppeling hangt aan een plug-in die bij de volgende update breekt, de laadtijd zakt in onder campagneverkeer, en een tweede taal wordt een tweede website. Dat zijn de symptomen van een site die zijn fundament ontgroeid is, en geen ontwerpbudget repareert ze.

Het kostenargument is wel te berekenen. Tel licenties, plug-inabonnementen, hosting en de uren die je team kwijt is aan omwegen bij elkaar op. Zet daar een herbouw tegenover, verdeeld over drie jaar. Zodra de som van de omwegen groter is, heeft de beslissing zichzelf genomen.

Er bestaan ook slechte redenen, en die zijn duur: een nieuwe marketingmanager met voorkeur voor een andere stack, een bureau dat maar één systeem bouwt, of een ontwerpwens die als template-update op het huidige systeem kan. Verandert alleen het uiterlijk, dan wil je een redesign, en de voorbereiding van een redesign is de kortere en goedkopere route.

Afbakenen is hier inventariseren, en dat gebeurt voor het ontwerp, voor de bouw en voor de platformkeuze. Je beantwoordt één vraag: wat bestaat er vandaag, en wat is elk onderdeel waard? Wie de inventarisatie overslaat, laat het projectteam per ongeluk beslissen, meestal door te migreren wat makkelijk exporteerde.

Begin met vier exports. Een volledige crawl van de live site geeft elke URL met statuscode, titel en canonical. Search Console geeft elke pagina die in twaalf maanden vertoningen kreeg. De statistieken geven instappagina's en conversies per pagina. Een backlinkexport geeft de pagina's waar andere sites naar wijzen, en precies die mogen nooit 404 worden.

Leg de vier lijsten naast elkaar in één blad en markeer elke URL met een besluit: houden, samenvoegen, hernoemen of uitfaseren. Een pagina zonder verkeer, zonder positie en zonder links mag weg. Een pagina met twee backlinks en nul verkeer heeft alsnog een bestemming nodig. Dit blad is tegelijk het redirectplan, het contentplan en de opleverlijst.

Dezelfde ronde beantwoordt de vragen die projecten laat verrassen: hoeveel formulieren er zijn en waar de inzendingen heen gaan, welke systemen in de site schrijven, hoeveel talen er bediend worden, welke pagina's juridische teksten dragen, en wie de DNS-records beheert.

Het redirectplan is een tabel met één regel per oude URL en precies één bestemming per regel. Het is het document dat je bij naam opvraagt, voor de livegang naloopt en na afloop van het project bewaart. Kan een bureau er geen tonen, dan wordt de migratie op gevoel gedaan.

Drie regels houden het eerlijk. Elke bestemming moet de inhoudelijk dichtstbijzijnde pagina zijn, geen categorie en niet de homepage. Elke redirect is permanent, een 301, zodat zoekmachines de oude signalen doorgeven. En elke oude URL zonder equivalent geeft 410, wat crawlers vertelt dat de pagina bewust weg is in plaats van een verhuizing voor te wenden.

Loop het zelf na, in een spreadsheet, op de regels die tellen: je 50 drukste pagina's, je 50 meest gelinkte pagina's en elke pagina die voorkomt in een lopende campagne of een e-mailhandtekening. Dat is een uur van jouw tijd tegenover de prijs van dezelfde fout drie maanden later in je statistieken vinden.

Zichtbaarheid in zoekmachines krijgt de aandacht omdat die in het openbaar meetbaar is. De storingen die meer geld kosten blijven meestal wekenlang onzichtbaar: een contactformulier dat het niets in stuurt, een consentbanner die alle meting blokkeert, of transactionele e-mail die niet meer aankomt omdat de DNS-records met de hosting meeverhuisden.

Consent verdient een eigen regel. Een nieuwe site betekent een nieuwe cookiebanner, en volgens de AVG samen met de cookiebepaling in de Telecommunicatiewet mogen niet-noodzakelijke cookies pas na toestemming worden geplaatst. Teams die de meting onder tijdsdruk opnieuw opbouwen, leveren vaak een banner die of alles blokkeert, waardoor de rapportage op een verkeersinstorting lijkt, of niets blokkeert, wat dan geen rapportageprobleem meer is.

De tabel hieronder is de korte versie van het overdrachtsgesprek. Elke regel heeft een eigenaar nodig en een test op de testomgeving, niet de belofte het na de livegang na te kijken.

Testen voor de livegang is vergelijken, geen mening geven. Je crawlt de testomgeving met hetzelfde gereedschap dat je op de live site gebruikte en legt beide bestanden naast elkaar. Alles wat in de oude crawl staat en in de nieuwe ontbreekt, is of een bewuste uitfasering met 410 of een defect, en een derde optie bestaat niet.

Vijf controles vangen het meeste af. Aantal pagina's en titels tussen oud en nieuw vergelijken. Controleren dat elke canonical naar het productiedomein wijst en niet naar de testomgeving. Controleren dat hreflang wederkerig is, want Google vraagt dat elke taalversie alle andere en zichzelf noemt. Controleren dat er geen noindex blijft staan op pagina's die geïndexeerd moeten worden. En het redirectplan als batch doorlopen: de oude URL's aan de crawler geven en bevestigen dat elke met precies één 301 naar een levende pagina antwoordt.

Snelheid hoort in dezelfde ronde. Core Web Vitals worden beoordeeld op het 75e percentiel van echte paginaweergaven, dus een template kan op jouw laptop prima ogen en in het veld toch zakken. Meet de nieuwe templates tegen de drempels op web.dev en behandel achteruitgang als blokkerend, niet als optimalisatie voor later. Onze aantekeningen over laadtijd beschrijven wat je eerst aanpakt als de nieuwe site trager start dan zijn voorganger.

Toegankelijkheid hoort sinds 2025 in hetzelfde gesprek. De richtlijn (EU) 2019/882 geldt sinds 28 juni 2025, en een herbouwde of ingrijpend gewijzigde dienst telt als nieuw, niet als bestaand. Verkoop je aan consumenten, dan is de migratie het moment om toegankelijkheid in te bouwen, niet om die door te schuiven.

De livegang mislukt vaker op volgorde dan op code. Het stappenplan hieronder gaat ervan uit dat de nieuwe site op de testomgeving is goedgekeurd en het redirectplan als batch is geverifieerd, zodat de dag zelf mechanisch verloopt.

1. Contentbewerkingen op de oude site bevriezen, met een aangekondigd starttijdstip voor het team.
2. Een laatste crawl van de live site draaien. Dat is de laatste momentopname om mee te vergelijken.
3. De DNS-TTL 48 uur vooraf verlagen zodat de omschakeling in minuten doorwerkt in plaats van in een dag.
4. De nieuwe site uitrollen, nog gesloten voor crawlers, en de kritieke paden doorlopen.
5. De blokkades weghalen: eerst robots.txt, daarna alle noindex-tags in de templates.
6. De redirects aanzetten en 20 URL's met de hand testen, gekozen op verkeer en op links.
7. De nieuwe XML-sitemap publiceren en in Search Console indienen.
8. Bevestigen dat meting, consent en formulieren in productie registreren, niet alleen op de test.
9. De serverlogs de rest van de dag op 404's volgen en oplossen wat opduikt.

Houd de oude omgeving na de omschakeling nog even bereikbaar. Niet live, maar herstelbaar. Een terugvalplan dat alleen als zin in een offerte bestaat, is geen terugvalplan.

De eerste maand bepaalt of de migratie een project was of een incident. Zoekmachines hebben tijd nodig om de nieuwe adressen opnieuw te crawlen en te verwerken, dus een dip in de eerste twee weken is normaal en een dip die in week vier dieper wordt niet. Volg paginagroepen in plaats van het sitetotaal, want een gemiddelde verbergt precies de sectie die brak.

Leg het ritme vast voor de livegang: dagelijks in de eerste week, tweemaal in de tweede, daarna wekelijks. Geef één persoon de taak erover te rapporteren. Migraties mislukken zelden luid, ze mislukken als een trage daling waarvan iedereen aanneemt dat een ander erop let.

De kosten volgen het soort verhuizing, niet het aantal pagina's. Hosting verplaatsen is een werkdag. Van platform wisselen met behoud van URL's is de templates herbouwen plus een data-export. Van domein wisselen en alle URL's hernoemen legt de koppeling, de tests en het bewakingsvenster daar bovenop.

Gepubliceerde prijzen geven houvast. Onze eigen prijzen beginnen bij €1.500 voor een landingspagina met een levertijd van twee tot drie dagen, €4.500 voor een bedrijfswebsite van 10 tot 30 pagina's met een levertijd van één tot drie weken, en €9.000 voor een portaal vanaf 50 pagina's met één tot drie maanden. Het verhuizen van een bestaande site van gelijke omvang valt in dezelfde marge, met de koppeling en de verificatie erbovenop, omdat de herbouw dezelfde is en de inventarisatie extra is. Cijfers geldig in augustus 2026.

Wat verrast is zelden de bouw, maar zijn de twee uiteinden. Inventarisatie en koppeling kosten op een middelgrote site één tot drie weken doorlooptijd, omdat ze input vragen van marketing, sales en juridische zaken en niet meer developeruren. Het bewakingsvenster na de livegang duurt vier tot acht weken en hoort als betaald werk in het contract, niet als coulance.

Begroot apart wat standaard vergeten wordt: de consentopzet opnieuw bouwen, elk formulier en elke koppeling opnieuw testen, campagne-URL's in advertentie- en mailtools bijwerken, en de interne links in oude artikelen herstellen die naar hernoemde pagina's wijzen.

Een migratiecontract dat alleen belooft dat de nieuwe site op de ontwerpen lijkt, laat alles weg wat mis kan gaan. Opleverpunten horen controleerbaar te zijn door iemand die niet programmeert, dus geschreven als checks met een uitkomst geslaagd of niet geslaagd.

Vraag deze zeven punten schriftelijk. Een redirectplan over alle URL's die in twaalf maanden verkeer of een backlink hadden, ter controle geleverd vóór de livegang. De bevestiging dat oude URL's met precies één 301 naar een passende pagina antwoorden en dat uitgefaseerde pagina's 410 geven. Behoud van titels, omschrijvingen, canonicals en hreflang, of een gedocumenteerde reden waar ze wijzigen. Een testplan voor de meting met elke gebeurtenis, doel en formulier dat op de dag zelf moet werken. Een uitspraak over de toegankelijkheidsverplichtingen uit de Europese richtlijn waar de site eronder valt. In het veld gemeten snelheidsdoelen voor de belangrijkste templates. En een benoemd bewakingsvenster van vier tot acht weken, met reactietijden voor de gebreken die daarin gevonden worden.

Voeg één clausule toe die niets kost en ruzie voorkomt: het redirectplan, de crawlexports en het meetplan worden bij afronding als bestanden overgedragen. Dat zijn jouw documenten. Het volgende bureau vraagt erom, en jij ook.

Dit is de korte versie van alles hierboven, in de volgorde waarin het werk gebeurt. Neem hem over in je projecttool en geef elke regel een eigenaar en een datum.

Voor de bouw

• De live site crawlen en elke URL met status, titel en canonical exporteren.
• Twaalf maanden Search Console, instappagina's uit de statistieken en verwijzende domeinen exporteren.
• Elke URL markeren: houden, samenvoegen, hernoemen of uitfaseren.
• Formulieren, koppelingen, meet-tags, feeds en juridische pagina's met eigenaren op een lijst zetten.
• Beslissen of platform, structuur en domein in één release wisselen of in meerdere.

Voor de livegang

• Redirectplan met de hand nagelopen op de 50 drukste en de 50 meest gelinkte pagina's.
• Testomgeving gecrawld en vergeleken met het live paginabestand.
• Canonicals wijzen naar productie, hreflang is wederkerig, geen verdwaalde noindex.
• Formulieren, consentroutes en meetgebeurtenissen op de testomgeving getest.
• Core Web Vitals op de nieuwe templates gemeten, achteruitgang is blokkerend.
• Terugvalplan op papier, DNS-TTL verlaagd.

Livegang en daarna

• Blokkade weg, redirects actief, sitemap ingediend.
• Twintig redirects met de hand getest, serverlogs op 404's gevolgd.
• Bestemmings-URL's van advertenties en mailings omgezet naar de nieuwe adressen.
• Bewakingsritme afgesproken: een week dagelijks, daarna een maand wekelijks.
• Redirects minstens een jaar actief houden en het plan bij de projectdocumenten archiveren.

Dit geval kunnen we van binnenuit beschrijven, want het is onze eigen site. Vezert draait in het Engels, Duits, Spaans, Frans en Nederlands, en elke taal heeft een eigen slug in de URL in plaats van een vertaalde pagina onder een Engels adres. Bij elke slugwijziging krijgt het oude adres een permanente redirect, en het bestand dat ze verzamelt bevat er op dit moment 329.

Twee besluiten deden het werk. Elk artikel draagt een vaste identificatie die nooit verandert, zodat hreflang uit die identificatie wordt opgebouwd en niet uit een bestandsnaam: een pagina hernoemen in één taal kan de verbinding met de andere vier daardoor niet verbreken. En de slugwijziging levert haar redirect automatisch op, binnen hetzelfde script dat het bestand hernoemt, waarmee de stap vervalt die mensen vergeten.

De les geldt voor elke migratie: de redirect is onderdeel van het hernoemen, geen taak die erna komt. Staan die twee los, dan hernoemt iemand op een vrijdag een pagina en komt de redirect maandag, als hij komt. Voeg je bij de verhuizing ook talen toe, dan behandelt onze gids over meertalige websites de URL-keuzes die later moeilijk terug te draaien zijn, en behandelt de websitestructuur de paginaboom waar het redirectplan op moet aansluiten.