SEO-migratie: van URL-mapping tot livegang zonder verlies

Een SEO-migratie is het verplaatsen van de adressen, content en signalen van een bestaande website naar een nieuwe structuur zonder de opgebouwde posities te verliezen. Het is in de eerste plaats inventarisatiewerk, en het hoort aan het begin van het project thuis en niet in de week vóór livegang.

Dit artikel gaat ervan uit dat het besluit tot vernieuwing al genomen is. Omvang, budget, doorlooptijd en de keuze van een bureau staan in onze gids over je website vernieuwen. Hier gaat het om de verhuizing zelf: de tabel die je opbouwt, de regels waar redirects aan voldoen, wat je op staging controleert en wat je daarna volgt.

Posities zakken na een redesign om mechanische redenen, niet om raadselachtige. Een URL die een fout teruggeeft verdwijnt uit de index. Een pagina die niet meer bestaat scoort niet meer. Interne links die breken geven geen signalen meer door. Niets daarvan is pech, en alles ervan is te voorkomen met een tabel die vóór livegang klaar is.

Wat de prestaties echt onderuithaalt:

• Ontbrekende redirects. Het oude adres geeft een fout en de pagina verdwijnt samen met alles wat zij had opgebouwd.
• Verwijderde pagina's. Een pagina opruimen die organische bezoeken opleverde haalt dat verkeer weg, met of zonder redesign.
• Gebroken interne links. Links zorgen voor vindbaarheid en geven belang aan. Een nieuwe navigatie die naar oude adressen wijst beschadigt allebei.
• Titels en koppen in één keer herschrijven. Ze beschrijven waar een pagina over gaat. Allemaal vervangen verandert waarvoor de pagina relevant is.
• Content die pas in de browser ontstaat. Verstopt de nieuwe bouw de hoofdinhoud achter JavaScript, dan wordt die mogelijk helemaal niet geïndexeerd.

Wat het níét kost, anders dan de meeste checklists beweren: een puur visuele vernieuwing op ongewijzigde URL's met ongewijzigde content brengt weinig risico mee, want vrijwel niets waar zoekmachines op letten is verplaatst. En een tijdelijke redirect geeft signalen wel degelijk door: volgens Google Search Central dragen server-side redirects ranking- en canonicalisatiesignalen over. De reden om de permanente variant te gebruiken is dat die de verhuizing als definitief meldt, niet dat de andere waarde zou verliezen.

Dat onderscheid bepaalt waar het budget heen gaat: naar de URL-inventaris en de redirectkaart, niet naar het herschrijven van metadata die al werkte.

De mappingtabel is het enige document waar de hele migratie op draait, en hij wordt opgebouwd voordat er sjablonen bestaan. Elk oud adres krijgt een regel en elke regel een besluit. Een URL zonder vastgelegd besluit is een onbehandelde URL, en zo ontdekken sites hun verlies zes weken na livegang uit een 404-rapport.

Bouw hem op uit zes bronnen, in deze volgorde. Geen enkele bron is compleet, en precies daarom zijn het er zes:

1. Geïndexeerde URL's uit Search Console, onder Indexering en dan Pagina's.
2. Een volledige crawl van de huidige site.
3. De geldende sitemaps.
4. Pagina's met organische bezoeken en conversies, uit de analytics.
5. URL's waar externe links naartoe wijzen.
6. Een contentexport uit het CMS, die gepubliceerde maar ongelinkte pagina's blootlegt.

Die volgorde is werkwijze uit de praktijk en geen eis van Google. Dat hoort erbij gezegd, want de meeste checklists presenteren hun eigen volgorde alsof die gedocumenteerd is. Wat wél gedocumenteerd is, is wat er gebeurt als een adres wordt overgeslagen.

De tabel hieronder is de specificatie waarmee wij werken. Een lijstje tips downloaden helpt weinig; een kolomstructuur helpt wel, want dat is wat je daadwerkelijk invult.

Redirects volgen drie regels, en alle drie zijn gedocumenteerd in plaats van een kwestie van smaak. Gebruik een permanente redirect voor een definitieve verhuizing, laat elke redirect in één hop oplossen, en houd ze minstens een jaar in stand. Sites die tijdens een redesign posities verliezen overtreden meestal een van deze drie.

Permanent, omdat de verhuizing dat is. Volgens Google Search Central geeft een permanente redirect aan dat de oorspronkelijke URL niet langer geserveerd hoort te worden. Dat is precies het signaal dat je wilt als een pagina definitief is verhuisd.

Eén hop, nooit een keten. Oud rechtstreeks naar nieuw. Ketens van oud via tussenadres naar nieuw verspillen crawlverzoeken en voegen faalpunten toe. Dit gebeurt makkelijk per ongeluk: een URL-wijziging gevolgd door een tweede maanden later levert een keten op, tenzij de eerste redirect wordt omgezet naar het definitieve adres. Controleer de kaart op ketens als processtap, niet uit gewoonte.

Minstens een jaar bewaren. Google's richtlijnen over siteverhuizingen noemen een jaar als minimum, en langer schaadt niet. Let op de richting van die instructie: het is een ondergrens, geen vervaldatum. Er is geen reden een redirect weg te halen zolang het oude adres nog verkeer krijgt of externe links draagt.

Nog één besluit hoort hier: wat te doen met pagina's die je bewust weghaalt. Verwijs ze alleen door waar een echt gelijkwaardige pagina bestaat. Een opgeruimde pagina naar de homepage sturen omdat er iets mee moet, is slechter dan een nette foutmelding, want het levert een irrelevante bestemming op voor iedereen die de link volgt.

Meertalige sites dragen een extra faalpatroon, en dat is het patroon dat de meeste migratiechecklists volledig overslaan. Als URL's in meerdere talen tegelijk veranderen, breken de annotaties die die taalversies verbinden op hetzelfde moment, met als gevolg dat de verkeerde taalversie in de verkeerde markt verschijnt.

Na de verhuizing moeten drie dingen kloppen. Volgens de Google-documentatie over gelokaliseerde versies moeten taalannotaties naar canonieke URL's verwijzen, moet elke versie alle andere noemen inclusief zichzelf, en kan een standaardvermelding worden opgegeven voor niet-gedekte talen.

Praktisch betekent dat: taalannotaties worden bij livegang opnieuw gegenereerd tegen de nieuwe adressen, en niet overgelaten aan de redirects. Een redirect vertelt een crawler waar een pagina heen ging; hij repareert geen annotatie die nog naar het oude adres wijst.

Hier verdient een stabiele identifier zich terug. Heeft elke taal een eigen gelokaliseerde slug, dan moet iets anders dan die slug de versies verbinden. Een permanente identifier die nooit verandert, ook niet als elk zichtbaar adres verandert, maakt het opnieuw genereren van annotaties machinaal in plaats van handwerk. Dat is de ontwerpbeslissing die wij als eerste zouden herhalen; ons artikel over website-architectuur en zoekzichtbaarheid gaat er dieper op in.

Op staging wordt de migratie geverifieerd, en daar hoort één schakelaar bij die in de juiste volgorde om moet. Blokkeer staging voor indexering vóórdat het werk begint, en geef productie vrij bij livegang. Die twee omdraaien is een van de gangbaarste manieren om een maand te verliezen, want een geïndexeerde stagingomgeving is tegelijk een index- en een duplicatieprobleem.

Wat je controleert vóór het omzetten:

• Het oplossen van redirects. Draai de volledige lijst oude URL's tegen staging en bevestig dat elke in één hop op de bedoelde bestemming uitkomt. Test de lijst, geen steekproef.
• Interne links wijzen naar definitieve adressen. Niet via een redirect. Controleer de content zelf net zo goed als navigatie en knoppen, want die staan apart opgeslagen.
• Canonical-tags verwijzen naar de nieuwe URL's. Zelfverwijzend, niet naar de oude site.
• Taalannotaties noemen elkaar, in beide richtingen.
• Contentpariteit. De nieuwe pagina draagt de inhoud waarmee de oude scoorde. Een pagina die tijdens de migratie de helft van haar inhoud verliest, verliest de reden van haar relevantie.
• Rendering. Bevestig dat de hoofdinhoud aanwezig is zonder uitvoering in de browser. Volgens Google Search Central rendert Googlebot JavaScript wel, maar die rendering is uitgesteld en afhankelijk van capaciteit, waardoor content die pas daarna verschijnt meer kans loopt gemist te worden.
• Sitemaps. Gegenereerd uit de nieuwe structuur, met kloppende wijzigingsdatums.

Leg het resultaat van elke controle vast in de mappingtabel en niet in iemands hoofd. De statuskolom bestaat om onvolledige controle zichtbaar te maken in plaats van aangenomen.

De checklist hieronder is per fase geordend en niet per onderwerp, want de volgorde is wat hem laat werken. Punten die in de verkeerde fase worden gedaan, zijn precies de punten die worden gemist. Elk item is een handeling met een controleerbaar resultaat, geen aansporing tot zorgvuldigheid.

Vóór de contentbevriezing

1. Exporteer geïndexeerde URL's uit Search Console.
2. Crawl de huidige site volledig en leg die naast de export.
3. Haal pagina's met organische bezoeken en conversies uit de analytics.
4. Haal de URL's op die externe links dragen.
5. Bouw de mappingtabel met alle URL's uit alle bronnen, ontdubbeld.
6. Leg per regel een besluit vast: behouden, doorverwijzen, samenvoegen of verwijderen.
7. Leg positie en verkeer van de belangrijkste pagina's vast als nulmeting.

Op staging

1. Bevestig dat staging geblokkeerd is voor indexering.
2. Richt de redirects in en test de volledige lijst oude URL's ertegen.
3. Controleer op ketens en lussen; elke redirect lost in één hop op.
4. Zet interne links om naar definitieve adressen, in content én navigatie.
5. Controleer canonical-tags en taalannotaties.
6. Controleer contentpariteit voor de pagina's met de meeste zoekwaarde.
7. Bevestig dat de hoofdinhoud verschijnt zonder uitvoering in de browser.

Op de dag van livegang

1. Geef productie vrij voor indexering en controleer dat, controleer daarna dat staging nog geblokkeerd is.
2. Dien de opnieuw gegenereerde sitemaps in.
3. Controleer live redirects een tweede keer steekproefsgewijs, in productie.
4. Bevestig met een echte inzending dat analytics, doelen en formuliermeting op de nieuwe sjablonen vuren.

In de eerste weken

1. Volg de indexdekking op nieuwe fouten en uitgesloten pagina's.
2. Vergelijk de nulmetingspagina's stuk voor stuk.
3. Los nieuwe 404's op door regels aan de mappingtabel toe te voegen, zodat die de bron van waarheid blijft.
4. Houd redirects in stand, minimaal een jaar.

Elke oorzaak van verkeersverlies na een redesign is te rangschikken op hoe sterk het bewijs ervoor is, en die rangschikking bepaalt wat je eraan doet. Oorzaken die Google documenteert krijgen ontwikkeltijd. Beweringen zonder gedocumenteerde basis krijgen scepsis, en dan vooral die met concrete hersteltermijnen.

De tabel hieronder scheidt die twee. De laatste regel verdient een tweede lezing: nergens is een hersteltermijn in getallen gedocumenteerd. Google noemt te verwachten schommelingen terwijl signalen opnieuw worden verwerkt, en geeft geen duur. Cijfers als negentig dagen of drie tot zes maanden komen uit ervaring van losse leveranciers zonder openbaar gemaakte methode, en dat is een andere klasse bewering dan documentatie.

Beantwoord die vraag met het mechanisme: veranderingen worden zichtbaar naarmate Google de betrokken URL's opnieuw crawlt, van dagen tot weken afhankelijk van de crawlfrequentie, en het consolideren van signalen via redirects kost verdere tijd die Google alleen kwalitatief beschrijft.

In mei 2026 verplaatste deze site zijn volledige contentbestand naar gelokaliseerde URL's in vijf talen tegelijk. Dat is precies het geval dat andere migratiegidsen het slechtst behandelen, want de faalpatronen vermenigvuldigen zich als elke taal op dezelfde dag van adres verandert. Het verslag hieronder komt uit de repositorygeschiedenis en niet uit het geheugen.

De volgorde van handelingen, en dat is het deel dat telt:

1. Een stabiele identifier ging in de contentindexen vóór er iets werd hernoemd. Elk artikel hield één permanente identifier die nooit verandert, terwijl elke taal een eigen zichtbare slug kreeg. Zonder dat verbreekt het wijzigen van slugs in vijf talen de band tussen de taalversies.
2. De taalannotaties werden omgebouwd naar expliciete paden vóórdat de slugs verhuisden, niet erna. Andersom zou een periode met kapotte taalsignalen hebben opgeleverd.
3. Slugs gegenereerd, daarna bestanden hernoemd. Eén hernoemcommit raakte 491 bestanden.
4. Redirectkaart gebouwd, daarna in de build gehangen. Per 3 augustus 2026 bevat zij 383 permanente redirects. 358 daarvan zijn blog-URL's, oftewel 93 % van de kaart, en Spaans en Frans dragen er elk 96, elk 25 % van het totaal.
5. Interne links in de content werden herschreven naar definitieve adressen, zodat interne links niet via redirects lopen.
6. Sitemaps met taalalternatieven, daarna de markdown-spiegels en de machineleesbare index.

Wat er misging, en dat is nuttiger dan de delen die werkten:

De eerste ronde over de interne links miste velden die er niet als links uitzagen. Sleutels die naar actieknoppen waren vernoemd in plaats van naar URL's bleven staan, en er was een herstelcommit nodig. De les laat zich veralgemenen: scan op de vorm van de waarde, niet op de veldnaam.

Drie dagen later kwam een tweede gat boven. Links binnen de markdown-content vielen buiten de ronde over de gestructureerde velden en moesten apart worden gerepareerd. Content in twee verschijningsvormen vraagt twee rondes, en de tweede is de ronde die wordt vergeten.

Daarna kwam een derde punt: ontbrekende wijzigingsdatums in de statische sitemap, ontdekt na livegang in plaats van ervoor.

We noemen bewust geen verkeersresultaat van deze migratie. Er is geen geïsoleerde meting om het aan toe te schrijven, omdat in dezelfde periode voortdurend content werd toegevoegd. De waarde van dit verslag zit in de volgorde en de fouten, niet in een cijfer.

Monitoren na livegang gaat over specifieke pagina's, niet over een totaal. Een sitebrede verkeerslijn beweegt om allerlei redenen en vertelt niet of de verhuizing geslaagd is. De pagina's die je als belangrijkste had genoteerd, stuk voor stuk vergeleken met je nulmeting, vertellen dat wel.

Wat je volgt, in de volgorde waarin het iets zegt:

• Indexdekking. Nieuwe fouten en nieuw uitgesloten pagina's verschijnen hier het eerst en wijzen meestal op een ontbrekende redirect of een geblokkeerd pad.
• Crawlactiviteit op de oude adressen. Zolang Google ze nog opvraagt, wordt de verhuizing nog verwerkt.
• De nulmetingspagina's, één voor één. Positie en vertoningen per pagina, vergeleken met wat je vóór de bevriezing vastlegde.
• Nieuwe 404's. Elke daarvan is een regel die in de mappingtabel ontbrak. Zet hem in de tabel en niet alleen in de serverconfiguratie, zodat de tabel leidend blijft.
• Rendering van de nieuwe sjablonen, als de bouw van renderaanpak is veranderd.

Weersta de neiging om in de eerste dagen in te grijpen. Kapotte redirects en echte fouten herstel je meteen, maar titels herschrijven of pagina's verbouwen terwijl de signalen nog consolideren maakt het onmogelijk te zien welke wijziging wat deed. Het vervolgwerk daarna staat in ons artikel over optimalisatie na lancering.

Wil je de verhuizing liever laten doen door mensen die hem over vijf talen hebben uitgevoerd, dan hoort dat bij onze SEO-diensten.