Migration WordPress : les 10 erreurs à éviter

Changer d’hébergeur ou refaire un site WordPress paraît simple tant que la page d’accueil fonctionne. Le vrai test, c’est ce qui arrive aux commandes, aux anciennes URL, aux formulaires et aux visiteurs qui reviennent par Google.

Une migration réussie ne se résume pas à déplacer des fichiers

La migration peut concerner seulement le serveur, ou aussi le domaine, la structure des pages et les extensions. Ces situations n’ont pas les mêmes risques. Si les URL restent identiques, une série de redirections n’est généralement pas nécessaire. Si elles changent, il faut préparer une correspondance précise entre anciennes et nouvelles adresses.

Les dix erreurs les plus fréquentes

1. Partir sans sauvegarde restaurable. Une copie des fichiers ne suffit pas toujours : il faut aussi la base de données, les fichiers de configuration et un moyen de revenir en arrière. Idéalement, testez la restauration.
2. Ne pas tester sur un environnement temporaire. Avant de modifier le DNS, vérifiez les pages, les formulaires, les accès administrateur et le processus de commande WooCommerce. Baissez la durée de cache DNS (TTL) un ou deux jours avant la bascule, et gardez l’ancien hébergement actif quelques jours après : certains visiteurs arriveront encore sur l’ancien serveur pendant la propagation.
3. Modifier domaine, thème, hébergement et extensions en même temps. Lorsque plusieurs éléments changent simultanément, il devient beaucoup plus difficile d’identifier la cause d’un problème.
4. Oublier les URL internes de WordPress. Les réglages « Adresse web de WordPress » et « Adresse web du site » doivent correspondre à la configuration retenue. Une mauvaise modification peut bloquer l’administration.
5. Mettre les redirections 301 au hasard. Une ancienne page produit doit pointer vers son équivalent pertinent, pas automatiquement vers l’accueil. Préparez un tableau ancienne URL → nouvelle URL.
6. Empiler les redirections. Une règle Cloudflare, une autre dans l’hébergement et une troisième dans WordPress peuvent créer deux ou trois sauts, voire une boucle.
7. Mal configurer HTTPS. Testez le certificat du domaine principal et de la variante www, même si elle sert seulement à rediriger. Avec Cloudflare, le mode Flexible peut entrer en conflit avec un serveur qui force HTTPS (voir le guide HTTP vers HTTPS).
8. Laisser un noindex de préproduction. Après la bascule, retirez les restrictions de test si elles ne sont plus souhaitées. Contrôlez aussi robots.txt et les balises canonical.
9. Oublier cache, courriels et tâches planifiées. Purgez les caches au bon moment; vérifiez SMTP, formulaires, paiements, sauvegardes et tâches cron après migration.
10. Considérer le projet terminé dès que l’accueil s’ouvre. Surveillez les erreurs 404, les journaux, Google Search Console, la vitesse et les conversions pendant les jours et semaines suivants.

La liste de vérification après la bascule

• Tester le domaine principal, ses variantes HTTP/HTTPS et www/sans www.
• Vérifier un échantillon d’anciennes URL importantes et leur destination précise.
• Tester une page produit, un formulaire, un compte client et une commande fictive lorsque pertinent.
• Contrôler les balises canonical, le sitemap et l’absence de noindex accidentel.
• Comparer les performances et surveiller les erreurs serveur.

Comment Redirect Audit peut aider

Redirect Audit permet de contrôler rapidement les variantes d’un domaine, les codes 301/302, les chaînes, HTTPS et certains signaux SEO. Il ne remplace toutefois pas un contrôle de toutes les anciennes pages d’une migration : testez ces URL individuellement, avec leur destination attendue.

Si l’audit met en évidence une boucle ou plusieurs sauts, consultez le guide de correction WordPress ou celui sur les chaînes de redirections. Pour planifier une migration d’hébergement avec un retour arrière et des vérifications sérieuses, parlons-en.

Références : Google Search Central — migrations de sites · WordPress — Migrating WordPress.