Devrais-je utiliser un seul type de balisage?
J'essaie d'être un bon garçon et de mettre en œuvre le balisage et les balises pertinentes qui rendent les gens heureux et applaudissants. Ce faisant, j’ai assimilé de multiples sources d’information et mis en œuvre de nombreux types de balises.
Ce que je me demande c'est: devrais-je?
Au début, il semble judicieux d'utiliser autant de formats que vous pouvez être dérangé pour implémenter, de sorte que tout ce qui regarde votre page engloutisse allègrement les données qu'il aime, mais il y a ensuite ceci:
"Ah, vous avez dupliqué vos données!" Je vous entends appeler. Oui, techniquement, oui, mais je l’ai fait intentionnellement en utilisant plusieurs formats:
<!DOCTYPE html>
<html itemscope itemtype='https://schema.org/WebPage' lang='en' vocab="http://schema.org/" typeof="WebPage">
<title>Example.com</title><meta charset=utf-8>
<meta name=DC.format content=text/html>
<meta name=DC.language content=en>
<meta name=DC.rights content="© 2015-2016 Example.com. All rights reserved.">
<meta itemprop='name' name='DC.title' property='name' content='Example.com'>
<meta itemprop='description' name='description' property='description' content='An example web page.'>
<meta name='DC.description' content='An example web page.'>
<meta name='DC.subject' content='Websites'>
<script type='application/ld+json'>
{
"@context": "http://schema.org",
"@type": "WebPage",
"name": "Example.com",
"description": "An example web page."
}
</script>
Tout cela est en fait fait avec un modèle PHP - je n'ai à entrer les données qu'une seule fois - mais ce qui m'inquiète, c'est la sortie de l'outil de test de données structurées de Google: il suggère qu'il existe deux éléments WebPage. , ce qui bien sûr il n'y en a pas.
Yandex vous dit simplement ce qu'il trouve:
- Google répertoriera-t-il deux pages Web ou Google est-il assez intelligent pour reconnaître que les données de formats différents sont séparées, même si elles sont identiques?
- Est-ce que ça importe? Peut-être que le fait d'être listé est suffisant, même si c'est en double. Et peut-être que ce serait le problème de Google à régler, même si cela me concernerait davantage.
- Devrais-je m'en tenir à un seul format?
J'ajouterai plus de balisage au fur et à mesure, ce n'est qu'un exemple, mais je pensais m'arrêter maintenant au cas où je perdrais mon temps et que je n'avais qu'à en retirer une partie plus tard.
Toute aide est bien sûr pleinement appréciée.
Il est logique que le SDTT de Google affiche plusieurs entrées¹, car il est impossible de savoir si ces entités sont supposées représenter la même chose ou non.
Les trois syntaxes prises en charge par Google Search permettent de désigner un URI pour l'entité (@id en JSON-LD, itemid dans Microdata, about en RDFa). C’est toujours une bonne idée de fournir un tel URI, mais si représenter la même entité dans des syntaxes différentes, cela devient particulièrement important. S'ils ont le même URI, il est clair que ces entités représentent la même chose.
Bien que le SDTT de Google fusionne des entités avec le même URI si la même syntaxe est utilisée , il ne les fusionne pas si des syntaxes différentes sont utilisées (tout en affichant les URI, il est donc possible que seul le SDTT ne le supporte pas).
Donc, si vous décidez de fournir les mêmes données structurées dans différentes syntaxes, vous pouvez envisager de spécifier des URI qui représentent l'élément (que Google le prenne en charge ou non).
Mais devriez-vous fournir les mêmes données structurées dans plusieurs syntaxes? Difficile de donner une réponse définitive sans connaître tous les facteurs qui pourraient jouer un rôle dans votre cas. Par exemple, si vous savez que certains de vos utilisateurs souhaitent utiliser différents outils ne prenant en charge que certaines syntaxes, il peut avoir un sens de fournir vos données structurées dans toutes ces syntaxes.
Dans le cas général, je n’utiliserais qu’une seule syntaxe.
¹ Fait intéressant, le SDTT ne semble pas créer d’entrée supplémentaire pour le RDFa spécifié dans le head, mais lorsqu’il est déplacé vers le body, deux entrées sont créées (l’une à partir de Microdata, l’autre à partir de RDFa). . Le comportement de head est probablement un bogue du SDTT.
Un classement sain rejetterait la redondance comme inutile ou la pénaliserait , donc je m'en tenais à un seul format. (Cela réduira le nombre de pages et rendra vos pages plus faciles à compiler et à charger plus rapidement, même si cela ne vous préoccupe pas trop.)
Hélas, je ne connais pas les algorithmes utilisés par Google (ou tout autre site d'indexation automatique), je ne peux donc pas vous garantir que c'est ainsi ça va marcher.
Vous êtes réellement complètement redondant, là-bas. Ce ne sont que deux façons d’incorporer ces chaînes de microformats. Les paires clé/valeur sont les mêmes et doivent être interprétées de la même manière. Yandex vous en dit plus sur la façon dont il l'a trouvé, et Google en dit plus sur ce que cela dit.
Étant donné que c’est ce que les métadonnées d’en-tête sont censées faire, j’envisage de l’utiliser.
(J'ai de la sympathie pour les utilisateurs de JSON, cependant, puisqu'il s'agit d'un beaucoup plus court)
Déterminez un seul type de balisage à utiliser et n'indexez que celui-ci. Toutes les autres annotations doivent être déclarées comme des doublons en insérant les éléments suivants entre <head> et </head> du code HTML des pages en double:
<link rel="canonical" href="http://domainoforiginalpage.com/path/to/original/document.htm">
Google recommande cette approche aux webmasters comme moi possédant une version de bureau et mobile du même site. Après tout, c’est le contenu imprimable qui compte en fin de compte.
Voici des informations: https://developers.google.com/webmasters/mobile-sites/mobile-seo/separate-urls
Vous pouvez également souhaiter inclure les éléments suivants entre <head> et </head> dans le document original à indexer.
<link rel="alternate" href="http://alternateurl.com/path/to/repeated/document.htm">
Vous pouvez également ajouter un paramètre de support si le document copié est destiné à des périphériques spécifiques à des résolutions spécifiques.
Voici plus d'informations sur les paramètres pouvant être utilisés pour les médias: