Site inaccessible après migration d'hébergeur : la checklist

Le site tourne chez le nouvel hébergeur, mais rien ne s’affiche

Tu viens de migrer. Le nouvel hébergeur t’a confirmé que tout est en place, la base est importée, les fichiers sont uploadés. Et pourtant : écran blanc, erreur SSL, ou pire, le site affiche encore l’ancienne version chez certains visiteurs et la nouvelle chez d’autres. Panique légère, boîte mail qui commence à recevoir des messages de clients inquiets.

Respire. C’est probablement l’un des cinq points classiques d’une migration mal terminée : propagation DNS pas finie, cache résiduel (navigateur, CDN, hébergeur), base de données pas totalement importée, chemins absolus codés en dur qui pointent vers l’ancien serveur, ou certificat SSL pas encore réémis sur la nouvelle machine. Aucun de ces cas n’est une catastrophe si tu sais où regarder — mais l’ordre dans lequel tu vérifies compte énormément, sinon tu perds des heures à changer des choses qui n’étaient pas cassées.

Pourquoi ça arrive (les causes classiques)

• TTL DNS trop long : si l’ancien enregistrement avait un TTL (Time To Live) de 24h, certains résolveurs DNS dans le monde continuent de servir l’ancienne IP pendant des heures, voire jusqu’à 48h dans de rares cas.
• Cache navigateur ou CDN : ton navigateur a mis en cache l’ancienne page, ou un CDN comme Cloudflare continue de servir une version figée de l’ancien serveur.
• Import de base partiel : l’export SQL a été tronqué, une table (souvent wp_options ou les tables WooCommerce) n’a pas été importée entièrement, ou l’import s’est arrêté sans message d’erreur visible.
• Chemins absolus codés en dur : des URLs complètes (https://ancien-domaine.com/wp-content/...) enregistrées dans la base ou dans des fichiers, qui pointent encore vers l’ancien serveur.
• SSL non réémis : le certificat a été généré pour l’ancien serveur (ou l’ancienne IP), et le nouveau serveur n’a pas encore son propre certificat valide.
• Fichiers manquants ou permissions cassées : un transfert FTP interrompu qui laisse des dossiers wp-content/uploads ou wp-content/plugins incomplets.

1. Vérifie d’abord si c’est vraiment un problème DNS

Avant de toucher à quoi que ce soit côté serveur, confirme que le DNS pointe bien vers la nouvelle IP. Utilise un outil de vérification DNS externe (type whatsmydns.net) pour voir la propagation dans le monde, pas juste depuis ton propre poste.

Si tu vois encore l’ancienne IP dans plusieurs régions, c’est simplement une question de temps — le TTL doit expirer. Si tu avais anticipé la migration en abaissant le TTL à 300 secondes (5 minutes) 24h avant la bascule, la propagation est quasi instantanée. Si tu ne l’as pas fait, tu peux attendre, ou temporairement éditer ton fichier hosts local pour forcer ton poste à pointer vers la nouvelle IP et vérifier que tout fonctionne bien de ton côté, pendant que le reste du monde rattrape le retard.

Pour la configuration DNS elle-même selon ton hébergeur, les guides DNS sur o2switch, DNS sur Hostinger et DNS sur IONOS détaillent la marche à suivre pas à pas. Si le domaine semble ne jamais vouloir basculer, le guide DNS qui ne propage pas couvre les cas plus tordus (glue records, DNSSEC mal configuré, etc.).

2. Vide les caches, dans le bon ordre

Une fois le DNS confirmé côté nouvel hébergeur, si l’affichage reste incohérent, le coupable est presque toujours le cache. Vide-les dans cet ordre :

1. Cache navigateur : Ctrl+Maj+R (ou Cmd+Maj+R sur Mac) pour un rechargement forcé sans cache.
2. Cache CDN/proxy (Cloudflare notamment) : purge complète depuis le dashboard, pas juste “purge selective”.
3. Cache serveur (LiteSpeed, Varnish, ou plugin WordPress) : vide le cache depuis l’admin ou le panel hébergeur.
4. Cache objet/opcache PHP : souvent oublié, il peut garder en mémoire d’anciennes données même après un import frais.

Si le site reste lent ou incohérent même après ce nettoyage, le guide LiteSpeed Cache : la configuration optimale et Meilleurs plugins de cache WordPress t’aideront à repartir sur une config propre plutôt que de rallumer un cache mal réglé.

3. Confirme que l’import de la base est complet

Ouvre phpMyAdmin (ou Adminer) sur le nouvel hébergeur et compare le nombre de lignes dans les tables principales avec l’ancien serveur, si tu y as encore accès. Regarde en particulier wp_posts, wp_options et, si c’est une boutique, les tables wp_woocommerce_*.

Un import tronqué donne souvent une erreur silencieuse : le fichier SQL était trop gros pour la limite d’upload du panel, ou la connexion a timeout en cours de route. Si c’est le cas, réimporte via SSH avec la commande mysql -u user -p database < fichier.sql, beaucoup plus fiable qu’un import via interface web pour les grosses bases. Le guide se connecter en SSH sur OVH ou SSH sur Plesk selon ton panel t’explique la connexion pas à pas si tu ne l’as jamais fait.

Si l’erreur affichée est littéralement une erreur de connexion à la base, direction ce guide dédié : Erreur de connexion à la base de données WordPress.

4. Traque les chemins absolus codés en dur

C’est le piège le plus sournois, parce que le site “fonctionne” mais des images ne chargent pas, des liens internes redirigent vers l’ancien domaine, ou l’éditeur (Elementor, WPBakery) charge des ressources cassées.

Le problème vient de deux endroits : la table wp_options (les champs siteurl et home) et le contenu même des articles, si des URLs complètes de l’ancien domaine ont été enregistrées en dur au lieu de chemins relatifs.

Corrige siteurl et home directement dans phpMyAdmin, table wp_options. Pour les URLs dans le contenu, utilise un plugin de recherche-remplacement en base (Better Search Replace est le plus courant) plutôt que de modifier manuellement — un remplacement texte brut mal fait peut casser les données sérialisées de WordPress et provoquer un écran blanc. Si ça arrive, le guide écran blanc WordPress t’aide à revenir en arrière.

5. Réémets le certificat SSL sur le nouveau serveur

Le SSL est lié au serveur, pas au domaine. Même si ton certificat était valide chez l’ancien hébergeur, il faut en générer un nouveau (Let’s Encrypt gratuit, généralement automatique via le panel) une fois le DNS propagé vers le nouveau serveur.

Tant que ce n’est pas fait, tu peux voir une erreur NET::ERR_CERT_DATE_INVALID ou ERR_SSL_PROTOCOL_ERROR. Les guides certificat SSL expiré et ERR_SSL_PROTOCOL_ERROR détaillent la réémission selon le cas. Attention aussi au contenu mixte (images ou scripts encore chargés en HTTP) qui casse le cadenas même avec un SSL valide : voir contenu mixte HTTPS.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Si après avoir vérifié DNS, cache, base, chemins absolus et SSL le site reste cassé, ou si tu n’as tout simplement pas accès en SSH ou à phpMyAdmin pour faire ces vérifications toi-même, arrête de perdre du temps à deviner. Une migration mal terminée qui traîne coûte plus cher en clients perdus et en positionnement SEO que l’intervention d’un technicien qui referme le dossier en une heure. C’est exactement le genre de situation où une agence en mode maintenance reprend la main, corrige, et documente ce qui a été fait — plutôt que de te laisser seul face à un phpMyAdmin ouvert à 23h.