Een domein migreren zonder je zoekposities te laten kelderen

Van domein veranderen is een van de weinige SEO-projecten waarbij een technisch kleine fout heel snel heel zichtbaar kan worden. Een ontbrekende redirect, een geblokkeerd crawlpadd of een vergeten canonical kan een eenvoudige rebranding veranderen in weken van schommelende rankings.

Enige beweging is normaal. Zoekmachines hebben tijd nodig om de oude URL's te crawlen, de redirects te ontdekken, signalen te verwerken en het nieuwe domein in de index te laten landen. Het doel is niet om elke dip te voorkomen. Het doel is om de migratie saai te maken: één oude URL verwijst naar één equivalente nieuwe URL, de server reageert duidelijk en niets belangrijks verdwijnt.

Begin met een inventaris, niet met een redirectregel

De meest voorkomende fout bij migraties is dat ze worden behandeld als een taak voor serverconfiguratie. Dat is het niet. Het is een taak voor informatiearchitectuur die toevallig eindigt in serverconfiguratie.

Maak vóór je DNS aanraakt een lijst van URL's die ertoe doen:

• URL's die organisch verkeer ontvangen
• URL's met externe backlinks
• URL's die converteren, leads genereren of campagnes ondersteunen
• Canonieke URL's die momenteel in je XML-sitemap staan
• PDFs, afbeeldingen en downloadbare bestanden waar extern naar wordt gelinkt
• Waardevolle legacy-URL's die mogelijk niet in de huidige navigatie voorkomen

Wijs voor elke oude URL een bestemming op het nieuwe domein toe. In de meeste gevallen moet die bestemming dezelfde pagina met dezelfde intentie zijn. Als /pricing verandert in https://newdomain.com/pricing, is dat eenvoudig. Als drie oude productpagina's worden samengevoegd tot één nieuwe gids, documenteer die beslissing dan bewust.

Vermijd het luie patroon: alles redirecten naar de nieuwe homepage. Het is handig, maar het gooit relevantie weg. Zowel zoekmachines als gebruikers verwachten dat de bestemming dezelfde behoefte beantwoordt als de oorspronkelijke URL.

Behoud de URL-structuur waar dat kan

Een domeinmigratie is eenvoudiger wanneer paden stabiel blijven. Verhuizen van oldsite.com/blog/example naar newsite.com/blog/example is veel netter dan tegelijk domein, CMS, slugs, mappenstructuur en content wijzigen.

Soms maken een redesign of CMS-migratie URL-wijzigingen onvermijdelijk. Scheid dan de beslissingen:

1. Wat verandert omdat het domein verandert?
2. Wat verandert omdat de sitestructuur verandert?
3. Wat wordt verwijderd, samengevoegd of herschreven?

Hoe meer variabelen je introduceert, hoe moeilijker het later wordt om problemen te diagnosticeren. Als de migratie belangrijk is en de huidige site goed presteert, overweeg dan eerst het domein te verhuizen en pas later te redesignen.

Gebruik permanente redirects met één hop

Gebruik voor een echte domeinmigratie server-side 301- of 308-redirects van oude URL's naar hun nieuwe equivalenten. Tijdelijke redirects zijn voor tijdelijke situaties. JavaScript-redirects, meta refreshes en soft redirects zijn zwakkere signalen en gemakkelijker te breken.

Je redirectdoelen zijn eenvoudig:

• Elke belangrijke oude URL geeft een permanente redirect terug.
• Elke redirect gaat rechtstreeks naar de eindbestemming.
• HTTP redirect netjes naar HTTPS.
• www- en non-www-varianten worden consequent afgehandeld.
• Redirects zijn niet afhankelijk van fragiel query-stringgedrag, tenzij dat nodig is.

Een slechte keten ziet er zo uit:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Die komt uiteindelijk misschien op de juiste pagina uit, maar is traag, moeilijker te crawlen en verbergt fouten sneller. Streef naar één hop van elke oude variant naar de uiteindelijke nieuwe URL.

Controleer bij het valideren van gedrag de daadwerkelijke HTTP-responses in plaats van te vertrouwen op wat de browser toont. Onze gids over redirects en HTTP-headers in productie debuggen is hier nuttig, omdat browsers te beleefd zijn: ze volgen de keten en verbergen de rommelige delen.

Bereid DNS en certificaten voor vóór de lancering

DNS draagt rankings niet rechtstreeks over, maar slechte DNS kan een migratie kapot laten lijken. Verlaag TTL-waarden vóór het lanceervenster, zodat wijzigingen voorspelbaarder propageren. Controleer of het nieuwe domein correcte records heeft voor webverkeer, e-mail en eventuele vereiste subdomeinen.

Je hebt ook geldige TLS-certificaten nodig voor beide domeinen. Dit wordt gemakkelijk over het hoofd gezien. Het oude domein moet na de migratie nog steeds HTTPS-redirects kunnen aanbieden. Als het certificaat verloopt, kunnen gebruikers en crawlers browserwaarschuwingen tegenkomen voordat ze ooit de nieuwe site bereiken.

Als de verhuizing invloed heeft op e-mail, behandel dat dan niet als een bijzaak. Domeinwijzigingen breken vaak SPF, DKIM, DMARC, MX-records, trackinglinks en transactionele e-mail. Voor een opfrisser over de records die ertoe doen, zie onze ontwikkelaarsvriendelijke gids over MX, SPF, DKIM en DMARC.

Controleer canonicals, interne links en sitemaps

Na de lancering moet het nieuwe domein zich gedragen alsof het altijd al de canonieke thuisbasis van de content is geweest.

Dat betekent:

• Canonical-tags verwijzen naar de nieuwe URL's, niet naar het oude domein.
• Interne links gebruiken het nieuwe domein of root-relatieve paden.
• XML-sitemaps bevatten alleen definitieve, indexeerbare nieuwe URL's.
• hreflang-annotaties, indien gebruikt, verwijzen naar de nieuwe URL's.
• Open Graph, structured data en alternate links zijn bijgewerkt.
• Robots.txt blokkeert geen belangrijke secties.

Publiceer geen sitemap vol oude URL's in de verwachting dat redirects dat wel opruimen. Een sitemap moet een lijst zijn van URL's die je geïndexeerd wilt hebben. Na een migratie betekent dat definitieve URL's op het nieuwe domein.

Let ook op canonical-tegenspraken. Een pagina die van oud naar nieuw redirect, maar een canonical heeft die terugwijst naar het oude domein, stuurt gemengde signalen. Zoekmachines kunnen meestal wel door enige inconsistentie heen werken, maar je moet ze daar niet om vragen.

Verander niet alles op de lanceringsdag

Een migratie is al een groot genoeg event. Vermijd het, indien mogelijk, om die te combineren met grote contentopschoning, template-herschrijvingen, navigatiewijzigingen, wijzigingen in JavaScript-rendering of een nieuw prestatieprofiel.

Dit is geen bijgeloof. Het is debugdiscipline. Als rankings na de lancering dalen, moet je weten of de oorzaak ligt in redirectmapping, crawltoegang, gewijzigde content, tragere rendering, ontbrekende structured data of iets anders.

Houd de initiële lancering zo dicht mogelijk bij de oude site als praktisch haalbaar is. Zodra het nieuwe domein stabiel is, voer je grotere redactionele en ontwerpwijzigingen in kleinere batches door.

Vertel zoekmachines wat er is veranderd

Verifieer in Google Search Console zowel het oude als het nieuwe domein. Gebruik daarna de Change of Address-tool wanneer de verhuizing een wijziging op domeinniveau is en de content naar een nieuw domein verhuist. Dien na de lancering de nieuwe sitemap in.

Dit vervangt redirects niet. Het ondersteunt ze. Zoekmachines hebben nog steeds crawlbare, blijvende redirects nodig om de mapping op URL-niveau te begrijpen.

Gebruik voor Bing en andere zoekmachines hun webmastertools waar beschikbaar. Werk ook de plekken bij waar je controle over hebt: social profielen, bedrijfsvermeldingen, advertentiebestemmingen, e-mailfooters, documentatie, partnerlinks en canonieke verwijzingen in gesyndiceerde content.

Externe links zullen niet allemaal worden bijgewerkt, en dat is prima. Maar de belangrijkste zouden dat wel moeten worden. Als een grote partner, app marketplace, documentatieportaal of perspagina naar het oude domein linkt, vraag dan om een update.

Monitor de juiste dingen na de lancering

De eerste dagen na de migratie moeten actieve monitoring zijn, geen viering.

Controleer:

• Serverlogs voor crawlactiviteit op oude en nieuwe domeinen
• 404's en onverwachte 5xx-fouten
• Redirectketens en -loops
• Indexeringsstatus in Search Console
• Ontdekking en verwerking van sitemaps
• Organische landingspagina's en querypatronen
• Conversiepaden die afhankelijk zijn van oude URL's
• Analytics-filters en referral-exclusions

Verwacht ruis in rapportages. Sommige analyticstools behandelen het nieuwe domein als een nieuwe property, tenzij ze correct zijn geconfigureerd. Sommige dashboards vergelijken verkeer op het oude domein met verkeer op het nieuwe domein en laten de migratie erger lijken dan die is.

Zoekzichtbaarheid kan een paar weken schommelen. Wat je niet wilt, is een patroon waarbij waardevolle oude URL's herhaaldelijk worden gecrawld maar niet correct worden geredirect, of waarbij nieuwe pagina's worden ontdekt maar als duplicaten van het oude domein worden gemarkeerd.

Prestaties mogen ook niet worden genegeerd. Als het nieuwe domein live gaat met zwaardere templates, kapotte caching of niet-geoptimaliseerde assets, kunnen gebruikers de migratie ervaren als een vertraging. Als je Lighthouse gebruikt als onderdeel van je checks, lees het dan met prioriteiten in gedachten; ons stuk over hoe je een Lighthouse-rapport leest zonder in paniek te raken legt uit hoe je betekenisvolle problemen van ruis scheidt.

Houd het oude domein lang aan

Laat het oude domein niet verlopen nadat de migratie “werkt.” Houd het geregistreerd, houd certificaten geldig en laat redirects zo lang mogelijk draaien. In de praktijk betekent dat vaak jaren.

Oude links blijven bestaan in blogposts, bookmarks, documentatie, PDFs, e-mails en social posts. Redirects zijn de brug tussen die historische voetafdruk en het nieuwe domein. Ze te vroeg uitschakelen breekt gebruikerspaden en verspilt opgebouwde signalen.

Bewaar ook een kopie van je redirectmap en lanceringsnotities. Zes maanden later, wanneer iemand vraagt waarom een legacy-URL zich op een bepaalde manier gedraagt, ben je blij dat je het hebt gedocumenteerd.

<!-- tool-cta:start -->

💡 Probeer dit: Traceer na de omschakeling je oude URL's met Redirect Checker om te bevestigen dat elke URL in één enkele 301-hop naar de juiste nieuwe pagina wordt opgelost.

<!-- tool-cta:end -->

Een verstandige migratiechecklist

Vóór de lancering:

• Verifieer beide domeinen in Search Console.
• Crawl de huidige site en exporteer belangrijke URL's.
• Bouw een één-op-één redirectmap.
• Verlaag DNS-TTL's.
• Bereid TLS-certificaten voor oude en nieuwe domeinen voor.
• Werk canonicals, interne links, hreflang, structured data en sitemaps bij.
• Test redirects in staging of een gecontroleerde omgeving.

Op de lanceringsdag:

• Deploy redirects.
• Bevestig het gedrag van HTTP naar HTTPS.
• Test belangrijke URL-voorbeelden uit elk templatetype.
• Dien de nieuwe sitemap in.
• Gebruik de Change of Address-tool waar passend.
• Let op serverfouten, redirectloops en geblokkeerde resources.

Na de lancering:

• Monitor crawlfouten en indexeringsrapporten.
• Werk belangrijke externe links bij waar je kunt.
• Vergelijk verkeer op basis van de intentie van landingspagina's, niet alleen op domeintotalen.
• Houd redirects voor onbepaalde tijd live.
• Stel niet-gerelateerde redesign- of contentexperimenten uit totdat de verhuizing stabiel is.

Domeinmigraties zijn niet risicovrij, maar ze zijn beheersbaar. Rankings lijden meestal wanneer de migratie onduidelijke signalen stuurt: ontbrekende redirects, gewijzigde content, tegenstrijdige canonicals, geblokkeerde crawlers of een vergeten oud domein. Geef zoekmachines en gebruikers een duidelijke kaart, en de verhuizing wordt veel minder dramatisch.