Je me demande quels sont les effets/avantages/problèmes liés à la liaison des données structurées Website
et Organization
(en particulier dans JSON-LD).
Sur la page d'accueil de mon site, j'ai quelque chose comme ça:
<script type='application/ld+json'>
[{
"@context":"http://schema.org",
"@type":"Organization",
"@id":"https://example.com/",
"url":"http://example.com",
"name":"My site",
"logo":"https://example.com/logo.jpg",
"sameAs": [
"https://www.facebook.com/example/",
"https://Twitter.com/example"
]},
{
"@context":"http://schema.org",
"@type":"WebSite",
"@id":"https://example.com/",
"url":"https://example.com",
"name":"My Site",
"potentialAction":{
"@type":"SearchAction",
"target":"https://example.com?searchQuery={search_term_string}",
"query-input":"required name=search_term_string"
}
}]
</script>
Dans ce cas, j'ai connecté les Website
et Organization
avec le même ID. J'ai remarqué dans Structured Data Tool , Google combinera cela en un seul type de données:
J'utilise Website
pour les avantages potentiels de la zone de recherche du site et j'utilise Organization
pour les avantages du point de contact et des liens vers les comptes sociaux.
Ma question est: est-ce une bonne idée? Y a-t-il une raison de ne pas connecter ces deux éléments dans des données structurées? Quelles sont les implications pour lier ces éléments par rapport à les conserver en tant qu'identités distinctes?
@id
?Si les éléments ont le même @id
, ils sont identiques. Ces deux extraits sont sémantiquement équivalents:
[
{
"@context": "http://schema.org",
"@type": "Organization",
"@id": "https://example.com/"
},
{
"@context": "http://schema.org",
"@type": "WebSite",
"@id": "https://example.com/"
}
]
{
"@context": "http://schema.org",
"@type": ["Organization", "WebSite"],
"@id": "https://example.com/"
}
Mais l'organisation et son site Internet sont-ils la même chose? Je dirais non. Exemples qui montrent pourquoi ce sont des entités différentes:
D'autres pourraient vouloir faire des déclarations uniquement sur le site Web ou uniquement sur le organisation. Par exemple, si quelqu'un déclare <#i> ex:likes <https://example.com/> .
, ils n'aiment peut-être que le site Web, mais pas l'organisation. Si les deux étaient identiques, il ne serait pas possible de faire la différence.
Une organisation peut avoir plusieurs sites Web (par exemple, par langue), mais si l'organisation et tous ses sites Web étaient la même entité, il ne serait pas possible d'associer les différents url
valeurs avec les valeurs inLanguage
correspondantes. Chaque version linguistique devrait avoir son propre élément WebSite
( exemple ).
@id
pour chaque choseJe recommanderais pour donner à votre Organization
son propre @id
, par exemple:
{
"@type": "Organization",
"@id": "https://example.com/#org",
"url": "https://example.com/"
}
Si vous voulez aller plus loin , vous pouvez même donner à votre WebSite
son propre @id
, afin qu'il puisse être différencié de la page d'accueil:
{
"@type": "WebSite",
"@id": "https://example.com/#site",
"url": "https://example.com/"
}
{
"@type": "WebPage",
"@id": "https://example.com/",
"url": "https://example.com/"
}
Organization
et WebSite
Vous pouvez associer l'organisation et ses sites Web à des propriétés appropriées telles que author
/ creator
, copyrightHolder
, et/ou publisher
, ainsi que mainEntity
/ about
.
( exemple JSON-LD )