Migration des URL d’un site multilingue : préparer le lot bilingue

9 min de lecture

La migration des URL d’un site multilingue se prépare par couples de contenus, pas par simple remplacement de préfixes. Pour chaque page déplacée, l’ancienne adresse doit conduire au bon thème dans la même langue. Canonical, hreflang, sélecteur de langue et sitemap doivent ensuite décrire les nouvelles destinations, y compris lorsqu’une page n’a pas de traduction.

Votre livrable central est une table bilingue : elle fixe les correspondances, les destinations du menu de langues et les preuves attendues avant la bascule. Les redirections seules ne constituent pas un plan complet.

Établir l’inventaire et les correspondances éditoriales

Réunissez l’export du CMS, un crawl du site, les sitemaps existants et les URL retrouvées dans les journaux serveur ou Search Console. Ne vous limitez pas aux menus : une ancienne adresse peut encore recevoir des visites ou être référencée ailleurs.

Pour chaque URL, relevez la langue, le thème, le statut HTTP, la canonical actuelle, les alternates, les liens internes entrants et l’existence d’un équivalent traduit. Notez les variantes de protocole, d’hôte, de slash final et les paramètres qui modifient le contenu.

Attribuez un identifiant commun aux traductions d’une même page. Vous évitez ainsi de rapprocher deux contenus sur la seule ressemblance de leurs chemins. Faites approuver les correspondances par un responsable éditorial et les exceptions par le responsable technique.

Le guide des redirections 301 aide à décider du devenir des pages. Le lot bilingue ajoute la vérification des langues et des relations entre traductions.

Une table de migration des URL pour un site multilingue

Exemple entièrement fictif : https://atelier.example déplace ses routes françaises vers /fr/ et remplace /en/ par /english/. Le contenu reste français ou anglais ; le nom du répertoire ne sert pas de code hreflang.

Les chemins ci-dessous sont abrégés pour la lecture. Dans le fichier d’exécution, anciennes URL, destinations, canonicals et alternates sont des URL absolues sur ce domaine. Le code en désigne ici l’anglais sans ciblage régional.

Chaque ancienne route reçoit une 301 directe vers la nouvelle page, attendue en 200. Pour chaque paire, les alternates sont identiques sur les deux versions. La page de conditions reste uniquement française : ne lui attribuez ni traduction supposée ni équivalent commercial anglais. Faites valider séparément toute adaptation contractuelle ; le balisage ne garantit aucune conformité juridique.

Ajoutez un propriétaire et une décision éditoriale à chaque ligne. Une destination non approuvée bloque le lot concerné, sans redirection automatique vers l’accueil.

Canonical et hreflang : aligner des signaux différents

Pour des versions linguistiques destinées à rester indexables, retenez ici une canonical auto-référente dans chaque langue. Google recommande, avec hreflang, une canonical dans la même langue lorsque cette page existe.^[24] Envoyer toutes les canonicals anglaises vers le français contredirait ce choix éditorial.

Sur /fr/entretien/, les annotations attendues sont :

<link rel="canonical" href="https://atelier.example/fr/entretien/" />
<link rel="alternate" hreflang="fr" href="https://atelier.example/fr/entretien/" />
<link rel="alternate" hreflang="en" href="https://atelier.example/english/maintenance/" />

La page anglaise possède sa propre canonical et reprend les mêmes alternates. Chaque version doit se désigner elle-même et citer ses autres versions avec des URL complètes. Les liens hreflang doivent être réciproques ; sans renvoi mutuel, Google ignore les annotations concernées.^[26]

Sur la page française sans équivalent, conservez la canonical vers sa nouvelle URL et n’annoncez pas d’alternate anglais. Contrôlez aussi le HTML initial : le CMS ne doit pas produire une canonical différente de celle ajoutée par un composant JavaScript.

Ces signaux ne forcent pas la décision de Google. Les redirections et les annotations canonical constituent des signaux forts, tandis que l’inclusion au sitemap est un signal plus faible.^[24] Votre travail consiste à éviter leurs contradictions, non à garantir l’URL retenue.

Le sélecteur de langue conserve le contexte

Le sélecteur de langue, ou picker, doit utiliser la correspondance éditoriale, pas une substitution mécanique de répertoire. Depuis l’entretien français, le bouton English conduit à la maintenance anglaise. En revenant au français, il ramène vers l’entretien, pas vers l’accueil.

Pour la page sans traduction, choisissez une interface explicite : masquer l’option anglaise ou afficher « Traduction indisponible ». Si vous proposez malgré tout une navigation vers une rubrique anglaise, nommez-la comme telle. Ce lien ne devient pas un alternate et ne doit pas être présenté comme une traduction.

Testez le contrôle au clavier, sur mobile et après rechargement direct d’une URL anglaise. Une préférence mémorisée ne doit pas renvoyer automatiquement le visiteur à l’accueil lors du clic. Ne transformez pas non plus x-default en traduction manquante : cette valeur sert de repli pour les langues non couvertes et a été conçue notamment pour les pages de sélection.^[26]

Déployer les 301, les liens et les sitemaps ensemble

Activez les changements à partir de la même version de table : routes applicatives, redirections, liens internes, canonical, alternates et sitemap. Google recommande des redirections permanentes côté serveur et conseille de viser directement la destination finale plutôt que d’enchaîner les sauts.^[32]

Dans cet exemple, /en/maintenance/ mène directement à /english/maintenance/, sans transiter par une variante française. Intégrez les règles de normalisation existantes pour éviter qu’un changement d’hôte ou de slash ne recrée une chaîne.

Remplacez les anciennes adresses dans les menus, fils d’Ariane, liens de contenu et picker. Publiez un sitemap courant contenant les nouvelles URL canoniques, puis soumettez-le dans Search Console. Gardez l’ancien inventaire comme référence de contrôle, sans l’utiliser pour générer les nouveaux liens.

Si les alternates figurent dans le sitemap, chaque entrée doit lister toutes les variantes, elle-même comprise.^[26] Si HTML et sitemap coexistent, comparez leurs annotations. Enfin, une suppression sans remplacement pertinent ne justifie pas une redirection vers l’accueil : Google avertit que ces redirections peuvent être assimilées à des soft 404.^[32]

La recette suit un ordre vérifiable

Voici un protocole de validation proposé, distinct des règles documentées de Google.

1. Vérifier les destinations. Chaque nouvelle page répond en 200, présente le bon contenu et n’est pas bloquée par une règle de préproduction. Contrôlez robots.txt, les directives noindex et les protections d’accès.
2. Tester les anciennes URL. Enregistrez le statut 301, l’en-tête Location et les sauts jusqu’à la page finale. Comparez langue et thème avec la ligne approuvée, pas seulement le code HTTP.
3. Lire les annotations. Comparez canonical et hreflang à la table, puis vérifiez les retours réciproques sur l’autre langue. Inspectez le HTML et le rendu si nécessaire.
4. Parcourir les liens. Cliquez sur le picker dans les deux sens, contrôlez les menus et parsez le sitemap. Cherchez les anciennes routes, les destinations inexistantes et les alternates redirigés.
5. Statuer sur le lot. Toute boucle, mauvaise langue, destination absente ou contradiction de canonical bloque la bascule des pages concernées.

Utilisez cette fiche de recette : « Lot entretien ; ancienne URL /en/maintenance/ ; cible /english/maintenance/ ; attendu 301 puis 200 ; canonical anglaise ; alternates fr/en réciproques ; picker vers /fr/entretien/ ; preuves exigées : trace HTTP, extrait HTML, capture du menu et version du sitemap ».

Ajoutez l’horodatage réel, l’identité du vérificateur et sa décision après contrôle. Les états attendus de cet exemple ne sont pas des résultats de tests exécutés.

Surveiller les deux langues et préparer un retour coordonné

Après ouverture, filtrez les journaux serveur par anciennes routes, nouvelles routes et langue. Recherchez erreurs, boucles, redirections inattendues et destinations françaises appelées depuis d’anciennes pages anglaises. Dans Search Console, comparez les groupes français et anglais pour repérer des anomalies que la vue globale masquerait.

Surveillez aussi la disponibilité et la charge serveur : Google indique que l’exploration peut augmenter temporairement pendant une migration.^[32] Un test réussi avant bascule ne remplace donc pas l’observation des requêtes réelles.

Conservez les redirections aussi longtemps que possible, généralement au moins un an selon Google.^[32] Leur retrait ne doit pas dépendre uniquement de la disparition des anciennes URL du menu. Vérifiez les requêtes persistantes et les liens externes connus.

Préparez enfin un retour arrière coordonné : configuration serveur, routes, annotations, picker et sitemap reviennent ensemble à une version cohérente. Ne rétablissez pas les anciennes pages tout en laissant des redirections vers les nouvelles. Désignez qui autorise ce retour et quelle défaillance le justifie.

Questions fréquentes

Peut-on basculer une langue avant l’autre ?

Oui, si les correspondances restent cohérentes pendant la transition. La page française migrée doit annoncer l’adresse anglaise encore active, et celle-ci doit renvoyer vers la nouvelle française. Le picker suit ce même état intermédiaire. Versionnez cette configuration temporaire, puis remplacez ses références lors de la seconde bascule ; ne publiez pas des alternates vers des pages encore indisponibles.

Que faire des paramètres utilisés par les campagnes ?

Distinguez les paramètres de suivi des paramètres qui changent le contenu. Pour les premiers, décidez avec l’équipe marketing si la destination doit conserver l’attribution, puis testez une ancienne adresse réellement utilisée. Pour les seconds, traitez chaque variante utile dans la correspondance. Une règle qui efface tous les paramètres peut supprimer une sélection ou conduire au mauvais contenu.

Comment traiter un PDF disponible dans une seule langue ?

Conservez une destination documentaire pertinente dans cette langue et contrôlez les liens de téléchargement des pages migrées. Ne créez pas une version anglaise fictive pour compléter la paire. Si le fichier exige une canonical, utilisez l’en-tête HTTP adapté aux documents non HTML.^[24] Vérifiez la réponse du fichier lui-même, car le contrôle du gabarit de page ne suffit pas.

Prochaine action : faire approuver un premier lot bilingue

Exportez les URL d’une rubrique et remplissez la table pour ses versions françaises, anglaises et ses exceptions. Faites approuver les destinations, puis exécutez la recette avant d’étendre le plan. Si vous souhaitez cadrer cette préparation avec un intervenant, les services web et SEO de 4SYSTEM permettent d’aborder le périmètre technique, éditorial et les contrôles nécessaires.

Sources

• How to Specify a Canonical with rel= »canonical » and Other Methods | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)
• Localized Versions of your Pages | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)
• Site Moves and Migrations | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)