Éviter la Perte de SEO lors d'une Migration de Site: Guide
Après une refonte, les positions chutent surtout à cause de redirections oubliées, pas d'un design faible. Mapping d'URL et checklist de migration.
Équipe rabbitclipPublié: 6 min de lecture
En bref
La raison la plus fréquente d'une chute de classement après une refonte, c'est que les anciennes URLs ne sont jamais redirigées vers les nouvelles. Google attend une redirection 301 correcte à chaque changement d'URL, afin que le signal accumulé par l'ancienne page se transmette à la nouvelle adresse; sauter cette étape, et le moteur de recherche recommence à évaluer la page depuis zéro (Google Search Central, Site moves with URL changes).
Cette perte n'est généralement pas la faute de l'équipe design, mais un trou dans la planification du projet. Le nouveau design est validé, le développement démarre, mais personne n'extrait la liste complète des URLs de l'ancien site; le soir de la mise en ligne, personne ne détient la correspondance entre anciennes et nouvelles adresses.
Ce qui suit couvre les trois étapes d'une migration: la préparation, le soir de la mise en ligne, et les vérifications qui suivent.
Préparation: l'ancien site est entièrement cartographié
Avant le basculement, toutes les URLs indexables (indexées) de l'ancien site sont rassemblées, à partir du rapport de couverture dans Search Console, du sitemap, et si besoin d'un outil de crawl. Si le site d'un service de signature électronique compte des centaines d'articles d'aide, chacun doit figurer individuellement sur cette liste.
Chaque ancienne URL est ensuite associée à son équivalent sur le nouveau site. Si une page n'a pas d'équivalent exact dans la nouvelle structure, elle redirige vers la page la plus proche sur le même sujet; sans équivalent du tout, rediriger vers une page de catégorie pertinente donne un meilleur résultat que rediriger vers la page d'accueil.
Pourquoi une redirection 301 n'est pas la même chose qu'une 302
Une redirection 301 dit «cette page a déménagé de façon permanente», et le moteur de recherche transfère le signal de l'ancienne page vers la nouvelle adresse. Une 302 dit «cette page est temporairement ailleurs», et aucun transfert de signal n'est attendu. Utiliser une 302 pour un changement de site permanent est une erreur fréquente qui bloque ce transfert (Google Search Central).
Les chaînes de redirection méritent aussi une vérification; si l'ancienne adresse A ne redirige pas directement vers la nouvelle mais d'abord vers une autre ancienne adresse, puis seulement vers la nouvelle, cette chaîne coûte à la fois en vitesse et en signal. L'objectif est que chaque ancienne adresse atteigne la nouvelle en une seule étape.
Le sitemap et le fichier robots sont mis à jour
Une fois le nouveau site en ligne, le sitemap (sitemap.xml) doit contenir les nouvelles URLs et être soumis au moteur de recherche via Search Console; un ancien sitemap encore tourné vers les anciennes adresses perturbe le crawl.
Le fichier robots.txt doit lui aussi être vérifié; une règle ajoutée en développement pour empêcher les moteurs de recherche de crawler le site, si elle survit à la mise en production, peut rendre le nouveau site totalement invisible dans les recherches. C'est une erreur fréquente mais facile à éviter lors des migrations.
La checklist du soir de la mise en ligne
Certains points méritent une vérification au moment même de la mise en ligne et juste après; la plupart prennent quelques minutes, mais les sauter peut coûter des semaines de classement perdu.
- Confirmer que robots.txt ne bloque plus le crawl
- Générer le nouveau sitemap et le soumettre à Search Console
- Tester les redirections de toutes les anciennes URLs, en incluant au moins les vingt pages à plus faible trafic
- Vérifier que les données structurées (schema) existent toujours sur les nouvelles pages
- Suivre le rapport de couverture dans Search Console les jours suivant la mise en ligne
Après le basculement: combien de semaines observer
Google peut mettre quelques semaines à traiter entièrement les nouvelles URLs; des fluctuations temporaires de classement pendant cette période sont normales. Le vrai signal d'alerte n'est pas la fluctuation, mais une page précise encore indexée sous son ancienne adresse des semaines plus tard; cela indique une rupture quelque part dans la chaîne de redirection.
Protéger les liens internes et les backlinks
Les liens internes, c'est-à-dire une page qui en lie une autre au sein du site, sont ce qui est le plus souvent oublié lors d'une migration; même avec les anciennes URLs redirigées, si le texte d'une page pointe encore vers d'anciens liens, un visiteur traverse une chaîne de redirection, et cela coûte de la vitesse à chaque clic.
Les backlinks, c'est-à-dire les liens d'autres sites vers le vôtre, ne peuvent pas être modifiés directement, mais si la redirection est correctement configurée, le signal que ces liens portent se transmet quand même à la nouvelle adresse; une configuration 301 complète compte donc autant pour les liens externes que pour les internes.
Protéger l'analytics et le suivi de conversion pendant la migration
Le code analytics et les balises de suivi de conversion, envoi de formulaire, suivi de recherche, sont un autre élément qui s'oublie lors du passage à un nouveau site; si ces balises manquent, les données de trafic et de conversion présentent un angle mort pendant un moment après la mise en ligne.
Si le code de suivi des envois de formulaire d'un service de signature électronique fonctionne sur l'ancien site mais n'est jamais reconstruit sur le nouveau, personne ne peut dire combien de personnes ont réellement rempli le formulaire après la mise en ligne; c'est pourquoi la liste des balises de suivi devrait être rassemblée avant le basculement, au même titre que la liste des URLs.
Le premier jour après la mise en ligne, chaque formulaire et bouton actif mérite d'être testé une fois manuellement; voir cette entrée de test apparaître dans le tableau analytics confirme que le code de suivi fonctionne bien.
Aussi bon que soit le design d'un nouveau site, des redirections manquantes et un mapping d'URL incomplet coûtent la visibilité déjà acquise dans les moteurs de recherche. rabbitclip traite la liste des anciennes URLs, le plan de redirection et le suivi post-lancement comme un poste à part sur chaque projet de migration; un plan de refonte existant peut se vérifier avec nous, en regard de cette checklist.
Questions fréquentes
Une redirection 301 nuit-elle au classement ?
Non, pas si elle est correctement configurée; le vrai risque est l'absence de redirection, ou l'usage d'une redirection temporaire comme la 302.
Chaque ancienne page a-t-elle besoin d'un équivalent exact sur le nouveau site ?
Non, une page sans équivalent exact peut rediriger vers la page la plus proche sur le même sujet.
Combien de temps faut-il pour que le classement se stabilise après une migration ?
Généralement quelques semaines; cela varie selon la taille du site et l'ampleur du changement.
Pourquoi la vérification du robots.txt compte-t-elle autant ?
Un blocage de crawl ajouté en développement, s'il passe en production, peut rendre le nouveau site totalement invisible dans les recherches.
Les liens internes doivent-ils être corrigés avant la migration ?
Idéalement oui; au minimum, tous les liens internes doivent être mis à jour vers les nouvelles adresses juste après la mise en ligne.
