Blog
Het risico zit in je adressen, niet je techniek.
Hoe je een migratie uitvoert zonder rankings te verliezen, met aandacht voor redirects, markup en laadtijden.
Het grootste risico bij een migratie zit in je adressen, niet in je techniek.
Een nieuw CMS, andere hosting of een nieuw thema kost je op zich geen posities, zolang je adressen, je markup en je laadtijden meeverhuizen.
Dat gebeurt pas wanneer een pagina die jaren op hetzelfde adres stond plots elders staat, zonder dat iemand die twee verbindt.
Dat laatste is handwerk en het enige deel van een migratie dat je niet achteraf herstelt.
Voor veel Drupal-sites is dat nu aan de orde.
Drupal 10 bereikt end of life op 9 december 2026 en 10.6.0 is de laatste minor release, Drupal 7 is uit support sinds 5 januari 2025 en Drupal 12 verschijnt in de week van 7 december 2026.
Wie deze winter verhuist doet dat onder tijdsdruk en dan sneuvelt het redirectplan als eerste.
De URL-inventaris komt voor alles
Je begint met een lijst van elk adres dat vandaag bestaat, niet met de pagina's die je wil behouden.
De adressen die verkeer opleveren zijn zelden die uit je menu: een persbericht uit 2019 met twintig inkomende links weegt zwaarder dan je nieuwe dienstenpagina.
Vijf bronnen samen geven een volledig beeld.
| Bron | Wat het oplevert |
|---|---|
| XML-sitemap | Wat je site denkt te publiceren, meestal alleen de gewenste pagina's |
| Volledige crawl | Alles wat intern gelinkt wordt, ook paginering, facetten, feeds en PDF's |
| Search Console, rapporten Pagina's en Prestaties | Wat Google echt kent (rapport Pagina's, circa drie maanden historiek) en welke adressen klikken opleveren (rapport Prestaties, zestien maanden terug) |
| Serverlogs | Adressen die nog opgevraagd worden maar nergens meer gelinkt staan |
| Backlinkdata | Externe links naar pagina's die je zelf vergeten was |
Per adres leg je statuscode, canonical, indexeerbaarheid, inkomende links en het verkeer van twaalf maanden vast.
Vergeet de niet-HTML-adressen niet: afbeeldingen, PDF's, feeds en taalvarianten hebben er ook een.
Exporteer je indexeringsdata zelf voor de migratie, want die historiek is er later niet meer.
Deze lijst is je nulmeting.
Het redirectplan: een 301 per oud adres
Elk oud adres krijgt precies één 301 naar het meest gelijkende nieuwe adres.
Een 301 zegt tegen zoekmachines en AI-crawlers dat de verhuizing permanent is en dat de opgebouwde signalen mee moeten.
Een 302 zegt dat het tijdelijk is: Google volgt die wel, maar gebruikt hem niet als signaal dat het nieuwe adres het canonieke moet worden, dus voorlopig blijft het oude adres het canonieke.
Staat die 302 lang genoeg, dan behandelt Google ze meestal alsnog als permanent, maar dat kost weken die je met een 301 niet verliest.
De mapping is een tabel met drie kolommen: oud adres, nieuw adres en waarom.
Die derde kolom lijkt overbodig tot iemand later vraagt waarom drie pagina's in één zijn samengevoegd.
Bestaat er geen redelijk equivalent, dan is een 410 eerlijker dan een redirect naar iets wat de bezoeker niet zocht.
In Drupal handelt de Redirect-module dit af en met de Migrate API neem je bestaande path-aliassen mee.
Bij grote aantallen horen de regels op webserver- of CDN-niveau, buiten PHP.
Wat je niet doet
Vier fouten doen de meeste schade en alle vier zijn gratis te vermijden.
- Alles naar de homepage redirecten. Google behandelt zo'n massaredirect als een soft 404, dus je verliest net de signalen die je dacht te bewaren.
- Redirectketens bouwen. Elke hop kost tijd en op een bepaald punt stopt de keten gewoon.
Houd het op één hop en werk je interne links bij naar de eindbestemming. - De testomgeving meeverhuizen. Een robots.txt die alles blokkeert, een noindex in de meta tags of een canonical naar je staging-domein: de drie klassieke oorzaken van een site die na livegang uit de index valt.
- Redirects pas na livegang bedenken. Dan mis je net de adressen waarvan je het bestaan niet kende, want die staan niet in het nieuwe CMS.
Controleren na livegang: statuscodes, canonicals, sitemap, structured data
Op de dag van livegang controleer je vier zaken.
Crawl je volledige oude adreslijst en kijk of elk adres met één hop op een 200 uitkomt.
Controleer of elke canonical naar zichzelf wijst, op het juiste domein en protocol.
De sitemap bevat alleen adressen die 200 teruggeven, geen redirects en geen noindex en je robots.txt verwijst naar het juiste bestand.
Structured data is de vierde en wordt het vaakst overgeslagen.
Je schema.org-markup zit in je thema of in je Metatag-configuratie, dus bij een nieuw thema is die markup nieuw en ongetest.
Let op de eigenschappen die zelf een adres bevatten: @id, url, logo en sameAs wijzen na een verhuizing verrassend vaak nog naar het oude domein.
Valideer je belangrijkste paginatypes met de Rich Results Test en de Schema Markup Validator.
AI-zichtbaarheid vraagt hetzelfde werk, maar strenger
AI-assistenten lezen dezelfde pagina's als Google, alleen krijg je er geen tweede kans.
Op de meeste informatieve zoektermen in mijn vakgebied zie ik een AI Overview boven de gewone resultaten.
Een foute verwijzing kost je daar geen positie, maar de vermelding.
Drie dingen controleer je apart.
Je schema.org-markup moet op adresniveau kloppen, inclusief de sameAs-verwijzingen naar externe profielen.
Een llms.txt is een lijst adressen, dus na een migratie per definitie verouderd.
En kijk na of je robots.txt de AI-crawlers nog toelaat, want dat is net de regel die onbedoeld verandert.
Over llms.txt hoor je eerlijk te zijn: het is een voorstel, geen norm en niemand is verplicht het te lezen.
Ik houd het bij omdat het een halfuur werk is.
Wat je meet om te weten of het goed ging
Vier metingen vertellen je of de migratie geslaagd is en geen van de vier geeft antwoord op dag één.
| Wat | Waar | Wanneer |
|---|---|---|
| Statuscodes van de oude adreslijst | Crawler | Dag 1, dag 7, dag 30 |
| Aantal geïndexeerde pagina's | Search Console, rapport Pagina's | Wekelijks, acht weken lang |
| Klikken en impressies per adres | Search Console, rapport Prestaties | Per URL, tegen dezelfde periode vorig jaar |
| LCP, INP en CLS | Search Console, Core Web Vitals | Pas na een maand, de velddata loopt op 28 dagen |
Reken op een tijdelijke daling, ook bij een nette migratie: zoekmachines moeten elk oud adres opnieuw opvragen, de redirect volgen en het nieuwe adres herwaarderen.
Niet normaal is een daling die na acht weken niet hersteld is.
Laat je redirects minstens een jaar staan en eigenlijk permanent.
Wanneer dit werk grotendeels wegvalt
Verandert je URL-structuur niet, dan verdwijnt het grootste deel van dit artikel uit je project.
Een upgrade van Drupal 10 naar Drupal 11 binnen dezelfde site behoudt je node-ids en path-aliassen, dus er is niets om te herverbinden.
Een crawl vooraf en achteraf is dan genoeg.
Het onderscheid tussen een upgrade en een echte migratie bepaalt of dit een namiddag of weken werk is.
Bij een platformwissel zoals een verhuizing van WordPress naar Drupal verandert vrijwel elk pad wel en dan geldt dit artikel van de eerste tot de laatste stap.
Hoe ik een migratie aanpak
Ik maak de inventaris en het redirectplan voor de eerste regel migratiecode en lever ze op als een bestand dat je zelf kunt nakijken.
Daarna volgen de techniek, de controle op livegang en de metingen erna.
Meer daarover op Drupal migratie en upgrade en technische SEO en frontend performance.
Mijn tarief is 75 tot 95 euro per uur of 650 tot 800 euro per dag, exclusief btw, lager bij lange trajecten en terugkerende klanten.
Wat een migratie kost hangt vooral af van je aantal adressen en je custom code, niet van je Drupal-versie.
Draait er nog een Drupal 7-site, begin daar. Leg je situatie voor en ik geef binnen 24 uur een eerlijk beeld van wat er nodig is.
Veelgestelde vragen
Hoe kopieer je een website?
Kopiëren en migreren zijn twee verschillende dingen.
Een kopie is een volledige export van bestanden en database, om op een tweede omgeving te testen.
Een migratie zet inhoud over naar een nieuwe structuur en dan veranderen je adressen meestal wel.
Zet een kopie nooit op een indexeerbare omgeving, want een tweede vindbare versie is schadelijker dan geen.
Kan ik een website maken met een bestaande domeinnaam?
Ja en dat is de aangewezen weg.
Je domein draagt je vindbaarheid, dus een nieuwe site op je bestaande domein start niet bij nul.
Wat je wel regelt zijn de adressen eronder: elk oud pad krijgt een 301 naar zijn nieuwe pad.
Bij een ander domein komt een adreswijziging in Search Console bij.
Wat doe ik met een oude pagina die geen nieuw equivalent heeft?
Dan is een 410 eerlijker dan een 301 naar iets wat de bezoeker niet zocht.
Alles naar de homepage sturen is de slechtste optie, want Google behandelt zo'n massaredirect als een soft 404 en dan verlies je net de signalen die je dacht te bewaren.
Noteer in je mapping waarom je voor een 410 koos, zodat je die afweging later niet opnieuw hoeft te maken.
Hoe lang moet ik mijn 301-redirects laten staan?
Minstens een jaar en er is geen goede reden om ze daarna te verwijderen.
Zoekmachines hebben tijd nodig om elk oud adres opnieuw op te vragen en externe links naar oude adressen blijven vaak jarenlang bestaan.
Wat je wel opruimt zijn ketens, want na een tweede migratie moeten die platgeslagen worden naar één hop.
Verlies ik altijd bezoekers bij een migratie?
Tijdelijk meestal wel, structureel niet als het redirectplan klopt.
Zoekmachines moeten elk oud adres opnieuw opvragen, de 301 volgen en het nieuwe adres herwaarderen en dat duurt weken.
Een daling die na acht weken nog staat komt bijna altijd van ontbrekende redirects, een noindex uit de testomgeving of een verkeerde canonical.
Hoe controleer ik na livegang of mijn redirects kloppen?
Crawl je volledige oude adreslijst en kijk of elk adres met één hop op een 200 uitkomt, niet met twee of drie.
Diezelfde crawl herhaal je op dag 7 en dag 30.
Controleer daarnaast of elke canonical naar zichzelf wijst op het juiste domein en protocol en of je sitemap alleen adressen bevat die 200 teruggeven.
Een vraag over dit onderwerp?
Beschrijf kort je situatie, dan laat ik weten wat er speelt en wat het zou kosten. Zonder offertetraject.
