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

Er is een moment waarop je merkt dat je vastzit. Je vraagt een simpele tekstwijziging aan en er gebeurt drie weken niets. Je vraagt om toegang tot je eigen hosting en krijgt een vaag antwoord. Je vraagt wat je website eigenlijk kost per jaar en niemand kan het uitsplitsen. Overstappen naar een andere partij voelt dan als een dreiging, want je hebt geen idee wat je precies in handen hebt. Dit artikel zet op een rij wat je bezit, wat je moet opvragen en in welke volgorde je verhuist zonder dat je site of je mail eruit klapt.

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.

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.

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.

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.

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.

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.

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.

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.

Wij doen dit soort verhuizingen regelmatig, en meestal is het minder spannend dan het vooraf voelt. 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.

Veelgestelde vragen over overstappen van webbureau

Van wie is mijn domeinnaam?
Van degene die als houder geregistreerd staat, niet van degene die de factuur stuurt. Voor een .nl-domein kun je de houder opzoeken via de whois van SIDN. Staat je bureau daar als houder, dan moet er eerst een houderwijziging plaatsvinden voordat je kunt verhuizen.

Hoe vraag ik een verhuiscode op?
Bij je huidige registrar. Voor .nl heet dat een verhuistoken, voor .com, .eu en de meeste andere extensies een auth- of EPP-code. Je nieuwe partij zet met die code de verhuizing in gang. Reken op dagen doorlooptijd, niet op minuten.

Mag een webbureau mijn site vasthouden bij een conflict?
Toegang tot hosting is iets anders dan eigendom van je content en je domein. Je teksten, foto's en klantgegevens zijn van jou, en persoonsgegevens moeten onder de AVG op verzoek worden teruggegeven of verwijderd. Over broncode van maatwerk kan wél discussie ontstaan als overdracht van rechten nooit schriftelijk is vastgelegd.

Gaat mijn site offline tijdens de verhuizing?
Niet bij een goede voorbereiding. Je zet de site eerst volledig op de nieuwe server, test daar op een tijdelijk adres, verlaagt de TTL van je DNS een dag vooraf en zet dan pas de records om. Beide omgevingen draaien even naast elkaar.

Raak ik e-mail kwijt bij een migratie?
Alleen als de MX-records worden omgezet voordat de postbussen zijn gekopieerd, of als er nog POP3 gebruikt wordt en de berichten alleen lokaal staan. De juiste volgorde is: postbussen aanmaken, inhoud synchroniseren via IMAP, dan pas MX omzetten, en daarna nog een keer nasynchroniseren.

Verlies ik mijn Google-posities?
Niet als je URL-structuur gelijk blijft of als elke oude URL een 301-redirect krijgt naar de inhoudelijk overeenkomende nieuwe pagina. Verlies ontstaat door alles naar de homepage te redirecten, door een vergeten noindex of door oude URL's die een 404 gaan geven.

Wat vraag ik precies op bij mijn oude bureau?
Een export van bestanden en database, de verhuistoken van je domein, toegang tot of export van je DNS-records, een lijst met alle e-mailadressen op je domein, eigendom van je Analytics- en Search Console-property, en op wiens naam de betaalde plugin-licenties staan. Vraag het schriftelijk en in één mail.