Réponse courte. Changer de domaine, CMS ou structure sans perdre la traçabilité ni les URL utiles.
Définir ce qui change réellement
Une migration SEO prépare le passage entre deux états d’un site en conservant des destinations compréhensibles pour les visiteurs et les moteurs. Elle peut accompagner un changement d’adresses, de domaine, d’architecture ou de plateforme. Le premier travail consiste à décrire exactement ce qui change et ce qui doit rester identique. Une refonte visuelle sans changement d’URL ne présente pas les mêmes risques qu’un regroupement de plusieurs sites.
Le projet doit partir de l’objectif de l’entreprise. Cherchez-vous à simplifier la publication, à réunir des offres, à corriger une architecture ou à changer d’identité ? Chaque objectif crée des contraintes différentes. Si les raisons du changement sont floues, le chantier risque d’accumuler des décisions indépendantes jusqu’à rendre le résultat difficile à tester. Un périmètre explicite permet de distinguer la migration nécessaire des améliorations qui peuvent attendre une étape séparée.
Google distingue la migration avec changement d’URL du changement d’hébergement sans changement d’adresse. Cette distinction aide à choisir les contrôles pertinents. Dans tous les cas, le nouveau site doit être vérifié avant la bascule. Une livraison technique réussie ne suffit pas à démontrer que les anciennes pages, les contenus et les parcours commerciaux ont été correctement repris.
Une migration bien préparée vise à réduire les risques, pas à garantir une absence de variation dans les recherches. Le prestataire doit expliquer les étapes, les tests et les limites du suivi. Vous devez savoir ce qui est prêt, ce qui reste à valider et qui peut autoriser la mise en ligne. Ce cadre est particulièrement important lorsque plusieurs équipes interviennent sur le domaine, le contenu et l’application.
Constituer l’inventaire de départ
Rassemblez les adresses connues depuis plusieurs sources : navigation, sitemap, exports du système, données propriétaires et documents utilisés par l’entreprise. Aucune liste ne doit être considérée automatiquement comme exhaustive. Une page ancienne peut recevoir des visites sans figurer dans les menus. Un document peut être partagé par les commerciaux depuis longtemps sans apparaître dans l’arborescence actuelle. Ces destinations doivent être prises en compte avant leur disparition.
L’inventaire doit décrire le rôle de chaque adresse, son état et sa future destination envisagée. Ajoutez la langue, le type de contenu et les dépendances importantes. Une fiche produit, un formulaire et une notice téléchargeable ne suivent pas le même traitement. Le but n’est pas de conserver toute adresse sans discussion, mais de rendre visible chaque décision qui modifiera l’accès à une information utile.
Les données de recherche permettent d’identifier certaines pages importantes, sous réserve des accès et des périodes disponibles. Les demandes commerciales, les liens entrants connus et les usages internes complètent cette lecture. Une page sans clic dans un rapport limité peut encore avoir une utilité contractuelle ou pratique. La décision de suppression ne doit donc pas reposer uniquement sur une colonne de trafic.
Conservez un état de référence avant modification. Il doit permettre de retrouver le texte, les métadonnées, les médias et le comportement des parcours critiques. Ce n’est pas seulement une sauvegarde technique. C’est aussi la matière nécessaire pour comparer l’ancien et le nouveau site. Sans référence identifiable, une information oubliée peut être difficile à prouver et à rétablir après la bascule.
Décider du devenir de chaque page
Une page peut être conservée à la même adresse, déplacée, fusionnée avec une autre ou retirée. Ces décisions doivent être prises en fonction de son contenu et du besoin qu’elle couvre. Déplacer toutes les pages pour uniformiser des noms ne présente pas le même intérêt que corriger une architecture devenue illisible. Conservez les adresses utiles lorsque le projet ne justifie pas leur changement.
Lorsqu’une fusion est retenue, la page de destination doit réellement reprendre les informations nécessaires. Une simple proximité de mots dans le titre ne suffit pas. Relisez les sections, les documents liés et les questions auxquelles répondait chaque ancienne page. Le lecteur qui suit un ancien lien doit retrouver une réponse pertinente, même si elle est désormais organisée dans une page plus complète.
Une suppression doit aussi être explicite. Certaines offres abandonnées n’ont pas d’équivalent actuel. Inventer une correspondance pour éviter toute erreur apparente peut conduire les visiteurs vers une prestation sans rapport. Le traitement doit refléter la situation et être validé par l’entreprise. Le chantier ne doit pas modifier silencieusement les engagements, les informations publiques nécessaires ou les contenus que les équipes utilisent encore.
Les changements éditoriaux importants demandent leur propre validation. Une migration n’autorise pas automatiquement une réécriture générale, un nouveau positionnement ou un remplacement des visuels. Le travail sur les contenus et leur organisation peut accompagner le projet, mais ses décisions doivent être distinguées des changements d’adresse. Cette séparation facilite la recette et l’analyse ultérieure des effets.
Préparer la table de correspondance
La table de correspondance relie chaque ancienne destination à son traitement prévu. Elle doit contenir une justification lorsque la relation n’est pas évidente. Pour une page conservée, confirmez que son contenu et son rôle restent cohérents. Pour une page déplacée, identifiez la nouvelle adresse exacte. Pour une fusion ou un retrait, notez la décision et la personne qui l’a validée.
Les règles automatiques peuvent aider lorsque la structure est régulière, mais elles doivent être testées sur des exceptions. Un remplacement de préfixe peut fonctionner pour les articles et échouer pour les téléchargements. Une règle trop large peut envoyer des pages différentes vers la même destination. Préparez des exemples représentatifs, y compris des adresses anciennes contenant des paramètres ou des caractères particuliers.
La correspondance doit être compréhensible par l’équipe technique et par les responsables du contenu. Évitez les indications approximatives comme rediriger vers la rubrique la plus proche. Elles déplacent une décision éditoriale vers le moment de l’implémentation. Une adresse finale confirmée, accompagnée d’un rôle explicite, permet de tester le résultat sans interprétation supplémentaire.
| Situation | Décision à documenter | Vérification attendue |
|---|---|---|
| Page conservée | Même adresse et même rôle | Contenu et accès préservés |
| Page déplacée | Nouvelle destination précise | Arrivée sur la bonne réponse |
| Contenus fusionnés | Informations reprises dans la destination | Absence de perte éditoriale utile |
| Offre retirée | Traitement validé sans faux équivalent | Réponse cohérente avec le retrait |
Cette table doit rester disponible après la mise en ligne. Elle permet d’examiner un ancien lien signalé par un client et de vérifier si le comportement observé correspond à la décision prise. Sans cette trace, les corrections peuvent devenir une suite de règles ajoutées au hasard, difficiles à maintenir lors de la prochaine évolution.
Tester les redirections
Une redirection doit conduire vers la destination attendue, avec un comportement adapté au caractère du déplacement. La documentation Google sur les redirections distingue notamment les déplacements permanents et temporaires. Le choix technique doit refléter la décision de migration. Un changement durable ne doit pas être traité comme une simple interruption passagère par défaut.
Le test doit relever la réponse initiale, les éventuelles étapes intermédiaires et l’adresse finale. Ouvrir seulement la nouvelle page ne vérifie pas le traitement de l’ancienne. Examinez aussi les variantes réellement utilisées du domaine et les chemins historiques connus. Une règle peut fonctionner sur une version d’adresse et échouer sur une autre, laissant certains anciens liens sans traitement.
Évitez les boucles et les enchaînements inutiles. Lorsqu’une destination a déjà été déplacée, la nouvelle migration doit examiner la chaîne existante. Le lecteur doit parvenir à la réponse finale sans passer par plusieurs étapes évitables. Google recommande également de ne pas rediriger indistinctement les anciennes pages vers l’accueil. Une destination doit correspondre à l’information recherchée.
Les redirections doivent être conservées et maintenues selon le plan établi, pas supprimées dès que la nouvelle page apparaît dans un rapport. Les anciens liens peuvent continuer à circuler dans des documents ou des favoris. La durée et les responsabilités de maintien doivent être prévues avec le propriétaire du domaine et l’équipe technique. Une migration n’est pas terminée si son fonctionnement dépend d’un ancien service que personne n’a prévu de conserver.
Contrôler le contenu et les médias
La comparaison entre ancien et nouveau site doit porter sur les informations utiles, pas uniquement sur le nombre de pages générées. Vérifiez les titres, les explications, les listes, les tableaux et les documents. Une conversion de format peut perdre des notes, casser des caractères ou supprimer une partie du texte sans faire échouer la génération. Les pages les plus structurées méritent un contrôle spécifique.
Les images doivent rester associées au bon contenu. Contrôlez les fichiers, les variantes, les descriptions et les liens de téléchargement. Une nouvelle organisation des dossiers peut casser des ressources référencées depuis des documents anciens. Notre page sur les images du site distingue les questions de contexte, d’accessibilité et de chargement. Une migration ne donne pas l’autorisation de remplacer une photo par une image externe non validée.
Les liens internes du nouveau site doivent pointer vers les destinations retenues. La présence d’une redirection ne dispense pas de mettre à jour les liens que vous maîtrisez. Vérifiez les menus, les liens dans le texte, les boutons et les ancres de section. Un titre déplacé peut conserver le même texte tout en changeant d’identifiant, ce qui rend un lien profond inutilisable.
Les contenus commerciaux sensibles restent à préserver. Les paiements, les conditions affichées, les coordonnées et les éléments validés par l’entreprise ne doivent pas être modifiés au passage. Si une erreur est découverte, elle doit être traitée dans un périmètre explicite. La recette doit permettre de distinguer une correction autorisée d’une perte accidentelle lors du transfert.
Vérifier les langues et les marchés
Un site suisse peut contenir plusieurs versions linguistiques et des offres dont le périmètre diffère. L’inventaire doit donc être organisé par langue et par marché réellement servi. Il faut vérifier que chaque page déplacée conserve sa correspondance avec les versions pertinentes. Une règle technique qui fonctionne pour le français ne doit pas être appliquée aux autres langues sans contrôler leurs exceptions.
Le sélecteur de langue doit retrouver la même réponse lorsque son équivalent existe. Les liens de variantes et les indications canoniques doivent utiliser les destinations actuelles. Les consignes Google sur les pages localisées servent de référence technique pour ces relations. La décision éditoriale reste indispensable : deux pages ne sont pas équivalentes uniquement parce qu’elles occupent une position similaire dans les menus.
Testez les formulaires, les confirmations et les documents dans chaque version concernée. Une reprise peut traduire les pages principales tout en conservant un ancien message automatique dans une autre langue. Les clients doivent pouvoir comprendre la suite de leur démarche. Le chantier de référencement multilingue permet de traiter ces parcours lorsque leur organisation demande plus qu’un simple changement d’adresse.
Ne profitez pas d’une migration pour ouvrir artificiellement de nouveaux territoires. Les textes doivent rester fidèles aux zones d’intervention, aux produits et aux capacités de suivi. Un domaine différent ou une nouvelle langue ne change pas les conditions d’une prestation suisse. Toute extension commerciale doit être décidée et validée séparément, avec les informations nécessaires au public concerné.
Préparer un environnement de recette
Le futur site doit pouvoir être examiné avant son exposition publique, avec un environnement clairement identifié. Les personnes chargées de la recette doivent savoir quelle version elles contrôlent et comment accéder aux pages représentatives. Le dispositif de protection choisi doit empêcher une exposition non souhaitée. Une simple consigne d’indexation n’est pas un moyen de sécuriser des informations confidentielles.
Vérifiez les paramètres qui différeront entre recette et production. Les adresses canoniques, les liens absolus, les retours de formulaire et les intégrations peuvent conserver des valeurs de test. La bascule doit inclure un contrôle de ces éléments. Une page visuellement correcte peut envoyer un message au mauvais destinataire ou désigner un domaine de préproduction dans ses métadonnées.
Les tests doivent inclure l’ouverture directe des pages, la navigation, l’actualisation et les adresses inexistantes. Certaines applications fonctionnent après un clic interne mais échouent lorsqu’un visiteur arrive depuis un ancien lien. La recette doit reproduire ces modes d’entrée. Les pages d’erreur doivent elles aussi être cohérentes et ne pas dissimuler une disparition de contenu derrière un écran générique présenté comme réussi.
Conservez les preuves proportionnées au risque : résultats de requêtes, liste des liens contrôlés, captures des parcours critiques et version testée. Une capture d’accueil ne couvre pas une boutique ou un site multilingue entier. La page de SEO technique détaille les contrôles de rendu et de réponse qui peuvent être nécessaires pour vérifier les modèles utilisés.
Protéger les parcours commerciaux
Identifiez les actions dont dépend l’activité : demande de contact, réservation, téléchargement, inscription ou commande. Chaque parcours doit être testé avant la bascule, puis sur la version publique autorisée. Le texte d’un bouton peut être préservé alors que sa destination ou son traitement a changé. La recette doit donc aller jusqu’au résultat attendu, sans effectuer de transaction réelle non autorisée.
Les balises de mesure existantes doivent être conservées, sauf décision explicite de changement. Relevez les identifiants et les événements utiles avant la migration, puis vérifiez leur présence et leur fonctionnement après intégration. Une rupture de suivi peut ressembler à une disparition du trafic alors que les visiteurs continuent à arriver. Il faut pouvoir distinguer une baisse d’activité d’une panne de collecte.
Prévoyez le traitement des demandes reçues pendant la transition. Si plusieurs systèmes coexistent temporairement, l’équipe doit savoir où regarder et comment éviter les doublons. Les coordonnées publiques doivent rester exactes. Les messages de confirmation ne doivent pas annoncer un canal abandonné. Ces détails opérationnels comptent pour la réussite du projet, même s’ils ne sont pas tous des facteurs de référencement.
Les liens distribués hors du site méritent une liste séparée : signatures, documents commerciaux, profils publics et supports déjà diffusés. Leur mise à jour peut être planifiée, sans supposer que toutes les références externes sont sous votre contrôle. Les redirections maintiennent l’accès lorsque c’est possible. La communication vers des partenaires ou des tiers nécessite toutefois une validation distincte du simple travail technique.
Fixer les conditions de bascule
La mise en ligne doit dépendre de critères explicites. Les pages prioritaires doivent être présentes, les correspondances testées, les parcours critiques fonctionnels et les défauts bloquants résolus. Une date prévue ne suffit pas à rendre un site prêt. La personne qui autorise la bascule doit disposer d’un état clair des vérifications réalisées et des limites restantes.
Répartissez les responsabilités : qui publie, qui contrôle le domaine, qui vérifie les formulaires et qui surveille les premières demandes ? Les accès doivent être confirmés avant l’intervention. Découvrir au dernier moment qu’un ancien domaine dépend d’un compte inaccessible peut compromettre le plan de redirection. Ce contrôle préalable évite de transformer une migration préparée en improvisation technique.
Le retour arrière doit être défini, mais il ne faut pas le présenter comme une opération sans conséquence. Si des commandes ou des données ont été enregistrées dans le nouveau système, revenir à l’ancien peut nécessiter une réconciliation. La décision doit tenir compte de l’état des données et du défaut rencontré. Une restauration aveugle peut créer un problème plus grave que celui qu’elle cherche à résoudre.
Exemple hypothétique : les pages sont correctement déplacées, mais le formulaire principal n’arrive plus à son destinataire. Le plan doit indiquer qui peut corriger ce défaut, dans quelles conditions la mise en ligne est suspendue et comment préserver les demandes déjà reçues. Cet exemple montre pourquoi les critères commerciaux et techniques doivent être examinés ensemble avant d’autoriser la transition.
Contrôler le site public après lancement
Après la bascule, vérifiez la version réellement servie par le domaine public. Les résultats locaux ne prouvent pas que la bonne version a été livrée. Testez les anciennes adresses importantes, leurs destinations et les parcours critiques. Confirmez les informations visibles, les métadonnées et les ressources. Les caches ou les réglages d’environnement peuvent créer un écart entre le site prévu et le site accessible aux visiteurs.
Les sitemaps et les outils propriétaires doivent être utilisés dans le cadre de la migration autorisée. L’outil Changement d’adresse de Search Console répond à des cas précis, notamment certains changements de domaine; ce n’est pas une action à appliquer à toute refonte. Vérifiez son applicabilité et les accès nécessaires avant de l’utiliser. Un changement d’hébergement à adresses constantes suit un autre parcours.
Les premiers contrôles doivent distinguer un incident immédiat d’une observation de recherche encore en cours. Une mauvaise destination ou un formulaire cassé demande une correction. Une différence temporaire entre anciennes et nouvelles adresses dans les rapports doit être interprétée avec la période et les données disponibles. Il ne faut pas modifier de nouveau toute l’architecture à partir d’une seule observation isolée.
Conservez une liste des anomalies et de leur résolution. Chaque correction doit préciser le défaut, le périmètre et la vérification après intervention. Cette discipline évite l’empilement de changements non testés pendant une période où plusieurs paramètres évoluent déjà. Le compte rendu doit identifier les pages et les parcours réellement contrôlés, sans annoncer une validation globale à partir d’un échantillon limité.
Interpréter les résultats de transition
Le suivi doit relier les anciennes et les nouvelles adresses à l’aide de la table préparée. Comparer deux listes d’URL sans correspondance peut faire apparaître une perte simplement parce que les destinations ont changé. Regroupez les pages selon leur rôle et leur évolution. Les contenus fusionnés demandent une lecture spécifique, car une seule nouvelle page peut reprendre plusieurs réponses anciennes.
Notez les changements simultanés qui peuvent influencer les observations : contenu réécrit, offre modifiée, disponibilité du catalogue ou campagne commerciale. Le trafic n’est pas un indicateur isolé de la qualité de migration. Une variation peut avoir plusieurs causes. Le rapport doit conserver les hypothèses et les preuves disponibles, puis proposer les vérifications qui permettraient de les départager.
Les demandes reçues permettent de vérifier si le nouveau parcours reste utile. Un prospect peut trouver la page mais ne plus comprendre comment contacter l’entreprise. À l’inverse, une diminution des demandes hors périmètre peut être cohérente avec un meilleur cadrage. Ces conclusions exigent des données et une méthode de comparaison; elles ne doivent pas être inventées pour justifier le projet après coup.
Notre page sur les preuves et le reporting SEO détaille cette séparation entre livrables, fonctionnement et résultats. La clôture technique peut être acquise alors que certaines observations d’indexation restent en attente. Le compte rendu doit le dire. Une migration réussie se documente par les contrôles effectués et la continuité constatée, sans promettre une position déterminée sur les moteurs.
Organiser votre migration avec nous
Pour cadrer votre projet, indiquez le site actuel, les changements envisagés, les équipes impliquées et les contraintes de calendrier. Ajoutez les langues, les formulaires et les contenus que vous devez absolument préserver. Si la refonte est déjà engagée, fournissez les décisions prises et les environnements disponibles. Un accompagnement peut commencer par la vérification du plan existant plutôt que par une reconstruction complète du projet.
La proposition doit préciser les livrables : inventaire, correspondances, revue du futur site, tests de bascule et suivi après lancement. Chaque responsabilité doit être attribuée. Une agence chargée du contenu ne contrôle pas forcément le domaine; un développeur ne valide pas seul les conditions commerciales. Le projet doit réunir ces compétences autour de critères communs, avec des étapes d’acceptation lisibles.
La publication reste une décision distincte du travail préparatoire. Les accès au domaine, les modifications d’hébergement et les communications aux partenaires ne sont pas des conséquences automatiques d’un audit. Ils doivent être autorisés dans le périmètre convenu. La préparation doit permettre d’arriver à cette décision avec des tests locaux concluants, un plan de contrôle public et une compréhension des risques restants.
Vous préparez une refonte ou un déplacement de site pour votre entreprise suisse ? Présentez les changements prévus. Nous examinerons les pages à préserver, les correspondances à établir et les points qui doivent bloquer une bascule prématurée. Le résultat attendu est une transition pilotable, des responsabilités claires et des vérifications documentées, avec un suivi séparé de la visibilité et des demandes commerciales.
SOURCES DE RÉFÉRENCE
Pour vérifier le cadre de votre projet
- Guide Google des migrations avec changement d’URLDocumentation de référence.
- Changement d’hébergement et SEODocumentation de référence.
Besoin d’appliquer cette méthode à votre site suisse ? Présenter votre situation.