Je WordPress-site verhuizen

Voordat je begint. Dit is algemene uitleg, geen advies over jouw specifieke site. Je werkt hieronder aan een live database. Zorg dus eerst dat je een backup hebt die je ook echt kunt terugzetten, en houd je oude omgeving bereikbaar tot je zeker weet dat alles goed staat.

01Wat een backup precies moet bevatten

Een WordPress-site bestaat uit twee delen die je allebei nodig hebt. De bestanden staan op je webserver: WordPress zelf, je thema, je plugins, je uploads, plus wp-config.php en .htaccess. De database staat ergens anders en bevat je pagina's, je instellingen, je reacties en je bestellingen.

Dat onderscheid is de meest gemaakte fout bij een verhuizing. Je map downloaden voelt als een backup, maar je database zit daar niet in: die haal je apart op als exportbestand. Heb je alleen de bestanden, dan heb je een lege site met de juiste vormgeving.

De volgorde is bovendien niet symmetrisch, en dat is precies waar het misgaat. WordPress zelf adviseert: bij het maken van een backup eerst de database exporteren en daarna de bestanden. Bij het terugzetten juist andersom, eerst de bestanden en dan de database importeren. Bewaar beide delen als één set van hetzelfde moment, anders zet je straks een database terug die niet bij je bestanden hoort.

02De volgorde die downtime voorkomt

De verleiding is om te beginnen bij je domeinnaam. Doe dat als laatste. De volgorde die werkt:

1. Zet de kopie klaar op de nieuwe host: bestanden erop, database importeren.
2. Pas wp-config.php aan, maar alleen als de databasenaam, de gebruiker, het wachtwoord of de databaseserver verandert. Blijft dat gelijk, dan hoef je er niet aan te komen.
3. Test de site daar, terwijl je bezoekers gewoon nog op de oude server zitten.
4. Pas als de test klopt, wijs je je domeinnaam naar de nieuwe server.

Testen vóór de omschakeling is het hele punt van deze volgorde. Dat kan door tijdelijk de adresvelden in de database aan te passen, of door je eigen computer alvast naar de nieuwe server te laten kijken terwijl de rest van de wereld dat nog niet doet. Je hosting kan je meestal vertellen welke van de twee bij hen het handigst werkt.

03De stap waarop de meeste sites breken

Dit speelt alleen als je domeinnaam of adresstructuur óók verandert, bijvoorbeeld van je oude naam naar een nieuwe, of van een submap naar de hoofdmap. Je oude adres staat dan namelijk nog honderden keren in je database: in links, in afbeeldingen, in thema-instellingen.

De reflex is een zoek-en-vervangactie over de hele database. Precies daar sneuvelen sites, en WordPress waarschuwt er zelf voor: sommige thema's en plugins slaan waarden op met de lengte van je adres erin geschreven. Wordt dat adres langer of korter, dan klopt die lengte niet meer en breekt het onderdeel. Je merkt het aan een widget die leeg is, instellingen die terugvallen naar de standaard, of een thema dat zijn eigen opmaak niet meer vindt.

Gebruik daarom altijd gereedschap dat dit begrijpt: de opdrachtregel van WordPress, of een plugin die speciaal voor het vervangen van adressen is gemaakt. Twee gewoontes die je hierbij aanhoudt:

• Draai eerst een proefronde. WordPress' eigen opdracht heeft daar een stand voor die alles doorrekent en laat zien wat er zou veranderen, zonder iets op te slaan. Kijk of het aantal treffers klopt met wat je verwacht.
• Sla de kolom guid over. Dat doet WordPress in het eigen voorbeeld ook. Dat veld is bedoeld als vast kenmerk van een bericht en niet als adres; feedlezers gebruiken het om te bepalen of ze iets al kennen. Verander je het, dan kan een bericht van jaren geleden ineens als nieuw langskomen.

04Het uur waarin je site op twee servers staat

Dit is het stuk dat in de meeste handleidingen ontbreekt, en het is voor een webshop het duurste. Een domeinnaam schakelt niet in één klap om. Een tijdlang komt de ene bezoeker al op de nieuwe server terwijl de andere nog op de oude zit, en beide sites werken gewoon.

Alles wat in dat venster op de oude server binnenkomt, belandt in de oude database. Een bestelling, een contactformulier, een nieuwe abonnee, een reactie. Die verhuist niet meer mee, want jouw kopie is van daarvoor. De site is dus geen moment plat, en toch ben je iets kwijt.

Wat helpt:

• Verlaag vooraf de vernieuwingstijd van je domeinnaam, als je hosting of domeinbeheerder dat toestaat. Dan schakelt de wereld sneller om en is het venster korter.
• Plan de omschakeling op je rustigste moment. Kijk in je statistieken wanneer dat is, in plaats van te gokken.
• Zet de oude site na de omschakeling op onderhoud in plaats van hem meteen weg te gooien. Wie er dan nog belandt, ziet dat er iets aan de hand is en bestelt niet in het niets.
• Controleer de oude database achteraf op wat er in dat venster nog is binnengekomen, voordat je de oude omgeving opzegt.

05Wat je na de omschakeling controleert

• Je permalinks. Gebruik je nette adressen, sla je permalink-instellingen dan opnieuw op zodat het herschrijfbestand klopt. Had je eigen omleidingen in .htaccess staan, bewaar die dan eerst apart: WordPress schrijft het bestand opnieuw en jouw eigen regels staan er daarna niet meer in. Test daarna of die omleidingen nog werken.
• Gemengde inhoud. Laadt je pagina over een beveiligde verbinding terwijl er nog afbeeldingen of scripts via het oude, onbeveiligde adres binnenkomen, dan blokkeert de browser die stilletjes. Vaak zie je alleen een afbeelding die ontbreekt.
• E-mail vanaf je site. Contactformulieren en bestelbevestigingen lopen via de nieuwe server, en die staat bij je afzenderinstellingen mogelijk nog niet als toegestane verzender. Stuur zelf een testbericht en kijk of het aankomt en niet in de spam belandt.
• De zoekmachine-instelling. Heb je op een testomgeving gewerkt, dan staat daar vaak de instelling aan die zoekmachines vraagt weg te blijven. Verhuist die mee, dan verdwijn je stilletjes uit Google. Dit is de duurste vinkjesfout die er is.

06Meet of de verhuizing iets heeft opgeleverd

Bijna niemand verhuist voor de lol. Meestal is de reden dat de site traag was, of dat de support niet thuis gaf. Snelheid is daarvan het enige deel dat je hard kunt vaststellen, en dan alleen als je het vóór én ná meet.

Doe dat eerlijk: dezelfde pagina's, hetzelfde soort apparaat, en het liefst op hetzelfde moment van de dag. Meet niet alleen je homepage, want juist een productpagina of een categoriepagina met veel afbeeldingen laat zien wat een server echt doet. Zonder die twee metingen weet je achteraf alleen dat het "anders voelt", en dat is geen antwoord op de vraag of je nieuwe hosting zijn geld waard is.

07Wanneer je dit beter niet zelf doet

Een verhuizing van een eenvoudige site met een handvol pagina's is een prima klus voor een rustige avond. Er zijn situaties waarin de rekensom anders uitvalt:

• Een webshop met lopende bestellingen. Elk uur in het omschakelvenster kan een order zijn die in de verkeerde database landt.
• Je domeinnaam verandert mee. Dan komt de zoek-en-vervangstap erbij, en daarmee het risico uit stap 03.
• Je hebt geen testomgeving en geen recente backup. Dan heb je ook geen weg terug als het misgaat.
• Je site is je inkomen. De vraag is dan niet of je het kunt, maar wat een dag stilstand kost.