Vorige week belde een klant in paniek. Hij had zijn site zelf naar een nieuwe host verplaatst en zag alleen een witte pagina. Geen foutmelding, niets. Dit soort migraties gaat vaker mis dan je denkt, en bijna altijd om dezelfde redenen.
Wat er bij een migratie allemaal fout kan gaan
Een WordPress-migratie is meer dan bestanden kopiëren. Je hebt te maken met de database, de configuratie, de domeinkoppeling en de serveromgeving. Als één van die onderdelen niet klopt, werkt de site niet.
De meest voorkomende fout is een verkeerde database-verbinding. In het bestand wp-config.php staan de inloggegevens voor de database. Op de nieuwe server heten de database, de gebruiker en het wachtwoord anders. Als je die waarden niet aanpast, krijg je een foutmelding of een witte pagina.
Een tweede probleem is de siteurl en home instelling in de database. WordPress slaat die op in de tabel wp_options. Als die nog naar het oude domein of het oude pad wijzen, laadt de site niet goed. Dat merk je aan kapotte links, omleidingslussen of een inlogpagina die je steeds teruggooit.
De juiste volgorde voor een migratie
Migraties gaan beter als je een vaste volgorde aanhoudt. Improviseren kost tijd en fouten zijn dan moeilijker terug te draaien.
Stap één: maak een volledige back-up van de huidige site. Dat betekent alle bestanden via FTP of SSH, plus een export van de database via phpMyAdmin of een tool als WP-CLI. Sla die back-up op buiten de server, bijvoorbeeld op je eigen computer of in cloudopslag.
Stap twee: upload de bestanden naar de nieuwe server en importeer de database. Pas daarna wp-config.php aan met de nieuwe databasegegevens. Gebruik voor het aanpassen van de siteurl en home waarden bij voorkeur een SQL-query of een tool als Search Replace DB. Dat voorkomt dat je vergeet ergens een verwijzing te vervangen.
Stap drie: test de site voordat je het domein omzet. Dat doe je via een tijdelijk subdomein of door je eigen hosts-bestand aan te passen. Zo zie je al of de site werkt zonder dat bezoekers daar last van hebben.
Domeinkoppeling en DNS-propagatie
Als de site werkt op de nieuwe server, zet je het domein om. Dat doe je door de nameservers of de A-records bij de domeinnaamregistrar aan te passen. Welke methode je kiest hangt af van of je ook e-mail via hetzelfde domein hebt lopen.
Als je alleen de A-records aanpast, blijft de MX-record voor e-mail intact. Dat is veiliger als je e-mail bij een andere partij hebt dan je hosting. Verander je de nameservers volledig, dan overschrijf je alle DNS-instellingen en moet je e-mail opnieuw instellen.
DNS-propagatie duurt meestal tussen de 15 minuten en 24 uur. In die periode kunnen bezoekers op de oude of de nieuwe server uitkomen, afhankelijk van hun internetprovider. Houd daar rekening mee bij het plannen van de migratie. Doe het bij voorkeur op een moment met weinig verkeer, zoals een doordeweekse nacht.
Er zijn veel situaties waarbij je ook te maken krijgt met aanvullende vereisten rondom veiligheid op de werkvloer. Denk aan sectoren waar gewerkt wordt met servers in fysieke omgevingen, magazijnen of technische ruimtes. Voor wie in zo’n context wil begrijpen wat daarvoor nodig is, lees meer over de relevante certificeringen.
Veelgemaakte fouten na de migratie
Na de migratie is het nog niet klaar. Er zijn een paar dingen die je altijd moet controleren voordat je de klant zegt dat alles in orde is.
Controleer of SSL correct werkt. Als de oude site een certificaat had, geldt dat niet automatisch op de nieuwe server. Vraag een nieuw certificaat aan via Let’s Encrypt of de hostingprovider. Controleer daarna of alle interne links naar https gaan en niet meer naar http. Gemengde content geeft browserfouten en is slordig.
Controleer de permalinks. Ga in het WordPress-dashboard naar Instellingen > Permalinks en sla de instellingen opnieuw op zonder iets te veranderen. Dat herschrijft het .htaccess-bestand en lost vaak problemen op met 404-fouten op pagina’s die er wel zouden moeten zijn.
Controleer formulieren, betaalplugins en externe koppelingen. Die verwijzen soms naar een oud domein of hebben een API-sleutel die aan de oude server gebonden is. Dat geldt ook voor caching-plugins: die sla je het best even leeg na de migratie.
Hieronder een overzicht van wat je na elke migratie doorloopt:
- SSL-certificaat aanvragen en activeren
- Interne links controleren op
httpverwijzingen - Permalinks opnieuw opslaan
- Formulieren testen (verzenden en ontvangen)
- Caching legen en opnieuw configureren
- Betaalplugins en API-koppelingen verifiëren
- Bestandsrechten controleren (mappen 755, bestanden 644)
- Back-up van de nieuwe situatie maken
Veelgestelde vragen over WordPress-migraties
Moet ik de site offline zetten tijdens de migratie?
Dat hoeft niet altijd, maar het is verstandig bij sites met actieve gebruikers of webshops. Als bezoekers bestellingen plaatsen of formulieren invullen terwijl jij de database kopieert, mis je die gegevens op de nieuwe server. Zet een onderhoudspagina neer via een plugin of via .htaccess en informeer klanten van tevoren als de site even niet beschikbaar is.
Wat doe ik als de site na de migratie een witte pagina toont?
Begin bij wp-config.php en controleer of de databasegegevens kloppen. Zet daarna tijdelijk foutrapportage aan door define('WP_DEBUG', true); en define('WP_DEBUG_LOG', true); toe te voegen. De foutmelding in wp-content/debug.log vertelt je meestal precies wat er mis is. Veelvoorkomende oorzaken zijn een ontbrekende databaseverbinding, een incompatibele PHP-versie of een plugin die niet overweg kan met de nieuwe serveromgeving.
Hoe lang duurt een migratie gemiddeld?
Een eenvoudige WordPress-site zonder webshop migreer je in één tot twee uur als alles klaarstaat. Dat is inclusief back-up, upload, databaseimport, configuratie en eerste tests. Een grote WooCommerce-omgeving met veel producten, orders en koppelingen kan een halve dag kosten. De DNS-propagatie tel je daar apart bij op, want die wacht je af voordat je de migratie officieel afsluit.