SEO-site-migratie: zo verplaatst u zonder rankings te verliezen

TL;DR: Een migratie behoudt zoekzicht wanneer elke waardevolle oude URL een relevante bestemming krijgt, permanente server-side redirects daar direct naartoe wijzen en Google de vervanging kan crawlen en indexeren. Inventariseer en benchmark de oude site vóór de livegang. Bouw een 1-op-1 redirectmap, update interne links en canonical tags, dien nieuwe sitemaps in en monitor daarna de overlap in indexatie van oud naar nieuw. Gebruik Change of Address voor domeinverhuizingen, niet voor HTTP-to-HTTPS of alleen hostingwijzigingen.

De eerste vraag bij SEO voor site-migraties is niet welke plugin je moet installeren. Het is dit: zien gebruikers en Google na de verhuizing andere URLs?

Google Search Central splitst migraties op in site moves met URL-wijzigingen en site moves zonder URL-wijzigingen. Dat onderscheid bepaalt het merendeel van het werk. Domeinwijzigingen, HTTP-to-HTTPS moves, gewijzigde paden en domeinconsolidaties vallen in de eerste categorie. Hosts switchen of verhuizen naar een CDN terwijl elke zichtbare URL behouden blijft, valt in de tweede.

Wij voerden zelf een domeinmigratie uit toen ons team van twee, Lida en ik, SEOJuice verplaatsten van seojuice.io naar seojuice.com in januari 2026. Het verplaatsen van de applicatie maakte me niet zo veel zorgen. Het risicovolle deel was aantonen dat elke oude URL de juiste vervanger bereikte, dat de nieuwe site niet leunde op interne links met het oude domein, en dat Google de URLs vervangt in plaats van ze alleen maar te ontdekken.

Dat onderscheid telt. “De nieuwe site is live” is een mijlpaal op infrastructuurniveau. Het is geen bewijs dat de migratie geslaagd is.

Wat telt als een SEO site-migratie?

Een SEO site-migratie is een wijziging die groot genoeg is om invloed te hebben op hoe zoekmachines een website bereiken, crawlen of indexeren. Een nieuw domein is het meest voor de hand liggende voorbeeld, maar ook minder ingrijpende projecten vereisen dezelfde controles.

• Domeinwijziging: Verhuizen naar een ander domein tijdens een rebrand, overname of wijziging van top-level domain.
• HTTP naar HTTPS: Het protocol maakt onderdeel uit van de URL. Dus ook al blijft de hostname gelijk, dit is een move met URL-wijzigingen.
• Platform- of CMS-wijziging: Een nieuw platform kan paden, parameters, paginering, hoofdletterafhandeling of trailing slashes veranderen. Behandel dit als een migratie met URL-wijzigingen als er als gevolg URLs verschillen.
• Redesign of herstructurering: Een visuele redesign is niet automatisch een migratie. Het wordt er één wanneer paden, slugs, navigatie, canonicals, gegenereerde content of indexeerbaarheid veranderen.
• Domeinconsolidatie: Het samenvoegen van meerdere domeinen of hostnames in één domein vereist een aparte inventaris en redirectplan voor elk bron-domein.
• Hosting of CDN move: Als de URLs die gebruikers zien identiek blijven, is dit vooral een DNS- en infrastructuuroperatie, niet een redirectproject.

Ik zou deze wijzigingen niet combineren, tenzij de businessconstraint zwaarder weegt dan het diagnostische risico. Google’s guidance is kort en helder: “Wijzig maar één ding tegelijk.” Een gelijktijdige domein-, CMS-, design- en taxonomie-wijziging geeft je vier plausibele oorzaken voor elke verloren landingspagina (en eigenlijk nog meer zodra rendering en templates meedoen).

Vóór livegang: eerst inventariseren, dan migreren

Maak een verdedigbare inventaris van oude URLs

Je redirectmap kan alleen de URLs beschermen die erin staan. CrawI de oude site en combineer die crawl vervolgens met XML-sitemaps, exporten uit Search Console, analytics landingspagina’s, backlinkdata waar beschikbaar en serverlogs. Elke bron “ziet” een andere slice van de site.

Een crawler vindt gelinkte pagina’s, maar kan weespagina’s missen. Een sitemap kan oude URLs uitsluiten die nog steeds ranken. Analytics toont geen pagina’s zonder recente bezoeken. Logs kunnen verzoeken naar bestanden en legacy-paden blootleggen die niet meer in de huidige navigatie staan. “Compleet” is hier een ongemakkelijk woord (ik kom meestal uit op: onafhankelijk gereconcilied).

Houd non-HTML assets binnen scope wanneer ze zoekwaarde hebben of externe links aantrekken. PDFs, downloadbare gidsen, afbeeldingen en oude campagnagina’s worden vaak overgeslagen omdat ze niet opduiken in een normale page crawl.

Leg een baseline vast buiten het systeem dat je vervangt

Exporteer organisch verkeer naar landingspagina’s, belangrijke query- en paginaprestaties, informatie over geïndexeerde pagina’s, best scorende URLs en de huidige crawlresultaten. Segmenter op directory of paginatype. Eén enkel sitewide verkeersgetal is te grof om een migratie te debuggen.

Als verkeer daalt met 12 procent, zegt dat getal bijna niets. Als één productdirectory verdwijnt terwijl het blog stabiel blijft, heb je een bruikbare aanwijzing. Controleer eerst de redirects, templates, canonical tags en indexeringsinstructies voor die directory.

Ik heb baseline-werk overgeslagen omdat de livegang urgent voelde. Misschien scheelde het een uur, maar het maakte de latere diagnose trager en minder zeker. Geen slimme ruil.

Map elke oude URL naar de dichtstbijzijnde vervanger

Google Search Central geeft de kerninstructie:

Een redirectmap stuurt elke oude URL naar de echte nieuwe tegenhanger, 1-op-1:

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

“Zodra je de lijst met oude URLs hebt, bepaal je waar elke URL naartoe moet redirecten.”

Maak een mapping met één rij per oude URL. Neem de beoogde bestemming, verwachte responsecode, paginatype, migratiestatus en eventuele reden voor beëindiging op. Geef prioriteit aan URLs met organische bezoeken of externe links, maar zie “prioriteren” niet als toestemming om de long tail te negeren.

De bestemming moet intent behouden. Een oude productpagina moet leiden naar hetzelfde product of naar de echte opvolger. Een gemigreerd artikel moet naar dat artikel leiden. De homepage is geen universeel alternatief.

Behoud bestaande paden waar dat praktisch kan. Elke URL die niet verandert, verwijdert een redirectregel, een mappingbeslissing en een mogelijke failure. Teams herschrijven slugs tijdens een redesign vaak omdat de nieuwe versies er netter uitzien. Ik zou eerst vragen: welk meetbaar probleem lost die opschoonactie op voordat je het migratierisico accepteert?

Bepaal wat je níet moet redirecten

Een 1-op-1 mapping betekent niet dat elke verwijderde pagina ergens naartoe moet. Als een pagina geen equivalent heeft en geen nuttige opvolger, kan een correcte 404 of 410 duidelijker zijn dan een irrelevante redirect.

Dat vraagt om editorial judgment, niet om een spreadsheetformule. Het redirecten van een stopgezet product naar het vervangende model kan zinvol zijn. Het redirecten van een verwijderde eventpagina naar een niet-gerelateerde eventsindex is dat mogelijk niet. Relevantie eerst.

Bereid de vervanger voor op crawling

Importeer de content, configureer HTTPS, bereid het production robots.txt-bestand voor, controleer de relevante Search Console-eigenschappen en bekijk indexing-instructies op paginaniveau. Valideer canonical tags, hreflang waar gebruikt, structured-data-URLs, paginering en XML-sitemaps tegen de production hostname.

Staging-sites worden vaak afgeschermd met robots.txt-regels, noindex-directives, authenticatie of een combinatie daarvan. Die beveiligingen mogen niet “lekken” naar productie. Als pagina’s na de livegang afwezig blijven, dekken de checks in Waarom staat mijn site niet op Google? robots-controles, noindex-directives en URL-Inspectie.

Voor een grote site: migreer eerst een sectie als de architectuur dat toelaat. Google raadt aan: “verplaats aanvankelijk alleen een deel van de site om de effecten op verkeer en search indexing te testen.” Een gefaseerde move is niet altijd mogelijk, maar het is zeker om over na te denken voordat je voor een alles-of-niets cutover kiest.

Tijdens de livegang: laat elk signaal met elkaar kloppen

Gebruik directe, permanente redirects op serverniveau

Google beveelt aan: “server side permanent redirects van de oude URLs naar de nieuwe URLs, zoals je die in je mapping hebt aangegeven.” Als je niet bekend bent met redirect-mechanica, lees What is a redirect? eerst. Onze vergelijking van 301 en 302 redirects gaat dieper in op de keuze permanent versus tijdelijk.

Zoals Patrick Stox, lead auteur van het Web Almanac SEO-hoofdstuk, het verwoordt:

“Zorg ervoor dat je redirects 301 of 308 zijn in plaats van 302 of 307 status codes als je een permanente move doet en wilt dat URLs op de nieuwe website geïndexeerd worden in plaats van op de oude.”

De statuscode is niet ceremonieel. Google’s redirect documentatie legt uit wat er gebeurt bij een permanente redirect: “Googlebot volgt de redirect en de indexing pipeline gebruikt de redirect als signaal dat de redirectdoel-URL canoniek moet zijn.”

Elke oude URL moet direct naar de eindbestemming wijzen. Vermijd oude-tussenstap-naar-eindbestemming-ketens. Test op loops door overlappende regels voor HTTPS, www, trailing slash, CDN, server en applicatie.

Inspecteer vervolgens de live response in plaats van het configuratiebestand. Een regel kan correct zijn op zichzelf en toch conflicteren met een andere laag. Dit is waar ik stop met vertrouwen op de migratie-sheet (en, eerlijk is eerlijk, op mijn eigen geheugen) en productie opnieuw crawl.

Redirect geen grote batches pagina’s naar de homepage

Google waarschuwt expliciet:

“Redirect niet veel oude URLs naar één irrelevante specifieke bestemming, zoals de homepage van de nieuwe site.”

Een massale homepage-redirect verbergt het ontbrekende mapping-werk; het maakt het niet af. Zoekmachines en gebruikers verwachten een specifiek resource. Iedereen naar een generieke pagina sturen, verbreekt die relatie.

Als veel URLs een legitieme opvolger delen, kan een many-to-one mapping logisch zijn. Meerdere duplicate product-URLs kunnen bijvoorbeeld allemaal uitkomen op de canonieke productpagina. Het probleem is irrelevantie, niet de wiskunde.

Update interne links, canonicals en gegenereerde referenties

Redirects zijn fallback-infrastructuur. Ze horen niet het interne-linking-systeem van de nieuwe site te worden.

Update navigatie, breadcrumbs, artikel-links, related-content modules, canonical tags, hreflang-referenties, structured data, sitemap entries en asset-referenties zodat ze direct naar de eind-URLs verwijzen. Google’s instructie is: “Wijzig de interne links op de nieuwe site van de oude URLs naar de nieuwe URLs.”

Op basis van wat we bij SEOJuice over sites heen zien, zijn template-level oude links vaak belangrijker dan losse editoriale links. Eén verouderd component kan dezelfde redirect-afhankelijkheid kopiëren over honderden pagina’s. Check eerst de templates en daarna pas de content body.

Dien sitemaps in en gebruik Change of Address correct

Dien de nieuwe XML-sitemap in via Search Console. Google zegt dat dit helpt om de nieuwe URLs te leren kennen. Door aparte oude-URL en nieuwe-URL sitemaps te gebruiken, krijg je een praktische manier om de vervanging te monitoren.

Bij een move van domein naar domein dien je Change of Address in vanuit de oude Search Console property. Google’s exacte instructie is om verzoeken in te dienen voor “alle subdomeinen en de www- en non-www-varianten van de oude domeinnaam.” De tool vult permanente redirects aan; hij vervangt ze niet.

Gebruik Change of Address niet bij HTTP-to-HTTPS migraties. HTTPS verandert de URL, maar Google sluit dit expliciet uit van de tool. Het is ook niet nodig voor moves die alleen hosting betreffen en voor padwijzigingen binnen hetzelfde domein.

Na de livegang: kijk naar de vervanging, niet alleen naar verkeer

Een migratie is niet afgerond wanneer DNS resolveert en de homepage renderend is. De migratie is afgerond wanneer gebruikers en crawlers consequent de beoogde content bereiken en de nieuwe URLs de oude URLs vervangen in Google’s index.

Monitor Search Console indexatierapporten, crawl-errors, rankings en organisch verkeer naar landingspagina’s tegen de baseline. Google beschrijft het verwachte indexatiepatroon duidelijk:

“In de loop van de tijd zou het aantal pagina’s geïndexeerd vanaf de oude URLs-sitemap dalen naar nul, met een overeenkomstige toename van indexatie van de nieuwe URLs.”

Die crossover is nuttiger dan alleen het verversen van één verkeersgrafiek. Als een sectie aan de nieuwe kant niet stijgt, controleer dan de redirects, canonical tags, interne links, sitemap-inclusie, gerenderde content en indexeringsinstructies. Onze gids over hoe Google indexing werkt legt het crawling- en canonicalisatieproces uit achter deze vervanging.

Een tijdelijke dip kan optreden terwijl Google URLs opnieuw crawlt en opnieuw indexeert. Er is geen geloofwaardige universele percentage of recovery-deadline. Websites verschillen in omvang, crawlfrequentie, interne linking, redirectkwaliteit en de mate van de wijziging. Een scherp verlies op paginaniveau of directory-niveau is bovendien actiegerichter dan een gemiddelde uit de sector.

Laat redirects doorlopen

Google zegt: “Houd redirects zo lang mogelijk aan, doorgaans minimaal 1 jaar.” Nuttige redirects onbeperkt laten bestaan kan ook bezoekers helpen die oude bookmarks en links gebruiken naar sites die je niet zelf beheert.

Stop het oude domein niet vroegtijdig en beëindig ondersteunende infrastructuur niet te snel. Een redirect die werkt voor de launch-crawl, maar maanden later verdwijnt, kan niet helpen voor gebruikers of crawlers die later nog steeds een oude link tegenkomen.

De failures die ik als eerste zou onderzoeken

Controleer toegankelijkheid en redirects voordat je titels herschrijft of een algoritme-update de schuld geeft. Migratiefouten zijn vaak mechanisch: een pagina wordt geblokkeerd, een redirect botst met een andere regel, of een canonical wijst naar de verkeerde host.

De volgorde doet ertoe. Metadata fixen op een URL die Google niet kan crawlen is tijdverspilling.

Een hosting-only migratie is een andere operatie

Als elke voor gebruikers zichtbare URL identiek blijft, moet je geen redirectproject “fabriceren”. Google definieert dit als het switchen van hostingproviders of verhuizen naar een CDN zonder de zichtbare URL aan te tasten.

Bereid en test de nieuwe infrastructuur, verlaag DNS time-to-live waar passend, pas DNS aan en monitor requests die door beide omgevingen worden geserveerd. Google raadt aan om de oude infrastructuur pas uit te schakelen wanneer je zeker weet dat alle gebruikers, inclusief Googlebot, content correct ontvangen vanuit de nieuwe setup.

Er is geen redirectmap en geen Change of Address request, omdat de URLs niet zijn verhuisd. De belangrijkste risico’s zitten in beschikbaarheid, performance, DNS-configuratie, serverresponses en verschillen in wat de nieuwe infrastructuur serveert aan crawlers.

Hoe SEOJuice aansluit na een migratie

Nadat we seojuice.io naar seojuice.com hadden verplaatst, hadden we vooral behoefte aan een herhaalbare inspectie van het live resultaat. Geen extra launch-spreadsheet.

SEOJuice’s gratis SEO-audit controleert migratie-gevoelige onderdelen, waaronder robots.txt, sitemaps, canonical tags, HTTPS-configuratie, redirects en interne links. Het kan links blootleggen die nog naar het oude domein wijzen, redirectbestemmingen die errors teruggeven, achtergebleven noindex-directives en canonical- of HTTPS-mismatches.

De grens is belangrijk. De audit identificeert wat er mis is en waar. Hij schrijft geen server redirectregels voor en dient geen Change of Address voor je in. Die stappen blijven onder jouw controle (wat waarschijnlijk precies is waar domein-level wijzigingen zouden moeten blijven).

Veelgestelde vragen

Wat is een SEO site-migratie?

Een SEO site-migratie is een verandering die invloed heeft op hoe zoekmachines een website bereiken, crawlen of indexeren. Voorbeelden zijn domeinen verplaatsen, overschakelen van HTTP naar HTTPS, CMS-platforms of URL-structuren wijzigen, domeinen consolideren en hosts verplaatsen. Het kernonderscheid is of zichtbare URLs veranderen, omdat gewijzigde URLs mapping en redirects vereisen.

Verlies ik rankings als ik mijn site migreer?

Niet per se. Permanente redirects helpen Google om de bestemming als canoniek te behandelen en de oude URL te vervangen. Tijdens opnieuw crawlen en herindexeren kan wat fluctuatie optreden. Aanhoudende verliezen rechtvaardigen meestal het checken van ontbrekende redirects, irrelevante bestemmingen, loops, tijdelijke redirects, gewijzigde content, canonicals en geblokkeerde indexatie.

Hebben oude URLs one-to-one redirects nodig?

Elke waardevolle oude URL moet afzonderlijk worden beoordeeld en worden geredirect naar de dichtstbijzijnde relevante vervanger. Stuur geen ongepaste pagina’s naar de homepage. Als er geen relevante vervanger bestaat, kan een correcte 404 of 410 nauwkeuriger zijn dan een misleidende redirect.

Wanneer moet ik de Change of Address tool van Google gebruiken?

Gebruik deze bij een move van het ene domein naar het andere. Dien de noodzakelijke requests in voor subdomeinen en varianten van het oude domein met www of non-www. Gebruik de tool niet voor HTTP-to-HTTPS wijzigingen, padwijzigingen binnen één domein of moves van hosting en CDN. Change of Address vervangt geen permanente redirects.

Hoe lang moeten migratie-redirects actief blijven?

Google raadt aan redirects zo lang mogelijk te bewaren, doorgaans minimaal één jaar. Nuttige redirects onbeperkt aanhouden kan beschermen tegen verloren oude bookmarks en externe links, mits de bestemmingen relevant blijven.

Hoe controleer ik of een migratie geslaagd is?

Vergelijk post-launch verkeer, rankings, geïndexeerde URLs en crawlresultaten met de baseline. CrawI oude URLs om te bevestigen dat directe permanente redirects werken, crawl de nieuwe site om te checken op oude interne links, en inspecteer robots-directives, canonicals, sitemaps en serverresponses. In Search Console zou het geïndexeerde aantal van de oude sitemap moeten dalen terwijl dat van de nieuwe sitemap stijgt.