Comment bien mettre en place les bases du SEO d’un site multilingue dès le départ

Après avoir mis en ligne une même page produit en anglais, allemand et japonais, il arrive que seuls les résultats dans la langue par défaut apparaissent dans les moteurs de recherche, que les utilisateurs allemands accèdent à la page anglaise, ou que les pages dans différentes langues se concurrencent pour le classement. Ces problèmes ne sont généralement pas dus à la qualité de la traduction, mais au fait que les relations d’indexation entre les versions linguistiques n’ont pas été clairement établies dès le départ.

Comment mettre en place correctement les bases SEO d’un site multilingue dès la première fois ? L’essentiel consiste à définir d’abord une architecture linguistique évolutive, puis à faire en sorte que chaque page indexable dispose simultanément d’une URL indépendante, d’un contenu dans la bonne langue, de déclarations hreflang réciproques, de liens explorables et de règles de canonicalisation cohérentes. La traduction n’est qu’une partie de la couche de contenu ; dès qu’un conflit survient au niveau de l’URL, de la balise canonical, de la redirection linguistique ou du sitemap, les moteurs de recherche peuvent ignorer les signaux de langue.

Distinguer d’abord les « versions linguistiques » des « versions régionales »

Avant la mise en place, répondez d’abord à une question : les pages sont-elles destinées à servir les utilisateurs selon leur langue, ou séparément selon leur langue et leur marché ? L’anglais destiné aux visiteurs du monde entier peut utiliseren ; ce n’est que si les pages américaines et britanniques diffèrent réellement en matière de devise, de mode de livraison, d’études de cas, de coordonnées ou de contenu rédactionnel qu’il convient de les séparer enen-useten-gb. Le simple fait de modifier l’orthographe entre color et colour ne justifie généralement pas deux ensembles de pages indépendants.

Une segmentation excessive entraîne une forte duplication de contenu, augmente les coûts de maintenance et complique le maintien de relations hreflang exactes dans la durée. À l’inverse, lorsqu’il existe réellement des pages pour les marchés russophones, du Moyen-Orient ou d’Amérique latine, mais qu’une seule page en anglais les couvre, la correspondance avec l’intention de recherche locale s’en trouve affaiblie. Le critère de décision n’est pas le nombre de zones de vente, mais l’existence de différences stables, visibles et significatives pour les utilisateurs entre les pages.

Une fois l’architecture des URL définie, ne laissez plus le système « deviner la langue »

Les sous-répertoires, sous-domaines et domaines nationaux peuvent tous être traités par les moteurs de recherche ; l’essentiel réside dans leur maintenabilité à long terme. Pour la plupart des sites devant gérer de manière centralisée les contenus, modèles et composants techniques, les sous-répertoires facilitent la création d’un mappage clair, par exemple/en/products/et/de/produkte/. Quelle que soit la forme choisie, une même page ne doit avoir qu’une seule adresse stable dans une même langue.

Les pratiques suivantes présentent facilement des risques : générer?lang=devia des paramètres sans contrôler les pages dupliquées ; rester sur la page d’accueil après le changement de langue ; placer toutes les langues sur une même URL et remplacer le texte par un script de navigateur ; modifier les chemins linguistiques à chaque refonte. La réponse initiale du serveur doit contenir le contenu principal, les titres et les liens internes dans la langue correspondante ; le contenu ne doit pas dépendre entièrement de l’exécution d’un script par le navigateur de l’utilisateur pour apparaître.

Le sélecteur de langue doit également utiliser des liens ordinaires explorables, plutôt que de dépendre uniquement d’événements de menu déroulant ou de cookies. Lorsqu’un utilisateur passe de la fiche détaillée d’un produit en allemand à l’anglais, le résultat idéal est qu’il accède à la fiche produit anglaise correspondante ; en l’absence de version correspondante, il peut revenir à la page de catégorie supérieure dans cette langue, mais il ne faut pas le rediriger silencieusement vers la page d’accueil.

hreflang doit indiquer des « pages alternatives », et non être une balise décorative

hreflangsert à indiquer aux moteurs de recherche quelles URL sont des versions alternatives du même contenu destinées à des utilisateurs de langues ou régions différentes. Il peut être placé dans le

de la page, dans l’en-tête de réponse HTTP ou dans le sitemap XML ; il suffit de choisir l’une de ces trois méthodes comme méthode principale de maintenance. La gestion au niveau de la page est la plus intuitive, mais elle est aussi la plus susceptible de générer des incohérences dues à des omissions dans les modèles.

Un ensemble de relations correct doit au minimum remplir trois conditions : chaque page se déclare elle-même ; lorsque la page A déclare la page B, la page B doit également déclarer la page A en retour ; l’URL cible déclarée doit être accessible, indexable et renvoyer un code d’état 200. Si la page anglaise pointe vers la page allemande, mais que la page allemande ne renvoie pas vers la page anglaise, les moteurs de recherche risquent de ne pas prendre en compte cet ensemble de signaux.

<link rel="alternate" hreflang="en" href="https://example.com/en/product-a/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt-a/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

x-defaultconvient aux pages de sélection de langue, aux pages d’entrée mondiales ou aux pages de destination par défaut lorsqu’aucune langue ne correspond clairement, mais il ne peut pas remplacer une véritable version linguistique. Le code, l’URL et le contenu linguistique doivent être cohérents : si le contenu principal d’une page est en japonais mais qu’elle est marquée commeko, ou si le chinois simplifié est marqué commezh-tw, les signaux seront faussés.

En cas de conflit entre canonical et hreflang, à lequel se fier en premier ?

C’est souvent la cause première des anomalies d’indexation multilingue. La balise canonical sert à désigner « quelle est la version principale parmi plusieurs pages dupliquées ou similaires » ; hreflang sert à indiquer « qu’il s’agit de versions alternatives dans différentes langues ou régions ». Par conséquent, une page allemande doit généralement avoir une canonical vers elle-même, et non vers la page anglaise ; une page japonaise doit également pointer vers elle-même. Si toutes les versions sont canonicalisées vers l’anglais, le système indique en réalité que les pages dans les autres langues ne doivent pas participer indépendamment à l’indexation, et hreflang aura naturellement du mal à jouer son rôle.

Ce n’est que lorsqu’il existe réellement des URL dupliquées dans une même langue, par exemple avec des paramètres de suivi, des pages d’impression ou des pages filtrées, que la canonical doit être concentrée vers l’URL standard dans cette langue. N’utilisez pas la canonical pour gérer les relations entre les versions traduites.

La localisation du contenu doit prioriser les éléments qui influencent la recherche et la conversion

La publication directe après traduction automatique présente souvent des problèmes qui ne se limitent pas à une formulation maladroite : le title, la description, le fil d’Ariane, les textes alternatifs des images, les indications de formulaire et les données structurées peuvent encore rester dans la langue source. Les moteurs de recherche déterminent la langue en combinant le contenu textuel visible de la page et les signaux associés ; les utilisateurs, quant à eux, perçoivent si la page est réellement adaptée à travers les unités de spécification, les formats de date et d’heure, les formats de téléphone, les devises et les champs de demande de renseignements.

Il est recommandé de garantir d’abord l’exhaustivité des pages essentielles : page d’accueil, principales pages de catégories, pages produit prioritaires, pages de services, pages de demande de renseignements et informations de confiance nécessaires. Avant la mise en ligne d’une version linguistique, vérifiez au minimum qu’elle possède un titre et une description indépendants, que le contenu principal correspond à l’usage linguistique du marché cible, que les liens internes mènent vers les chemins de la même langue et que la recherche interne, les filtres ou les documents à télécharger ne reviennent pas accidentellement à la langue par défaut.

Après la mise en ligne, effectuez un échantillonnage pour identifier les problèmes bloquants

1. Choisissez une page essentielle et accédez une à une aux URL de chaque langue afin de confirmer que le code d’état est 200 et qu’aucune redirection automatique vers une autre langue ne se produit.
2. Consultez le code source de la page afin de confirmer que la canonical pointe vers elle-même et que hreflang inclut la page elle-même ainsi que toutes les versions correspondantes.
3. Depuis chaque page linguistique, cliquez sur la navigation, le fil d’Ariane et le sélecteur de langue, et vérifiez que les liens mènent de manière stable vers la bonne version.
4. Vérifiez que le sitemap XML ne soumet que des URL standard indexables et n’inclut pas de pages redirigées, de pages de test ou de pages marquées noindex.
5. Observez les indications relatives à l’exploration, à l’indexation et aux pages alternatives dans les outils pour webmasters des moteurs de recherche ; après une publication groupée de nouvelles langues, contrôlez en priorité que les déclarations générées par les modèles sont complètes.

Une fois l’architecture technique définie, l’ajout ultérieur de nouvelles langues ne doit pas dépendre de l’ajout manuel de balises page par page. Une approche plus fiable consiste à enregistrer dans le modèle de contenu le « groupe de versions linguistiques » et les correspondances entre les pages, afin que le système de création de sites génère les URL, canonical, liens de changement de langue et hreflang selon des règles. Ainsi, lors de la création de nouvelles pages produit, de la suppression d’anciennes pages ou de l’ajustement des chemins, les relations entre les langues peuvent être mises à jour simultanément, ce qui évite l’apparition d’un grand nombre de pages isolées et de déclarations invalides à mesure que le site prend de l’ampleur.