Schema.org sur un site multilingue : les champs qu’il faut adapter par langue

Un client éditeur de formations en ligne, disponible en français, anglais et portugais, nous a demandé un audit SEO technique après une stagnation du trafic sur ses versions traduites. Le balisage hreflang était correct, la structure d’URL propre en sous-dossiers par langue. Mais en inspectant le code source des trois versions d’une même page de formation, nous avons trouvé un bloc JSON-LD strictement identique, y compris sur la version portugaise, où le champ description reproduisait mot pour mot le texte français.

Ce constat revient sur la quasi-totalité des audits de sites multilingues que nous menons. Le balisage lang HTML, souvent bien géré par les extensions multilingues, donne une fausse impression de sécurité : le contenu visible est traduit, mais les données structurées injectées en JSON-LD, elles, sont fréquemment générées une seule fois et dupliquées telles quelles sur chaque langue.

Le champ inLanguage, trop souvent absent ou figé

La propriété inLanguage, disponible sur la plupart des types Schema.org (Article, Course, Product, WebPage…), déclare explicitement la langue du contenu décrit par le bloc structuré. Beaucoup d’implémentations l’omettent purement et simplement, ou pire, la codent en dur avec la langue par défaut du site sur toutes les versions :

{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "Formation développement web",
  "description": "Apprenez à créer des sites modernes.",
  "inLanguage": "fr"
}

Sur la version portugaise de la même page, ce bloc doit devenir :

{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "Formação em desenvolvimento web",
  "description": "Aprenda a criar sites modernos.",
  "inLanguage": "pt"
}

Sans cette adaptation, un moteur de recherche qui exploite les données structurées associe un contenu en portugais à une déclaration de langue française, ce qui affaiblit la confiance qu’il peut accorder à l’ensemble du balisage.

Les champs textuels : le piège de la copie automatique

Les champs comme name, description, headline ou les libellés d’un FAQPage doivent reprendre le texte réellement affiché sur la page, dans la langue de cette page. Or de nombreuses implémentations construisent le JSON-LD via une fonction générique appelée sur chaque version linguistique, mais qui va chercher la valeur du champ dans une méta ACF ou un champ personnalisé non traduit par l’extension multilingue en place. Le résultat visuel de la page est bien traduit, mais le JSON-LD injecté en arrière-plan reste dans la langue source.

Le diagnostic est rapide : ouvrir l’outil de test de résultats enrichis de Google sur chacune des versions linguistiques d’une même page, et comparer le contenu du champ description du balisage à la meta description réellement affichée dans la langue concernée. Un écart de langue confirme le problème.

Le cas particulier de l’identifiant @id

Un point plus subtil, qui échappe souvent même à des développeurs expérimentés : le champ @id, utilisé pour relier des entités entre elles (un Organization référencé depuis un Article, par exemple), doit rester cohérent pour désigner la même entité réelle, mais ne doit jamais mélanger involontairement des pages de langues différentes sous un même identifiant d’URL non résolu. Une pratique correcte consiste à faire pointer @id vers l’URL canonique de la page elle-même (qui diffère par langue), sauf pour les entités globales comme l’organisation éditrice, qui peut légitimement partager un identifiant unique inter-langues si son URL de référence est elle-même unique.

Comment structurer correctement ce balisage sous WPML ou Polylang

• Générer le JSON-LD à partir des champs déjà traduits par l’extension multilingue (titre, contenu, champs ACF traduisibles), jamais depuis les champs sources bruts.
• Ajouter systématiquement inLanguage avec la locale courante récupérée via get_locale() ou l’équivalent fourni par l’extension multilingue (wpml_current_language côté WPML).
• Vérifier, pour les types imbriqués (une Review dans un Product, par exemple), que chaque sous-bloc respecte aussi la langue de la page, et pas seulement le bloc racine.
• Auditer le résultat avec l’outil de test de résultats enrichis de Google sur chaque langue, pas uniquement sur la langue par défaut du site.

Un balisage Schema.org valide en JSON mais figé en une seule langue donne une fausse impression de conformité. La validation technique ne remplace pas la vérification langue par langue.

Ce que cet article ne couvre pas

Ce sujet porte spécifiquement sur l’adaptation des données structurées par langue. La configuration de l’attribut lang HTML lui-même, sur la balise <html>, répond à une logique différente et a déjà été traitée en détail précédemment.

En résumé

Un site multilingue correctement traduit en surface peut très bien diffuser des données structurées non adaptées en arrière-plan. Les trois points à vérifier systématiquement sont la présence et la justesse du champ inLanguage, la traduction réelle des champs textuels du JSON-LD, et la cohérence des identifiants @id entre les différentes versions linguistiques d’une même page.