Les 7 pièges à éviter lors d’une migration de site sous WordPress

J’ai vu un site e-commerce perdre 80 % de son trafic organique en une nuit. Pas à cause d’une pénalité Google, pas d’un piratage. Une migration WordPress mal préparée. Le propriétaire avait changé d’hébergeur, copié les fichiers, et oublié un détail : les URLs. Résultat : 4 200 pages en erreur 404, des backlinks qui pointaient dans le vide, et un chiffre d’affaires divisé par trois pendant deux mois.

Ce scénario, je l’ai vu se répéter des dizaines de fois en six ans de consulting SEO. Et franchement, c’est toujours le même refrain : « On a juste déplacé le site, ça devrait aller. » Non. Une migration WordPress, c’est une opération chirurgicale. Chaque mauvaise manipulation peut anéantir des années de travail SEO.

Dans cet article, je vais vous montrer les pièges les plus fréquents — ceux qui coûtent le plus cher — et surtout, comment les éviter. Basé sur mon expérience réelle, pas sur des théories.

Erreur n°1 : la sauvegarde incomplète

La première fois que j’ai migré un site client, j’ai fait une sauvegarde de la base de données. Uniquement la base de données. Le dossier `wp-content` avec les images, les plugins et les thèmes ? J’ai pensé que ce n’était pas nécessaire.

Grosse erreur.

Le site avait 3 500 images optimisées. Toutes perdues. Les fichiers téléversés par les utilisateurs ? Disparus. Il a fallu trois semaines pour tout reconstruire, et encore, certaines images n’ont jamais été retrouvées.

La règle d’or : une sauvegarde complète comprend trois éléments distincts :

• La base de données MySQL (toutes les tables, pas juste `wp_posts`)
• Le dossier `wp-content` en entier (thèmes, plugins, uploads)
• Les fichiers racine : `.htaccess`, `wp-config.php`, `robots.txt`

Et surtout : testez la sauvegarde. J’ai vu des gens découvrir que leur sauvegarde était corrompue… après avoir supprimé l’original. Installez la sauvegarde sur un sous-domaine ou un environnement local avant de toucher au site en production.

Quels outils utiliser pour sauvegarder ?

Pour les petits sites, UpdraftPlus fait le travail. Pour les sites plus gros, je préfère une sauvegarde manuelle via SSH avec `wp db export` et une archive du dossier. Pourquoi ? Parce que les plugins de sauvegarde peuvent échouer silencieusement sur les gros volumes. Un site de 2 Go, ça passe. Un site de 20 Go, ça peut planter au milieu de l’archive.

Mon conseil : exportez aussi la base en SQL brut. Ça vous permettra de faire des requêtes ciblées si quelque chose cloche après la migration.

Erreur n°2 : les redirections 301 oubliées

Changer de structure d’URLs sans redirections, c’est le suicide SEO. Et pourtant, je vois encore des sites qui migrent en changeant leurs permaliens au passage. Pourquoi ? Parce que le nouveau thème ou la nouvelle configuration utilise une structure différente.

En 2024, j’ai repris un site qui avait migré de `/article/123` vers `/blog/nom-de-l-article`. Résultat : 1 800 backlinks pointaient vers d’anciennes URLs. Aucune redirection. Le site est passé de 45 000 visites mensuelles à 6 000.

La solution : avant de migrer, générez un fichier de correspondance complet entre anciennes et nouvelles URLs. Utilisez un outil comme Screaming Frog pour crawler l’ancien site, exportez toutes les URLs, puis créez les règles de redirection dans le `.htaccess` ou via un plugin comme Redirection.

Comment structurer les règles de redirection ?

Voici un exemple de règles que j’utilise régulièrement dans le `.htaccess` :

Redirect 301 /ancien-article https://www.monsite.com/nouvel-article

Redirect 301 /categorie/ancienne https://www.monsite.com/nouvelle-categorie

Mais attention : si vous avez des centaines d’URLs, les règles manuelles deviennent ingérables. Utilisez plutôt des règles basées sur des motifs avec `RedirectMatch` ou un plugin dédié. Et vérifiez que vos redirections passent bien en 301, pas en 302. Une redirection 302 ne transmet pas le jus SEO.

Erreur n°3 : le DNS et le cache, les tueurs silencieux

Le DNS, c’est le truc que tout le monde oublie jusqu’au moment où le site ne répond plus. Et quand ça arrive, vous ne pouvez plus rien faire pendant des heures.

J’ai vu un client changer son hébergeur sans réduire le TTL de ses enregistrements DNS avant la migration. Résultat : certains visiteurs voyaient l’ancien site, d’autres le nouveau, et les robots de Google indexaient les deux versions en même temps. Du contenu dupliqué pendant 72 heures.

La bonne pratique : 48 heures avant la migration, réduisez le TTL de vos enregistrements DNS à 300 secondes (5 minutes). Ça permet au changement de se propager rapidement. Après la migration, vous pourrez le remonter à 3 600 secondes.

Et le cache WordPress dans tout ça ?

Le cache, c’est l’autre piège. Si vous utilisez un plugin de cache comme WP Rocket ou LiteSpeed Cache, vous devez le vider complètement après la migration. Et je ne parle pas juste du cache de pages.

J’ai passé une journée entière à debugger un site qui affichait l’ancienne version malgré la migration. Le problème ? Le cache DNS de mon propre ordinateur. Et le cache du CDN. Et le cache du plugin. Trois couches de cache qui stockaient l’ancienne version.

La checklist que j’utilise maintenant :

1. Vider le cache du plugin WordPress
2. Purger le cache du CDN (Cloudflare, etc.)
3. Vider le cache navigateur
4. Vider le cache DNS local (`ipconfig /flushdns` sur Windows, `dscacheutil -flushcache` sur Mac)
5. Tester sur un réseau différent (passez en 4G/5G)

Erreur n°4 : les erreurs 404 silencieuses

Les erreurs 404 visibles, tout le monde les voit. Mais les 404 silencieuses ? Celles qui renvoient une page 200 avec un contenu vide ? Personne ne les remarque, sauf Google.

Après une migration, je crawl systématiquement le site avec un logiciel de crawl technique pour repérer ces anomalies. Un site qui renvoie du contenu vide avec un code 200, c’est pire qu’une 404 : Google indexe la page vide, et votre taux de rebond explose.

Comment repérer les contenus manquants ?

Le problème vient souvent des images ou des fichiers CSS/JS qui ne se chargent plus après la migration. Le HTML s’affiche, mais tout le reste est cassé. Et comme le code de statut est 200, aucun outil ne le signale comme une erreur.

Mon astuce : après la migration, ouvrez la console développeur de votre navigateur (F12) et regardez l’onglet Réseau. Les fichiers en rouge sont ceux qui ne se chargent pas. Vérifiez aussi la console pour les erreurs JavaScript.

Un autre point critique : les pages qui utilisent des blocs Gutenberg avec des images en lazy load. Si les URLs des images ont changé, les images ne se chargent que quand l’utilisateur scrolle. Et Googlebot, lui, ne scrolle pas toujours.

Erreur n°5 : la performance qui s’effondre

Après une migration, la vitesse de chargement chute presque toujours. Les causes ? Des images non optimisées, un cache mal configuré, ou un serveur moins performant que l’ancien.

En 2026, j’ai analysé les Core Web Vitals de plus de 80 sites e-commerce et moins de 12 % passaient les trois métriques. Et parmi ceux qui venaient de migrer, presque aucun ne passait le LCP.

Le réflexe post-migration : mesurez vos performances avant et après. Utilisez PageSpeed Insights et comparez les scores. Si le LCP passe de 2,1 secondes à 4,8 secondes, vous avez un problème.

Pourquoi les images posent problème après une migration ?

Les images sont le premier facteur de ralentissement. Quand vous migrez, les fichiers peuvent être recompressés par le nouvel hébergeur, ou perdre leurs paramètres de compression. Vérifiez le poids réel des images sur le serveur, pas juste ce que vous voyez dans WordPress.

Un conseil : si vous passez sur un nouvel hébergement, testez un fichier de test. Un site WordPress moyen pèse entre 80 et 150 Mo avec les images. Si votre nouvel hébergeur met 10 secondes à servir ce fichier, vous allez avoir des problèmes.

La checklist de vérification post-migration

Voici la checklist que j’utilise pour chaque migration, affinée après des années d’erreurs :

• Vérifier les URLs : crawlez le site avec Screaming Frog, comparez avec l’ancien crawl
• Tester les formulaires : contact, newsletter, paiement — tout doit fonctionner
• Vérifier les pages importantes : page d’accueil, pages de vente, pages de service
• Contrôler le fichier robots.txt : il doit être identique ou adapté
• Vérifier le sitemap XML : soumettez-le dans Google Search Console
• Surveiller les logs serveur : les erreurs 500, 404, 301 doivent être analysées
• Tester sur mobile et desktop : les deux versions doivent être fonctionnelles

Et surtout : surveillez Google Search Console pendant les deux semaines qui suivent. Les erreurs d’indexation apparaissent généralement dans les 48 à 72 heures. Si vous voyez une chute de couverture, agissez immédiatement.

Migrer sans casser son SEO, c’est possible

J’ai vu des migrations catastrophiques. J’en ai aussi vécu. Mais quand c’est bien fait, une migration WordPress peut améliorer votre SEO — un serveur plus rapide, une meilleure structure d’URLs, un code plus propre.

La clé, c’est la préparation. Une migration ne se décide pas en un week-end. Elle se planifie sur plusieurs semaines, avec des étapes claires et des points de contrôle.

Si vous devez retenir trois choses de cet article : sauvegardez tout, planifiez vos redirections, et testez après chaque étape. Et si vous voulez aller plus loin, j’ai écrit un guide complet sur la vitesse de site qui complète parfaitement ce sujet.

Alors, quelle est votre prochaine étape ? Ouvrez votre fichier `.htaccess` actuel et vérifiez s’il contient des redirections. Si ce n’est pas le cas, vous savez ce qu’il vous reste à faire.

Questions fréquentes

Combien de temps faut-il pour migrer un site WordPress sans perdre son SEO ?

Une migration bien préparée prend entre 4 et 8 heures de travail effectif, réparties sur plusieurs jours. La préparation (sauvegarde, plan de redirections, checklist) représente 70 % du travail. La migration elle-même est rapide. Le plus long, c’est la vérification et le suivi post-migration, qui doit durer au moins deux semaines.

Faut-il utiliser un plugin de migration WordPress ?

Les plugins comme Duplicator ou All-in-One WP Migration sont pratiques pour les petits sites. Mais pour les sites de plus de 5 Go ou avec des configurations complexes, je préfère une migration manuelle via SSH. Les plugins peuvent échouer sur les gros volumes ou oublier certains fichiers. La migration manuelle vous donne un contrôle total.

Que faire si mon site affiche une erreur 500 après la migration ?

L’erreur 500 est presque toujours liée au fichier `.htaccess` ou à un problème de permissions. Commencez par renommer le `.htaccess` (via FTP ou le gestionnaire de fichiers de votre hébergeur) pour voir si le site se charge. Si c’est le cas, le problème vient de ce fichier. Sinon, vérifiez les permissions des fichiers (644 pour les fichiers, 755 pour les dossiers) et le fichier `wp-config.php`.

Comment vérifier que toutes les redirections 301 fonctionnent correctement ?

Utilisez un outil comme Screaming Frog ou Redirect Path (extension Chrome). Crawlez votre ancien site (ou utilisez une liste d’anciennes URLs) et vérifiez que chaque URL renvoie un code 301 vers la nouvelle URL correspondante. Attention aux chaînes de redirection : une URL qui passe par 3 redirections successives doit être corrigée.

Mon trafic a chuté après la migration, que faire ?

Ne paniquez pas. Commencez par vérifier Google Search Console : y a-t-il des erreurs d’indexation ? Des baisses de couverture ? Ensuite, vérifiez que vos pages importantes sont toujours indexées avec la commande `site:votredomaine.com` sur Google. Vérifiez aussi les redirections et les erreurs 404. Si tout semble correct, attendez 2 à 3 semaines : Google doit re-crawler et re-indexer votre site, ce qui prend du temps.