Een website verhuizen is meer dan bestanden kopiëren en de domeinnaam omzetten. De website kan gekoppeld zijn aan e-mail, formulieren, cronjobs, externe API’s, betaalproviders, DNS-records en zoekmachine-indexatie. Met een rustige voorbereiding kan de overgang vrijwel onmerkbaar verlopen. Zonder plan ontstaan juist ontbrekende orders, foutmeldingen, dubbele content of een daling in organisch verkeer.
Begin met een volledige inventarisatie
Noteer de domeinen en subdomeinen, DNS-zone, mailboxen, databases, PHP-versie, geplande taken, SSL-certificaten, redirects en externe koppelingen. Controleer ook hoeveel opslag werkelijk wordt gebruikt en of er grote archieven of oude back-ups tussen staan. Een migratie is een goed moment om ballast niet mee te nemen.
Maak eerst een testkopie
Kopieer bestanden en database naar de nieuwe omgeving en test via een tijdelijk adres of een lokale hosts-aanpassing. Houd de testomgeving uit zoekmachines met authenticatie of een duidelijke noindex. Controleer inloggen, formulieren, e-mail, afbeeldingen, permalinks, winkelmandje, betalingen en achtergrondtaken.
De nieuwe omgeving kan andere PHP-versies, modules of beveiligingsregels gebruiken. Los compatibiliteitsproblemen vóór de publieke omschakeling op, niet tijdens het drukste moment.
Verlaag de DNS-TTL op tijd
De TTL bepaalt hoelang resolvers een DNS-antwoord mogen bewaren. Verlaag relevante records bijvoorbeeld een dag voor de migratie, zodat de uiteindelijke wijziging sneller wordt opgepakt. Niet iedere cache volgt de waarde onmiddellijk; houd daarom rekening met een overgangsperiode waarin bezoekers op beide servers kunnen uitkomen.
Plan de laatste synchronisatie
Bij een statische website is de eerste kopie vaak voldoende. Een webshop, forum of ledensite blijft veranderen. Plan daarom een korte contentstop of onderhoudsperiode, maak een laatste database- en uploadsync en zet daarna DNS om. Zo voorkomt u dat bestellingen of reacties alleen op de oude server achterblijven.
Bescherm SEO-signalen
Als alleen de hosting verandert, moeten URL’s hetzelfde blijven. Controleer canonicals, robots.txt, XML-sitemaps en statuscodes. Verandert ook de sitestructuur of domeinnaam, maak dan een één-op-één redirectlijst met permanente 301-redirects. Stuur niet alle oude pagina’s gemakshalve naar de homepage; dat verliest relevantie en maakt fouten moeilijker zichtbaar.
- Bewaar paginatitels, metadata en hoofdcontent waar mogelijk.
- Werk interne links, structured data en hreflang bij.
- Voeg de nieuwe sitemap toe in Search Console.
- Controleer 404’s, redirectketens en indexeerbaarheid na livegang.
Vergeet e-mail en DNS-beveiliging niet
Een verhuizing kan MX-, SPF-, DKIM en DMARC-records raken. Kopieer de volledige DNS-zone bewust en controleer welke records echt moeten wijzigen. Test inkomende en uitgaande mail afzonderlijk. Pas SPF alleen aan wanneer een nieuwe server daadwerkelijk gaat verzenden.
Uitgebreid stappenplan: van voorbereiding tot 72 uur na livegang
Fase 1 — zeven tot veertien dagen vooraf
- Bepaal de scope. Schrijf op welke website, subdomeinen, mailboxen, databases, DNS-records, cronjobs en externe diensten meeverhuizen. Benoem wat nadrukkelijk niet wordt gewijzigd.
- Wijs verantwoordelijkheden toe. Leg vast wie de technische omschakeling uitvoert, wie functioneel test, wie klanten informeert en wie een terugvalbesluit mag nemen.
- Kies een migratievenster. Gebruik bezoek- en orderstatistieken om een rustig moment te kiezen. Reserveer extra tijd vóór en na de verwachte omschakeling.
- Maak een nulmeting. Noteer TTFB, laadtijd, Core Web Vitals, actieve plug-ins, PHP-versie, databasegrootte, aantal bestanden en belangrijke conversies. Maak screenshots van kritieke instellingen.
- Verlaag DNS-TTL. Zet alleen de records die gaan veranderen tijdelijk lager, bijvoorbeeld naar 300 seconden. Doe dit ruim vóór de migratie zodat de oude TTL al is verlopen.
- Controleer toegang. Test SSH/SFTP, cPanel, database, domeinbeheer, CDN, betaalprovider en Search Console. Wachtwoorden zoeken tijdens de omschakeling kost onnodig tijd.
Fase 2 — maak een aantoonbaar complete bronback-up
Maak vóór iedere wijziging een volledige kopie van bestanden en database. Noteer tijdstip, bestandsgrootte en waar de kopie staat. Controleer of het archief kan worden geopend en of de database-export eindigt zonder fouten. Bewaar deze herstelkopie buiten zowel de oude als de nieuwe productieserver.
- Sluit cachemappen, tijdelijke sessies en oude lokale back-ups uit wanneer ze niet nodig zijn.
- Neem verborgen bestanden zoals
.htaccessen relevante configuratiebestanden wel mee. - Exporteer de database met de juiste tekenset en controleer tabellen op fouten.
- Leg checksums of minimaal bestandenaantallen en totale grootte vast, zodat u bron en doel kunt vergelijken.
Fase 3 — bouw en beveilig de nieuwe omgeving
Maak de nieuwe accountstructuur, databasegebruiker en PHP-configuratie aan. Activeer SSL, firewallregels, malwaredetectie, back-ups en monitoring voordat de site publiek wordt. Gebruik niet automatisch exact dezelfde oude instellingen: controleer of de nieuwe omgeving een modernere PHP-versie of andere veilige standaard vereist.
Importeer bestanden en database. Voer domein- of padvervangingen uit met gereedschap dat geserialiseerde WordPress-data begrijpt; een gewone tekstvervanging kan widgets en plug-ininstellingen beschadigen. Controleer bestandsrechten, eigenaar, uploads en de verbinding met de database.
Fase 4 — test de stagingkopie systematisch
Test via een lokale hosts-regel of afgeschermd stagingadres, zodat publiek DNS nog naar de oude server blijft wijzen. Gebruik een checklist en noteer per onderdeel geslaagd, fout of niet van toepassing.
- Homepage, belangrijkste landingspagina’s, zoekfunctie en 404-pagina.
- WordPress-login, rollen, wachtwoordreset en beveiligde beheeracties.
- Contact-, offerte- en nieuwsbriefformulieren inclusief ontvangst van e-mail.
- WooCommerce: product, voorraad, winkelmand, kortingscode, checkout, betaling, ordermail en webhook.
- Afbeeldingen, downloads, PDF’s, video-embeds en grote mediabestanden.
- Permalinks, redirects, canonicals, hreflang, structured data, robots.txt en XML-sitemap.
- Cronjobs, imports, exports, API-koppelingen, licenties en externe IP-allowlists.
- Page cache, Redis-objectcache, sessies, uitsluitingen voor account- en checkoutpagina’s.
- Mobiel, desktop en ten minste twee browsers.
Fase 5 — bereid het terugvalplan voor
Een rollback is geen mislukking maar een vooraf ontworpen veiligheidsklep. Schrijf op welke DNS-records teruggezet moeten worden, hoe nieuwe transacties worden veiliggesteld en tot welk moment terugschakelen nog verantwoord is. Definieer concrete criteria, bijvoorbeeld mislukte betalingen, ontbrekende data, ernstige 5xx-fouten of een niet-oplosbare e-mailstoring.
Fase 6 — de laatste synchronisatie en omschakeling
- Zet de website indien nodig kort in onderhoud of maak alleen wijzigingen die u later kunt nasynchroniseren.
- Noteer de laatste order-, gebruiker- of content-ID op de oude omgeving.
- Maak een nieuwe database-export en synchroniseer gewijzigde uploads sinds de stagingkopie.
- Importeer de laatste database, wis caches en voer een korte rooktest uit op de nieuwe server.
- Wijzig A/AAAA- of relevante CNAME-records. Laat MX-records ongemoeid tenzij e-mail bewust meeverhuist.
- Controleer vanaf meerdere resolvers welk IP wordt teruggegeven en test de site op zowel oud als nieuw IP.
- Haal onderhoud pas weg wanneer database, formulieren, login en belangrijkste conversiepad op de nieuwe omgeving werken.
Fase 7 — de eerste twee uur
Bekijk live foutlogs, PHP-errors, firewallmeldingen, CPU, geheugen en databasebelasting. Test formulieren en transacties opnieuw vanaf een normale internetverbinding. Controleer of nieuwe orders, accounts en uploads uitsluitend op de nieuwe omgeving terechtkomen. Vergelijk het laatste ID van de oude server met de eerste nieuwe transacties om een datagat uit te sluiten.
Fase 8 — na 24 en 72 uur
- Controleer Search Console, 404-rapporten, sitemapverwerking en crawlproblemen.
- Vergelijk organisch verkeer, conversies, responstijd en foutpercentage met de nulmeting.
- Controleer SPF, DKIM, DMARC, reverse DNS en aflevering van website-e-mail.
- Verhoog DNS-TTL weer naar de normale waarde wanneer alles stabiel is.
- Maak een nieuwe volledige back-up van de werkende doelomgeving en voer een kleine hersteltest uit.
- Verwijder de oude omgeving pas na de afgesproken bewaartermijn en nadat gevoelige gegevens veilig zijn gewist.
Controleer na de omschakeling
Test vanaf verschillende verbindingen, controleer het certificaat, bekijk serverlogs en monitor foutpercentages, responstijd en belangrijke conversies. Laat de oude omgeving tijdelijk intact en alleen-lezen totdat u zeker weet dat alle data is overgekomen. Maak vervolgens direct een nieuwe back-up van de werkende productieomgeving.
Een goede migratie is saai — en dat is positief
Het doel is geen spectaculaire nachtactie, maar een voorspelbare overgang met een terugvalplan. Leg vast wie beslist, hoe u terugschakelt en hoe lang dat mogelijk blijft. Met voorbereiding kan zelfs een complexe WordPress-site gecontroleerd worden verhuisd.
Wilt u uw website naar Gigatech verhuizen? Bekijk onze WordPress-hosting of neem vooraf contact op via Support. Dan kunnen we afhankelijkheden en het beste migratiemoment samen bepalen.
