WordPress-site verhuizen naar een nieuwe host of domein zonder downtime

Een site verhuizen lijkt op kopiëren. Bestanden erover, database erover, klaar. En dan werkt alles op de nieuwe server, behalve de afbeeldingen die nog naar het oude domein wijzen, het slotje dat ontbreekt en de bestelling die net tijdens de verhuizing binnenkwam.

Het lastige zit in de database. WordPress bewaart zijn eigen adres niet op één plek, maar honderden keren. In je content, in widgetinstellingen, in de opties van je thema en je pagebuilder. Een deel daarvan staat er als geserialiseerde data, en daarin staat bij elke tekst ook hoe lang die is.

Vervang je het oude domein door het nieuwe met een simpele zoek-en-vervang, dan klopt die lengte niet meer. PHP kan de instelling dan niet meer uitlezen en WordPress doet alsof hij leeg is. Geen foutmelding. Je widgets zijn gewoon weg.

Wat je nodig hebt

• Toegang tot beide hostings: SFTP en de database, of liever SSH
• Toegang tot je DNS. Dat is niet altijd je hoster, soms staat je domein ergens anders
• WP-CLI op beide servers. Niet verplicht, maar het scheelt je een hoop geklik
• Een moment waarop er weinig gebeurt op je site

Een dag van tevoren: zet de TTL laag

Elk DNS-record heeft een TTL: hoe lang andere servers het adres mogen onthouden. Vaak is dat een uur, soms een hele dag. Zet je het IP-adres om, dan komt een deel van je bezoekers dus nog tot een dag lang bij de oude server uit.

Zet daarom een dag voor de verhuizing de TTL van je A-records op 300 seconden. Voor het domein zelf en voor www. Wacht daarna minstens zo lang als de oude TTL was. Als je straks omzet, is iedereen binnen een paar minuten over.

Verhuist je DNS mee naar de nieuwe partij, neem dan ook je MX-records over. Die bepalen waar je mail heen gaat. Vergeet je ze, dan werkt je site prima en komt er geen mail meer binnen. Dat merk je meestal pas na twee dagen, als het opvallend stil is.

Plugin of met de hand?

Voor een gewone site is een migratieplugin prima. WPvivid heeft een Auto-Migration: je maakt op de nieuwe site een sleutel aan, plakt die op de oude, en de oude site duwt alles over. Duplicator en All-in-One WP Migration doen iets vergelijkbaars.

Bij grote sites lopen die plugins op goedkope hosting nogal eens vast op een time-out, halverwege twintig gigabyte aan uploads. Dan wil je het met de hand kunnen. Die route beschrijf ik hieronder. Het is precies wat zo’n plugin onder water doet, dus je snapt daarna ook waar het vastloopt als de plugin het opgeeft.

Stap voor stap

1. Exporteer de database

Heb je een webshop of komen er veel formulieren binnen? Zet de oude site dan eerst in onderhoudsmodus. Alles wat er na je export binnenkomt, staat alleen in de oude database en gaat niet mee.

Daarna exporteer je op de oude server:

wp db export verhuizing.sql

Zonder SSH gaat het via phpMyAdmin, met Exporteren.

2. Kopieer de bestanden

Minimaal de map wp-content, want daarin zit met uploads ook meteen het zware deel. Het makkelijkst is de hele installatie. Met rsync gaat dat direct van server naar server. Draai dit op de nieuwe server:

rsync -avz gebruiker@oudeserver.nl:/pad/naar/site/ /pad/naar/nieuwe/site/

Via SFTP kan ook. Dan ga je wel even koffie halen. Of drie.

3. Zet de database erin

Maak op de nieuwe hosting een lege database met een gebruiker aan. Zet die gegevens in wp-config.php bij DB_NAME, DB_USER, DB_PASSWORD en DB_HOST. Laat $table_prefix staan zoals hij was, anders zoekt WordPress naar tabellen die er niet zijn. Dan importeren:

wp db import verhuizing.sql

4. Vervang de URL, alleen bij een nieuw domein

Blijft je domein hetzelfde, sla deze stap dan over. Verandert het wel, draai dan eerst een proefrun:

wp search-replace 'https://oudedomein.nl' 'https://nieuwdomein.nl' --all-tables --skip-columns=guid --dry-run

Je krijgt per tabel te zien hoeveel er vervangen zou worden, zonder dat er iets verandert. Ziet dat er logisch uit, draai hem dan nog een keer zonder --dry-run.

wp search-replace snapt geserialiseerde data en past de lengtes netjes aan. Daarom gebruik je dit en geen SQL-query. Heb je geen WP-CLI, dan doet de plugin Better Search Replace hetzelfde.

De kolom guid sla je over omdat dat de vaste ID van een bericht is in je RSS-feed. Pas je die aan, dan denken feedlezers dat al je berichten nieuw zijn.

Staan er in wp-config.php regels met WP_HOME of WP_SITEURL, pas die dan ook aan. Die winnen van alles wat in de database staat.

Pagebuilders apart

Elementor en een paar andere pagebuilders bewaren hun data als JSON, met de slashes ge-escaped: https:\/\/oudedomein.nl. Daar loopt de gewone vervanging langs. Doe er daarom een tweede ronde achteraan:

wp search-replace 'https:\/\/oudedomein.nl' 'https:\/\/nieuwdomein.nl' --all-tables --skip-columns=guid

Elementor heeft er ook een eigen knop voor, onder Elementor, Tools, Replace URL.

5. Test voordat de wereld het ziet

Je wilt de nieuwe server testen met je echte domein, voordat je de DNS omzet. Dat kan met je hosts-bestand. Daarin vertel je alleen je eigen computer waar het domein staat.

Op een Mac open je het met sudo nano /etc/hosts. Op Windows is het C:\Windows\System32\drivers\etc\hosts, geopend als beheerder. Zet er een regel in met het IP-adres van de nieuwe server:

123.45.67.89 jouwdomein.nl www.jouwdomein.nl

Nu zie alleen jij de site op de nieuwe server. Klik alles door: een paar pagina’s, het inloggen, een formulier, en bij een webshop een bestelling. Twijfel je of je echt op de nieuwe server zit, zet dan daar tijdelijk een extra woord in een paginatitel. Klaar met testen? Haal de regel weer weg.

Denk ook aan het SSL-certificaat. Let’s Encrypt controleert dat meestal via je domein, en dat wijst nog naar de oude server. Veel hosters regelen het certificaat daarom pas zodra de DNS om is, en dan zien bezoekers een paar minuten een waarschuwing. Vraag je nieuwe hoster of ze het vooraf kunnen regelen. Vaak kan dat.

6. Zet de DNS om

Pas het A-record aan naar het nieuwe IP-adres. Door die lage TTL zit het grootste deel van je bezoekers binnen een paar minuten op de nieuwe server. Zet de TTL daarna weer terug naar een uur.

Laat de oude site nog een paar dagen staan. Er is altijd wel een provider die zich niets van je TTL aantrekt.

Nieuw domein? Stuur het oude door

Google en al je bezoekers kennen je oude adressen nog. Stuur ze per pagina door, niet allemaal naar je homepage. Op de server van het oude domein zet je dit in .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?oudedomein\.nl$ [NC]
RewriteRule ^(.*)$ https://nieuwdomein.nl/$1 [R=301,L]

Draait die server op Nginx, dan werkt .htaccess niet en vraag je je hoster om de redirect.

Meld de verhuizing daarna aan in Google Search Console, via Instellingen, Adreswijziging. En houd het oude domein nog minstens een jaar in je bezit. Anders registreert iemand anders hem, compleet met al je oude links.

Waar het meestal misgaat

• URL’s vervangen met een SQL-query of in een teksteditor. De geserialiseerde data breekt. Widgets en thema-instellingen zijn weg, zonder foutmelding.
• Maar half vervangen. Je vervangt https://oudedomein.nl, maar in oude berichten staat nog http:// of www. Draai achteraf een proefrun op alleen oudedomein.nl om te zien wat er over is. Dan pak je wel ook info@oudedomein.nl in je formulierinstellingen mee. Soms wil je dat. Soms juist niet.
• Paden van de oude server. De firewall van Wordfence zet het volledige pad naar zijn eigen bestanden in .user.ini of .htaccess. Op de nieuwe server bestaat dat pad niet en krijg je een witte pagina nog voordat WordPress laadt. Haal die regel weg en stel de firewall opnieuw in.
• Cachebestanden die meeverhuizen. advanced-cache.php en object-cache.php in wp-content verwijzen soms naar paden of een Redis-server die er niet meer zijn. Verwijder ze en laat je cacheplugin ze opnieuw aanmaken.
• De oude hosting te vroeg opgezegd. Blijkt er na een week toch een map te missen, dan heb je niets meer om uit te putten.

Tot slot

Een verhuizing is geen moeilijk werk, wel precies werk. De meeste problemen komen niet van de verhuizing zelf, maar van een stap die overgeslagen werd omdat het al zo goed leek te gaan. Plan hem op een rustige ochtend. Niet op vrijdag om vier uur.