Données structurées multilingues : localiser le JSON-LD pour chaque URL de langue et de région

Apprenez à localiser le JSON-LD schema.org sur chaque URL explorable de langue et de région, à mettre inLanguage et les entités en cohérence avec hreflang, et à contrôler la qualité des données structurées multilingues sans inventer de gains de classement.

Grant DaviesMis à jour

Données structurées multilingues : un graphe de nœuds JSON-LD avec des étiquettes inLanguage sur les entités, sur une grille blanche

Il est facile de mal gérer les données structurées multilingues lorsque les équipes considèrent le JSON-LD comme un extrait de code en anglais, commun à tout le site, à coller sur chaque URL localisée. Les moteurs de recherche et les moteurs de réponse interprètent les données structurées comme une description de la page à une URL précise. Si votre page produit en français déclare encore inLanguage: en, des valeurs name en anglais et un graphe d’entités canonique copié du site américain, vous envoyez des signaux contradictoires qui nuisent à la fois à l’indexation classique et à la clarté pour les moteurs de réponse.

Ce guide explique comment localiser le balisage schema.org pour chaque URL localisée explorable, aligner le JSON-LD sur hreflang et les URL canoniques, assurer la cohérence des entités d’organisation et de produit, et contrôler la qualité d’un déploiement de données structurées multilingues. Il s’appuie sur la documentation multilingue de Google et sur un balisage fidèle au contenu. Aucune promesse inventée de gain de positionnement : les données structurées aident les systèmes à comprendre le contenu ; elles ne compensent pas des traductions pauvres.

Les questions auxquelles ce guide répond

  • Pourquoi faut-il localiser les données structurées pour chaque URL linguistique ?
  • Comment représenter inLanguage et les pages dans d’autres langues ?
  • Quels types schema.org sont les plus importants pour les sites multilingues ?
  • Comment hreflang et les URL canoniques interagissent-ils avec les données structurées ?
  • Quelles erreurs produisent un balisage mêlant plusieurs langues ou des entités en double ?
  • Comment assurer la cohérence des entités d’organisation et de produit entre les versions localisées ?
  • Comment les données structurées aident-elles les moteurs de réponse sans inventer de facteurs de classement ?
  • Quels contrôles qualité prévoir pour le déploiement de données structurées multilingues ?

Réponse rapide : localisez le balisage sur chaque URL localisée explorable

En bref : Générez sur chaque URL localisée explorable du JSON-LD qui décrit fidèlement la page visible dans cette langue : une valeur inLanguage correcte, des propriétés textuelles localisées, une valeur url exacte et des identifiants d’entités cohérents d’un marché à l’autre.

Google recommande des URL explorables distinctes pour chaque version linguistique ou régionale, plutôt que de s’appuyer uniquement sur les cookies ou la langue du navigateur. Les données structurées doivent décrire la page que les utilisateurs et les robots d’exploration voient à cette URL, et non un modèle unique en anglais injecté sur l’ensemble du site.

Chaque bloc doit être rédigé dans la même langue que le contenu visible principal. Google détermine la langue d’une page principalement à partir du contenu visible ; un balisage qui contredit le corps de la page impose aux robots d’exploration un travail de mise en cohérence inutile.

Pourquoi les données structurées suivent l’architecture des versions linguistiques

Les données structurées ne constituent pas une couche de SEO international indépendante de l’architecture des URL : elles en sont le reflet. Lorsque vous publiez /de/produkt/widget, le JSON-LD de cette URL doit décrire la page en allemand : titres et descriptions en allemand, offres le cas échéant, et inLanguage défini sur une balise BCP 47 valide telle que de ou de-DE.

Les versions linguistiques nécessitent des URL explorables distinctes ; les données structurées doivent décrire la page que les utilisateurs et les robots d’exploration voient à cette URL, et non un modèle unique partagé en anglais. Si votre CMS utilise un seul composant de balisage global, les noms d’entités restent en anglais dans toutes les versions localisées. C’est une source fréquente de problèmes d’éligibilité aux résultats enrichis dus au mélange des langues et de résumés peu pertinents dans les moteurs de réponse.

Hreflang indique aux moteurs de recherche les autres versions disponibles ; les données structurées leur indiquent le sujet de la page actuelle. Les deux doivent confirmer que chaque URL correspond à une version linguistique complète, et non à un doublon qui se fait passer pour une autre langue.

Pour mieux comprendre les enjeux stratégiques du ciblage par langue ou par pays, consultez notre article sur le SEO international et le SEO multilingue.

Propriétés essentielles : inLanguage, url et identité des entités

Trois propriétés méritent une vérification prioritaire dans chaque modèle localisé :

inLanguage — Utilisez un code de langue ou de paramètres régionaux valide correspondant à la page. Ne laissez pas l’anglais sur les URL localisées. Lorsque vous ciblez des variantes régionales (en-GB ou en-US), alignez-les sur vos codes hreflang.

url — Doit pointer vers l’URL canonique de la page décrite : généralement, la même URL que celle affichée dans la barre d’adresse pour cette version localisée, et non la page d’accueil en anglais.

@id de l’entité ou identifiants stables — Les entités d’organisation et de produit nécessitent souvent des identifiants cohérents entre les versions localisées (https://example.com/#organization), tout en localisant les propriétés lisibles par les utilisateurs. Des identifiants cohérents aident les systèmes à reconnaître une même marque ou une même référence SKU dans plusieurs langues ; les champs name et description localisés portent le texte propre à chaque marché.

Évitez de multiplier les définitions contradictoires d’une même entité sur une URL. Un seul graphe Organization cohérent par page est plus propre que trois blocs concurrents injectés par différentes extensions.

Types schema.org qui nécessitent souvent une localisation

Tous les types schema.org ne nécessitent pas de traduction, mais c’est souvent le cas des suivants sur les sites multilingues :

  • WebPage / Article / BlogPosting — headline, description, inLanguage et url.
  • Product — name, description, offers avec la devise et le texte de disponibilité appropriés.
  • FAQPage — Les questions et réponses doivent correspondre au contenu visible de la FAQ, dans la langue de la page.
  • Organization — name localisé lorsque les dénominations sociales ou commerciales diffèrent selon les marchés ; @id cohérent.
  • BreadcrumbList — Libellés du fil d’Ariane localisés et conformes à la navigation.
  • LocalBusiness — Adresse et areaServed adaptés aux paramètres régionaux, le cas échéant.

Un contenu utile, conçu pour les utilisateurs, reste la base ; les données structurées doivent refléter fidèlement le contenu localisé plutôt que compenser des traductions pauvres. Ajouter du balisage à une page vide ou embryonnaire ne la rend pas utile.

Alignement de hreflang, des URL canoniques et du JSON-LD

Les annotations hreflang indiquent à Google les URL des autres versions linguistiques ou régionales et doivent être réciproques entre toutes les pages qu’elles décrivent. Les balises canoniques indiquent à Google quelle URL privilégier parmi les doublons dans une même langue. Le JSON-LD ne doit contredire aucun de ces deux signaux.

Règles pratiques d’alignement :

  1. URL canoniques dans la même langue — Chaque URL linguistique ou régionale doit avoir une URL canonique clairement définie, qui désigne l’URL à privilégier dans la même langue en cas de doublons. Ne faites pas pointer les balises canoniques de toutes les versions localisées vers l’anglais si vous publiez des pages entièrement localisées.
  2. Hreflang dans le HTML ou le sitemap — Les sitemaps XML facilitent la découverte des versions linguistiques et peuvent contenir des annotations xhtml:link hreflang si vous choisissez cette méthode d’implémentation.
  3. url du JSON-LD conforme à l’URL canonique — Lorsque vous définissez /fr/produit comme sa propre URL canonique, la propriété url du balisage doit faire référence à cette URL, et non à /en/product.
  4. Pas de hreflang dans le JSON-LD en guise de remplacement — Les recommandations de Google concernant hreflang portent sur les éléments link, les en-têtes HTTP ou les sitemaps, et non sur le balisage schema.org comme méthode principale de déclaration des autres versions.

Lorsque des extensions génèrent automatiquement ces trois couches de manière indépendante, vérifiez leur cohérence après le lancement de chaque version localisée.

Assurer la cohérence des entités d’organisation et de produit

Le SEO multilingue se dégrade lorsque chaque version linguistique invente un nouveau nom d’organisation ou identifiant de produit. Voici une stratégie concrète pour gérer les entités :

  • Un seul @id stable par organisation dans toutes les versions linguistiques ; localisez les propriétés d’affichage.
  • Les références SKU ou les identifiants globaux des produits restent inchangés ; localisez les intitulés marketing.
  • La même URL logo, sauf si certains marchés nécessitent des ressources différentes ; documentez alors la raison.
  • Des profils sociaux sameAs cohérents, sauf si un marché dispose de comptes vérifiés distincts.

Les recommandations de Google sur les contenus utiles privilégient les pages conçues d’abord pour les internautes. Les versions linguistiques pauvres en contenu ou composées uniquement de textes standardisés sont peu performantes en SEO et constituent de piètres sources de réponses. La cohérence des entités aide les systèmes à rattacher les pages localisées à une marque connue, mais elle ne peut pas compenser un contenu de mauvaise qualité.

Les équipes qui gèrent de nombreuses versions linguistiques ont intérêt à utiliser une plateforme de SEO multilingue qui assure la cohérence des termes du glossaire entre le contenu visible et les champs de données structurées.

Les implications pour les moteurs de réponse, sans inventer de facteurs de classement

Les moteurs de réponse et les AI Overviews peuvent utiliser les données structurées comme un signal parmi d’autres pour résumer ou citer des pages. Toutefois, aucune documentation publique ne promet que le JSON-LD suffit à obtenir des citations, un classement ou une présence dans les AI Overviews.

Ce que les données structurées peuvent réellement faire :

  • Préciser le type de page (Article, FAQPage, Product).
  • Fournir inLanguage pour l’URL décrite.
  • Favoriser une reconnaissance cohérente des entités lorsque les identifiants concordent entre les versions linguistiques.

Ce qu’elles ne peuvent pas faire :

  • Compenser un contenu non traduit ou pauvre.
  • Remplacer des URL localisées explorables ou les annotations hreflang.
  • Garantir des résultats enrichis sur tous les marchés.

Considérez le balisage de données structurées comme des métadonnées exactes décrivant des pages conçues pour les internautes, et non comme une astuce pour améliorer le classement.

Erreurs courantes dans le balisage multilingue

  1. Du JSON-LD en anglais sur des URL non anglophones — inLanguage et les propriétés textuelles restent dans la langue source.
  2. Un fragment de balisage global — Un même bloc du CMS est copié dans toutes les versions linguistiques sans mécanisme de localisation.
  3. Une URL canonique et un url contradictoires — Le balisage pointe vers la version anglaise, tandis que l’URL canonique de la page renvoie vers la version française.
  4. Un balisage FAQ dans la mauvaise langue — La langue du balisage ne correspond pas à celle de la FAQ visible.
  5. Des graphes d’entités en double — Plusieurs extensions injectent des blocs Organization concurrents.
  6. Des propriétés de produit inventées — Le balisage décrit des offres ou des avis absents de la page.
  7. Le hreflang négligé pendant que le balisage est « corrigé » — Les annotations et le JSON-LD doivent fonctionner ensemble.
  8. Des pages sommaires dotées d’un balisage complet — Des traductions de textes standardisés accompagnées d’un balisage élaboré.

Les recommandations de Bing aux webmasters soulignent l’importance d’un contenu utile et explorable ainsi que d’une structure de site claire pour l’indexation sur les différents marchés. Ces mêmes exigences d’explorabilité doivent être remplies avant que les données structurées puissent apporter de la valeur.

Liste de contrôle de mise en œuvre

Utilisez cette liste de contrôle avant chaque déploiement d’un nouveau lot de balisages localisés :

Les fondamentaux de la recherche traditionnelle et des moteurs de réponse

Les mêmes fondamentaux restent essentiels pour Google, Bing et les moteurs de réponse : des versions linguistiques explorables, des entités clairement identifiées, des affirmations étayées, des données structurées fidèles au contenu et une véritable localisation — pas de simples façades laissant le contenu en anglais. Considérez les guides ci-dessous comme des éclairages propres à chaque plateforme sur un même niveau d’exigence en matière de publication multilingue.

Pour Google Search, la découverte repose sur des URL localisées explorables, avec un HTML dans la langue appropriée, des titres et intertitres précis, ainsi que des annotations hreflang réciproques lorsque des versions alternatives existent. Les fondements techniques comprennent du contenu indexable plutôt qu’un changement de langue reposant uniquement sur des cookies, des métadonnées localisées, des sitemaps et une gestion rigoureuse des URL canoniques pour chaque version linguistique. La qualité du contenu suppose un contenu principal conçu avant tout pour les internautes dans chaque langue ; l’autorité repose sur une identité claire de l’organisation et des sources concordantes, et non sur les promesses marketing des outils de traduction. Conséquence pour le multilingue : chaque URL ciblant un marché ou une langue doit constituer à elle seule une page complète que Google peut positionner sur des requêtes locales. Mesurez les résultats à l’aide des rapports de couverture de Search Console et de l’outil d’inspection d’URL pour chaque version linguistique ou régionale. Ce qui est établi et ce qui reste incertain : Google documente le fonctionnement du multilingue et des annotations hreflang, mais ne garantit aucun positionnement lié à un CMS ou à un processus de traduction.

Guide par plateforme : Bing

Bing découvre et indexe les pages multilingues explorables dont la structure est claire, avec des attentes proches de celles de Google en matière de clarté des URL et du contenu. Les fondations techniques comprennent des URL linguistiques et régionales accessibles aux robots, un contenu utile et un suivi dans Bing Webmaster Tools pour chaque propriété ou domaine validé. Privilégiez des titres, des affirmations et des FAQ localisés plutôt que la seule traduction de l’interface, où la navigation change de langue mais pas le corps du texte. Les signaux d’autorité reposent toujours sur des sources fiables et des entités cohérentes d’une version linguistique ou régionale à l’autre. Conséquence pour le multilingue : ne masquez pas les langues derrière des sélecteurs fonctionnant uniquement côté client ou derrière des changements de langue par cookie sur une URL unique, qui empêchent les robots de découvrir les différentes versions. Mesurez l’indexation et les statistiques d’exploration dans Bing Webmaster Tools. Ce qui est établi et ce qui reste incertain : les consignes de Bing mettent l’accent sur un contenu utile et explorable ; n’inventez pas de facteurs de classement propres à Bing pour les outils de traduction.

Guide par plateforme : ChatGPT

ChatGPT peut citer ou résumer des pages accessibles au public lorsque les versions linguistiques sont clairement identifiées et que leur contenu permet de répondre directement aux questions. La découverte ne repose pas sur un classement classique de pages explorées : la visibilité se traduit par une sélection comme source ou une mention dans les réponses, plutôt que par une place dans une page de résultats classés. Les fondations techniques commencent toujours par des URL au contenu HTML accessible, et non par des widgets en surimpression qui masquent le texte aux outils de récupération. Parmi les qualités de contenu utiles figurent les réponses directes, les FAQ et une terminologie stable issue de glossaires tenus à jour pour chaque version linguistique et régionale. L’autorité repose sur des éléments probants et des entités cohérentes d’une langue à l’autre. Conséquence pour le multilingue : chaque page localisée doit pouvoir se lire de façon autonome, sans supposer que l’internaute changera de langue. La mesure reste imparfaite : considérez les vérifications de citations comme un moyen d’explorer des hypothèses qualitatives, et non comme des indicateurs clés de performance. Ce qui est établi et ce qui reste incertain : aucune documentation ne garantit que les données structurées, hreflang ou un quelconque processus de traduction permettent d’obtenir des citations dans ChatGPT.

Guide par plateforme : Gemini

Gemini et les autres expériences d’IA de Google bénéficient d’entités cohérentes, de données structurées exactes lorsqu’elles sont pertinentes et de pages localisées indexables. La visibilité consiste à être cité ou reconnu, et non à inventer des facteurs de classement propres à Gemini. Les fondements techniques recoupent les exigences de Google Search en matière d’exploration et de qualité des métadonnées pour chaque URL localisée. Dans chaque langue, le contenu doit présenter des affirmations et des définitions claires, avec un niveau de détail pensé avant tout pour les internautes. L’autorité repose sur la cohérence des informations relatives à l’organisation et leur corroboration sur les différents marchés. Conséquence pour le multilingue : des noms de produits encadrés par un glossaire limitent les confusions entre entités d’une version locale à l’autre, aussi bien dans la recherche que dans les interfaces d’IA. Mesurez les résultats de manière classique avec Search Console et évaluez qualitativement un échantillon de réponses de l’IA dans les langues cibles. Ce qui est établi et ce qui reste incertain : le comportement de Gemini ne remplace pas les recommandations documentées de Google Search sur hreflang et les versions linguistiques.

Guide par plateforme : Google AI Overviews

Les AI Overviews de Google peuvent inclure des liens vers des pages étayant leurs réponses ; les conditions d’éligibilité reposent toujours sur un contenu indexable, conçu avant tout pour les internautes dans chaque langue. Ces aperçus ne sont pas un sélecteur de langue et ne remplacent pas les annotations hreflang entre versions alternatives. Les fondements techniques restent un HTML localisé explorable et des données structurées fidèles au contenu visible de la page. Un contenu de qualité comprend des réponses concises et des titres clairs dans chaque version linguistique. Les signaux d’autorité répondent aux attentes en matière de contenu utile et ne reposent pas sur le seul balisage schema. Conséquence pour le multilingue : aucune page traduite n’est assurée de figurer dans les AI Overviews, quelles que soient ses performances en anglais. Utilisez les rapports de Search Console consacrés aux résultats génératifs lorsqu’ils sont disponibles et suivez séparément les indicateurs d’indexation classiques. Ce qui est établi et ce qui reste incertain : aucun processus de traduction ne peut promettre une présence dans les AI Overviews.

Le rôle de GlotEO

La localisation du balisage à grande échelle relève autant de la gestion opérationnelle des contenus que du développement. Lorsque les glossaires, les champs traduits et les annotations SEO divergent, le JSON-LD devient le dernier endroit où se cachent les erreurs de mélange de langues. GlotEO aide les équipes à maintenir la cohérence de leurs processus de SEO multilingue, afin que les données structurées, les annotations hreflang et le contenu des pages utilisent la même terminologie et les mêmes URL localisées.

Découvrez la plateforme de SEO multilingue si vous avez besoin d’une gouvernance couvrant de nombreuses versions linguistiques, et consultez les tarifs et offres de GlotEO pour comparer les niveaux de fonctionnalités dédiés au contrôle qualité du balisage et à la révision des traductions.

Références