Website verhuizen naar andere hosting: zo voorkom je downtime en SEO-problemen

Je website verhuizen naar andere hosting klinkt alsof je op één moment de oude server uitzet en hoopt dat de nieuwe het overneemt. Dat is precies hoe je onnodige downtime, ontbrekende e-mail of een halve website op de verkeerde server krijgt.

Een veilige verhuizing werkt anders: je bouwt eerst een complete kopie op de nieuwe hosting, test die terwijl de oude website gewoon live blijft, en wijzigt pas daarna DNS. Als je dezelfde domeinnaam en URL’s behoudt, hoeft een hostingwissel bovendien geen klassieke SEO-migratie met honderden redirects te zijn.

Wanneer is het tijd om van hosting te veranderen?

Een hostingwissel is zinvol wanneer de huidige omgeving je website structureel tegenhoudt: terugkerende storingen, trage serverrespons, te weinig resources, onduidelijke ondersteuning, verouderde softwareversies of een pakket dat niet meer bij de website past.

Prijs kan natuurlijk ook een reden zijn, maar verhuis niet uitsluitend voor een paar euro verschil als je daarvoor goede support, back-ups of stabiliteit opgeeft. Voor een bedrijfswebsite is voorspelbare ondersteuning vaak belangrijker dan het goedkoopste pakket.

Controleer vóór je beslist ook of het probleem echt bij hosting ligt. Een zware WordPress-site met slechte plugins wordt niet automatisch snel op een andere server. Als performance de hoofdreden is, onderzoek dan eerst wat de website vertraagt. De gids WordPress sneller maken helpt om hostingproblemen van applicatieproblemen te scheiden.

Wat moet er eigenlijk mee verhuizen?

Onderdeel	Waarom het belangrijk is
Websitebestanden	WordPress/core, thema’s, plugins, uploads, maatwerk en configuratie
Database	Pagina’s, producten, instellingen, gebruikers en veel plugin-/shopdata
Domein/DNS	Bepaalt naar welke server website en diensten verwijzen
SSL/TLS	Zorgt dat HTTPS op de nieuwe omgeving geldig werkt
E-mail en MX-records	Moet apart worden gecontroleerd als mail aan hetzelfde domein hangt
Cronjobs / taken	Kunnen orders, imports, backups of synchronisaties aansturen
Externe koppelingen	Betalingen, API’s, webhooks, SMTP, formulieren, analytics

Bij WordPress zijn bestanden en database twee aparte delen van dezelfde site. De officiële WordPress-documentatie benadrukt daarom dat je voor een volledige back-up beide nodig hebt.

Stap 1. Maak een herstelbare back-up vóór je iets verandert

Begin met een volledige back-up van bestanden én database. Bewaar die buiten de huidige hostingomgeving. Een back-up die alleen op dezelfde server staat, helpt weinig als je daar tijdens de verhuizing geen toegang meer toe hebt.

Controleer ook of je weet hoe je moet herstellen. Bij een webshop of site met veel wijzigingen is timing belangrijk: een databasekopie van gisteren kan betekenen dat nieuwe bestellingen, formulieren of accounts ontbreken. Plan daarom wanneer je de laatste synchronisatie doet.

Stap 2. Richt de nieuwe hosting in vóór je DNS wijzigt

Maak op de nieuwe hosting eerst de websiteomgeving, database, PHP-versie, certificaten en benodigde serverinstellingen klaar. Zet nog niets live voor het publiek.

Controleer of de nieuwe omgeving past bij je CMS en plugins. WordPress zelf kan naar een nieuwe server worden verplaatst zonder opnieuw geïnstalleerd te moeten worden. Wanneer domein en URL’s gelijk blijven, kunnen bestanden en database in veel gevallen gewoon worden gekopieerd; veranderen databasegegevens, dan moeten die bijvoorbeeld in wp-config.php worden bijgewerkt.

Heb je server-specifieke zaken zoals redirects, cronjobs, beveiligingsregels, caching of een CDN? Neem die mee in je inventaris. Alleen de zichtbare pagina’s kopiëren is niet hetzelfde als de hele productieomgeving migreren.

Stap 3. Kopieer de website en database naar de nieuwe server

Voor een WordPress-site kun je handmatig migreren, een betrouwbare migratietool gebruiken of de verhuizing door een beheerder/hostingpartij laten uitvoeren. Welke methode je kiest is minder belangrijk dan de controle erna.

Bij een handmatige migratie gaan de bestanden naar de nieuwe webroot en wordt de database geïmporteerd. Controleer daarna databaseverbindingen, bestandspaden, schrijfrechten en serverconfiguratie. Bij WooCommerce of andere dynamische sites moet je extra opletten dat er tijdens de laatste overgang geen nieuwe transacties tussen de oude en nieuwe database uiteenlopen.

Stap 4. Test de nieuwe hosting terwijl de oude site live blijft

Dit is de stap die downtime voorkomt. Test de nieuwe site vóór de DNS-switch via een tijdelijke hostname of lokaal hosts-bestand, zodat alleen jij de nieuwe server ziet terwijl gewone bezoekers nog naar de oude gaan.

Controleer niet alleen de homepage. Open belangrijke landingspagina’s, formulieren, zoekfunctie, login, downloads en mobiele navigatie. Bij een webshop test je productvarianten, winkelmand, checkout, betaalprovider in veilige testmodus, bevestigingsmails en eventuele voorraad- of ERP-koppelingen.

Let ook op robots- en indexeringsinstellingen. Een testomgeving mag niet per ongeluk in Google verschijnen. Google raadt bij een tijdelijke testhost noindex aan. Wanneer je live gaat, moet je zulke tijdelijke blokkades natuurlijk verwijderen.

Stap 5. Controleer DNS en verlaag vooraf de TTL waar dat zinvol is

De uiteindelijke hostingwissel gebeurt doordat DNS naar de nieuwe infrastructuur gaat wijzen. Google adviseert bij een geplande hostingmove om de TTL van relevante DNS-records vooraf naar een conservatief lage waarde te brengen, bijvoorbeeld enkele uren, en dat idealiter minstens een week voor de verhuizing te doen. Zo kunnen caches sneller vernieuwen wanneer je overschakelt.

Maak vóór de wijziging een kopie van je huidige DNS-zone. Kijk niet alleen naar het A- of AAAA-record van de website. MX-records, SPF, DKIM, DMARC, subdomeinen, verificatierecords en externe diensten kunnen allemaal in dezelfde zone staan. Een foutieve “schone” DNS-zone kan je website laten werken terwijl e-mail of andere diensten uitvallen.

Stap 6. Doe vlak voor livegang een laatste synchronisatie

Bij een brochurewebsite verandert tussen de eerste kopie en livegang misschien niets. Bij een webshop, boekingssysteem of drukbezocht formulier kan dat anders zijn. Nieuwe data die op de oude database binnenkomt nadat je de eerste kopie hebt gemaakt, moet je niet verliezen.

Plan daarom een kort wijzigingsvenster of een gecontroleerde laatste databasesynchronisatie. Voor shops kan het verstandig zijn orders tijdelijk te pauzeren of een korte onderhoudsmelding te gebruiken als dat nodig is om dataconsistentie te garanderen. Een paar minuten gepland en duidelijk gecommuniceerd is beter dan later bestellingen reconstrueren.

Stap 7. Wijzig DNS pas als de nieuwe site echt klaar is

Als tests groen zijn, pas je de relevante DNS-records of nameservers aan. Vanaf dat moment zullen verschillende internetproviders op verschillende momenten de nieuwe informatie gebruiken. Daarom moet de oude website nog blijven draaien tijdens de overgang.

Google Search Central adviseert bij een hostingwissel zonder URL-wijzigingen om verkeer op zowel de oude als nieuwe infrastructuur te monitoren. Zodra de oude server geen verkeer meer ontvangt en de nieuwe omgeving correct werkt voor gebruikers én Googlebot, kun je de oude hosting later afsluiten.

Stap 8. Controleer SSL, formulieren, e-mail en externe koppelingen

Een homepage die opent is geen geslaagde migratie. Controleer HTTPS en certificaatketen, formulieren, SMTP, e-mailbezorging, webhooks, betaalproviders, analytics, Search Console-verificatie, caching en scheduled jobs.

Stuur zelf een test via ieder belangrijk formulier. Plaats bij een webshop een volledige testbestelling als dat veilig kan. Controleer of bevestigingen aankomen, transacties correct geregistreerd worden en externe systemen de juiste callbacks ontvangen.

Bekijk ook server- en applicatielogs. Een site kan voor bezoekers normaal lijken terwijl op de achtergrond foutmeldingen, time-outs of mislukte cronjobs ontstaan.

Stap 9. Verandert de URL niet? Houd hem dan ook echt hetzelfde

Wanneer je alleen hosting verandert, is het juist een voordeel dat de zichtbare URL’s gelijk blijven. Behoud dezelfde HTTPS-URL’s, canonicals, interne links en sitemap. Dan hoeft Google geen nieuwe URL-structuur te leren.

Gebruik tijdens het testen geen tijdelijke domeinnaam die later per ongeluk in links, afbeeldingen of canonicals achterblijft. Controleer na livegang een steekproef van belangrijke pagina’s met Search Console en let op crawl- of indexeringsfouten.

Stap 10. Verandert ook je domein of URL-structuur? Behandel dat als aparte SEO-migratie

Een hostingwissel en een domeinwissel zijn niet hetzelfde project. Als oude URL’s veranderen, maak je een mapping van elke belangrijke oude URL naar de meest relevante nieuwe URL en gebruik je permanente server-side redirects, zoals 301 of 308.

Google adviseert om grote veranderingen waar mogelijk niet allemaal tegelijk te doen. Dus: als je hosting, domein, CMS en volledig design wilt wijzigen, verklein het risico door die veranderingen te scheiden wanneer dat praktisch kan.

Bij een domeinmigratie horen daarnaast bijgewerkte interne links, canonicals, hreflang waar relevant, een nieuwe sitemap, monitoring in Search Console en voor een echte domeinwijziging de Change of Address-tool. Laat redirects langdurig staan; Google adviseert doorgaans minstens een jaar.

Wat kan er misgaan na een WordPress-verhuizing?

Symptoom	Waarschijnlijke richting
Witte pagina / 500	PHP-fout, plugin/theme-conflict, configuratie of ontbrekende extensie
Error establishing database connection	Verkeerde databasegegevens, host of database niet bereikbaar
Afbeeldingen ontbreken	Bestanden niet compleet, rechten of oude paden/URL’s
Redirect-loop	HTTPS/proxy/cache/redirectconfiguratie botst
Formulier verstuurt niets	SMTP, DNS, firewall of externe mailconfiguratie
Alleen jij ziet oude site	Lokale/ISP DNS-cache of hosts-bestand
Checkout faalt	Webhook, API, SSL, sessie/cache of betaalinstellingen

Ga in zo’n situatie niet willekeurig plugins verwijderen of DNS blijven wijzigen. Noteer de fout, vergelijk oud en nieuw en werk systematisch. Als de site na de verhuizing helemaal niet bereikbaar is, is dat een ander diagnosepad dan een gewone hostingkeuze.

Hoe voorkom je downtime bij een websiteverhuizing?

Het principe is eenvoudig: de oude omgeving blijft beschikbaar totdat de nieuwe bewezen werkt en DNS grotendeels is overgeschakeld. Je kopieert dus eerst, test daarna en schakelt pas als laatste om.

Bij een dynamische site is “nul downtime” niet hetzelfde als “nul migratierisico”. Bestellingen, boekingen of formulieren kunnen tijdens de overgang nog op de oude omgeving terechtkomen. Daarom is dataconsistentie net zo belangrijk als de vraag of de homepage online blijft.

Wanneer laat je de verhuizing beter uitvoeren?

Een eenvoudige brochurewebsite kun je met voldoende technische kennis zelf verhuizen. Laat hulp inschakelen zodra e-mail, webshoporders, ledenaccounts, meertaligheid, maatwerk, externe API’s of belangrijke SEO-posities meespelen.

Ook wanneer je geen toegang hebt tot DNS, database of oude hosting is het verstandig eerst de eigendom en toegangen te regelen. Een migratie onder tijdsdruk terwijl de oude leverancier al wil afsluiten, is precies het scenario waarin fouten duur worden.

Moonbeetle kan technische verhuizingen en controles begeleiden via de webmasterdiensten. Daarbij is de veiligste volgorde altijd hetzelfde: inventariseren, kopiëren, testen, omschakelen, controleren en pas daarna de oude omgeving sluiten.

Veelgestelde vragen over een website verhuizen naar andere hosting

Verlies ik mijn Google-posities als ik van hosting verander?

Niet automatisch. Als je domein en URL’s hetzelfde blijven en de nieuwe server de pagina’s snel en betrouwbaar blijft aanbieden, is een hostingwissel vooral een infrastructuurwijziging. Google waarschuwt wel dat crawlactiviteit tijdelijk kan fluctueren. Grote problemen ontstaan vooral bij onbereikbaarheid, blokkades of onverwachte URL-wijzigingen.

Moet ik 301-redirects instellen als alleen de hosting verandert?

Normaal niet als alle zichtbare URL’s exact hetzelfde blijven. Redirects zijn nodig wanneer URL’s of domeinen veranderen. Controleer wel dat HTTPS, www/non-www en bestaande redirects hetzelfde gedrag houden.

Hoe lang moet de oude hosting blijven draaien?

Tot je zeker weet dat gebruikers, crawlers en diensten de nieuwe omgeving gebruiken en de oude server geen relevant verkeer meer ontvangt. Google adviseert de logs van beide omgevingen tijdens de overgang te monitoren.

Kan ik een WordPress website verhuizen zonder opnieuw te bouwen?

Ja. WordPress documenteert expliciet dat je bij een verhuizing naar een nieuwe server niet opnieuw hoeft te installeren. Je verplaatst bestanden en database en past configuratie aan waar de nieuwe omgeving dat vereist.

Moet e-mail mee verhuizen met de website?

Niet noodzakelijk. Website en e-mail kunnen bij verschillende providers blijven. Maar controleer MX-, SPF-, DKIM- en DMARC-records zorgvuldig zodat een wijziging aan DNS niet per ongeluk mail onderbreekt.

Wanneer is een hostingverhuizing ook een SEO-migratie?

Zodra domeinnaam, protocol of URL-paden zichtbaar veranderen. Dan heb je URL-mapping, permanente redirects en extra Search Console-controles nodig.

Bronnen voor verdere controle

• Google Search Central — hosting veranderen zonder URL-wijzigingen
• Google Search Central — site moves met URL-wijzigingen
• WordPress Developer Resources — Moving WordPress
• WordPress Developer Resources — Backups