Weg bij je huidige webbureau: hoe je je website, domein en e-mail meeneemt

Je website, domein en e-mail meenemen naar een andere partij kan: controleer eerst in de SIDN-whois wie de houder van je domein is, vraag dan de verhuistoken op bij je huidige registrar en verhuis site en mail pas als alles op de nieuwe omgeving getest is, met 301-redirects om je vindbaarheid te behouden. Een .nl-domein verhuizen mag altijd. Het moment waarop je merkt dat je vastzit komt vaak als een simpele tekstwijziging drie weken duurt, je geen toegang krijgt tot je eigen hosting of niemand kan uitsplitsen wat je website per jaar kost. Dit artikel zet op een rij wat je bezit, wat je moet opvragen en in welke volgorde je verhuist.

Hoe neem je je domein mee?

Begin bij het domein, want dat is het enige onderdeel waar je echt vastzit als het misgaat. Een domeinnaam heeft een houder, en die houder is niet automatisch degene die de rekening betaalt. Voor een .nl-domein zoek je dat op via de whois van SIDN, de beheerder van het Nederlandse .nl-domein. Staat jouw bedrijfsnaam daar als houder, dan is het domein van jou en kan je bureau je niet tegenhouden. Staat het bureau er als houder, dan is het juridisch hun domein en moet er eerst een houderwijziging gebeuren voordat je kunt verhuizen. Controleer dit vandaag, niet op het moment dat je al ruzie hebt.

Verhuizen zelf gaat met een code. Bij .nl-domeinen heet dat een verhuistoken, bij .com, .net, .eu en de meeste andere extensies een auth- of EPP-code. Je vraagt die op bij je huidige registrar, dus bij het bureau of de hostingpartij waar het domein nu staat, en geeft hem door aan je nieuwe partij. Die zet de verhuizing in gang. Bij internationale extensies moet het domein bovendien ontgrendeld zijn en let je op de lock die na een recente houderwijziging of verhuizing kan gelden. Hoe de verhuizing van een .nl-domein stap voor stap verloopt en welke rol de houder daarin heeft, beschrijft SIDN zelf. Reken op dagen, niet op minuten, en plan daaromheen.

Wat is DNS, en wat moet je ervan weten?

DNS is een apart onderdeel en dat verwarren mensen vaak met het domein. Je domein kan bij partij A staan terwijl je DNS-records naar de servers van partij B wijzen en je mail bij partij C ligt. Dat is prima, zolang je maar weet waar je aan de knoppen kunt draaien. Vraag daarom niet alleen om je verhuistoken maar ook om toegang tot je DNS-beheer, of om een export van alle records: A, AAAA, CNAME, MX, TXT met daarin je SPF- en DMARC-regel, en eventuele DKIM-records. Zonder die lijst ben je bij het omzetten aan het gokken.

Van wie is de website zelf?

Dan de website zelf. Wat je in elk geval bezit is je content: je teksten, je foto's, je productinformatie, je klantgegevens. Die kun je opvragen en die horen aan jou geleverd te worden. Over de broncode van maatwerk ligt het genuanceerder dan de meeste ondernemers denken. In Nederland ligt het auteursrecht op een werk bij de maker, tenzij het schriftelijk is overgedragen. Staat er in je opdrachtbevestiging niets over overdracht van rechten, dan heb je in de praktijk een gebruiksrecht en geen eigendom. Dat is zelden een blokkade voor verhuizen, maar het is wel de reden om bij je volgende bureau vooraf vast te leggen dat je eigenaar wordt.

Draait je site op WordPress, dan is die discussie grotendeels academisch. WordPress zelf en alles wat erop bouwt valt onder de GPL, dus met een volledige kopie van je bestanden en je database kun je overal opnieuw opstarten. Wat je nodig hebt is dus vooral toegang: een export van de bestanden, een dump van de database, en de licentiesleutels van betaalde plugins. Staan die licenties op naam van het bureau, dan vervallen ze bij vertrek en moet je ze zelf opnieuw aanschaffen. Vraag dat expliciet na, want het is een post die mensen pas ontdekken als hun formulieren stoppen met werken.

Hoe vraag je alles op?

Vraag alles in één keer en schriftelijk op. Een korte, zakelijke mail met een opsomming werkt beter dan drie losse telefoontjes: een volledige export van bestanden en database, de verhuistoken van het domein, toegang tot of export van de DNS-records, een lijst met alle e-mailadressen op het domein, overdracht van je Google Analytics- en Search Console-property, en een overzicht van welke betaalde licenties op wiens naam staan. Zet er een redelijke termijn bij. Je hebt dan meteen een dossier als het stroef gaat lopen.

Loopt er een conflict over facturen, houd dan twee sporen uit elkaar. Een geschil over geld is een geschil over geld, maar je persoonsgegevens en die van je klanten vallen onder de AVG. Een partij die voor jou gegevens verwerkt, moet die op verzoek teruggeven of verwijderen. Je klantenbestand en je bestellingen zijn geen onderpand. Vraag dat rustig en schriftelijk op, zonder dreigende taal, en bewaar de correspondentie. In verreweg de meeste gevallen wordt er gewoon meegewerkt zodra duidelijk is dat je weet wat je vraagt.

Hoe migreer je zonder onderbreking?

Nu de migratie zelf, en de hoofdregel is simpel: je bouwt de nieuwe situatie helemaal op voordat je iets omzet. Je zet een volledige kopie van de site op de nieuwe server, je test daar op een tijdelijk adres of een staging-domein of alles werkt, en pas als dat klopt raak je je DNS aan. Zet een dag van tevoren de TTL van je records omlaag naar bijvoorbeeld vijf minuten, zodat de wijziging snel doorwerkt in plaats van dat een deel van je bezoekers nog uren op de oude server landt. Laat de oude omgeving daarna nog een tijdje draaien. Zo verloopt een website-migratie zonder dat je bezoekers er iets van merken.

Hoe neem je je e-mail mee?

E-mail is het onderdeel waar het het vaakst misgaat, en het is ook het pijnlijkst omdat verloren berichten niet terugkomen. De klassieke fout: iemand zet de MX-records om naar de nieuwe partij voordat de bestaande postbussen zijn gekopieerd. Vanaf dat moment komt nieuwe mail binnen op een lege omgeving en staat de oude mail nog achter een postbus waar je toegang toe kwijtraakt zodra het contract eindigt. De juiste volgorde is: eerst nieuwe postbussen aanmaken, dan de inhoud kopiëren met een IMAP-synchronisatie, dan pas de MX-records omzetten, en daarna nog een keer synchroniseren voor wat er tussendoor is binnengekomen.

Twee valkuilen bij mail specifiek. De eerste is POP3: als iemand jarenlang mail met POP3 heeft opgehaald, staan de berichten alleen lokaal in Outlook en niet op de server. Er valt dan niets te synchroniseren en je moet de mailbox handmatig importeren. De tweede is authenticatie. Je SPF-record, je DKIM-sleutel en je DMARC-beleid horen bij de partij die je mail verstuurt. Verhuis je zonder die records aan te passen, dan komt je mail bij ontvangers in de spam of wordt hij geweigerd. Laat de oude mailomgeving na de omzetting minstens een week doorlopen voor nagekomen berichten.

Hoe behoud je je vindbaarheid?

Dan het onderdeel waar je het meeste geld mee kunt verliezen zonder dat je het meteen ziet: je vindbaarheid. Verandert bij de overstap ook je website zelf, dan verandert vaak je URL-structuur mee. Elke oude URL die geen 301-redirect krijgt naar de inhoudelijk overeenkomende nieuwe pagina, geeft straks een 404 en verliest zijn positie. Crawl daarom je huidige site vóór de overstap en bewaar de volledige lijst met URL's. Exporteer daarnaast uit Search Console welke pagina's daadwerkelijk verkeer binnenhalen. Die twee lijsten zijn je blauwdruk.

Maak vervolgens een 1-op-1 koppeling tussen oud en nieuw. De grootste fout die we in de praktijk zien is dat alle oude URL's naar de homepage worden geredirect. Dat lijkt netjes en oogt als nul 404-fouten, maar Google schrijft in de documentatie over een siteverhuizing met URL-wijzigingen letterlijk dat je niet veel oude URL's naar één irrelevante bestemming zoals de homepage moet sturen, omdat dat als een zachte 404 behandeld kan worden. De waarde van die pagina gaat dan verloren. Een oude dienstenpagina hoort naar de nieuwe dienstenpagina te wijzen, een oud blogartikel naar dat artikel. Alleen als er echt geen equivalent bestaat, laat je een pagina bewust verdwijnen.

Controleer na de overstap een handvol dingen in de eerste week. Staat er geen noindex meer op de nieuwe site, want die stond er tijdens de bouw waarschijnlijk wel en dat vergeten is een klassieker. Werken je redirects allemaal en met een 301 in plaats van een 302. Is je nieuwe sitemap ingediend in Search Console. Staat je SSL-certificaat goed en gaat http netjes naar https. Werken je formulieren en komt de mail daadwerkelijk aan, want dat is niet hetzelfde als dat het formulier een bedanktscherm toont. En houd je Search Console een paar weken in de gaten op nieuwe 404-meldingen.

Hoe zorg je dat je nooit meer vastzit?

Nog een advies dat later goud waard is: regel de nieuwe situatie zo in dat je nooit meer vastzit. Zet het domein op naam van je eigen bedrijf, met een e-mailadres dat van jou is en niet van een medewerker die volgend jaar weg is. Zorg dat je zelf toegang hebt tot je DNS. Wees zelf eigenaar van je Google Analytics- en Search Console-property en geef je bureau toegang, in plaats van andersom. Vraag jaarlijks een export van bestanden en database, ook als je nergens heen wilt. Vastzitten is geen ongeluk, het is een optelsom van kleine dingen die op de verkeerde naam staan.

Hulp bij de overstap

Verhuizen is minder spannend dan het vooraf voelt als je het in de juiste volgorde doet. Bij een website-migratie zetten we de site eerst compleet op de nieuwe omgeving, brengen we redirects en mail in kaart en zetten we pas om als alles getest is. Daarna staat je site op onze hosting of op een omgeving die je zelf kiest, want eigenaar blijf je hoe dan ook. Wil je daarna niet opnieuw achterstallig onderhoud opbouwen, dan is een onderhoudscontract de saaie maar effectieve oplossing. Zit je nu klem en weet je niet waar te beginnen? Stuur ons je situatie, dan zeggen we eerlijk wat je zelf kunt regelen en wat niet.

Laatst bijgewerkt op 11 oktober 2026