Migrer son site sans perdre son référencement : la méthode

Pourquoi une refonte peut-elle perdre de la visibilité ?

Le risque ne vient pas seulement du changement de technologie. Une page disparaît, une adresse change, un contenu utile est raccourci, une règle empêche l’indexation ou un formulaire cesse de fonctionner. Une interface plus moderne peut alors masquer une régression commerciale. Le projet doit donc comparer des usages et des contenus, pas uniquement deux captures d’écran.

Séparez les changements nécessaires des changements décoratifs. Si une adresse claire fonctionne déjà, elle n’a pas besoin d’être remplacée pour accompagner une nouvelle direction artistique. Si un article répond correctement à une question, conservez cette réponse même si sa mise en page évolue. Cette discipline réduit le nombre de causes possibles lorsqu’un indicateur varie après le lancement.

Quel inventaire préparer avant de commencer ?

Rassemblez le sitemap, les adresses connues dans l’outil de mesure et les pages liées depuis la navigation. Ajoutez les pages de campagnes, les fichiers téléchargeables, les anciennes versions linguistiques et les formulaires. Comparez les sources : aucune liste isolée ne garantit de contenir tout ce qui est encore utilisé.

Pour chaque adresse, notez son rôle, son contenu principal, sa destination future et la personne qui valide la décision. Classez les pages à conserver, à fusionner et à retirer. Une suppression doit avoir une raison liée au contenu ou à l’activité, plutôt qu’à la seule volonté de simplifier le projet technique.

Comment préparer les redirections ?

Une redirection utile relie une ancienne adresse à la page qui répond au même besoin. Envoyer toutes les anciennes pages vers l’accueil crée une mauvaise expérience et fait perdre le contexte. Lorsqu’aucun remplacement pertinent n’existe, il vaut mieux traiter clairement la disparition que simuler une continuité.

Testez chaque règle sur l’environnement de recette. Vérifiez la destination finale, l’absence de boucle et les chaînes successives. Contrôlez aussi les variantes réellement utilisées : adresse avec ou sans barre finale, anciennes routes traduites et liens de documents. Le plan de redirection doit rester un fichier consultable et maintenable, pas une série de règles oubliées au fond d’une configuration.

Que faut-il conserver dans les pages ?

Reprenez les réponses utiles, les titres cohérents, les liens internes et les informations qui permettent de choisir une offre. Une nouvelle mise en page peut améliorer la lecture sans effacer les détails techniques ou les conditions d’un service. Comparez le contenu rendu, car une donnée présente dans la base mais absente de la page ne sert ni le visiteur ni le moteur.

Sur un site multilingue, vérifiez les trois versions d’un même parcours. Un lien de changement de langue ne doit pas conduire systématiquement à l’accueil. Les titres, les champs du formulaire, les messages d’erreur et les destinations des boutons doivent correspondre à la langue sélectionnée. Le travail multilingue et RTL fait partie de la recette de migration.

Comment organiser la recette avant lancement ?

1. Parcourez les pages principales sur ordinateur et téléphone.
2. Vérifiez les redirections à partir de la liste des anciennes adresses.
3. Contrôlez les contenus réellement visibles et les liens présents dans les articles.
4. Testez les formulaires avec des données de recette isolées.
5. Vérifiez les messages de succès et la réception dans l’administration.
6. Contrôlez les règles d’indexation de l’environnement final.
7. Préparez une sauvegarde et une procédure de retour arrière.

Attribuez un responsable à chaque contrôle. « Le site fonctionne » n’est pas un résultat de test : « une demande de recette apparaît dans le CRM avec sa langue et son origine » est une observation vérifiable. Conservez la date, l’environnement et les limites de la recette.

Quand faut-il décider de reporter ?

Un formulaire principal cassé, des redirections largement incorrectes, une absence de sauvegarde ou une règle qui bloque toutes les pages constituent des raisons de reporter. Une différence mineure de présentation peut être traitée dans une liste de corrections, à condition de ne pas empêcher l’usage. Écrivez ces critères avant le jour du lancement pour éviter de décider sous pression.

Le retour arrière doit préciser les données à conserver. Restaurer seulement les fichiers peut perdre les demandes arrivées entre-temps si la base est également remplacée. Le plan doit donc distinguer code, contenu, médias et données commerciales. Un exercice de restauration apporte davantage de confiance qu’une simple mention « sauvegardes incluses ».

Que surveiller après la migration ?

Surveillez les erreurs de navigation, les pages importantes, les formulaires et les demandes reçues. Comparez des périodes cohérentes et tenez compte des campagnes ou changements saisonniers. Une variation de trafic n’identifie pas à elle seule la cause du problème. Examinez les pages concernées et les changements effectivement déployés.

Conservez les accès aux anciens inventaires et documentez les corrections. La migration n’est pas terminée au moment où le nouveau site s’affiche : elle se termine lorsque les parcours essentiels sont vérifiés et que les écarts critiques sont résolus. Le suivi doit être prévu au devis.

Comment cadrer votre migration avec Azur Digital ?

Apportez l’adresse du site, vos principales offres, les outils reliés et les contraintes d’exploitation. Un diagnostic technique permet de distinguer les défauts actuels des risques de changement. Le service de refonte, les besoins de performance et le formulaire de projet servent ensuite à construire un périmètre vérifiable.

Source technique consultée le 20 septembre 2026 : recommandations Google pour les migrations avec changement d’URL. La grille de responsabilités et les critères de recette présentés ici constituent une méthode de conduite de projet ; ils ne garantissent pas un classement.