Een website verhuizen is pas klaar wanneer bezoekers de juiste site bereiken, nieuwe gegevens behouden blijven en de functies werken die je bedrijf nodig heeft. Dat de homepage verschijnt, bewijst niet dat je contactformulier, mailbox of geplande taak is meegekomen.
Maak eerst een controleerbare kopie, test die vóór de omschakeling en leg vast wanneer je teruggaat of doorgaat. Deze gids gaat over andere hosting met dezelfde domeinnaam en dezelfde pagina-URL’s. Een nieuwe domeinnaam, ander CMS of herontwerp vraagt extra stappen. Download het invulbare overdrachtsblad en bespreek de open punten met degene die de verhuizing uitvoert.
1. Bepaal wat verhuist en wie waarvoor verantwoordelijk is
Websitehosting, domeinregistratie, DNS-beheer en e-mail zijn verschillende onderdelen. Ze kunnen bij één leverancier zitten, maar hoeven niet tegelijk te verhuizen. De domeinnaam kan bij dezelfde registrar blijven terwijl de website naar een andere server gaat. Externe zakelijke e-mail kan eveneens blijven staan.
Maak vóór het opzeggen een overzicht:
| Onderdeel | Wat leg je vast? |
|---|---|
| Website | Bestanden, uploads, softwareversies en serverinstellingen |
| Database | Welke database hoort bij de site, en wie kan exporteren en herstellen? |
| Domein en DNS | Wie beheert de registratie en de records die verkeer sturen? |
| Waar staan mailboxen, aliassen en doorstuurregels? | |
| Achtergrondwerk | Geplande taken, formulieren, externe koppelingen en meldingen |
| Toegang | Wie kan testen, omschakelen, terugdraaien en opzeggen? |
Zet geen wachtwoorden of tokens in het overdrachtsblad. Regel toegang via een afgesproken veilige methode. Vraag je huidige en nieuwe leverancier wat hun verhuisservice precies omvat: “we verhuizen je website” zegt nog niets over mailboxinhoud, licenties of een formulierkoppeling.
2. Bewaar een herstelbare beginsituatie
Maak een back-up buiten de omgeving die je gaat veranderen. Controleer of je hem kunt terugvinden en herstellen. Een melding “back-up voltooid” is minder overtuigend dan een herstelproef in een aparte omgeving.
Bij een gebruikelijke WordPress-site heb je zowel de bestanden als de database nodig. Thema’s, plugins en uploads staan niet allemaal in de database; een download van alleen de websitemap bevat die database meestal ook niet. Bewaar bij elkaar horende versies als één herkenbare set, met datum en tijd.
Leg daarnaast de actuele DNS-records, bestaande doorverwijzingen en noodzakelijke instellingen vast. Noteer welke configuratie buiten de website wordt beheerd. Denk aan een verzenddienst voor formuliermail, een externe opslaglocatie of een taak die iedere nacht draait.
Stop als niemand kan aantonen hoe herstel werkt. Vraag eerst om een bruikbare back-up en een verantwoordelijke voor het herstel. De oude omgeving opzeggen voordat die basis vaststaat maakt een gewone verhuizing onnodig moeilijk terug te draaien.
3. Test de nieuwe omgeving zonder normaal verkeer om te leiden
Laat een kopie klaarzetten bij de nieuwe host. Controleer dat de benodigde softwareversies, databaseverbinding, bestanden en instellingen aanwezig zijn. Een verhuizing is geen goed moment om ongemerkt ook plugins, frameworkversies en de sitestructuur te vervangen: dan wordt onduidelijk waardoor een fout ontstaat.
Gebruik een afgeschermde testomgeving of een door de host ondersteunde previewmethode. Een publiek bereikbare testkopie vraagt een bewuste aanpak tegen ongewenste indexering; een noindex-instelling is bovendien geen toegangsbeveiliging. Bescherm vertrouwelijke gegevens met echte toegangsbeperking.
De testkopie mag niet onbedoeld echte klanten mailen, betalingen verwerken of dezelfde geplande taken uitvoeren als de actieve site. Test zulke functies met afgesproken testgegevens en testvoorzieningen. Voor de echte omschakeling controleer je vervolgens ook de juiste live-instellingen, het certificaat en het bedoelde domein. Een previewadres bewijst die laatste onderdelen niet vanzelf.
4. Controleer gedrag met een kort acceptatieblad
Kies vooraf de functies die aantoonbaar moeten werken. Test niet alleen de pagina die je toevallig als eerste ziet. Gebruik een herkenbare testreferentie zodat je het resultaat aan de juiste omgeving kunt koppelen.
Praktisch startpunt voor een kleine zakelijke site:
| Test | Bewijs dat je bewaart | Reden om niet om te schakelen |
|---|---|---|
| Belangrijke pagina’s | URL, tijdstip, zichtbare inhoud en status | Ontbrekende pagina of foutmelding |
| Afbeeldingen en downloads | Bestand opent en inhoud klopt | Gebroken verwijzing of verkeerde versie |
| Contactformulier | Afgesproken test komt aan op de juiste bestemming | Alleen een succesmelding, zonder ontvangstbewijs |
| Inloggen en beheer | Bevoegde tester kan de benodigde handeling uitvoeren | Rechten of sessies werken niet |
| Doorverwijzingen | Oude relevante URL komt op de bedoelde pagina uit | Lus, foutpagina of verkeerde bestemming |
| Achtergrondtaak | Vastgelegde testuitkomst, zonder dubbele verwerking | Onbekend of oud én nieuw tegelijk actief zijn |
Vul in het CSV-overdrachtsblad de eigenaar, waarneming en open actie in. Open het als UTF-8 met komma als scheidingsteken als je spreadsheetprogramma de kolommen niet vanzelf herkent. De lege velden zijn bewust: de verhuispartij moet concrete resultaten invullen, geen voorgedrukte vinkjes bevestigen.
5. Plan DNS, e-mail en nieuwe gegevens samen
DNS bepaalt naar welke omgeving verkeer wordt gestuurd. Bij een hostingwissel pas je de relevante webrecords aan volgens de aanwijzingen van je DNS- en hostingbeheerder. Een wijziging van nameservers is een bredere verandering dan alleen het webadres aanpassen: ook andere records moeten dan in de nieuwe DNS-zone aanwezig zijn.
Neem bestaande mailinstellingen niet als bijzaak mee. Als mail bij dezelfde externe dienst blijft, controleer je dat de verwijzingen naar die dienst behouden blijven. Als mailboxen wél verhuizen, zijn het overzetten van inhoud, aliassen, clients en de mailomschakeling afzonderlijke werkzaamheden. Test ontvangen én verzenden via een afgesproken testcontact.
DNS-antwoorden kunnen tijdelijk uit caches komen. Houd daarom rekening met bezoekers die nog op de oude omgeving terechtkomen. Vraag de beheerder hoe bestaande TTL-instellingen, de omschakeling en de controle van beide omgevingen samen worden gepland. Spreek geen gegarandeerde minuut af waarop iedereen vanzelf over is.
Belangrijker nog: waar komen nieuwe inzendingen of bestellingen terecht tijdens de overgang? Voor een site die gegevens opslaat is een eerste kopie niet genoeg. Leg een laatste synchronisatie, een gecontroleerde schrijfpauze of een andere door de uitvoerder onderbouwde aanpak vast. Laat dit punt niet open tot na het wijzigen van DNS.
6. Werkvoorbeeld: brochurewebsite met externe mail
Stel: een fictief adviesbureau heeft een WordPress-site met tien pagina’s en een contactformulier. Het domein en de zakelijke mailboxen blijven bij hun huidige leveranciers. Alleen de websitehosting verhuist. Het formulier verstuurt berichten via een aparte maildienst. Er is geen webshop.
De eigenaar kiest drie noodzakelijke acceptaties: de dienstenpagina is compleet, de brochure opent en een testaanvraag komt op de afgesproken bestemming aan. De uitvoerder herstelt bestanden en database op de nieuwe host en controleert de formulierconfiguratie. Mailboxen worden in dit scenario niet gekopieerd; hun bestaande DNS-verwijzingen blijven behouden.
Bij de eerste controle toont het formulier een succesmelding, maar er komt niets aan. Het overdrachtsblad krijgt daarom de status stop: aflevering niet aangetoond. De uitvoerder onderzoekt de verzending en herhaalt de afgesproken test. Pas na aantoonbare ontvangst én de overige geslaagde controles volgt de beslissing over omschakelen.
Dit is een fictieve oefening, geen klantcase of uitgevoerde migratie. De les is praktisch: een acceptatiecriterium beschrijft wat de gebruiker moet kunnen bereiken. Het gaat verder dan de aanwezigheid van dezelfde pagina op een andere server.
7. Spreek vóór de omschakeling af wanneer je teruggaat
Wijs één persoon aan die het go/no-go-besluit neemt. Leg vast welke fout een stop betekent, wie onderzoekt en welke herstelroute beschikbaar is. Houd de oorspronkelijke omgeving beschikbaar zolang dat voor een gecontroleerde overgang nodig is.
Terugzetten van DNS is niet altijd volledig herstel. Als de nieuwe omgeving inmiddels formulieren, wijzigingen of orders heeft opgeslagen, moet eerst duidelijk zijn hoe die gegevens behouden blijven. Anders kun je bezoekers terugsturen naar een oudere gegevensstand. De uitvoerder moet die afweging opnemen in het terugvalplan.
Kies een omschakelmoment waarop de verantwoordelijke mensen bereikbaar zijn. Controleer daarna het echte domein, HTTPS, de belangrijke gebruikershandelingen en waar nieuwe gegevens aankomen. Bewaar tijdstip en uitkomst in het blad. Bij een fout wordt daarmee zichtbaar welke stap nog wel en welke niet is bevestigd.
8. Rond af op bewijs en draag het beheer over
Beëindig de oude hosting pas nadat de overdracht is aangetoond en duidelijk is dat er geen noodzakelijke bestanden, mailfuncties of achtergrondtaken achterblijven. Gebruik waar mogelijk de serverlogs van beide omgevingen om het verkeer te volgen. Controleer ook welke opzegging eventueel gekoppelde diensten raakt.
Voor vindbaarheid blijven dezelfde pagina-URL’s het uitgangspunt. Controleer dat tijdelijke testblokkades op de productieomgeving weg zijn, dat belangrijke pagina’s bereikbaar zijn en dat Search Console-verificatie blijft werken. Er is geen garantie dat crawlgedrag of posities exact gelijk blijven na een hostingwissel.
Maak de overdracht compleet met de nieuwe beheerlocatie, toegangsverantwoordelijke, back-uproutine en een eigenaar voor controles. De gids over websiteonderhoud en de bijbehorende kosten helpt om dat vervolg af te bakenen. Gebruik de scorekaart voor een professionele website als je ook de kwaliteit van de hele site wilt beoordelen.
Blijkt tijdens de voorbereiding dat je eigenlijk functies of de website zelf wilt vervangen? Scheid dat besluit van de verhuizing. Op de pagina website laten maken staat de route voor een nieuwe websiteopdracht. Een hostingmigratie is daarmee niet automatisch inbegrepen: scope, uitvoering en verantwoordelijkheid moeten eerst worden afgesproken.
