Métadonnées de site Web SEO: Schema.org, Open Graph, Dublin Core et méta standard contre méta en double?
Il y a beaucoup de schémas là-bas. Que dois-je utiliser pour mon référencement de site Web? Lesquels sont inutiles ou peuvent même être nocifs? Je vais expliquer ma question par la balise description:
Schema.org: Il s’agit du premier choix de Google en matière de référencement. Je devrais donc l’utiliser (soit en JSON-LD, soit avec des microdonnées).
<meta itemprop="description" content="fdsa" />Open Graph: également obligatoire comme premier choix des sites de médias sociaux.
<meta property="og:description" content="fdsa" />Dublin Core: peut être utile? Est également utilisé, par exemple. par services de géolocalisation.
<meta name="DC.Description" content="fdsa">Méta standard:
<meta name="description" lang="de-DE" content="fdsa" />
Supposons que l'utilisateur puisse entrer un og:description différent, mais les autres descriptions seraient généralement les mêmes. Quoi qu'il en soit, je peux ajouter des informations supplémentaires utiles dans chaque schéma, donc ma première hypothèse serait o.k. utiliser chacun de ceux-ci?
Cependant, j'ai lu quelque part que les métadonnées en double sont considérées comme néfastes pour le référencement. Ma question est donc la suivante: Est-ce que c'est correct ou est-il préférable de s'en tenir à un ou deux?
J'ai lu quelque part que les métadonnées en double sont considérées comme néfastes pour le référencement
Ça n'a pas de sens. Je ne suppose pas que l'article que vous avez lu fait référence à une source faisant autorité pour cela? Je recommande de traiter avec prudence toute déclaration de connaissance absolue en matière de référencement qui ne provient ni d'un moteur de recherche ni d'une recherche de haute qualité.
Quoi qu'il en soit, vous avez largement répondu à votre propre question. Schema.org est une collaboration entre les principaux moteurs de recherche, notamment Google, Bing et Yandex. Du point de vue du référencement, c’est l’important.
De même, Open Graph (et Twitter Cards) ont des avantages démontrables pour le social.
Les métadonnées HTML valides et standard sont prises en charge à différents degrés par différents moteurs de recherche. Aucun mal à utiliser ceux qui servent un objectif clair, même si certains moteurs de recherche les ignoreront.
Le Dublin Core, à ma connaissance, n'a jamais été largement soutenu et offre donc peu d'avantages. Cela dit, il n'y a pas de mal à l'utiliser si vous le souhaitez.
La fourniture de métadonnées n’est jamais nuisible , sauf si
- vous essayez de tromper/spam, ou
- vous fournissez une quantité de métadonnées telle qu'elle affecte les performances de la page (ce qui est peu probable), ou
- laissez-le devenir obsolète ou ne vous souciez pas de la précision.
En général, plus il y a de métadonnées, mieux c'est . L’idée est que vous ne pouvez jamais connaître tous les consommateurs (ni tout ce qui existe actuellement, ni ceux qui le seront à l’avenir), vous ne pouvez donc pas savoir quelles métadonnées il serait utile de fournir. Et fournir ce qui intéresse les consommateurs (pour qu'ils puissent utiliser vos données quel que soit leur travail) est l’intérêt de proposer des métadonnées, non?
Toutefois, si vous souhaitez uniquement prendre en charge des consommateurs spécifiques et connus, indiquez simplement le contenu de la documentation à l'appui . Généralement, moins de travail, mais vous excluerez peut-être de nombreux autres consommateurs. ( plus de détails )
Doublons de métadonnées
(Notez que le problème du "contenu dupliqué" concerne quelque chose de différent.)
Les métadonnées en double ne devraient pas poser de problème pour le référencement (encore une fois, à l'exception des exceptions ci-dessus).
Dans les microdonnées, impossible d’utiliser le même élément meta comme balise méta (avec name) et comme propriété de microdonnées (avec itemprop). On peut s’attendre à ce que les consommateurs le sachent et il n’aurait aucun sens de leur demander d’imposer aux auteurs de n’utiliser qu’une de ces méthodes, car les deux peuvent être utiles et avoir des cas d’utilisation différents.
Bien sûr, il est préférable d’éviter la duplication de quelque chose, si possible. Comme indiqué dans la réponse liée ci-dessus, RDFa autorise un élément meta avec name et property, donc si vous utilisez RDFa, utilisez-en un. Au lieu de deux éléments est la meilleure façon de faire. Même idée si vous avez plusieurs balises META avec la même valeur: utilisez-les ensemble dans le même attribut name (par exemple, name="DC.Description description").
Syntaxes et vocabulaires
Vos exemples montrent l'utilisation de microdonnées (pour Schema.org), de RDFa (pour Open Graph) et de balises méta HTML simples (pour Dublin Core et le nom description).
Notez que Schema.org ne peut pas être utilisé uniquement avec les syntaxes Microdata et JSON-LD, mais également avec RDFa. Et Dublin Core est également défini comme RDF vocabulaire , de sorte qu'il peut également être utilisé avec RDFa. Cela signifie que vous pouvez utiliser RDFa pour couvrir Schema.org, Open Graph, Dublin Core et tout autre vocabulaire pertinent .
(JSON-LD étant également une RDF sérialisation, cela serait également possible avec JSON-LD, mais au moins, Facebook ne semble pas prendre en charge la consommation des données Open Graph en JSON-LD.)
Cela signifie que vous pouvez éviter d'utiliser des microdonnées et ne fournir qu'un seul élément au lieu de quatre meta:
<meta property="dc:description og:description schema:description" name="description" content="fdsa" />
(reposant sur le contexte initial de RDFa, où sont définis les préfixes dc, og et schema)
Les consommateurs conformes choisissent ce qui les intéresse (par exemple, pour obtenir de riches résultats, Google ne recherchera que les propriétés/types schema et ignorera le reste).