Migrer un site vers WordPress sans perdre son référencement

Pourquoi une migration WordPress peut fragiliser le référencement

Changer de CMS, de structure ou d’hébergement modifie souvent les éléments que les moteurs de recherche utilisent pour explorer et comprendre un site. Une page peut changer d’adresse, une image peut devenir inaccessible, une balise importante peut disparaître ou un fichier de configuration peut bloquer l’exploration. Ces incidents peuvent entraîner une baisse de visibilité, même lorsque le contenu reste identique.

La migration ne consiste donc pas à copier des fichiers puis à installer un thème. Elle doit être préparée comme un projet technique avec un inventaire des contenus, une stratégie d’URL, des sauvegardes et une phase de vérification. Le référencement naturel repose notamment sur la disponibilité des pages, leur accessibilité pour les robots, leur pertinence éditoriale et la qualité des liens internes.

Une baisse temporaire peut survenir lorsque les moteurs réexplorent une nouvelle architecture. En revanche, les erreurs durables proviennent généralement d’un oubli précis : redirections absentes, anciennes URL supprimées sans équivalent, directives noindex conservées depuis l’environnement de test, ou liens internes pointant vers des adresses obsolètes.

Définir le périmètre de la migration avant toute intervention

La première étape consiste à déterminer ce qui va réellement changer. Une migration peut concerner le CMS uniquement, le nom de domaine, le protocole HTTP vers HTTPS, l’hébergement, l’arborescence ou plusieurs de ces éléments à la fois. Plus les changements sont nombreux, plus il devient difficile d’identifier l’origine d’un problème de trafic ou d’indexation.

Établissez une fiche de cadrage qui précise :

• l’adresse actuelle du site et sa future adresse ;
• le maintien ou non du nom de domaine ;
• les modifications prévues dans les catégories, les rubriques et les permaliens ;
• les contenus conservés, fusionnés, réécrits ou supprimés ;
• la date et la durée prévues pour la bascule ;
• les personnes chargées de la technique, du contenu et des contrôles.

La conservation des URL existantes est généralement la solution la moins risquée lorsque l’ancienne structure répond aux besoins du projet. Si une nouvelle organisation est nécessaire, chaque ancienne adresse importante doit recevoir une destination cohérente. Une redirection ne doit pas envoyer toutes les anciennes pages vers la page d’accueil, car cette pratique ne fournit pas aux moteurs une information suffisamment précise et dégrade l’expérience des visiteurs.

Réaliser un inventaire complet des anciennes URL

Avant de modifier le site, rassemblez la liste des URL accessibles ou référencées. Le fichier obtenu servira à comparer l’ancien site et la nouvelle version, puis à construire le plan de redirections.

L’inventaire peut inclure :

• les pages et articles publiés ;
• les catégories, étiquettes et archives utiles ;
• les fichiers PDF ou autres documents réellement consultés ;
• les images qui reçoivent des visites depuis les moteurs ;
• les pages ayant des liens externes ;
• les URL présentes dans le sitemap XML ;
• les adresses signalées comme importantes dans les outils de suivi du référencement.

Ne vous limitez pas aux menus du site. Une page ancienne peut ne plus être visible dans la navigation tout en recevant des visites ou des liens. Analysez aussi les journaux du serveur lorsque cet accès est disponible. Ils peuvent révéler le passage des robots, les erreurs 404 et les URL encore sollicitées.

Pour chaque adresse, ajoutez des colonnes indiquant son statut futur : conserver, remplacer, fusionner ou supprimer. Lorsqu’une page est remplacée, notez sa nouvelle URL. Ce tableau devient la base du plan de redirections et facilite les contrôles après la mise en ligne.

Sauvegarder les fichiers, la base de données et la configuration

Une migration doit pouvoir être annulée ou restaurée. Préparez au moins une sauvegarde complète de la base de données, des fichiers du site, des médias, des réglages du serveur et des éventuels certificats ou tâches automatisées nécessaires au fonctionnement du service.

Une sauvegarde fiable doit être stockée dans un emplacement distinct de l’hébergement principal. Vérifiez aussi qu’elle est exploitable en réalisant une restauration sur un environnement séparé. Un fichier présent sur un serveur ne constitue pas une garantie si sa restauration n’a jamais été testée.

Avant la bascule, conservez également :

• le fichier robots.txt existant ;
• les règles de réécriture du serveur, par exemple dans la configuration Apache ou Nginx ;
• les réglages de suivi et les identifiants de propriété des outils pour webmasters ;
• les paramètres DNS et les informations liées au certificat TLS ;
• la liste des extensions et leur rôle ;
• les réglages de cache, de compression et de redirection.

Cette documentation évite de perdre un réglage important au moment du changement. Elle permet aussi de comparer l’ancien comportement avec celui de WordPress après la migration.

Construire WordPress dans un environnement de préproduction

La nouvelle version doit être préparée dans un environnement qui n’est pas encore destiné au public. Il peut s’agir d’un sous-domaine technique protégé par mot de passe ou d’un serveur de préproduction. Le but est de tester la structure, le thème, les extensions et les contenus sans exposer une version incomplète aux visiteurs et aux moteurs.

Protégez cet environnement par une restriction d’accès et une directive de non-indexation. Cette protection ne doit toutefois pas être oubliée lors de la mise en production. Une erreur fréquente consiste à laisser active une option de WordPress qui demande aux moteurs de ne pas indexer le site.

Dans l’administration WordPress, le réglage se trouve généralement dans Réglages, Lecture, sous l’option demandant de décourager les moteurs de recherche d’indexer le site. Sur un environnement de test, cette option peut être activée. Après la bascule, contrôlez qu’elle est désactivée et vérifiez les balises robots générées par le thème ou les extensions de référencement.

Ne développez pas le nouveau site en modifiant directement la version publique. Cette méthode rend les comparaisons difficiles et augmente le risque de perte de contenu si une extension ou une manipulation provoque un incident.

Reproduire les contenus sans casser leur structure

Lors de l’importation, vérifiez le texte, les titres, les images, les documents, les catégories, les dates de publication et les auteurs. Un import automatisé peut laisser des champs vides, convertir incorrectement certains caractères ou modifier les chemins des médias.

Chaque page importante doit conserver une hiérarchie de titres cohérente. Le titre visible de la page, la balise title et la meta description remplissent des fonctions différentes. La balise title décrit la page dans les résultats de recherche, tandis que la meta description fournit un résumé susceptible d’être affiché. Elle ne garantit pas à elle seule un meilleur classement, mais elle participe à la compréhension du contenu et à l’information de l’internaute.

Contrôlez aussi :

• les attributs alt des images lorsqu’ils sont nécessaires à l’accessibilité et à la compréhension ;
• les liens internes intégrés dans le contenu ;
• les données structurées lorsqu’elles sont utilisées ;
• les URL canoniques ;
• les contenus paginés ou chargés dynamiquement ;
• les fichiers téléchargeables et leurs droits d’accès.

Évitez de publier plusieurs versions concurrentes d’une même page pendant la transition. Une adresse de test accessible sans protection peut être explorée et créer des doublons.

Conserver les URL ou organiser les redirections 301

La règle opérationnelle est de préserver les anciennes adresses lorsqu’aucune raison solide ne justifie leur changement. Si une URL évolue, mettez en place une redirection permanente de l’ancienne adresse vers la page équivalente. La redirection HTTP 301 indique que la destination est permanente. Elle permet aux navigateurs et aux moteurs de comprendre le déplacement de la ressource.

Préparez un tableau de correspondance avant la mise en ligne :

Ancienne URL	Nouvelle URL	Action	Contrôle
/ancienne-page	/nouvelle-page	Redirection permanente	Réponse HTTP et contenu cible
/article-a	/guide/article-a	Redirection permanente	Absence de chaîne
/contenu-obsolete	Aucune équivalence	Réponse 404 ou 410 selon le cas	Retrait des liens internes

Les redirections doivent viser la page la plus proche sur le plan éditorial. Évitez les chaînes, par exemple une ancienne URL qui redirige vers une adresse intermédiaire puis vers une troisième. Mettez à jour directement chaque ancienne adresse vers sa destination finale.

Une redirection ne remplace pas la correction des liens internes. Dans WordPress, recherchez les liens qui renvoient encore vers les anciennes URL et remplacez-les par les adresses finales. Contrôlez également les menus, les fils d’Ariane, les liens de navigation et les plans de site.

Régler les permaliens et les éléments techniques de WordPress

Dans WordPress, le chemin Réglages, Permaliens permet de définir la structure des URL. Choisissez une organisation stable, lisible et cohérente avec l’ancienne architecture lorsque cela est possible. Une modification tardive des permaliens peut créer un grand nombre d’erreurs si les redirections ne sont pas préparées.

Après l’enregistrement des réglages, testez plusieurs types de pages : page statique, article, catégorie, étiquette, fichier média et page de recherche. Vérifiez la réponse du serveur, l’adresse affichée et le contenu livré.

Examinez ensuite les fichiers et réglages suivants :

• le fichier robots.txt, pour éviter un blocage involontaire de répertoires utiles ;
• le sitemap XML, qui doit contenir les URL canoniques destinées à l’indexation ;
• les balises canoniques, qui ne doivent pas pointer vers l’ancien domaine ou vers une version de test ;
• les redirections de domaine et de protocole ;
• les en-têtes de sécurité et les certificats ;
• les règles de cache, qui peuvent servir une ancienne version d’une page.

Une extension de référencement peut générer le sitemap et les balises, mais elle ne dispense pas d’une vérification. Les réglages dépendent du thème, des extensions et de l’hébergeur.

Tester la migration avant la mise en production

Organisez une recette technique sur l’environnement de préproduction. Elle doit couvrir les parcours d’un visiteur, les fonctionnalités métier et les signaux destinés aux moteurs de recherche.

Utilisez une liste de contrôle structurée :

1. Ouvrir plusieurs anciennes URL et vérifier leur destination.
2. Tester les URL qui ne doivent pas changer.
3. Contrôler les pages avec formulaire, téléchargement ou inscription.
4. Vérifier les menus, liens internes, fils d’Ariane et boutons.
5. Examiner les images, les fichiers PDF et les contenus intégrés.
6. Contrôler les balises title, les descriptions, les titres et les canoniques.
7. Lire le sitemap XML et le fichier robots.txt.
8. Tester l’affichage sur mobile et sur ordinateur.
9. Mesurer les temps de réponse et rechercher les erreurs dans les journaux.

Parcourez aussi le site avec un outil d’analyse technique afin d’identifier les liens cassés, les pages orphelines, les redirections en chaîne, les erreurs serveur et les pages bloquées. La performance doit être observée dans des conditions réalistes, car un cache vide peut donner des résultats différents d’une page déjà mise en cache.

Ne remplacez pas les données réelles par des contenus génériques sans validation. Les textes de démonstration, les images manquantes et les liens temporaires peuvent passer inaperçus lors d’une recette trop rapide.

Planifier la bascule et surveiller les premiers jours

Choisissez une période où les équipes techniques et éditoriales peuvent intervenir rapidement. Avant l’ouverture, réduisez la durée prévue d’indisponibilité et évitez de publier de nouveaux contenus sur l’ancien site pendant la copie finale. Une publication effectuée après l’importation peut ne pas apparaître dans la nouvelle base de données.

Le jour de la bascule, suivez un ordre documenté :

1. Réaliser une dernière sauvegarde de l’ancien site.
2. Mettre temporairement en pause les modifications éditoriales.
3. Importer les derniers contenus et médias.
4. Basculer les fichiers, la base de données ou le domaine selon le scénario retenu.
5. Activer les redirections et vérifier le certificat HTTPS.
6. Désactiver la non-indexation de l’environnement de test.
7. Contrôler la page d’accueil, les pages prioritaires et les anciennes URL.
8. Vérifier le sitemap et les principaux réglages de suivi.

Après l’ouverture, surveillez les erreurs 404, les erreurs serveur, les redirections et les variations inhabituelles de fréquentation. Les outils pour webmasters peuvent signaler des problèmes d’indexation, mais les données apparaissent parfois avec un délai. Les journaux du serveur et les tests manuels complètent donc cette surveillance.

Conservez l’ancien site dans un état récupérable pendant la période de stabilisation, sans le laisser accessible comme une copie concurrente. Il doit être possible de revenir à une version cohérente si un incident majeur survient.

Diagnostiquer une baisse de visibilité après la migration

Une variation de trafic ne signifie pas automatiquement que la migration est la seule cause. Commencez par comparer les périodes équivalentes et les pages concernées. Une baisse généralisée peut indiquer un problème de domaine, de serveur, de robots.txt ou de non-indexation. Une baisse limitée à certaines URL oriente plutôt vers des redirections, une modification de contenu ou une nouvelle architecture interne.

Les contrôles prioritaires sont les suivants :

• la réponse HTTP des anciennes et nouvelles adresses ;
• la présence d’une balise noindex inattendue ;
• la cohérence des URL canoniques ;
• la disponibilité du sitemap XML ;
• la résolution DNS et le certificat HTTPS ;
• les erreurs 404 et 5xx dans les journaux ;
• la conservation des textes, titres et liens internes importants ;
• la présence de blocages dans robots.txt ou dans la configuration du serveur.

Corrigez d’abord les problèmes qui empêchent l’accès ou l’indexation. Ensuite, traitez les défauts de contenu et de maillage interne. Évitez de modifier simultanément le thème, les URL, les textes et les extensions pendant le diagnostic, car plusieurs changements rendent l’analyse des causes plus incertaine.

FAQ sur la migration d’un site vers WordPress

Faut-il garder les mêmes URL pendant une migration WordPress ?

Lorsque l’ancienne structure convient au projet, sa conservation réduit le nombre de redirections et de contrôles nécessaires. Si une nouvelle architecture apporte une réelle amélioration, préparez une correspondance précise entre chaque ancienne adresse et sa destination. Les pages sans équivalent doivent être traitées au cas par cas, sans redirection automatique vers la page d’accueil.

Quelle différence entre une redirection 301 et une erreur 404 ?

Une redirection 301 indique qu’une page a été déplacée de manière permanente vers une autre adresse. Une erreur 404 indique que la ressource demandée n’a pas été trouvée. La 404 peut être appropriée lorsqu’aucun contenu équivalent n’existe, à condition de retirer les liens internes qui y renvoient et de fournir une page d’erreur utile.

Peut-on développer le nouveau site sur un sous-domaine ?

Oui, à condition de protéger l’environnement de test et d’empêcher son indexation. Avant la mise en ligne, retirez la restriction destinée aux robots uniquement sur le site public, puis vérifiez que le sitemap, les canoniques et les liens ne renvoient pas vers le sous-domaine technique.

Combien de temps faut-il surveiller une migration ?

La surveillance doit commencer dès la bascule et se poursuivre pendant la phase où les erreurs sont susceptibles d’apparaître dans les journaux et les outils pour webmasters. La durée dépend de la taille du site, du volume d’URL et de la fréquence de publication. L’important est de conserver un suivi documenté plutôt que de s’arrêter après les premiers tests positifs.

Une extension WordPress suffit-elle pour protéger le référencement ?

Une extension peut aider à gérer les titres, les descriptions, les canoniques, les sitemaps ou certaines redirections. Elle ne remplace pas l’inventaire des URL, les sauvegardes, les tests serveur, la vérification des contenus et le contrôle des réglages d’hébergement. La sécurité du référencement dépend de l’ensemble de la migration.