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

> Un site multilingue diffuse le même balisage Schema.org, mot pour mot, sur ses trois versions linguistiques. Voici quels champs doivent réellement changer d'une langue à l'autre, et pourquoi ce n'est pas un détail cosmétique.

- Auteur : Clément Hadrot
- Publié le : 2022-09-06
- Mis à jour le : 2022-09-06
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/attribut-lang-schema-org-multilingue/

## L’essentiel

- inLanguage doit refléter la langue réelle de chaque page, pas une valeur figée
- Les champs textuels (name, description) doivent être traduits, pas copiés
- Un même @id partagé entre langues peut créer une ambiguïté d'entité pour Google

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

> L'essentiel à retenir : inLanguage doit refléter la langue réelle de chaque page, pas une valeur figée ; Les champs textuels (name, description) doivent être traduits, pas copiés ; Un même @id partagé entre langues peut créer une ambiguïté d'entité pour Google

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.