La réponse en 60 secondes
Une refonte devient une migration SEO dès qu’elle modifie la manière dont Google découvre, identifie ou interprète les pages importantes du site.
Le nouveau design n’est généralement pas le principal risque. Le problème apparaît lorsque le lien entre l’ancien et le nouveau site est rompu : URL supprimée sans solution, mauvaise redirection, page bloquée, contenu essentiel perdu ou parcours de conversion défaillant.
Pour protéger cette continuité :
- recensez précisément ce qui va changer ;
- attribuez un résultat à chaque ancienne URL utile ;
- testez le référencement et les parcours commerciaux avant la mise en ligne ;
- analysez les incidents par type, plutôt qu’à travers un seul chiffre de trafic ;
- conservez un responsable jusqu’à ce que le nouveau site atteigne une base stable.
Google peut avoir besoin de temps pour traiter des changements corrects. Attendre n’est raisonnable qu’après avoir vérifié que l’implémentation fonctionne réellement.
1. Commencez par définir le périmètre de la migration
« Nous changeons le site » est trop vague pour évaluer le risque. Il faut identifier les éléments qui vont bouger.
Les adresses
Nom de domaine, sous-domaine, protocole, dossiers, URL de produits, versions linguistiques et paramètres.
Les contenus
Pages supprimées, services regroupés, catégories réécrites, titres modifiés et liens internes déplacés.
Le fonctionnement technique
Nouveau CMS, nouveau framework JavaScript, changement d’hébergement, affichage côté serveur ou navigateur, gestion des images et du consentement.
Les parcours commerciaux
Formulaires, prise de rendez-vous, espace client, paiement, catalogue, prix, stocks et mesure des conversions.
Les instructions données aux moteurs
Redirections, balises canoniques, règles robots.txt, sitemaps, données structurées et codes de réponse du serveur.
Cet ensemble forme le périmètre de migration : tout ce qui peut casser ou devoir être retraité. Une refonte visuellement légère peut malgré tout avoir un périmètre technique important.
2. Constituez le dossier de référence avant le plan de redirections
Le tableau de redirections est indispensable, mais il ne devrait pas être le premier document produit. Commencez par enregistrer ce que le site actuel apporte réellement.
Pour chaque URL prioritaire, rassemblez :
- son adresse actuelle et sa destination prévue ;
- son rôle dans le parcours client et le marché concerné ;
- ses clics et impressions dans Google ;
- les demandes, ventes ou autres actions commerciales qu’elle soutient ;
- ses principaux liens internes et externes ;
- son état d’indexation, sa balise canonique et son code serveur ;
- la décision prise : conserver, remplacer, regrouper ou retirer.
Ne conservez pas une page uniquement parce qu’elle existe. Ne la supprimez pas uniquement parce qu’elle reçoit peu de trafic. Une page discrète peut rassurer un prospect, répondre à une objection décisive ou recevoir un lien externe utile.
Ce dossier crée aussi une référence avant lancement. Sans elle, il devient difficile de distinguer un incident provoqué par la migration, un délai normal de retraitement et une faiblesse qui existait déjà.
3. Donnez un résultat explicite à chaque ancienne URL
Chaque URL identifiée doit aboutir à l’une de ces quatre décisions :
| Décision | Quand l’utiliser | Preuve attendue |
|---|---|---|
| Conserver | L’adresse et la fonction restent valables | La même URL affiche la bonne page |
| Rediriger | Une page de remplacement pertinente existe | Redirection permanente vers la destination la plus proche |
| Regrouper | Plusieurs pages répondent désormais au même besoin | La nouvelle page couvre les informations essentielles |
| Retirer | Aucun remplacement utile n’existe | Réponse 404 ou 410 volontaire et liens internes supprimés |
Évitez de rediriger toutes les anciennes pages vers l’accueil. Cette solution masque les trous du plan et envoie le visiteur vers une page qui ne répond pas à sa demande.
Dans son guide sur les changements d’URL, Google recommande notamment d’établir une correspondance entre anciennes et nouvelles adresses, d’utiliser des redirections permanentes côté serveur et d’éviter les chaînes inutiles (Google Search Central).
Le tableau doit ensuite être testé contre le site réel. Une ligne correcte dans un fichier ne prouve pas que le serveur exécute la bonne redirection.
4. Définissez les critères d’autorisation de mise en ligne
Le site ne devrait pas être lancé parce qu’il semble terminé. Il devrait être lancé lorsque les contrôles convenus sont validés.
Contrôles de visibilité
- Les nouvelles pages prioritaires répondent en HTTP 200.
- Les anciennes URL prioritaires renvoient la redirection permanente prévue.
- Les redirections ne créent ni boucle ni chaîne évitable.
- Les balises canoniques désignent des pages finales indexables.
- Les pages de production ne sont pas bloquées par
robots.txtounoindex. - Le sitemap contient les nouvelles URL canoniques.
- Les liens internes pointent directement vers les adresses finales.
- Les données structurées correspondent au contenu visible.
Contrôles commerciaux
- Les formulaires arrivent chez la bonne personne.
- La réservation, le paiement et l’espace client fonctionnent sur mobile.
- Les prix, stocks et flux produits sont cohérents.
- Le consentement et les événements analytics fonctionnent comme prévu.
- Les messages d’erreur permettent au client de poursuivre ou de recommencer.
Contrôles opérationnels
- La surveillance commence avant la bascule du domaine ou de l’hébergement.
- Une personne identifiée peut corriger ou revenir en arrière en cas d’incident critique.
- L’équipe sait quelles erreurs imposent une intervention immédiate.
Conservez la preuve des tests. « Le prestataire a vérifié » n’est pas un critère de recette exploitable.
5. Analysez les variations après lancement par type d’incident
Une courbe de trafic globale ne suffit pas pour diagnostiquer une migration. Séparez les signaux.
| Observation | Première piste à vérifier |
|---|---|
| De nombreuses erreurs d’exploration | Hébergement, routage, règles robots ou réponse serveur |
| Les anciennes URL restent visibles | Découverte des redirections, chaînes ou qualité des correspondances |
| Les nouvelles pages sont considérées comme des doublons | Balises canoniques, similitude et différenciation du contenu |
| Une section perd sa visibilité | Redirections, navigation, contenu ou modèle de page |
| Le trafic tient mais les demandes baissent | UX, formulaire, paiement ou mesure analytics |
| Un pays ou une langue disparaît | Localisation, routage, contenu régional ou hreflang |
Certains changements corrects demandent du temps. Google indique qu’après certaines corrections de contenu, des pages peuvent rester temporairement regroupées comme doublons pendant que le choix de l’URL canonique est réévalué (documentation Google sur la canonicalisation).
Cette information invite à diagnostiquer avant de réagir. Elle ne justifie pas d’attendre face à une erreur serveur, un blocage accidentel, un formulaire cassé ou une redirection incorrecte.
6. Fermez la migration sur des preuves, pas sur une date anniversaire
Une migration n’est pas stabilisée parce qu’un certain nombre de jours s’est écoulé. Elle l’est lorsque le nouveau système se comporte de manière cohérente.
Recherchez plusieurs signaux convergents :
- les redirections prioritaires sont régulièrement explorées et suivies ;
- les pages finales sont indexées comme prévu ;
- les anciennes adresses reculent sans laisser de pages utiles orphelines ;
- les erreurs reviennent dans la plage de fonctionnement convenue ;
- la visibilité forme progressivement une nouvelle base cohérente ;
- les parcours commerciaux et les données de suivi sont réconciliés ;
- chaque exception restante possède un responsable et une décision.
Analysez ces éléments par type de page, langue et marché. Une page d’accueil stable peut masquer la disparition d’une catégorie de produits. Un trafic total correct peut masquer une baisse de conversion.
Gardez le registre de migration ouvert jusqu’à ce que les preuves permettent de le clôturer. Le transfert au support est une décision opérationnelle, pas une simple étape du planning.
Conclusion : protégez la continuité, pas seulement les positions
Une migration déplace plus que des pages. Elle déplace des adresses, des preuves, des parcours commerciaux et les instructions qui permettent à Google de relier l’ancien site au nouveau.
Cartographiez le périmètre, testez l’implémentation et analysez chaque variation selon sa nature. L’objectif n’est pas de promettre « zéro mouvement », mais d’organiser une transition contrôlée dans laquelle les erreurs sont visibles, attribuées et récupérables.
Votre équipe peut-elle prouver que la migration est prête ?
Apportez-nous l’inventaire des URL, l’architecture prévue et les parcours clients critiques. Nous pouvons les transformer en registre de migration, contrôles exécutables et plan de suivi après lancement - sans prétendre que toute variation peut être éliminée.
Questions fréquentes
Non. Le risque dépend de ce qui change et de la manière dont la continuité est gérée. Les modifications d’URL, de contenu, de rendu ou d’instructions techniques nécessitent des contrôles explicites.
Non. Redirigez lorsqu’un remplacement pertinent existe. Lorsqu’il n’existe aucun équivalent utile, retirez la page volontairement et supprimez les liens internes qui y conduisent.
Immédiatement en cas d’erreur serveur, de blocage, de parcours cassé ou de mauvaise redirection. Pour un délai d’exploration ou une réévaluation canonique, vérifiez d’abord la configuration et les données avant de modifier à nouveau le site.
Google recommande de les maintenir au moins un an. Les visiteurs et les liens externes peuvent justifier de les conserver plus longtemps. Leur suppression doit être traitée comme une nouvelle décision de risque.
Le registre de migration vivant : il relie chaque URL importante, la décision prévue, le résultat des tests, l’observation après lancement et la personne responsable.
Documentation Google vérifiée le 15 juillet 2026. Les effets d’une migration varient selon le site, son architecture et l’ampleur des changements. Cet article fournit un cadre opérationnel, pas une garantie de performance.