Distinguer langue, région et marché commercial
Un site français et anglais est multilingue. Un site français pour la France et le Canada est multirégional même si une partie de la langue est commune. Les deux dimensions peuvent se combiner. Cette distinction décide les codes, les URL, les prix, les mentions, les disponibilités et les contenus. Ne créez pas une version par pays si l’offre, la langue et l’expérience restent rigoureusement identiques sans raison commerciale.
Listez les marchés réellement servis, les langues de vente, les moyens de paiement, la livraison, le support et les obligations locales. Une version doit pouvoir être maintenue après lancement. Si personne ne peut relire les nouveaux contenus ou répondre dans la langue promise, commencez par une page internationale honnête plutôt que de dupliquer tout le site.
Valider qu’un marché mérite une version
Rassemblez demandes commerciales, données de vente, requêtes Search Console, recherches locales, concurrents et capacité opérationnelle. Une traduction ne transforme pas une offre indisponible en opportunité. Définissez le segment, le problème, la proposition et l’action possible dans ce marché. Identifiez aussi les pages obligatoires : accueil, offre, livraison, contact, aide et informations légales.
Créez un gate de décision. La version passe si l’entreprise peut vendre, servir, maintenir et mesurer. Elle reste en attente si les prix, la logistique, le support ou la validation linguistique sont incertains. Cette étape évite un grand nombre de pages pauvres dont les métadonnées sont traduites mais dont le contenu principal ou le parcours reste français.
Choisir une architecture d’URL maintenable
Google accepte domaines nationaux, sous-domaines et sous-répertoires, chacun avec ses compromis. Un domaine national envoie un signal géographique clair mais sépare davantage la gestion et l’autorité. Un sous-domaine isole une version. Un sous-répertoire concentre les versions sur un domaine et simplifie souvent le démarrage. Le choix dépend de l’organisation, de la réglementation, des équipes et des systèmes, pas d’une règle universelle.
Utilisez des URL distinctes et stables pour chaque langue. Google déconseille de reposer uniquement sur cookies ou en-tête `Accept-Language`, car le robot peut ne pas découvrir toutes les variantes. Le sélecteur de langue doit produire de vrais liens. Évitez les paramètres opaques si une structure lisible peut être maintenue. Documentez la convention avant de publier la première traduction.
Localiser plutôt que traduire mécaniquement
La traduction conserve le sens ; la localisation adapte la requête, les exemples, unités, devises, preuves, appels à l’action et contraintes. Recherchez les mots employés dans chaque marché au lieu de traduire le mot-clé français. Une page allemande peut nécessiter d’autres objections et documents qu’une page française. Le plan des pages peut donc différer si les tâches diffèrent réellement.
Conservez toutefois l’équivalence lorsque vous déclarez des alternates. Une page produit doit pointer vers le même produit ou une variante fonctionnellement équivalente, pas vers une catégorie générique. Si aucun équivalent n’existe, ne fabriquez pas de relation hreflang. Le visiteur doit recevoir l’information promise dans la langue et le marché indiqués.
Construire la matrice d’équivalence avant hreflang
Créez une ligne par page source et une colonne par version. Notez URL, statut, canonical, langue, marché, titre, offre, disponibilité et date de validation. Les trous deviennent visibles : une page peut rester sans version plutôt que pointer vers une destination trompeuse. Cette matrice sert ensuite à générer et contrôler les annotations réciproques.
Exemple fictif : `/fr/maintenance` a des versions anglaise et belge, mais le service n’est pas vendu aux États-Unis. Le raisonnement distingue langue anglaise générique et marché américain. Résultat : créer `/en/maintenance` seulement si l’équipe sert réellement les anglophones, et ne pas déclarer `en-US`. Limite : la matrice décrit la disponibilité ; une recherche locale reste nécessaire pour décider le contenu.
Implémenter hreflang sans contredire canonical
Chaque version doit se déclarer elle-même et déclarer ses équivalents ; les relations doivent être réciproques. Utilisez des codes de langue conformes et, si nécessaire, une région valide. `x-default` peut désigner la page de repli lorsque aucune version ne correspond. Google accepte des annotations dans le HTML, les en-têtes HTTP ou le sitemap ; choisir une méthode suffit et réduit les incohérences.
Chaque page localisée doit généralement avoir une canonical vers elle-même si elle est la version de référence dans sa locale. Canonicaliser toutes les langues vers le français puis déclarer hreflang envoie des signaux contradictoires. Vérifiez aussi que les destinations renvoient 200, ne redirigent pas et restent indexables. Une balise correcte vers une page cassée ne produit pas un cluster valide.
Éviter les redirections automatiques qui enferment
Google recommande de ne pas rediriger automatiquement l’utilisateur vers une langue supposée. L’IP et les préférences du navigateur peuvent être inexactes, et le robot explore souvent depuis un contexte qui ne représente pas vos visiteurs. Proposez plutôt une suggestion non bloquante et un sélecteur accessible. Le choix doit être mémorisable sans rendre les autres URL inaccessibles.
Testez depuis plusieurs appareils et sans cookies. Un lien partagé vers la version anglaise doit rester anglais. Les moteurs et utilisateurs doivent pouvoir ouvrir chaque URL directement. Vérifiez également navigation, formulaires, messages d’erreur, emails et documents téléchargés : une page traduite qui bascule soudain vers un parcours français donne une promesse incomplète.
Mesurer par marché et maintenir les groupes
Séparez pages, requêtes et conversions par répertoire ou propriété lorsque l’architecture le permet. Comparez visibilité et demandes sans attribuer toute variation à hreflang. Contrôlez régulièrement réciprocité, statuts, canonical, sitemap, liens et dates de traduction. Lorsqu’une page source évolue, ouvrez une tâche de révision pour chaque version concernée.
Plan de recette : crawler les URL, valider les codes, comparer les groupes, ouvrir un échantillon dans Search Console et tester le parcours. Si un marché est abandonné, décidez page par page : maintenir, rediriger vers un équivalent ou retirer avec le bon statut. Une maintenance documentée vaut davantage qu’un grand nombre de versions laissées obsolètes.
Mise en pratique, sans collecte
Où en êtes-vous sur « Comment construire un site multilingue sans créer de conflits SEO ? » ?
Évaluez cinq critères concrets. Vos réponses restent dans votre navigateur.Votre premier chantier utile : Le marché peut être réellement servi
Outil pratique à copier
Matrice de versions localisées
Une ligne représente une tâche équivalente. Laissez la cellule vide lorsqu’aucune version réelle n’existe.
Checklist
À vérifier avant de passer à l’action.
- Le marché peut être réellement servi
- Chaque langue possède des URL distinctes
- Les équivalents sont documentés
- Hreflang est réciproque
- Canonical reste cohérente
- Aucune redirection forcée ne bloque les versions
- La maintenance est attribuée
Pour aller plus loin
Les réponses aux questions les plus fréquentes.
Des repères concrets pour passer de la lecture à une décision adaptée à votre situation.
Un site dans une seule langue a-t-il besoin de hreflang ?
Non. Hreflang sert à relier des versions linguistiques ou régionales alternatives. L’attribut HTML lang reste utile pour l’accessibilité, mais joue un autre rôle.
Faut-il traduire toutes les pages ?
Non. Publiez les pages utiles au marché et que vous pouvez maintenir. Ne pointez pas une page sans équivalent vers l’accueil avec hreflang.
Sous-domaine ou sous-répertoire ?
Les deux peuvent fonctionner. Comparez organisation, autorité, réglementation, équipes et maintenance. Le sous-répertoire simplifie souvent un démarrage sur un domaine unique.
Hreflang évite-t-il toute duplication ?
Il aide Google à comprendre les variantes. Il ne corrige pas une canonical incohérente, un contenu non traduit ou des pages sans valeur propre.
Sources consultées
Pour vérifier et approfondir.
Besoin de l’appliquer à votre site ?