De verhuizing naar de nieuwe hostingpartij is afgerond. De site staat online, de eerste pagina laadt, iedereen haalt opgelucht adem. En dan komen de meldingen. Een klant ziet oude afbeeldingen. Het contactformulier verstuurt niets meer. De webshop is opeens twee keer zo traag als eerst. Een pagina geeft een 404, een andere een foutmelding over de database. Niets is helemaal kapot, maar ook niets klopt helemaal.

Een website die kapot of traag is na een verhuizing, heeft bijna altijd een aantal kleine, voorspelbare oorzaken tegelijk. Ze zijn allemaal te vinden, mits u weet waar u moet kijken. Deze controlelijst loopt de twaalf punten na die wij bij elke verhuizing nalopen, in de volgorde waarin ze het meeste verschil maken.

Eerst: is de verhuizing wel klaar?

Een verrassend deel van de “problemen na de verhuizing” komt doordat de verhuizing nog niet af is. De DNS-wijziging, die de domeinnaam naar de nieuwe server wijst, heeft tijd nodig om overal door te dringen. Ondertussen ziet de ene bezoeker de oude server en de andere de nieuwe. Wijzigingen die u op de nieuwe server maakt, ziet een deel van de bezoekers dan niet. Bestellingen die op de oude server binnenkomen, staan niet op de nieuwe.

  • 1. Controleer waar de domeinnaam naartoe wijst. Met een gratis online DNS-checker ziet u of het IP-adres overal ter wereld al het nieuwe is. Zo niet, wacht dan met verdere conclusies. Verlaag bij een volgende verhuizing de TTL van de DNS-records een dag van tevoren, dan gaat het sneller.
  • 2. Zet de oude server pas uit als de DNS overal is doorgevoerd en u een laatste kopie van de database heeft gemaakt. Bij een webshop: vergelijk de laatste ordernummers op oud en nieuw.

Website kapot na verhuizing: de instellingen die het vaakst niet kloppen

  • 3. Site-URL en WordPress-URL. Onder Instellingen, Algemeen moeten beide adressen exact kloppen, inclusief https en wel of geen www. Staat hier nog een tijdelijk adres van de nieuwe host, of http in plaats van https, dan krijgt u kapotte afbeeldingen, een niet-ladende editor of een redirect-lus met "te veel omleidingen".
  • 4. Adressen in de database. Ook als de twee instellingen kloppen, kunnen in pagina-inhoud, thema-instellingen en pluginopties nog duizenden verwijzingen naar het oude adres staan. Een zoek-en-vervang-plugin die ook geserialiseerde gegevens begrijpt, lost dit op. Een gewone databasezoekopdracht maakt het juist kapotter.
  • 5. Permalinks. Geven losse pagina’s een 404 terwijl de homepage werkt, dan ontbreekt het .htaccess-bestand of kloppen de herschrijfregels niet. Ga naar Instellingen, Permalinks en sla op zonder iets te wijzigen. Op een Nginx-server zonder .htaccess moet de hostingpartij de regels zelf instellen.
  • 6. wp-config.php. Controleer de databasegegevens, maar ook regels die naar de oude server verwijzen: een absoluut pad naar een uploadmap, een hardgecodeerde site-URL of een cache-instelling van de vorige host. Een verkeerde regel hier geeft de “error establishing a database connection” of een wit scherm.

Ontbrekende bestanden en rechten

  • 7. De uploadmap. Bij grote sites wordt de mediabibliotheek wel eens onvolledig gekopieerd; een time-out tijdens het overzetten van tienduizend bestanden gaat vaak onopgemerkt. Vergelijk de grootte van wp-content/uploads op oud en nieuw. Ontbrekende afbeeldingen op oudere pagina’s zijn hiervan het symptoom.
  • 8. Bestandsrechten en eigenaar. Als de bestanden onder een andere gebruiker zijn overgezet, kan WordPress niet meer schrijven. Updates mislukken, uploads geven een HTTP-fout en cacheplugins kunnen hun bestanden niet aanmaken. De hostingpartij zet dit recht.
  • 9. PHP-versie en modules. Een nieuwe server draait vaak een andere PHP-versie. Nieuwer is meestal beter, maar oude plugins kunnen breken; ouder betekent dat moderne plugins weigeren. Vergelijk ook de PHP-modules onder Sitegezondheid, Info: ontbreekt bijvoorbeeld Imagick of intl, dan gedraagt de site zich net anders.

Waarom de site trager is dan eerst

  • 10. Cache-laag ontbreekt. Veel hostingpartijen bieden servercaching die u niet ziet, maar wel voelt. Na de verhuizing is die weg, en de cacheplugin die u had, was misschien afgestemd op de oude server. Controleer of paginacaching aan staat en of objectcaching (Redis of Memcached) op de nieuwe server beschikbaar is; anders verwijst een plugin naar een dienst die er niet is, wat elke pagina vertraagt.
  • 11. Het CDN of Cloudflare wijst nog naar het oude IP-adres. Dan haalt het bestanden op bij een server die inmiddels traag of uitgeschakeld is. Werk het oorsprongsadres bij.
  • 12. Cronjobs en e-mail. Als de vorige host een echte cronjob had ingesteld die WP-Cron aanriep, is die niet meegekomen. Geplande berichten, back-ups en voorraadsynchronisaties stoppen dan stil. Stel hem opnieuw in. Hetzelfde geldt voor e-mail: een SMTP-instelling, een SPF-record dat nog het oude IP-adres noemt, of een mailserver die op de nieuwe host anders heet. Test het contactformulier en bij een webshop een proefbestelling.

Praktijkvoorbeeld: een fietsenwinkel in Utrecht

Een fietsenwinkel met webshop in Utrecht verhuisde op advies van een kennis naar goedkopere hosting. De verhuizing zelf ging goed, maar in de week erna was de site “gewoon niet lekker”. Producten laadden langzaam, de zoekfunctie deed er vier seconden over en drie klanten meldden dat hun orderbevestiging niet was aangekomen.

Bij het nalopen van de lijst bleken vier punten mis. De Redis-objectcache van de oude host stond nog ingesteld, maar op de nieuwe server was er geen Redis; elke pagina wachtte eerst op een mislukte verbinding. Het SPF-record noemde nog het oude IP-adres, waardoor de bevestigingsmails als spam werden gezien. De cronjob voor de voorraadsynchronisatie was niet meegekomen. En de uploadmap miste 400 productfoto’s van vóór 2022. In een middag was alles hersteld, met als bijkomend voordeel dat de winkel nu weet welke instellingen bij een volgende overstap moeten meeverhuizen.

Wanneer u hulp inschakelt

De punten 1, 3, 5 en 12 kunt u zelf controleren via het beheer en met een paar gratis online tools. De overige punten vragen om toegang tot de server, de database of het DNS-beheer. Als de site na de verhuizing echt onbereikbaar is, of als het om een webshop gaat waar elk uur bestellingen binnenkomen, is snelheid belangrijker dan zelf uitzoeken; dan is het verstandig om de storing na de verhuizing te laten verhelpen door iemand die deze lijst dagelijks doorloopt.

Voor wie een verhuizing nog moet plannen: in het stappenplan voor het verhuizen van uw website staat hoe u de meeste van deze problemen vooraf voorkomt.

Samengevat

Een verhuizing is pas klaar als de DNS overal is doorgevoerd, de adressen in de database kloppen, de bestanden compleet zijn, de cache op de nieuwe server past en e-mail en cronjobs weer lopen. Loop de twaalf punten na, noteer wat u hebt aangepast en bewaar dat bij de documentatie van uw site. De volgende verhuizing gaat dan een stuk rustiger.