Votre migration est terminée, mais le site affiche une erreur, redirige vers l’ancien serveur ou perd ses images. Face à un site WordPress cassé après migration, la priorité n’est pas d’essayer dix corrections au hasard. Il faut d’abord identifier la couche qui échoue : domaine, serveur, base de données, fichiers ou application WordPress.
Cette méthode rassemble dix vérifications dans un ordre logique. Elle convient à une migration d’hébergeur, à un changement de domaine ou au passage d’un environnement de test vers la production.
À retenir : conservez l’ancien hébergement et une sauvegarde exploitable tant que le nouveau site n’a pas passé tous les tests. Notez chaque modification, ne changez qu’un élément à la fois et consultez les journaux d’erreurs plutôt que de deviner.
Site WordPress cassé après migration : sécuriser le diagnostic
1. Délimiter précisément ce qui ne fonctionne plus
Commencez par décrire le symptôme. « Le site est cassé » peut désigner une panne complète, une erreur 500, une boucle de redirection, un écran blanc, des pages internes en 404 ou seulement des images absentes. Testez au minimum :
- la page d’accueil et une page interne;
- /wp-admin/ et /wp-login.php;
- un formulaire;
- une image de la médiathèque, depuis un autre réseau.
Relevez aussi le code HTTP. Une erreur de certificat avant le chargement de WordPress n’a pas la même origine qu’une erreur PHP. Si seule une fonction est touchée, le transfert n’est probablement pas entièrement raté.
Comparez ensuite le résultat avec votre checklist de migration WordPress. Elle permet de retrouver une étape omise sans transformer cet incident en nouveau projet de migration.
2. Figer la situation et préserver un retour arrière
Avant toute correction, gardez une copie des fichiers, un export de la base migrée et la dernière sauvegarde fonctionnelle. Conservez également les accès à l’ancien serveur. N’installez pas de nouvelle extension et ne lancez pas toutes les mises à jour « pour voir » : vous ajouteriez des variables au diagnostic.
Notez l’heure de la bascule, les DNS modifiés, les versions PHP et les opérations déjà tentées. Si le site reçoit des commandes ou des réservations, déterminez où les nouvelles données sont enregistrées. Une restauration pourrait sinon effacer des transactions récentes.
3. Confirmer que le domaine arrive au bon serveur
Vérifiez que les enregistrements DNS utilisés par le domaine pointent vers la nouvelle infrastructure. Pendant la propagation, deux visiteurs peuvent encore atteindre des serveurs différents. Le certificat SSL doit couvrir le domaine final, et les redirections HTTP/HTTPS ou avec/sans www ne doivent pas se contredire.
Si l’ancien serveur répond encore, comparez ses journaux avec ceux du nouveau. Google recommande de surveiller le trafic sur les deux hébergements et de ne fermer l’ancien que lorsqu’il ne reçoit plus de trafic. Pour approfondir cette phase, consultez la méthode pour migrer WordPress sans interruption.
Contrôler WordPress, la base de données et le serveur dans l’ordre
4. Vérifier la connexion à la bonne base de données
Le fichier wp-config.php doit contenir le nom de base, l’utilisateur, le mot de passe et l’hôte fournis par le nouvel hébergeur. Confirmez aussi que la base a bien été importée, que les tables attendues sont présentes et que leur préfixe correspond à la valeur $table_prefix.
La documentation officielle sur le déplacement de WordPress confirme que les identifiants doivent être adaptés lorsqu’ils changent. Ne réimportez pas la base à répétition : sur un site actif, vous pourriez écraser de nouvelles données.
5. Contrôler home, siteurl et les anciennes URL
Une mauvaise valeur home ou siteurl peut provoquer des redirections vers l’ancien domaine, empêcher l’accès à l’administration ou charger les styles depuis une adresse temporaire. Vérifiez ces valeurs dans les réglages WordPress, dans la table des options ou dans wp-config.php si elles y sont forcées.
Si le domaine, le protocole ou le répertoire a changé, recherchez les anciennes adresses. Utilisez une méthode compatible avec les données sérialisées et commencez par une simulation. Un remplacement SQL aveugle peut endommager des réglages.
6. Comparer les fichiers, les médias et leurs droits d’accès
Assurez-vous que wp-content, les extensions, le thème actif et le dossier uploads ont été copiés intégralement. Pour une image brisée, ouvrez son URL : une réponse 404 suggère un fichier absent ou un chemin incorrect; une réponse 403 oriente plutôt vers les droits d’accès ou une règle de sécurité.
Comparez aussi le propriétaire et les permissions des fichiers avec les exigences de l’hébergeur. La documentation WordPress sur les permissions des fichiers rappelle que la configuration dépend de l’environnement. N’ouvrez pas excessivement les droits pour contourner l’erreur.
7. Lire les logs avant d’isoler PHP, les extensions et le thème
Le nouveau serveur peut employer une version PHP, des modules ou des limites différents. Consultez d’abord les logs. Au besoin, journalisez temporairement les erreurs avec WP_DEBUG_LOG en masquant leur affichage public; la documentation de débogage WordPress déconseille de laisser ce mode actif en production.
Si le journal pointe vers une extension ou le thème, désactivez seulement l’élément concerné et retestez. Une erreur HTTP 500 mérite le diagnostic détaillé proposé dans Erreur 500 WordPress : où chercher. Si la piste concerne l’environnement, vérifiez aussi la compatibilité entre la version PHP et WordPress.
8. Réparer les règles de permaliens sans masquer la cause
Lorsque la page d’accueil fonctionne mais que les pages internes renvoient une 404, vérifiez les règles de réécriture. Sous Apache, elles peuvent dépendre de .htaccess; sous Nginx, elles relèvent de la configuration du serveur. La simple visite de l’écran Réglages > Permaliens vide les règles de réécriture, selon la documentation officielle des permaliens.
Sauvegardez toute règle personnalisée avant de régénérer la configuration. Si l’erreur 404 persiste, contrôlez le chemin d’installation, le serveur et les redirections. Un guide distinct devra approfondir ce symptôme.
Valider le site avant de fermer l’ancien hébergement
9. Tester les fonctions qui produisent une action réelle
Un site peut paraître normal tout en ayant perdu ses fonctions essentielles. Effectuez un test complet, avec des données reconnaissables :
- envoi et réception d’un formulaire;
- compte utilisateur ou achat test si le site le permet;
- recherche, téléchargement, zone membre ou connexion API;
- tâches planifiées et sauvegardes;
- purge des caches WordPress, serveur et CDN.
Vérifiez le résultat final, pas seulement le message « envoyé » : un formulaire peut confirmer l’envoi sans que le courriel arrive. Documentez cette recette avant de déclarer la migration terminée.
10. Contrôler l’exploration, l’indexation et la surveillance
Retirez les protections de test qui n’ont plus lieu d’être : noindex, blocage dans robots.txt, authentification temporaire ou règle de pare-feu. Vérifiez ensuite les URL canoniques, le sitemap XML, les principales redirections et les codes HTTP des pages stratégiques. Dans Google Search Console, inspectez quelques URL et surveillez les erreurs d’exploration.
Surveillez les journaux des deux serveurs, les erreurs 4XX/5XX, la disponibilité et les formulaires. La maintenance WordPress après une migration ou une refonte couvre cette stabilisation; le monitoring WordPress aide à détecter une rechute.
FAQ sur un site WordPress cassé après migration
Pourquoi mon site WordPress redirige-t-il vers l’ancien domaine?
Les causes fréquentes sont des valeurs home ou siteurl incorrectes, des anciennes URL encore stockées dans la base, une règle de redirection ou un cache non purgé. Vérifiez-les dans cet ordre et modifiez un seul niveau à la fois.
Pourquoi la page d’accueil fonctionne-t-elle, mais pas les autres pages?
Ce symptôme correspond souvent à des règles de permaliens absentes ou incompatibles avec le nouveau serveur. Vérifiez .htaccess sous Apache ou la configuration de réécriture sous Nginx, puis régénérez les règles.
Pourquoi les images ont-elles disparu après la migration?
Le dossier uploads peut être incomplet, les URL peuvent encore viser l’ancien domaine, ou le serveur peut refuser l’accès aux fichiers. Le code HTTP de l’image aide à distinguer un fichier absent d’un problème d’autorisation.
Faut-il restaurer immédiatement l’ancien site?
Pas toujours. Si la panne bloque les ventes ou expose des données, un retour arrière contrôlé peut être nécessaire. Avant toute restauration, sauvegardez l’état actuel et vérifiez les données créées depuis la bascule pour éviter de les perdre.
Quand faut-il appeler un spécialiste WordPress?
Demandez de l’aide si vous n’avez pas de sauvegarde fiable, si la base contient de nouvelles transactions, si les logs révèlent une erreur inconnue ou si plusieurs couches semblent touchées. CapsuleWeb peut réaliser un débogage ciblé de votre site WordPress ou reprendre une migration WordPress qui n’a pas abouti correctement.
Conclusion : réparer la cause, puis stabiliser la migration
Un site WordPress cassé après migration n’exige pas une collection de « trucs », mais un ordre de diagnostic. Commencez par le serveur réellement joint, sécurisez les données, puis contrôlez la base, les URL, les fichiers, PHP, les permaliens et les fonctions métier. Terminez par l’indexation et la surveillance.
Si votre site reste inaccessible ou si chaque correction révèle un nouveau symptôme, évitez d’accumuler les modifications. Contactez CapsuleWeb pour obtenir un diagnostic fondé sur les logs, protéger vos données récentes et remettre le site en service avec une cause clairement identifiée.