Een website verhuizen klinkt vaak eenvoudiger dan het in de praktijk is. Niet omdat het per se ingewikkeld moet zijn, maar omdat je te maken krijgt met meerdere onderdelen die samen je online bereikbaarheid bepalen: je domeinnaam, DNS, hosting, databases, e-mail en beveiliging. Als één van die schakels niet klopt, merk je dat meteen aan downtime, ontbrekende mail of een site die “net anders” reageert. In dit artikel leggen we helder uit waar je op moet letten als je je website gaat verhuizen, hoe je risico’s beperkt en hoe je de verhuizing zo voorspelbaar mogelijk maakt, ook als je met meerdere omgevingen of zakelijke e-mail werkt.
Wat betekent website verhuizen precies?
Met website verhuizen bedoelen mensen vaak één van deze drie dingen:
- Je verhuist alleen de websitebestanden en database naar een andere hostingpartij, maar je domeinnaam blijft waar hij is.
- Je verhuist de hosting én je laat de domeinnaam “wijzen” naar de nieuwe omgeving via DNS.
- Je verhuist ook de domeinnaamregistratie naar een andere registrar, zodat beheer en facturatie op één plek zitten.
Die varianten lijken op elkaar, maar de impact verschilt. Als je bijvoorbeeld alleen hosting verhuist, blijft de domeinregistratie onveranderd, maar moet je wel DNS aanpassen. Verhuis je óók de domeinnaam, dan heb je te maken met verhuisautorisatie, registratieregels en timing. Het is daarom belangrijk om vooraf scherp te hebben wat je precies wilt verhuizen: content, infra, beheer, of alles tegelijk.
Waarom website verhuizen (en wanneer is het verstandig)?
Een website verhuizen is vaak een gevolg van een technische of zakelijke aanleiding. Bijvoorbeeld omdat je huidige omgeving niet meer meegroeit, omdat performance achterblijft, of omdat je meer controle wilt over security, back-ups en updates. Ook zie je het bij consolidatie: domeinen, hosting en e-mail onderbrengen bij één partij om beheer simpeler te maken.
Zakelijk gezien is “het werkt nu toch?” niet altijd een goede reden om niets te doen. Als je site kritiek is voor leadgeneratie, support of omzet, dan wil je voorspelbaarheid. Een verhuizing kan dan juist rust brengen, mits je het gestructureerd aanpakt. Andersom: als je site nauwelijks wijzigt en je huidige omgeving stabiel is, kan het verstandiger zijn om een verhuizing uit te stellen tot een natuurlijk moment, zoals een redesign of platformupgrade.
De bouwblokken van een website verhuizen: domein, DNS, hosting, data en mail
Om een website verhuizen goed te begrijpen, helpt het om het op te knippen in onderdelen. Veel problemen ontstaan doordat mensen alleen “de site” zien, terwijl de technische werkelijkheid breder is.
Domeinnaam: eigenaar, registrar en beheer
De domeinnaam is je adres op internet. De registrar is de partij waar je domeinnaam administratief beheerd wordt. Je kunt een website verhuizen zonder de registrar te wijzigen, maar je kunt ook de domeinnaam zelf verhuizen naar een andere partij. Dat kan handig zijn als je het beheer wilt centraliseren of als je het eigenaarschap en facturatie strak wilt inrichten.
Als je ook je domein wilt verplaatsen, lees dan vooraf hoe een domeinnaam verhuizen doorgaans werkt, zodat je weet welke gegevens en autorisaties je nodig hebt en wat de afhankelijkheden zijn.
DNS: de “telefoonlijst” van je domein
DNS (Domain Name System) vertaalt je domeinnaam naar technische bestemmingen, zoals het IP-adres van je webserver of de mailservers voor e-mail. Tijdens een website verhuizen is DNS meestal het kantelpunt: op het moment dat je records wijzigt, gaan bezoekers naar de nieuwe omgeving.
Belangrijke DNS-records die vaak meespelen:
- A of AAAA record: verwijst naar het IP-adres van je website.
- CNAME: alias naar een andere hostnaam, vaak gebruikt voor subdomeinen.
- MX: bepaalt waar e-mail voor je domein afgeleverd wordt.
- TXT: wordt gebruikt voor verificatie en e-mailauthenticatie (SPF, DKIM, DMARC).
DNS-wijzigingen verspreiden zich niet overal tegelijk. Dat heet propagatie en wordt beïnvloed door TTL (Time To Live), een caching-instelling die bepaalt hoe lang resolvers records mogen onthouden. Als je wilt weten waarom verspreiding tijd kost en hoe DNS werkt in de internetketen, is de uitleg van Cloudflare een goede technische achtergrond: https://www.cloudflare.com/learning/dns/what-is-dns/.
Hosting: waar je site daadwerkelijk draait
Hosting is de omgeving waar je websitecode en database draaien. Dat kan variëren van eenvoudige webhosting tot een beheerde omgeving. In zakelijke situaties speelt vaak mee: resources, isolatie, monitoring, schaalbaarheid en beheer. Als je groei verwacht of je wilt meer voorspelbaarheid bij piekbelasting, is Cloud Hosting vaak een logische richting omdat je daar doorgaans flexibeler kunt schalen en beter kunt scheiden tussen componenten (bijvoorbeeld web en database), zonder dat je alles “vast” hoeft te zetten op één server.
Bij website verhuizen is het belangrijk dat de nieuwe hosting technisch past bij je stack. Denk aan PHP-versies, databasecompatibiliteit, caching, storage en de manier waarop je deployt. Een verhuizing is ook een kans om technische schuld te verkleinen, maar alleen als je die scope bewust kiest en niet alles tegelijk probeert te repareren.
Data: bestanden, database en uploads
Veel websites bestaan uit twee delen: bestanden (code, templates, uploads) en een database (content, instellingen, gebruikers). Bij een website verhuizen gaat het vaak mis door mismatch in databaseversies, ontbrekende extensies, of door te grote uploads die niet volledig meekomen. Ook kunnen paden of absolute URL’s in content problemen geven als je van domein of structuur verandert.
E-mail: vaak het meest risicovolle onderdeel
E-mail “hangt” aan je domein via MX-records. Als je tijdens website verhuizen ook DNS aanpast, kun je onbedoeld e-mail omleiden. Dat leidt tot gemiste berichten of afleverproblemen. Daarom is het verstandig om e-mail expliciet mee te nemen in je plan: welke mailprovider blijft, welke records staan er nu, en moeten SPF, DKIM en DMARC blijven werken zoals ze deden?
Website verhuizen zonder downtime: wat is realistisch?
Volledige nul downtime is niet altijd realistisch, maar je kunt het risico sterk verkleinen. In de praktijk draait het om drie principes:
- Werk met een parallelle nieuwe omgeving waar je uitgebreid kunt testen vóór je DNS omschakelt.
- Beperk het “schakelmoment” tot een gecontroleerde wijziging, meestal DNS.
- Houd rekening met caching, sessies en achtergrondprocessen die nog naar de oude omgeving wijzen.
Bij dynamische websites (zoals webshops of portals) kan een korte “freeze” nodig zijn: tijdelijk geen contentwijzigingen of bestellingen verwerken rondom het omschakelmoment, zodat de database consistent blijft. Bij minder dynamische sites kun je vaak ruimer migreren en alleen vlak voor livegang een laatste synchronisatie doen.
Risico’s en valkuilen bij website verhuizen (en hoe je ze voorkomt)
1) DNS te vroeg wijzigen
Als je DNS al wijzigt terwijl de nieuwe omgeving nog niet volledig getest is, stuur je bezoekers naar een onvolledige setup. Ook kan je certificaat (TLS/SSL) nog niet correct zijn ingericht of je applicatie kan nog verwijzen naar resources die ontbreken. Plan DNS als laatste stap, niet als eerste.
2) E-mailrecords overschrijven
Een veelvoorkomende fout bij website verhuizen is dat iemand “even” de DNS-zone vervangt en daarmee MX en TXT-records wist. Het gevolg kan zijn dat e-mail ineens niet meer aankomt of dat uitgaande mail sneller in spam belandt. Controleer daarom altijd welke records e-mail en authenticatie regelen, en zorg dat die ongewijzigd blijven als je mail niet verhuist.
Voor de achtergrond van DMARC en waarom dit belangrijk is voor afleverbaarheid en bescherming tegen spoofing, is de NCSC-uitleg een betrouwbare bron: https://www.ncsc.nl/onderwerpen/emailbeveiliging/dmarc.
3) Onvoldoende testdekking
“De homepage laadt” is geen testplan. Test ook formulieren, search, inloggen, betaalflows, API-koppelingen, cronjobs en e-mailnotificaties. Bij website verhuizen wil je zeker weten dat ook randfunctionaliteit werkt, juist omdat die vaak afhankelijk is van specifieke serverinstellingen of firewallregels.
4) Vergeten redirects en canonical instellingen
Als URL’s veranderen, kan je SEO schade oplopen door 404’s of dubbele content. Denk aan 301-redirects, canonical tags en sitemap updates. Ook zonder URL-wijzigingen is het verstandig om na website verhuizen te controleren of je site nog dezelfde indexeerbare structuur heeft en of tracking en consent tooling correct functioneren.
5) Performanceverschillen door caching en resources
Dezelfde site kan op een andere omgeving anders presteren door caching, PHP workers, database-tuning of file I/O. Meet vóór en na, zodat je objectief ziet wat de verhuizing oplevert. Een website verhuizen is ook een geschikt moment om laadtijden, TTFB en foutpercentages structureel te monitoren.
Website verhuizen en domeinnaam overzetten: samen of apart?
Je kunt website verhuizen en je domeinnaam overzetten los van elkaar uitvoeren. Dat kan prettig zijn als je risico wilt spreiden: eerst hosting migreren, daarna pas registratiebeheer centraliseren. Het kan ook andersom, maar dat is vaak minder logisch omdat je website technisch gezien nog niets opschiet met alleen een administratieve verhuisstap.
Checklist: voorbereiding voor website verhuizen
Onderstaande punten helpen om een website verhuizen voorspelbaar te maken, zonder dat dit een support-achtige stap voor stap handleiding wordt. Zie het als een volwassen voorbereidingslijst voor zakelijke omgevingen.
- Inventariseer: wat draait waar? Website, database, DNS, e-mail, certificaten, back-ups.
- Leg afhankelijkheden vast: API’s, webhook endpoints, payment providers, SSO, SMTP, CDN.
- Bepaal het doel: alleen hosting wisselen, ook domeinbeheer, ook mail, of herplatformen.
- Maak een testplan: functioneel, technisch, security, performance en logging.
- Regel terugvalscenario: hoe schakel je terug als er iets misgaat?
- Plan communicatie: intern en extern, inclusief onderhoudsvenster als dat nodig is.
- Controleer e-mailauthenticatie: SPF, DKIM, DMARC en eventuele verificatie-TXT’s.
Praktische scenario’s: website verhuizen in de echte wereld
Scenario 1: WordPress site verhuizen met minimale risico’s
Bij WordPress draait het vaak om compatibiliteit van PHP en database, en om plugins die afhankelijk zijn van servermodules of specifieke cron-instellingen. Test vooral contactformulieren, caching plugins, media uploads en e-mailverzending. Let ook op hardcoded URLs in content en in de database, vooral als je van domein of van http naar https wijzigt.
Een website verhuizen is hier vaak goed te doen met een parallelle omgeving, gevolgd door een gecontroleerde DNS-switch. Zakelijke sites gebruiken daarnaast regelmatig staging om wijzigingen te valideren voordat ze live gaan.
Scenario 2: Webshop verhuizen met bestellingen en voorraad
Webshops zijn dynamisch: bestellingen, betalingen, voorraadmutaties en klantaccounts veranderen continu. Daarom is consistentie belangrijker dan “snel klaar zijn”. Vaak kies je rond website verhuizen een kort onderhoudsvenster of een moment met laag verkeer. Ook wil je zeker weten dat betaalproviders en webhook callbacks naar de juiste omgeving wijzen.
Scenario 3: Zakelijke site met koppelingen en mailflows
Bij B2B-sites zie je vaak integraties met CRM, marketing automation, support tooling en identity providers. Een website verhuizen raakt dan al snel meer dan alleen hosting. Neem daarom ook DNS-records voor subdomeinen, verificaties en mailflows mee in de inventarisatie. Het succes zit hier in de voorbereiding: weten welke koppeling waarheen praat, en hoe je dat test.
Veelgestelde vragen over website verhuizen
1) Hoe lang duurt website verhuizen meestal?
Dat hangt af van de complexiteit van je website, de hoeveelheid data en het aantal afhankelijkheden zoals e-mail en koppelingen. Een eenvoudige site kan in korte tijd technisch overgezet worden, maar testen en DNS-propagatie vragen vaak extra tijd. Voor zakelijke omgevingen is het verstandig om ook ruimte te plannen voor validatie, monitoring en een eventuele terugval.
2) Kan ik website verhuizen zonder dat bezoekers iets merken?
In veel gevallen kun je de impact voor bezoekers heel klein maken, vooral als je met een parallelle nieuwe omgeving werkt en pas omschakelt als alles getest is. Toch blijven er factoren zoals DNS-caching en actieve sessies die je niet volledig controleert. Daarom is het realistischer om te streven naar “minimale impact” in plaats van absoluut nul risico.
3) Wat is het verschil tussen website verhuizen en domeinnaam verhuizen?
Website verhuizen gaat over waar je website draait: bestanden, database en de hostingomgeving. Domeinnaam verhuizen gaat over het administratieve beheer van je domein bij een registrar, inclusief verlenging en beheerrechten. Je kunt je website verhuizen zonder je domeinnaam te verhuizen, zolang je DNS maar goed staat.
4) Wat moet ik doen met e-mail als ik een website ga verhuizen?
E-mail blijft vaak gewoon bij dezelfde provider, maar je moet ervoor zorgen dat de DNS-records voor mail intact blijven. Bij een wijziging van DNS of nameservers is het belangrijk om MX en relevante TXT-records (zoals SPF, DKIM en DMARC) niet kwijt te raken. Als je ook e-mail wilt migreren, vraagt dat meestal om extra planning en testen, los van de webmigratie.
5) Waar gaat website verhuizen het vaakst mis?
De meest voorkomende oorzaken zijn onvolledige DNS-zones, te weinig testen en onderschatting van afhankelijkheden zoals API’s en mail. Ook zien we dat mensen te laat aan certificaten en redirects denken, waardoor bezoekers foutmeldingen krijgen of SEO-impact ontstaat. Een goede inventarisatie vooraf is meestal het verschil tussen “spannend” en “gecontroleerd”.
6) Is Cloud Hosting een goede keuze als ik mijn website wil verhuizen?
Voor veel organisaties is Cloud Hosting een logische stap als je meer schaalbaarheid, betere scheiding van componenten of professioneler beheer wilt. Het is niet altijd nodig voor een kleine, statische site, maar bij groei, piekbelasting of hogere beschikbaarheidseisen is het vaak passend. Belangrijk is dat de omgeving aansluit op jouw applicatie en beheerwensen, niet dat je per se “zwaarder” gaat.
Tot slot: website verhuizen met rust en overzicht
Een website verhuizen hoeft geen stressproject te zijn, als je de verhuizing benadert als een technisch traject met duidelijke afhankelijkheden. Bij Oxilion houden we van heldere uitleg, korte lijnen en een aanpak die past bij jouw situatie: van een eenvoudige site tot een zakelijke omgeving met e-mail en koppelingen. Wil je sparren over de beste route, de risico’s in jouw huidige setup of de juiste hostingrichting, neem dan contact met ons op. We denken met je mee, stellen de juiste vragen en helpen je om de verhuizing gecontroleerd en netjes uit te voeren, zonder ruis en zonder onnodige complexiteit.
