La plupart des migrations WordPress n'entraînent pas de perte de classement, car Google ne pénalise pas le fait de changer de site. Elles entraînent une perte de classement parce que les URL changent sans que personne ne s'en aperçoive, que les images renvoient vers des chemins d'accès qui n'existent plus et que personne ne compare le nouveau site à une version d'archive de l'ancien.
Voici la liste de contrôle que j'utilise concrètement lorsque je transfère un site : ce qu'il faut noter avant de toucher à quoi que ce soit, comment gérer correctement les redirections, et les vérifications après la mise en ligne qui permettent de détecter les dysfonctionnements avant que Google ne le fasse.
Principaux enseignements
- La plupart des baisses de classement liées à la migration sont dues à des URL non redirigées et à des chemins d'accès erronés, et non à la migration elle-même
- Dressez un inventaire complet des URL et effectuez un crawl avant toute intervention ; vous ne pouvez pas rediriger des URL que vous n'avez jamais répertoriées.
- Les redirections 301 redirigent directement l'ancienne URL vers la nouvelle URL exacte en une seule étape ; les redirections générales vers la page d'accueil vous font perdre le référencement que vous avez acquis.
- Les images cessent le plus souvent de s'afficher lors d'un transfert de site WordPress en raison de chemins d'accès codés en dur et d'URL sérialisées qui restent dans la base de données
- Un léger fléchissement temporaire pendant quelques semaines est normal ; une baisse qui persiste signifie généralement qu'une étape de cette liste de contrôle a été omise.
Pourquoi les migrations WordPress entraînent une perte de classement
Propre à Google documentation relative au transfert du site Il est clair qu’une migration correctement effectuée ne devrait pas entraîner de perte durable de positionnement, et mon expérience le confirme. Les dommages durables que je constate lors des audits proviennent d’erreurs techniques : une ancienne URL qui renvoie désormais un code 404 au lieu d’un 301, une page de catégorie dont le slug a changé sans que personne ne s’en aperçoive, ou une médiathèque diffusant des images à partir d’un chemin d’accès qui n’existe plus depuis la fermeture de l’ancien serveur.
Chaque URL cassée est une petite fuite. On peut s'en remettre si elle est isolée, mais les migrations cassent rarement une seule chose ; elles cassent toute une catégorie d'éléments, comme toutes les images de 300 articles, ou toutes les URL d'une catégorie renommée. Les dégâts varient en fonction du motif que vous avez manqué, c'est pourquoi les vérifications ci-dessous portent sur des catégories d'URL et non sur des pages individuelles.
Il faut également tenir compte d'une réalité en matière de délais qu'il convient d'accepter d'emblée. Même une migration effectuée sans heurts s'accompagne de quelques semaines de fluctuations, le temps que Google effectue une nouvelle exploration et réévalue les signaux. Ne cédez pas à la panique en annulant la migration dès la deuxième semaine ; évaluez plutôt les résultats de la migration à la sixième semaine par rapport à la référence que vous êtes sur le point d'enregistrer.
Avant la migration : dressez l'inventaire de ce dont vous disposez
Il est impossible de vérifier un déplacement par rapport à un site qui n'existe plus ; c'est pourquoi la référence est l'élément le plus précieux de cette liste. Je note quatre éléments avant de toucher quoi que ce soit.
- Un inventaire complet des URL. Effectuez une exploration du site en ligne (avec Screaming Frog ou tout autre outil d'exploration) et exportez toutes les URL : pages, articles, catégories, balises, images, fichiers PDF. C'est à partir de cette liste que seront établies votre carte de redirection et votre comparaison post-lancement.
- Un aperçu des classements et du trafic. Exportez les statistiques de Search Console (requêtes et pages, derniers 3 mois) et notez vos pages les plus performantes. Il s'agit de la référence par rapport à laquelle vous évaluerez la migration ; conservez donc bien ce fichier d'exportation, ne vous contentez pas de vous en souvenir.
- Une sauvegarde complète, comprenant les fichiers et la base de données. Pas celle fournie automatiquement par l'hébergeur, mais la vôtre, que vous aurez téléchargée et testée. Si la migration tourne mal, cela fera la différence entre une heure d'indisponibilité et un week-end perdu.
- Le plan du site et le fichier robots.txt actuels. Conservez des copies. Vous pourrez ainsi comparer les versions du nouveau site avec celles-ci après sa mise en ligne ; les différences sautent immédiatement aux yeux lorsque l'on a les originaux côte à côte.
Les étapes de la migration vers WordPress, dans l'ordre
L'enchaînement des étapes est plus important que n'importe quelle opération prise isolément. Effectuez la configuration et les tests sur une copie, redirigez les URL, puis basculez ; les sites risquent de subir des dysfonctionnements si ces étapes sont effectuées dans le mauvais ordre ou sous la pression du temps sur le serveur de production.
Une migration WordPress en cinq étapes bien définies
- Effectuer un instantané et sauvegarder l'ensemble des données (URL, classements, fichiers, base de données)
- Développer et tester le nouveau site sur l'environnement de préproduction, en empêchant son indexation
- Redirigez chaque ancienne URL vers sa nouvelle adresse exacte
- Mise en production : basculer le DNS, activer les redirections 301, autoriser l'indexation
- Effectuer l'exploration, la vérification et la surveillance pendant 4 à 6 semaines
Sur l'environnement de test, deux paramètres assurent l'essentiel de la protection. Veillez à ce que la copie de l'environnement de test ne figure pas dans l'index (Paramètres, Lecture, “ Empêcher l'indexation par les moteurs de recherche ”, ainsi que l'authentification HTTP si l'hébergeur la propose), car un site de test indexé devient un doublon de votre site réel. Et lorsque vous migrez la base de données, utilisez un outil qui gère données sérialisées (WP Migrate, Duplicator ou la fonction « recherche-remplacement » de WP-CLI) ; une simple opération de recherche-remplacement sur une sauvegarde de base de données corrompt les paramètres qui stockent des URL dans des tableaux sérialisés, et les constructeurs de pages procèdent ainsi en permanence.
Si la migration implique un changement d'hébergeur, testez les performances sur le nouveau serveur avant la bascule DNS, et non après. Le temps de réponse jusqu'au premier octet et les Core Web Vitals font partie intégrante de ce que vous migrez, et un hébergeur plus lent dévalorise discrètement ce que vous avez mis des mois à construire ; c'est la même logique que celle exposée dans mon Guide sur les Core Web Vitals s'applique ici. Les formules WordPress gérées proposées par des hébergeurs tels que Hostinger ou Cloudways simplifier le processus « staging puis switch » grâce à l'intégration des fonctions de staging et de clonage.
Le mappage de redirection : l'étape décisive pour le résultat final
Si les URL subissent la moindre modification (nouveau domaine, suppression d'un sous-dossier, nouvelle structure de permaliens, changement de nom des catégories), chaque ancienne URL doit être 301 vers son nouvel équivalent exact, un seul saut, pas de chaîne. J'ai expliqué dans mon article quand il convient d'utiliser chaque type de redirection : répartition des redirections; pour un déménagement définitif, la réponse est 301.
Créez un tableau à partir de votre liste d'URL : l'ancienne URL dans une colonne, la nouvelle URL dans la suivante. Ce qui distingue une migration soignée d'une migration bâclée, c'est la précision. Rediriger systématiquement toutes les URL vers la nouvelle page d'accueil peut sembler suffisant, mais Google considère ces redirections comme des erreurs 404 « légères » et l'autorité de page que vous avez construite s'évapore.
L'endroit où vous effectuez la mise en œuvre a moins d'importance qu'on ne le pense : les règles au niveau du serveur (.htaccess ou Nginx) sont les plus rapides, et un plugin de redirection ou Rang Math’Le module de redirection de […] convient à la plupart des sites. L'important est que les modèles couvrent des catégories d'URL et que les exceptions soient gérées individuellement.
Un piège à éviter lors de la conception : si le site passe également de http à https ou supprime « www » au même moment, enchaînez les règles de manière à ce que toute ancienne variante atteigne l'URL finale en un seul saut. Les enchaînements du type http, puis https, puis le nouveau domaine ralentissent l'exploration et laissent échapper des signaux à chaque étape supplémentaire.
Après le lancement : vérifiez le transfert avant que Google ne le fasse
C'est dans les heures qui suivent les changements de DNS que la liste de contrôle prend toute sa valeur. Effectuez un crawl de la liste des ANCIENNES URL (pas du nouveau site, mais de l'ancienne liste) et vérifiez que chaque URL renvoie une seule redirection 301 vers la bonne destination. Effectuez ensuite un crawl du nouveau site et comparez-le à votre inventaire d'avant le transfert ; tout élément ayant disparu sans redirection constitue une fuite que vous pouvez encore colmater.
Pour les contrôles ponctuels, un testeur de chaîne vous montre ce que voit un robot d'indexation. Voici notre propre domaine sur httpstatus.io : l'URL HTTP « nue » nécessite deux redirections 301 pour aboutir à la version finale https avec www, ce qui est acceptable pour un changement de protocole, mais correspond exactement à ce qu'il ne faut PAS faire en cas de changement de domaine.
Dans Search Console, ajoutez la nouvelle propriété (si le domaine a changé) et utilisez la Outil de changement d'adresse dans la rubrique « Paramètres » ; ignorez cette étape en cas de transfert d’un hébergeur au sein du même domaine ou de passage de HTTP à HTTPS, où cela ne s’applique pas. Dans tous les cas, renvoyez le plan du site, puis surveillez le rapport « Pages » au cours des semaines suivantes : le nombre de pages indexées de l’ancienne propriété devrait diminuer à mesure que celui de la nouvelle augmente. Si, au contraire, vous constatez que le nombre de pages indexées du nouveau site stagne, mon Guide d'interprétation des baisses d'indexation explique comment faire la différence entre un simple recomptage et un véritable problème.
Quels sont les problèmes qui surviennent généralement lors d'une migration WordPress, et comment les détecter ?
| Ce qui se casse | D'où ça vient ? | Le contrôle qui permet de le détecter |
|---|---|---|
| Images non affichées | Chemins d'accès à l'ancien domaine codés en dur et URL sérialisées dans la base de données | Effectuez une exploration du nouveau site à la recherche d'images 404 ; ouvrez vos 10 articles les plus populaires dans un navigateur |
| URL manquantes | Modifications apportées aux slugs ou aux permaliens que personne n'a consignées | Comparez la nouvelle exploration avec la liste des URL établie avant le transfert |
| Chaînes de redirection | Empilement des règles relatives aux protocoles, au WWW et aux domaines | Passez les anciennes URL les plus fréquentes dans un testeur de chaîne ; signalez tout ce qui nécessite plus d'un saut |
| Canoniques incorrects | Canoniques de domaine ancien ou de site de test laissés dans l'en-tête | Consultez le code source des pages clés ; chaque URL canonique doit pointer vers la nouvelle URL en ligne. |
| Plan du site obsolète | Le plan du site mis en cache ou le plugin fait toujours référence à d'anciennes URL | Récupérez directement le fichier /sitemap.xml et soumettez-le à nouveau dans Search Console |
Deux d'entre elles méritent une attention particulière, notamment dans WordPress. Les images cessent si souvent de s'afficher correctement après un transfert que j'ai rédigé un guide de dépannage spécifique pour Les images ne s'affichent pas après la migration; en résumé, la base de données pointe généralement encore vers l'ancien chemin d'accès, et la solution consiste à effectuer une recherche-remplacement correcte des données sérialisées, et non à réimporter les fichiers.
Les balises canoniques sont plus discrètes. Une URL de staging laissée dans une balise canonique indique à Google que la page réelle se trouve ailleurs, ce qui se traduit par la suite par des anomalies d'indexation. Si Search Console commence à signaler une confusion au niveau des balises canoniques après un déplacement, mon guide de dépannage officiel le traverse.
Alors, quel est réellement le niveau de risque lié à la migration d'un site WordPress ?
Honnêtement, c'est bien moins risqué que ce que l'on dit, à une condition : qu'on s'occupe de la paperasse fastidieuse. Toutes les histoires d'horreur liées à une migration pour lesquelles j'ai été sollicité remontent à une étape omise de la liste ci-dessus, généralement l'inventaire des URL ou la carte de redirection, et presque jamais à une mauvaise gestion de la part de Google lors d'un transfert effectué dans les règles de l'art.
Considérez donc cette transition comme un problème de données, et non comme un acte de foi. Enregistrez tout, répertoriez tout, vérifiez par rapport à vos enregistrements, et laissez à Google quelques semaines pour s'adapter. Oui, un léger déséquilibre temporaire fait partie du jeu ; une perte définitive, en revanche, n'en fait pas partie, et c'est cette liste de contrôle qui fait toute la différence.
Vous migrez un site et vous souhaitez un avis extérieur ?
N'hésitez pas à nous contacter ou m'envoyer un courriel Avant de basculer le DNS, consacrez 30 minutes à vérifier votre plan de redirection : cela vous reviendra bien moins cher que de devoir regagner les positions perdues. N'oubliez pas : la sécurité d'une migration dépend entièrement de la liste de contrôle sur laquelle elle repose.
Vous souhaitez que nos publications apparaissent plus souvent sur Google ?
En un clic, Google affichera ce site dans votre rubrique « À la une ».
