web-dev-qa-db-fra.com

comment traiter le balisage LocalBusiness JSON-LD traduit?

J'ai un balisage JSON-LD (selon les directives de Google) pour:

  • Website avec Logo
  • LocalBusiness avec AggregateRating et Reviews
  • Breadcrumbs

Soudain, j'ai réalisé que chaque schéma avait une copie traduite pour chaque langue du site Web. C'est correct avec Breadcrumbs, mais pas avec, par exemple, LocalBusiness, car il a maintenant des doublons avec des évaluations en double.

Je n'ai trouvé aucune documentation officielle de Google sur la gestion du balisage dans plusieurs langues (tout ce que j'ai trouvé était lié à la page et au contenu, pas au balisage; utiliser hreflang et les sitemaps pour indiquer à Google les pages traduites n'est pas la solution utilisée. comme si vous faisiez un LocalBusiness json-ld, ils sont traités différemment).

Quelle serait la meilleure stratégie pour les schémas traduits?

  1. Conserver un schéma LocalBusiness dans une langue et supprimer les copies traduites?
  2. Garder traduit LocalBusiness schémas avec @SameAs pointant vers le schéma d'origine? Si tel est le cas, Google peut-il comprendre qu'il s'agit de traductions?
  3. Conservez plusieurs schémas dans différentes langues avec le même @id et laissez Google en choisir un ou distinguer les copies traduites?
  4. Les rendre uniques? Créez différents @id pour chaque traduction LocalBusiness?
duplicate-contentschema.orglocal-seojson-ldtranslation
2
Alex V

je garderais LocalBusiness dans une langue partout, mais sur des versions linguistiques différentes de votre site, j'ajouterais une définition de langue, comme ceci:

<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "LocalBusiness",
"mainEntityOfPage": {
"@type": "WebPage",
"url": "http://example.com/de/",
"inLanguage": "de"
}
}
</script>

Utilisez comme url celui que vous utilisez dans l'attribut hreflang, il n'y aura donc aucune différence.

1
Evgeniy

(À ma connaissance, Google Search ne publie pas de consignes dans ce cas.)

Je ne pense pas qu’il serait utile de supprimer les données structurées des pages traduites.

Les consommateurs (qu’ils soient humains ou non) intéressés par les données structurées n’explorent pas nécessairement la page dans d’autres langues. Ces consommateurs ne remarqueront même pas que vous fournissez des données structurées.

Un moteur de recherche qui décide d'afficher un résultat enrichi pour votre page pourrait également être intéressé à l'afficher pour vos pages traduites. Et si cela se produit, et si le résultat riche inclut du texte fourni par l'auteur, le moteur de recherche ne l'affichera probablement que sur les pages traduites si les données sont également dans la langue de la page.

JSON-LD @id

Comme il s’agit de la même organisation, le @id devrait également être le même.

C’est l’un des principaux objectifs de @id , qui indique que différents nœuds (éventuellement sur différents sites/pages, dans différentes langues, etc.) concernent la même entité.

JSON-LD @language

JSON-LD vous permet de spécifiez la langue des valeurs de chaîne avec @language. (Cela vous permettrait également d'avoir un nœud contenant les données dans toutes les langues.)

Mais au moins le SDTT de Google ne semble pas supporter @language. Il n’est pas certain que ce soit également le cas pour Google Search. En supposant que Google Search ne prenne pas en charge @language, il devrait être correct de fournir de telles annotations linguistiques, car elles seront probablement ignorées.

inLanguage de Schema.org

Comme Evgeniy le note , Schema.org définit la propriété inLanguage , qui vous permet de spécifier le langage des œuvres créatives (et non du LocalBusiness lui-même).

Vous pouvez indiquer cette propriété sur chaque élément WebPage et/ou WebSite de chaque langue.

workTranslation/translationOfWork de Schema.org

Pour indiquer que vos éléments WebPage (et éventuellement aussi WebSite) sont/ont des traductions, vous pouvez utiliser la propriété workTranslation / translationOfWork de l'extension bib de Schema.org.

0
unor