Veuillez considérer le code suivant marqué d'attributs pour fournir des microdonnées:
<!DOCTYPE html>
<html>
<head>
<title>Micro data test - Normal version</title>
</head>
<body>
<div itemscope itemtype="http://schema.org/Product">
<h1 itemprop="name">Product name</h1>
<img alt="" itemprop="image" src="http://placehold.it/200x200" />
<div itemprop="description">This is the product description.</div>
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<meta content="in_stock" itemprop="availability" />
<span content="GBP" itemprop="priceCurrency">£</span><span itemprop="price">100.00</span>
</div>
</div>
</body>
</html>
L'utilisation de l' outil de test de données structurées de Google donne des résultats positifs.
C'est très bien dans l'exemple de test, cependant, nous voulons implémenter des microdonnées sur une variété de sites dont la structure HTML varie considérablement. Pour implémenter les attributs de cette manière, il faudra que quelqu'un modifie manuellement le balisage HTML sur chacun des sites individuellement.
De préférence, nous aimerions pouvoir appeler une seule fonction qui regroupe toutes les microdonnées en un seul endroit; techniquement, cela est possible en utilisant des balises META de la manière suivante:
<!DOCTYPE html>
<html>
<head>
<title>Micro data test - Meta tag version</title>
</head>
<body>
<meta itemscope itemtype="http://schema.org/Product" itemref="microName microImage microDescription microOffer" />
<meta id="microName" itemprop="name" content="Product name" />
<link id="microImage" itemprop="image" href="http://placehold.it/200x200" />
<meta id="microDescription" itemprop="description" content="This is the product description." />
<meta id="microOffer" itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemref="microCurrency microPrice microAvail" />
<meta id="microAvail" itemprop="availability" content="in_stock" />
<meta id="microCurrency" itemprop="priceCurrency" content="GBP" />
<meta id="microPrice" itemprop="price" content="100.00" />
<div>
<h1>Product name</h1>
<img alt="" src="http://placehold.it/200x200" />
<div>This is the product description.</div>
<div>£100.00</div>
</div>
</body>
</html>
L'utilisation de l' outil de test de données structurées de Google donne les mêmes résultats positifs que le premier test.
Pour référence (nous ne le ferions jamais sur un site réel), l' outil de test de données structurées de Google renvoie une erreur si vous essayez de transmettre des microdonnées masquées par CSS.
Ainsi, le balisage normal et le méta tag produisent les mêmes résultats, cependant, j'ai quelques inquiétudes en raison des déclarations suivantes de Google et Schema.org:
https://support.google.com/webmasters/answer/146750 indique:
En général, Google n'utilisera que des données annotées visibles par l'utilisateur. Les données masquées seront ignorées. Cependant, dans certaines circonstances, il peut être utile de fournir à la fois une version lisible par machine et une version lisible par l'homme de votre contenu. Par exemple, bien que la chaîne de texte "L'anniversaire d'Elvis" soit importante pour de nombreux lecteurs humains, elle n'est pas aussi significative pour les moteurs de recherche que 1935-01-08. De même, les lecteurs humains peuvent déduire la signification du symbole $, mais il peut être utile d'indiquer spécifiquement aux moteurs de recherche si vos prix sont en pesos ou en dollars.
http://schema.org/docs/gs.html indique (par rapport à l'utilisation des balises META):
Cette technique doit être utilisée avec parcimonie. N'utilisez méta avec contenu que pour des informations qui ne pourraient pas être balisées autrement.
http://schema.org/docs/faq.html#13 déclare:
En règle générale, vous ne devez baliser que le contenu visible par les personnes qui visitent la page Web et non le contenu des div masqués ou d'autres éléments de page masqués.
Mes questions sont:
- Bien qu'aucune erreur ne soit renvoyée, serions-nous pénalisés par les moteurs de recherche pour l'utilisation de balises META de cette manière (c'est-à-dire du contenu en double, la dissimulation d'informations, etc.)?
- Si cela ne vous convient pas, pouvez-vous suggérer un moyen de séparer les microdonnées des données réelles ou devrons-nous mordre la balle et l'implémenter en HTML au cas par cas?
Réponses:
Votre plan d'utilisation des métadonnées pour les microdonnées n'est pas viable. Voici la FAQ de Google sur les raisons pour lesquelles elle n'affiche pas vos données dans les résultats de recherche :
Le seul moyen pour que Google utilise les microdonnées que vous fournissez est de les marquer là où elles se trouvent dans la page, visible par l'utilisateur.
À ce stade, Google ne pénalise pas pour avoir tenté d'abuser des extraits riches autres que simplement désactiver les extraits riches pour ce site. Cela ne me surprendrait pas si Google commençait à exclure complètement les sites des résultats de recherche lorsque Google trouve que le site essaie d'utiliser les microdonnées d'une manière qui ne correspond pas aux directives.
Tant que vos métadonnées que vous annotez sont également visibles quelque part sur la page, il est peu probable que Google pénalise votre site comme malveillant. Cependant, leurs outils automatiques détectent lorsque vous marquez les données dans un emplacement non visible et ils ne les afficheront pas dans les résultats de la recherche.
la source
L'utilisation d' éléments
meta(etlink) pour les microdonnées est très bien. Parfois, il n'y a même pas d'alternative sensée, par exemple, si des codes spécifiques doivent être fournis là où cela n'aurait aucun sens de les montrer à vos utilisateurs.Google utilise même
metadans certains de leurs exemples Rich Snippets:Produits et applications logicielles :
Avis :
Vidéos :
Articles :
Donc la question est, combien est trop (s'il y a une limite)? Et je pense qu'il est sûr de supposer qu'il n'y a pas dur limite, le plus dépend probablement de divers facteurs.
Cependant, il serait logique que Google ne rejette pas le balisage de microdonnées si seulement
meta/linkest utilisé. Pourquoi? Parce qu'ils prennent également en charge (et parfois même recommandent ) JSON-LD pour fournir des données Schema.org, et cela se compose uniquement de contenu "caché" (à savoir, unscriptélément caché utilisé comme bloc de données ).Et ce serait ce que je suggérerais dans votre cas: si vous ne voulez pas ajouter les données structurées en balisant vos éléments existants, utilisez JSON-LD .
la source
Je ne peux pas dire si cela fonctionnerait pour toutes les situations, mais nous utilisons Schema.org de la manière que vous décrivez - en tant que méta "contenu" sur les pages de produits. Pourquoi? C'est tellement plus portable et ne détruit pas les thèmes. Il permet également un contrôle plus granulaire sur le formatage des données, et il obtient des données pertinentes juste après
<body>(bien au-dessus du pli). Les plates-formes basées sur le hook (ou même basées sur F&R comme vQmod) me viennent à l'esprit: il n'y a aucun moyen de F&R de manière fluide toutes les directives dans la structure sans les coder en dur.Nous n'avons remarqué aucune pénalité, Google utilise toujours les données, les met toujours dans les widgets SERP. Nous avons toujours la plupart des données sur la page quelque part, mais dans la mesure où la plupart du balisage va, c'est dans un seul méta-conteneur hiérarchique en utilisant
content=""comme votre exemple inférieur uniquement son organisation enveloppée comme "faire une offre". Maintenant, ne prenez pas cela trop loin - il est préférable de laisser les éléments structurels comme la boucle de commentaires, le fil d'Ariane, la description principale ou les spécifications hors de ce méta-conteneur. Essayez de les coder en vue.La plupart des gens diront "n'utilisez pas de
content=""métas" mais là encore, la plupart de ces personnes ne l'ont jamais essayé. Il en va de même pour des choses comme le balisage riche sur les listes de produits dans les catégories ... oui, nous enfreignons également cette règle :) N'oubliez pas que Google n'est pas le seul poisson dans l'étang RDF. Ce que G dit n'est pas «faire ou casser» dans cette circonstance d'utiliser des formats de données standard d'une manière qui est parfaitement acceptable pour le reste de l'étang. Peut-être même parce que G lui-même change d'avis à l'avenir. Il veut des données au-dessus / surtout, mais il vous fait coder dans les données ci-dessous / ci-dessous, tandis que les méta-attributions le mettent en avant et au centre, dans un langage accessible à la machine.la source
<head>ou<body>. Pinterest aime les données d'abord de Schema. Les cartes Twitter fonctionnent de manière similaire. Et n'ayez pas peur d'utiliser le vocabulaire des données pour le fil d'Ariane et des parties de la boucle des avis, c'est valide.