Je site draait. Leads komen binnen. Misschien loopt er zelfs een campagne. En toch moet je verhuizen: naar snellere hosting, een nieuwe domeinnaam, een opgeschoonde WordPress-installatie of een compleet redesign. Dan is er maar één eis die telt: je wil geen minuut offline, geen gemiste bestellingen en geen SEO-dip.
Een wordpress website migratie zonder downtime is geen trucje. Het is een strak proces waarin timing, techniek en controle samenkomen. Doe je het goed, dan merkt niemand iets – behalve dat de site sneller wordt. Doe je het slordig, dan krijg je 500-errors, gemengde content, kapotte formulieren of plots dalende rankings.
Wanneer “zonder downtime” echt het verschil maakt
Bij sommige sites is een korte onderhoudspagina prima. Bij een lokale dienstverlener die vooral overdag leads pakt, kun je in de nacht iets plannen en ben je klaar. Maar bij webshops, campagnes, SEO-traffic en B2B-leadfunnels met formulieren is downtime gewoon omzetverlies.
En downtime is niet alleen “site onbereikbaar”. Een migratie kan ook half kapot zijn: checkout die faalt, mails die niet versturen, of pagina’s die ineens 404 geven. Voor je bezoeker voelt dat hetzelfde als offline.
Wat bedoelen we precies met een WordPress migratie?
“Migratie” kan drie dingen betekenen, en de aanpak verschilt per scenario.
- Je verhuist dezelfde site naar andere hosting (performance, stabiliteit, kosten).
- Je verhuist én verandert dingen, zoals een nieuw thema, nieuwe plugins, opgeschoonde content of een nieuwe structuur.
- Je migreert naar een andere domeinnaam of van http naar https, of je combineert sites.
Een wordpress website migratie zonder downtime is in alle gevallen mogelijk, maar hoe meer je tegelijk verandert, hoe meer je moet testen en afvangen.
De kern van migreren zonder downtime: parallel werken
De fout die we het vaakst zien: mensen sleutelen op de live site en hopen dat het “wel goed komt”. Dat voelt snel, maar het is juist traag zodra er iets misgaat.
De veilige aanpak is parallel: je bouwt en test de nieuwe versie in een afgeschermde omgeving (staging of tijdelijke URL), terwijl de huidige website gewoon doordraait. Pas als alles klopt, schakel je om.
Daarbij hoort ook een belangrijk besluit: hoe ga je om met content die tijdens de migratie verandert? Denk aan nieuwe bestellingen, nieuwe aanmeldingen, blogposts of voorraad. Bij een brochure-site is dat makkelijk. Bij een webshop moet je expliciet plannen hoe je dat synchroniseert of hoe kort de “freeze” mag zijn.
Stap 1: Voorbereiding die downtime voorkomt
Downtime voorkomen begint vóór je ook maar één bestand kopieert.
Maak eerst een nulmeting. Welke pagina’s trekken verkeer? Welke landingspagina’s draaien ads? Welke formulieren en integraties zijn cruciaal? Zet dat scherp, want dit zijn je testpunten.
Daarna check je de technische randvoorwaarden: PHP-versie, databaseversie, caching, serverlimieten, en vooral mailverzending (SMTP) en cronjobs. Veel migraties “werken” op het oog, maar vallen om op achtergrondprocessen zoals ordermails of geplande taken.
En ja: maak een goede backup. Niet alleen van WordPress-bestanden en database, maar ook van je uploads en je wp-config. Als je met een hosting-migratie werkt, wil je ook een export van DNS-records en een overzicht van bestaande redirects.
Stap 2: Staging opzetten en de site daar exact nabouwen
De staging-site is je werkplaats. Hier zet je een 1-op-1 kopie neer van de huidige website. Vervolgens kun je daar migreren, opschonen, updaten of herbouwen.
Belangrijk detail: blokkeer indexatie. Je wil niet dat Google je staging-versie gaat indexeren. Dat kan via noindex, htpasswd of IP-restrictie. Liefst een combinatie.
Als je tegelijk updates doet (bijvoorbeeld WordPress core, thema of plugins), doe dat hier. Het grootste risico op “plots downtime” zit namelijk in versies die niet lekker samenwerken. Een staging-omgeving is de plek om dat uit te vechten, niet op je live omzet.
Stap 3: Testen alsof je klant bent (niet alsof je developer bent)
Technisch gezien kun je een site laden en denken: klaar. Maar je bezoekers doen andere dingen dan jij.
Test dus de volledige flow:
- Formulieren: verzenden, bevestigingsmail, spamfilter, CRM-koppeling.
- Webshop: productpagina, variantkeuze, voorraad, kortingscodes, checkout, betaalprovider, ordermail.
- Tracking: GA4 events, Meta-pixel, conversies, consent banner.
- Performance: laadtijd op mobiel, cachinggedrag, afbeeldingen, fonts.
Ook SEO-tests horen hierbij. Check canonical tags, index/noindex, robots.txt, sitemaps, structured data, en of je belangrijkste pagina’s nog exact dezelfde URL’s hebben. Als URL’s veranderen, moet je redirects al klaar hebben staan vóór de switch.
Stap 4: DNS en omschakelen zonder dat bezoekers “middenin” vallen
Hier gaat het vaak mis, omdat DNS omschakelingen niet overal tegelijk zijn. De ene bezoeker zit al op de nieuwe server, de ander nog op de oude. Dat kan rommelig worden als je site dynamisch is.
De praktische aanpak:
- Verlaag de TTL van je DNS-records ruim vooraf (bijvoorbeeld 24 uur). Dan verspreidt de wijziging sneller.
- Plan de switch op een rustig moment, maar niet per se ’s nachts. Je wil juist wakker zijn om te monitoren.
- Zorg dat SSL-certificaten op de nieuwe omgeving al werken, vóór je DNS omgooit.
Voor webshops en sites met veel inzendingen is er nog een extra stap: een korte content-freeze. Dat kan betekenen dat je gedurende een kort venster geen nieuwe producten toevoegt of grote contentwijzigingen doet, zodat je geen dataverschillen krijgt. Dit is niet “downtime”, maar wel procesdiscipline.
Stap 5: Redirects en SEO: de stille omzetbewakers
Bij een wordpress website migratie zonder downtime is SEO vaak het echte risico. Je site kan technisch online zijn, maar als belangrijke pagina’s 404 worden of canonical tags fout staan, zie je het pas weken later in je cijfers.
Als URL’s hetzelfde blijven, is het simpel: je hoeft vooral te bewaken dat er niets stiekem verandert door een nieuw thema, andere permalink-instellingen of trailing slashes.
Als URL’s wél veranderen, zijn 301-redirects verplicht. Niet “later nog even”. Later betekent meestal dat Google de oude URL’s al als verdwenen ziet en je posities gaan schuiven.
Denk ook aan interne links, afbeeldingen (padwijzigingen), en eventuele hardcoded links in content of page builders. Een search-replace kan helpen, maar moet gecontroleerd gebeuren om serialized data niet te breken.
Stap 6: Livegang is het begin van de controle, niet het einde
Na de switch wil je direct bewijzen dat alles klopt.
Check meteen:
- Statuscodes van belangrijke pagina’s (200, geen 404/500)
- Checkout en betaalstatus (testorder)
- Formulieren en mail
- Caching en performance
- Search Console: dekking, sitemaps, eventuele spikes in fouten
De eerste 48 uur zijn cruciaal. Niet omdat er “magie” gebeurt, maar omdat je in die periode de meeste randgevallen vangt: bezoekers met oude caches, DNS dat nog doorsijpelt, bots die rare URL’s proberen.
Daarom werkt een onderhoudsplan in de praktijk zo goed. Niet als upsell, maar als verzekering: updates, beveiliging, monitoring en snelle fixes zijn precies wat je wil rondom en na een migratie. Als je dat structureel belegt, voorkom je dat je drie maanden later alsnog problemen krijgt door een plugin-update die net verkeerd valt.
Veelvoorkomende valkuilen (en hoe je ze voorkomt)
De drie klassiekers:
Ten eerste: gemengde content na https. Je site laadt dan “veilig”, maar met onveilige elementen zoals afbeeldingen of scripts. Oplossing: forceer https, controleer hardcoded URLs en check je thema-instellingen.
Ten tweede: mail die stopt. Op oude hosting werkte PHP mail “gewoon”, op nieuwe niet. Of je SPF/DKIM klopt niet meer. Oplossing: werk met SMTP en controleer je DNS-records voor mail.
Ten derde: performance die achteruitgaat terwijl je juist verhuisde voor snelheid. Dat komt vaak door caching die niet goed staat, te zware plugins, of een serverconfig die niet past bij je site. Oplossing: meet vóór en na, en optimaliseer gericht in plaats van “alles installeren wat belooft sneller te maken”.
Wanneer je het beter uitbesteedt
Als je site omzet draait, is migreren geen hobbyproject. Je kunt veel zelf als je technisch handig bent en je site simpel is. Maar als je afhankelijk bent van SEO, advertenties, of een webshop met betalingen en koppelingen, dan is het meestal goedkoper om het in één keer goed te doen dan achteraf bugs te fixen.
Bij JOYOmedia doen we dit soort migraties zoals we ook builds aanpakken: snel, transparant en met directe lijntjes naar de developers. Geen accountmanager ertussen, wel een plan, een testlijst en een livegang die je kunt vertrouwen.
Een migratie zonder downtime is uiteindelijk geen “feature”, maar een manier van werken: eerst bewijzen dat alles klopt, dan pas omzetten. Als je dat principe vasthoudt, wordt verhuizen ineens iets wat je met vertrouwen plant in plaats van iets wat je uitstelt tot het echt niet anders kan.
