Problème WordPress après migration : les vérifications à suivre

Un site WordPress qui ne répond plus après un changement d’hébergeur, de serveur ou de nom de domaine ne doit pas être corrigé au hasard. Les causes les plus fréquentes sont un DNS encore en propagation, une base de données mal importée, des identifiants incorrects dans wp-config.php, une URL restée sur l’ancien domaine ou une incompatibilité PHP. Pour résoudre un problème WordPress après migration, commencez par isoler la couche en cause : domaine, serveur, fichiers, base de données ou extensions. Voici les contrôles à effectuer dans l’ordre pour remettre le site en ligne sans aggraver la situation.

Pour sécuriser la reprise, notre accompagnement en migration WordPress couvre le transfert et les contrôles de fonctionnement. Si WordPress affiche précisément un message d’erreur fatale, consultez aussi notre diagnostic de l’erreur critique WordPress.

Avant toute modification, conservez une sauvegarde complète des fichiers et de la base du site actuel, ainsi que la copie d’origine. Testez les corrections sur une préproduction. Pour une boutique active, protégez les commandes et paiements récents avant tout retour à une ancienne base.

1. Vérifier que le domaine pointe bien vers le nouveau serveur

Avant de modifier WordPress, vérifiez le DNS. Si le domaine pointe encore vers l’ancienne adresse IP, vous pouvez voir un ancien site, une page par défaut de l’hébergeur ou une erreur de connexion. Dans la zone DNS, contrôlez l’enregistrement A du domaine et, si nécessaire, de www. Il doit correspondre à l’IP fournie par le nouvel hébergeur. Contrôlez aussi les éventuels enregistrements AAAA (IPv6) et les alias CNAME : un ancien pointage peut expliquer des résultats différents selon les visiteurs.

Une propagation DNS peut prendre du temps selon le TTL précédent et les résolveurs utilisés. Ne concluez pas trop vite que la migration est défaillante si le site fonctionne depuis certains réseaux mais pas d’autres. En revanche, si le domaine résout déjà vers le bon serveur, poursuivez les vérifications directement sur ce serveur.

• Contrôlez que le domaine principal et la version avec www sont configurés.
• Vérifiez que le virtual host ou le domaine additionnel cible le bon dossier, généralement celui qui contient wp-config.php.
• Évitez de modifier simultanément les DNS, les URLs WordPress et les redirections : vous perdriez la capacité à identifier la cause.

2. Contrôler les fichiers WordPress et le document root

Une migration par FTP, SFTP ou archive peut placer les fichiers dans un sous-dossier involontaire, par exemple /public_html/mon-site/ au lieu de /public_html/. Le document root défini chez l’hébergeur doit pointer vers le dossier contenant index.php, wp-admin, wp-content et wp-includes.

Vérifiez également que les fichiers cachés ont été transférés, en particulier .htaccess. Son absence ne bloque pas toujours la page d’accueil, mais peut provoquer des erreurs 404 sur les pages internes et les permaliens. Pour repartir d’une règle standard, connectez-vous à l’administration WordPress, ouvrez Réglages > Permaliens, puis cliquez sur Enregistrer les modifications. Cette action régénère les règles lorsque le serveur Apache les accepte.

Sur un serveur Nginx, le fichier .htaccess est ignoré : les règles de réécriture doivent être présentes dans la configuration Nginx de l’hébergeur. Une réécriture WordPress classique utilise notamment try_files $uri $uri/ /index.php?$args;.

3. Corriger l’erreur de connexion à la base de données

Le message « Erreur lors de la connexion à la base de données » indique généralement que WordPress ne peut pas joindre MySQL ou MariaDB avec les informations enregistrées. Ouvrez wp-config.php sur le nouveau serveur et comparez ces constantes avec celles du panneau d’hébergement :

• DB_NAME : nom exact de la base ;
• DB_USER et DB_PASSWORD : utilisateur et mot de passe associés ;
• DB_HOST : souvent localhost, mais parfois un nom d’hôte ou un port spécifique ;
• $table_prefix : préfixe des tables réellement importées, tel que wp_ ou abc_.

Dans phpMyAdmin ou Adminer, vérifiez que les tables existent et que leur nombre est cohérent avec le site d’origine. Une base importée mais vide, une archive SQL interrompue ou un mauvais préfixe peuvent produire un écran d’installation WordPress. Dans ce cas, ne lancez pas l’installation : elle risque d’ajouter des tables inutiles. Corrigez d’abord le nom de base ou le préfixe dans wp-config.php.

4. Remplacer proprement l’ancienne URL

Après un changement de domaine, de protocole ou de sous-domaine, WordPress peut rediriger vers l’ancienne adresse, afficher des liens cassés ou empêcher l’accès à wp-admin. Commencez par contrôler les valeurs siteurl et home dans la table wp_options correspondant au préfixe du site. Elles doivent refléter l’installation finale. home indique l’adresse publique, tandis que siteurl indique l’emplacement des fichiers WordPress ; ces valeurs peuvent différer si WordPress est installé dans un sous-dossier.

Pour une installation simple où les deux adresses sont identiques, vous pouvez reprendre temporairement la main sans modifier la base avec ces lignes dans wp-config.php, avant la ligne indiquant d’arrêter les modifications :

define('WP_HOME', 'https://www.exemple.fr');
define('WP_SITEURL', 'https://www.exemple.fr');

Ensuite, effectuez un remplacement des anciennes URLs dans le contenu et les réglages. N’utilisez pas un simple rechercher-remplacer SQL sur toute la base : des données sérialisées sont stockées par de nombreuses extensions et peuvent être corrompues si leur longueur n’est pas recalculée. Utilisez plutôt WP-CLI avec une sauvegarde préalable :

wp search-replace 'https://ancien-domaine.fr' 'https://www.exemple.fr' --all-tables-with-prefix --skip-columns=guid --dry-run

Cet exemple simule les remplacements sans écrire. Vérifiez le préfixe et la liste des tables, puis retirez --dry-run uniquement après validation et sauvegarde. N’utilisez pas cette commande telle quelle sur un multisite : son périmètre doit être défini séparément. Le champ guid des contenus n’est normalement pas une URL de navigation : ne le remplacez pas lors d’une migration standard.

5. Traiter les erreurs 500, page blanche et erreurs critiques

Une erreur HTTP 500 ou une page blanche après migration est souvent liée à une version de PHP différente, à une extension manquante ou à un plugin incompatible. Consultez en premier les journaux d’erreurs PHP dans le panneau d’hébergement. Pour obtenir un journal WordPress exploitable, activez temporairement le débogage dans wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/chemin/prive/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);

Adaptez le chemin du journal à un répertoire privé, hors de la racine web et accessible en écriture à PHP. Ne dupliquez pas des constantes déjà définies. Les journaux peuvent contenir des données sensibles : limitez leur accès et leur conservation. Ne laissez pas ce mode activé en permanence sur un site de production.

Sur une préproduction, testez d’abord l’extension citée dans le journal. Une désactivation globale peut interrompre les paiements, la sécurité ou des fonctions métier. Si le diagnostic exige de renommer le dossier wp-content/plugins, conservez ses fichiers et son nom d’origine, puis restaurez le nom plugins avant de réactiver les extensions une à une. Pour le thème, vérifiez qu’un thème de repli compatible est installé et réalisez le test sur la copie du site.

Comparez aussi la version PHP du nouveau serveur avec les prérequis de votre version de WordPress, du thème et des extensions. Une extension ancienne peut échouer sur une version PHP plus récente ; à l’inverse, un WordPress ou un plugin récent peut ne plus fonctionner sur une version PHP obsolète. Vérifiez les extensions indispensables, comme curl, mbstring, mysqli, xml, zip et les bibliothèques d’images utilisées par le site.

6. Réparer le HTTPS et les boucles de redirection

Le certificat SSL doit être installé pour le domaine exact visité, y compris la variante www si elle est utilisée. Une fois le certificat valide, choisissez une seule URL canonique : https://exemple.fr ou https://www.exemple.fr. Une boucle « trop de redirections » apparaît souvent lorsque WordPress force HTTPS alors qu’un proxy, un CDN ou l’hébergeur termine déjà la connexion SSL.

Conservez une copie des règles et recherchez, avec l’hébergeur, la couche qui renvoie chaque redirection. Corrigez seulement la règle contradictoire, de préférence sur une préproduction ; ne désactivez pas globalement HTTPS sur le site public. Si un proxy transmet HTTPS au serveur en HTTP, sa configuration doit transmettre correctement le protocole d’origine ; ne corrigez pas ce problème en ajoutant plusieurs redirections contradictoires.

7. Contrôler les médias, les droits et les tâches après remise en ligne

Des images cassées peuvent provenir d’un transfert incomplet du dossier wp-content/uploads, d’URLs anciennes ou de permissions incorrectes. Vérifiez la présence physique des fichiers concernés, puis testez leur ouverture directe dans le navigateur. Les dossiers doivent généralement être accessibles au serveur web et les fichiers lisibles ; des permissions trop ouvertes ne sont pas une solution de sécurité.

Terminez le diagnostic après migration par des tests ciblés :

1. ouvrez l’accueil, plusieurs pages, un article, la recherche et une page 404 ;
2. connectez-vous à wp-admin et enregistrez les permaliens ;
3. testez un formulaire, les e-mails transactionnels et, si applicable, une commande de test ;
4. purgez les caches WordPress, serveur et CDN après les corrections ;
5. consultez Outils > Santé du site pour détecter les problèmes d’API REST, de boucles ou de tâches planifiées ;
6. mettez à jour les sauvegardes automatiques pour qu’elles s’exécutent depuis le nouveau serveur.

Conservez l’ancienne sauvegarde des fichiers et de la base tant que ces contrôles ne sont pas validés. Elle constitue le point de retour le plus sûr si une correction de base de données ou une mise à jour révèle un défaut non détecté.