Pré­sen­ta­tion de votre site avec JSON-LD d’après schema.org

Les données struc­tu­rées per­met­tent aux moteurs de recherche de mieux com­prendre les sites Internet. Une an­no­ta­tion sé­man­tique permet d'établir des si­mi­la­ri­tés de sens, de lire les in­for­ma­tions au­to­ma­ti­que­ment, et de les trans­fé­rer sous d'autres formes de pré­sen­ta­tion. Google, le moteur de recherche le plus utilisé de nos jours, s'appuie sur les données struc­tu­rées pour fournir aux uti­li­sa­teurs des résultats de recherche riches et d'autres éléments SERP. Les résultats de recherche ainsi mis en évidence attirent l'at­ten­tion et aug­men­tent la vi­si­bi­lité d'un site Web, ce qui constitue un avantage pour Google.

Ceci implique que toutes les in­for­ma­tions per­ti­nentes soient signalées en con­sé­quence. Au fil du temps, la com­mu­nauté Internet a mis au point plusieurs normes de struc­tu­ra­tion des données. Voici les raisons pour les­quelles il est re­com­mandé de choisir JSON-LD plutôt que d'autres formats de données comme Mi­cro­for­mats, RDFa ou Microdata.

JSon-LD est une méthode basée sur JSON (Ja­vaS­cript Object Notation for Linked Data), per­met­tant d’intégrer des données struc­tu­rées dans un site Web. À l’inverse d’autres formats de données struc­tu­rées tels que Mi­cro­for­mats, RDFa et Microdata, le balisage ne se fait pas à l’aide d’an­no­ta­tions du texte source. Il s’agit à l’inverse d’un système de mé­ta­don­nées dans les balises de script, séparées du contenu du site Web et mises en œuvre dans les éléments head et body du document HTML. Par con­sé­quent, JSON-LD s’appuie sur la notation JSON, qu’elle développe en une syntaxe per­met­tant de nommer les données d’après des schémas nor­ma­li­sés à l’échelle mondiale. 

La spé­ci­fi­ca­tion JSON-LD a été créée par le fondateur de Digital Bazaar, Manu Sporny, et fait partie des re­com­man­da­tions W3C depuis le 16 janvier 2014.

L’abré­via­tion JSON cor­res­pond à Ja­vaS­cript Object Notation, et désigne un format texte compact per­met­tant un échange de données pouvant être géré fa­ci­le­ment aussi bien par les in­ter­nautes que par les or­di­na­teurs. JSON est un dérivé de Ja­vaS­cript, mais il peut être utilisé sur toutes les pla­te­formes, in­dé­pen­dam­ment du langage de pro­gram­ma­tion. En tant que format de données pour le trai­te­ment en série (la re­pré­sen­ta­tion d'objets pro­gram­mables sous un format sé­quen­tiel), JSON est utilisé pour le transfert et le stockage de données struc­tu­rées, ainsi que pour les ap­pli­ca­tions Web et mobiles. La syntaxe d'un objet JSON consiste es­sen­tiel­le­ment en des couples nom/valeur (name-value pairs) qui, à l'ex­cep­tion des valeurs nu­mé­riques, sont placés entre guil­le­mets et séparés par deux points. Chaque couple commence par un alinéa et finit par une virgule. Le dernier couple situé avant le crochet de de fermeture ne se termine pas par une virgule.

L’extrait précédent comporte le couple de mots « Manu Sporny ». Si un in­ter­naute est en mesure de com­prendre fa­ci­le­ment que cette séquence fait référence à un nom, et que l’hyperlien qui suit renvoie au site Internet du dé­ve­lop­peur de JSON-LD, les pro­grammes tels que les na­vi­ga­teurs ou les robots d’in­dexa­tion ont besoin de mé­ta­don­nées pour faire le lien. C’est ici qu’in­ter­vient JSON-LD.

L’exemple de code ci-dessus illustre deux éléments « name » et « homepage », suivis de leurs valeurs res­pec­tives. Un programme qui lit un site Internet avec un objet JSON est capable d’iden­ti­fier avec l’as­so­cia­tion de mots « Many Sporny » comme un nom et « http://manu.sporny.org/about/ » comme un site Internet.

Tandis qu’avec JSON une balise fonc­tionne fa­ci­le­ment au sein d’un seul site Internet, analyser des données JSON de plusieurs sites Internet peut ra­pi­de­ment conduire à un problème d’ambiguïté. En règle générale, les pro­grammes analysent la syntaxe d’un certain nombre de sites Internet, puis évaluent les in­for­ma­tions acquises dans les bases de données. En se basant sur l’exemple de code ci-dessus, il n’est toutefois pas possible de s’assurer que les éléments noms « name » et « homepage » soient toujours compris en tant que tels. Afin d’éviter les ma­len­ten­dus, JSON-LD complète la notation JSON classique par des éléments con­tex­tuels, basés sur le Web des données. Il s'agit de données dis­po­nibles gra­tui­te­ment sur Internet et ac­ces­sibles via Uniform Resource Iden­ti­fier (URI).

La vidéo de Manu Sporny, dé­ve­lop­peur de JSON-LD, apporte des in­for­ma­tions sup­plé­men­taires sur les linked data :

Ce processus a lieu grâce au Web de données (Linked Data). Il s’agit ici de données librement dis­po­nibles sur Internet pouvant être chargées via un URI (l'anglais Uniform Resource Iden­ti­fier, soit lit­té­ra­le­ment iden­ti­fiant uniforme de ressource). Le projet schema.org propose une com­bi­nai­son standard de schémas servant à struc­tu­rer des données. Toutefois, JSON-LD ne se base sur aucun vo­ca­bu­laire par­ti­cu­lier.

Afin de préparer JSON pour les Linked Data, JSON-LD complète les couples nom/valeur clas­siques de la notation JSON par des mots-clés (keywords). Ils sont ajoutés à la syntaxe de JSON-LD et précédés du signe @. Les mots-clés @context et @type sont d'une im­por­tance capitale. Alors que @context définit le vo­ca­bu­laire sous-jacent de l'éti­quette, @type spécifie le type de données (schéma) utilisé.

Le projet schema.org propose une base de données de schémas utiles à la struc­tu­ra­tion des données. Sur le site Web du projet du même nom, les opé­ra­teurs de site Web peuvent trouver de nombreux schémas de données (types), ainsi que des pro­prié­tés (pro­per­ties) associées à ces types de données, qui per­met­tent un marquage sé­man­tique détaillé du contenu du site Web.

Pour compléter l’élément contexte cor­res­pon­dant, reprenons l’exemple cité plus haut :

Le mot-clé @context de la ligne 02 définit le vo­ca­bu­laire relatif au script (ici schema.org). @type indique, à la ligne 03, le schéma, c’est-à-dire le type de données dont il est question. Un programme qui ana­ly­se­rait ce code de manière sé­man­tique peut donc iden­ti­fier l’élément texte « Manu Sporny » comme le nom d’une personne, grâce à la précision person d’après schema.org. Les couples nom/valeur in­tro­duits par name et url sont traités comme des pro­prié­tés (pro­per­ties) du schéma person. C’est le vo­ca­bu­laire sous-jacent qui définit les pro­prié­tés pouvant être classées dans un schéma.

Dans le modèle JSON-LD, les schémas et les pro­prié­tés sont classés de la même manière que les autres formats utilisés pour créer des balises sé­man­tiques dans les pages Web. Le script qui sert d’exemple ci-dessous est converti en une an­no­ta­tion de texte source, le script exemple est défini sans perte d’in­for­ma­tions également via mi­cro­don­nées ou RDFa en suivant le modèle de schema.org :

Syntaxe micro-data d’après schema.org :

Syntaxe RDFa d’après schema.org :

L’avantage principal de JSON-LD face aux formats con­cur­rents réside dans le fait qu’il n’est pas né­ces­saire d’intégrer di­rec­te­ment les données au code HTML, puisqu’elles peuvent être im­plé­men­tées sé­pa­ré­ment en tant que script à l’endroit voulu. L’im­plé­men­ta­tion de JSON-LD dans le code HTML grâce aux balises de script se traduit par le schéma suivant :

Dans l’exemple suivant, l’at­tri­bu­tion est faite selon schema.org :

La sé­pa­ra­tion stricte de HTML et de l’an­no­ta­tion sé­man­tique ne permet pas seulement une bien meilleure lecture du texte source. Ce type d’im­plé­men­ta­tion permet également de générer  des sites dy­na­miques, in­dé­pen­dam­ment de son contenu visible. Sur JSON-LD, les mé­ta­don­nées peuvent également être traitées via le backend, être lues à partir d’une base de données et être générées au­to­ma­ti­que­ment par Template. Ceci permet également d’avoir une an­no­ta­tion sé­man­tique agréable pour les contenus Web dynamique qui prennent toujours plus de place sur Internet.

Depuis juin 2013, le projet Schema.org a fait de JSON-LD l'un des formats de données préférés des uti­li­sa­teurs. Par ailleurs, Google re­com­mande également, dans la mesure du possible, d’intégrer des mé­ta­don­nées par script via JSON-LD. Cette renommée sert de base aux divers éléments SERP que Google utilise pour présenter les résultats de recherche avancée aux uti­li­sa­teurs.

Google a recours à diverses formes de pré­sen­ta­tion pour ses résultats de recherche. Outre des résultats de base (résultats de recherche simples), les uti­li­sa­teurs profitent également, depuis quelques années, en fonction de leur requête, de résultats spon­so­ri­sés et du Knowledge Graph. Si les résultats de base ne profitent que d’ex­ten­sions simples telles que Bread­crumbs, les résultats spon­so­ri­sés et le Knowledge Graph offrent un des ex­ten­sions étendues, également appelées En­han­ce­ments ou Search Result Features.

Google est com­pa­tible avec un balisage JSON-LD pour les ex­ten­sions pré­sen­tées ci-dessous. Le moteur de recherche fournit un exemple de chacun de ses résultats de recherche sur de­ve­lo­pers.google.com.

• Bread­crumbs : la na­vi­ga­tion dite en fil d’Ariane (de l’anglais bread­crumbs qui signifie miettes de pain) affiche la position de la page Web actuelle dans la hié­rar­chie du site. Les opé­ra­teurs de sites Web qui utilisent cette technique per­met­tent à Google de les afficher sur les SERP. Les bread­crumbs sont l'une des rares fonc­tion­na­li­tés de recherche que Google utilise également dans les résultats de base.
• Coor­don­nées de l’en­tre­prise : si les in­for­ma­tions de contact d’une en­tre­prise sont pré­sen­tées de façon sé­man­tique, Google peut les afficher sous la forme d’un Knowledge Graph Display, l’une des pré­sen­ta­tions de l’al­go­rithme du Knowledge Graph.
• Logos : les opé­ra­teurs de sites Web peuvent choisir quelle image doit être utilisée par le moteur de recherche comme logo d'en­tre­prise. Ceci permet à Google d'ajouter un logo pour re­cher­cher les résultats de la société en question.
• Sitelinks Searchbox : si un site Web propose une fonction de recherche et a été traité de façon sé­man­tique, Google peut utiliser une sitelink searchbox pour trouver des résultats sur le site Web.
• Liens vers les profils sociaux : si l’on utilise un balisage pour les liens vers des profils de médias sociaux, Google peut étendre l'af­fi­chage du Knowledge Graph, afin d'y inclure des boutons spé­ci­fiques pour les personnes ou les or­ga­ni­sa­tions. Google propose ac­tuel­le­ment un balisage JSON-LD com­pa­tible avec Facebook, Twitter, Google+, Instagram, YouTube, LinkedIn, Myspace, Pinterest, Sound­Cloud et Tumblr.

Les opé­ra­teurs de sites Web qui sou­hai­tent faire clai­re­ment ap­pa­raitre leur contenu parmi les SERP Google peuvent tagger dif­fé­rents types de données de façon sé­man­tique. Il est à noter que Google décide seul si un résultat de recherche est présenté en tant que résultat de base ou avec des ex­ten­sions. Ac­tuel­le­ment, Google prend en charge un balisage JSON-LD pour les types de données suivants et l'utilise pour traiter les in­for­ma­tions sous forme de Rich Search Results, Enriched Search Results ou de Knowledge Graph Results.

• Articles : les opé­ra­teurs de sites Web qui taggent des articles d'ac­tua­lité ou des blogs de façon sé­man­tique per­met­tent à Google de les inclure dans le carrousel des articles les plus po­pu­laires ou d'ajouter des fonctions de résultats de recherche comme les titres ou les vignettes aux SERP.

• Livres : si les opé­ra­teurs de sites Web proposent un balisage JSON-LD pour les in­for­ma­tions relatives aux livres, Google crée une Knowledge Graph Card pour des requêtes de recherche plus per­ti­nentes. Il ne contient pas seulement des in­for­ma­tions des­crip­tives sur le livre, mais permet également aux uti­li­sa­teurs de Google de l'acheter di­rec­te­ment à partir du moteur de recherche.

• Musique (entrées pour musiciens et albums) : de même que pour les in­for­ma­tions sur les livres, les offres musicales peuvent être annotées sé­man­ti­que­ment. Ceci permet à Google de créer des Knowledge Graph Cards pour le contenu musical. Ces cartes ne four­nis­sent pas seulement des in­for­ma­tions sur les albums et les musiciens, mais per­met­tent également des in­te­rac­tions telles que la lecture ou l'ac­qui­si­tion de musique.

• Offres de cours : certains opé­ra­teurs de sites Web proposant des cours (notamment des cours de langue) sont pourvus d’une an­no­ta­tion JSON-LD, qui permet de lire au­to­ma­ti­que­ment le titre, une brève des­crip­tion ainsi que le pres­ta­taire. Ces sites ont la pos­si­bi­lité d'uti­li­ser ces in­for­ma­tions comme résultats de recherche étendue dans les SERP.

•  Évé­ne­ments : les or­ga­ni­sa­teurs d'évé­ne­ments publics, tels que des concerts et des festivals, ont la pos­si­bi­lité d'annoter des in­for­ma­tions per­ti­nentes (par exemple le lieu de l'évé­ne­ment, la date et l'heure) via JSON-LD. Ceci permet à Google d’extraire au­to­ma­ti­que­ment ces in­for­ma­tions et de les afficher sur les SERP ou dans d'autres produits Google comme les cartes.

• Offres d’emploi : les offres d’emploi publiées par des or­ga­ni­sa­tions sur les sites Web peuvent également être taguées de sorte que Google présente les in­for­ma­tions im­por­tantes dans les résultats de recherche avancés.

• Com­mer­çants locaux : les commerces locaux qui sou­hai­tent diffuser des in­for­ma­tions struc­tu­rées sur leur activité, qu’il s’agisse d’un res­tau­rant ou d’une boutique, peuvent permettre à Google d’installer des Knowledge Graph Cards, de façon à ce que les résultats de recherche les plus per­ti­nents ap­pa­rais­sent dans les SERP ou dans Google Maps. Par exemple, si un uti­li­sa­teur de Google est à la recherche d’un res­tau­rant viet­na­mien, le moteur de recherche affiche un carrousel de tous les res­tau­rants viet­na­miens à proximité.

• Ensembles de données : il est également possible d’accéder aux ensembles de données tels que les tables CSV ou les fichiers dans des formats pro­prié­taires depuis le moteur de recherche via le balisage JSON-LD.

• Podcasts : Google est com­pa­tible avec un balisage JSON-LD pour les in­for­ma­tions relatives aux podcasts. Les in­for­ma­tions ainsi balisées s’affichent di­rec­te­ment dans le moteur de recherche.

• Vidéos : les four­nis­seurs de contenu qui offrent des données struc­tu­rées pour les vidéos mises en lignes sur un site Web, telles qu'une des­crip­tion, un lien vers une vignette, une date de té­lé­char­ge­ment ou une heure de lecture, per­met­tent à Google d'ex­traire ces in­for­ma­tions et de les diffuser sous forme de cartes riches ou de car­rou­sels sur les SERP.

• Films et émissions : lorsqu’un site Web fournit des données struc­tu­rées sur les offres de films ou d'émis­sions, Google les transfère sur les pages de résultats de recherche en tant que Knowledge Graph Cards, et permet ainsi de rendre les re­cherches plus per­ti­nentes. Si né­ces­saire, ces cartes  peuvent être com­plé­tées d’éléments in­te­rac­tifs qui per­met­tent à l’in­ter­naute d’utiliser ou d'acheter le produit.

• Recettes : depuis quelques années, Google propose également des recettes dans le résultat vedettes de son moteur de recherche. Pour ce faire, il est in­dis­pen­sable que les créateurs de contenu four­nis­sent toutes les in­for­ma­tions de recettes per­ti­nentes sous forme de données struc­tu­rées. L’une des re­pré­sen­ta­tions possibles dans  les SERPs est un carrousel avec des cartes riches cor­res­pon­dantes pour la requête.

• Avis : Google prend en charge les avis pour divers types de données Schema.org, notamment les boutiques de proximité, les res­tau­rants, les produits, les livres, les films et les pro­duc­tions cultu­relles. Le contenu dont il est question est affiché sous forme d'extrait. Google distingue les critiques d'auteurs in­di­vi­duels des con­tri­bu­tions sur les forums de con­som­ma­teurs. S'il y a une an­no­ta­tion sé­man­tique, les deux types d'éva­lua­tion sont présentés dans les SERP.

• Produits : en tant que vendeur en ligne, il est possible de fournir sur son site des in­for­ma­tions diverses sur les produits que l’on vend : les prix, la dis­po­ni­bi­lité ou les éva­lua­tions. Pré­sen­tées sous forme de données struc­tu­rées, ces données sont affichées par Google sous forme de résultats de recherche riches.

Les résultats de recherche avancés, qu'il s'agisse de résultats de recherche spon­so­ri­sés ou des Knowledge Graph Displays, pré­sen­tent un avantage majeur pour les opé­ra­teurs de sites Web, puisqu’ils se dis­tin­guent des autres résultats de recherche sur les SERP.

Pour les résultats spon­so­ri­sés, Google présente les displays et les car­rou­sels au-dessus des résultats de base, à la position zéro. Les af­fi­chages du Knowledge Graph ap­pa­rais­sent soit sous forme de carrousel en haut de la page, soit dans cadre à droite, séparés des résultats de recherche organique. Les résultats de recherche avancés per­met­tent ainsi aux opé­ra­teurs de sites Web d'at­teindre le haut du clas­se­ment des résultats de recherche, sans avoir à investir du temps et de l'argent dans l'amé­lio­ra­tion du clas­se­ment organique.

Outre la position mise en valeur, dif­fé­rentes ex­ten­sions telles que les vignettes, les éva­lua­tions, les extraits de texte et les éléments in­te­rac­tifs attirent l'at­ten­tion de l’uti­li­sa­teur et l’invitent à cliquer. Les opé­ra­teurs de sites Web peuvent supposer que le taux de clic pour les résultats de recherche avancée est sig­ni­fi­ca­ti­ve­ment plus élevé que pour les résultats de base.

Par ailleurs, les résultats de recherche avancée ont également un effet positif sur le taux de rebond. Con­trai­re­ment aux résultats de base, qui ne com­pren­nent que le méta-titre, une URL et une brève des­crip­tion, les résultats de recherche avancée offrent aux uti­li­sa­teurs de Google une vue d'en­semble de ce qu'ils pourront trouver sur le site en question. Les in­ter­nautes peuvent donc vérifier la per­ti­nence d'un site Web pour leur requête spé­ci­fique avant d’ouvrir le lien, et ainsi de cliquer seulement si né­ces­saire.

Toutefois, Google ne prend pas en compte la présence ou l'absence de balisage sé­man­tique via JSON-LD pour son clas­se­ment. Matt Cutts, ancien chef de l'équipe de Google Web Spam, l'a expliqué clai­re­ment dans la vidéo YouTube de la série Google Web Masters 2012 :

JSON-LD marque également des points pour la facilité d'uti­li­sa­tion et le dé­pla­ce­ment du balisage vers des sections de script séparées. En com­pa­rai­son avec les an­no­ta­tions al­ter­na­tives telles que Microdata ou RDFa, JSON-LD offre un code source allégé, malgré l'an­no­ta­tion sé­man­tique. Il peut ainsi être recherché ra­pi­de­ment, et fa­ci­le­ment indexé par Google bot et d'autres robots.

Mais l'ex­ter­na­li­sa­tion des données struc­tu­rées présente également des in­con­vé­nients. En principe, Google et les autres moteurs de recherche ap­pli­quent une règle de base, qui veut que seul le contenu ac­ces­sible aux in­ter­nautes soit lisible par les robots. Avec JSON-LD, cependant, il est possible, en théorie, d'im­plé­men­ter n'importe quel balisage, même s'il n’existe pas d'équi­valent pour les mé­ta­don­nées dans le contenu réel du site Web. Dans ce cas, le moteur de recherche et l'uti­li­sa­teur s’attendent à une po­ten­tielle valeur ajoutée qu'un tel site Web amélioré n'offre pas. En pratique, il n’est pas re­com­mandé d’avoir recours à ce type d’approche. Dans le cas contraire, les opé­ra­teurs de sites Web s’exposent à des pour­suites pour spam.

Pour éviter que les visiteurs ne dépassent in­vo­lon­tai­re­ment les limites de l'an­no­ta­tion sé­man­tique dans les moteurs de recherche, les Struc­tu­red Data General Gui­de­lines dé­fi­nis­sent un ensemble de règles précises, qui peuvent es­sen­tiel­le­ment être résumées par les points suivants :

• Format : les données struc­tu­rées doivent être conformes à l’un des trois formats établis : Microdata, RDFa ou JSON-LD. C’est ce dernier que Google conseille.

• Ac­ces­si­bi­lité : les pages pourvues de données struc­tu­rées doivent être ac­ces­sibles au Google Bot. Les méthodes de contrôle d’accès (via robots.txt ou noindex par exemple) empêchent que les mé­ta­don­nées ne soient lues.

• Équi­va­lence de contenu : le balisage JSON-LD doit seulement décrire des entités également décrites en code HTML.

• Per­ti­nence : un balisage JSON-LD ne doit men­tion­ner que des équi­va­lents per­ti­nents des types de données utilisés. Par exemple, un opérateur de site Web qui présente un manuel technique comme une recette de cuisine va à l’encontre des di­rec­tives de per­ti­nence.

• In­té­gra­lité : tous les types de données (types) ré­per­to­riés dans le balisage JSON-LD se doivent d’être in­té­gra­le­ment balisés et d’inclure les pro­prié­tés requises (pro­per­ties). Les types de données qui n’indiquent pas les pro­prié­tés es­sen­tielles ne sont pas adaptées aux résultats de recherche avancée.

• Spé­ci­fi­cité : les projets de linked data tels que schema.org offrent une variété de types de données. Afin de qualifier son propre contenu pour une pré­sen­ta­tion étendue des résultats de recherche, il est conseillé aux opé­ra­teurs de sites Web de choisir des schémas aussi spé­ci­fiques que possible.

Voici un exemple de la façon d'en­ri­chir votre site Web le plus ef­fi­ca­ce­ment possible avec des mé­ta­don­nées per­ti­nentes Le tutoriel JSON-LD qui suit est basé sur le vo­ca­bu­laire du projet schema.org.

Mettre en œuvre données struc­tu­rées est une opération plus ou moins longue en fonction selon la taille du site. Par con­sé­quent, il est conseillé de définir au préalable ses objectifs, de dé­ter­mi­ner le coût l'an­no­ta­tion et le temps de travail que l’on souhaite y investir.

En règle générale, une an­no­ta­tion a pour but de struc­tu­rer les in­for­ma­tions d’un site Web et de le rendre lisible aux moteurs de recherche. L'ob­jec­tif est que Google et consorts puissent montrer que le site Web optimisé fournit les meil­leures res­sources en rapport aux requêtes. Il est donc important de se poser les questions suivantes : 

• Quels sont les contenus du site Web les plus im­por­tants ?
• Quelle est la valeur ajoutée apportée par ces visiteurs po­ten­tiels ?
• Quels contenus sont si im­por­tants qu’ils devraient être ac­ces­sibles par les moteurs de recherche ?

Il est re­com­mandé de lister l’ensemble des contenus qui ajoutent de la valeur, puis de quel contenu doit être porté à l'at­ten­tion des visiteurs po­ten­tiels sur les pages de résultats de recherche.

Google, par exemple, re­com­mande d'at­tri­buer JSON-LD pour les in­for­ma­tions relatives aux évé­ne­ments. En HTML, il est possible d’afficher des annonces d'évé­ne­ments pour des concerts, des comédies musicales ou des re­pré­sen­ta­tions théâ­trales en suivant le schéma ci-dessous :

Les in­for­ma­tions ca­rac­té­ris­tiques du type de données event sont es­sen­tiel­le­ment la date et l'heure, le prix, la dis­po­ni­bi­lité des billets, l'adresse du lieu ainsi que des liens vers d'autres in­for­ma­tions sur l'évé­ne­ment ou le lieu. Lorsqu’un visiteur consulte les pages Web relatives à cet événement, il peut collecter ces in­for­ma­tions dans un texte, un tableau ou d'autres formes de pré­sen­ta­tion, et les com­prendre en fonction du contexte. Les pro­grammes comme les robots de recherche, en revanche, ont besoin de mé­ta­don­nées qui con­tien­nent des ins­truc­tions sur la façon de traiter l'in­for­ma­tion. JSON-LD les délivre sous forme d'un format de données, qui est séparé du contenu et peut être inséré n'importe où dans le code source HTML.

Schema.org fournit des règles générales sur la marche à suivre pour créer et intégrer un balisage JSON-LD en tant qu'opé­ra­teur de site Web.

Schema.org offre aux opé­ra­teurs de sites Web un vo­ca­bu­laire complet dédié à la struc­tu­ra­tion des données. La base de données comprend un total d'environ 600 types, qui peuvent être enrichis de plus de 860 pro­prié­tés.

Pour le choix des types de données, il existe deux stra­té­gies :

1. 1. En théorie, il est possible de comparer tout le contenu déterminé au préalable avec les types de données dis­po­nibles du vo­ca­bu­laire de schema.org, puis de sé­lec­tion­ner le type de données le plus adapté pour chaque élément de contenu. Ce type d’approche est long et gé­né­ra­le­ment inutile.
   2. En pratique, les opé­ra­teurs de sites Web se limitent gé­né­ra­le­ment à un sous-ensemble des types de données schema.org : si l’on utilise le balisage JSON-LD uni­que­ment pour fournir au moteur de recherche des données struc­tu­rées, il suffit de se limiter d'abord aux types de données ac­tuel­le­ment pris en charge par Google, et présentés en détail dans la zone Google Developer.

La deuxième solution est pré­fé­rable car Google propose une do­cu­men­ta­tion détaillée pour tous les types de données pris en charge par le moteur de recherche, ainsi qu’un exemple de balisage pour chaque type de données.

Pour équiper votre site de données struc­tu­rées, il n’est pas besoin d’inventer quoi que ce soit. En effet, il est plus simple s’appuyer des modèles pré­fa­bri­qués au lieu de réécrire le balisage pour chaque type de données à partir de zéro. Ceci est par­ti­cu­liè­re­ment vrai pour les uti­li­sa­teurs qui n’ont pas d'ex­pé­rience avec la syntaxe de JSON-LD.

Dans la do­cu­men­ta­tion Google, les opé­ra­teurs de site Web trou­ve­ront l'exemple de balisage suivant pour les évé­ne­ments :

Les balises de script dé­fi­nis­sent l'élément de la ligne 01 à la ligne 39 comme un script de type "ap­pli­ca­tion/ld+json". Les in­for­ma­tions qui suivent sont donc destinées aux pro­grammes capables de lire les Linked Data au format JSON.

Le premier niveau contient les mots-clés "@context" et "@type" avec les valeurs "http://schema.org" et "Event" (lignes 03 et 04). Un programme d'analyse reçoit l'ins­truc­tion d’affecter les in­for­ma­tions suivantes au schéma "Event" selon Schema.org : il s’agit donc une propriété spé­ci­fique de l'évé­ne­ment. Celles-ci sont affichées sous la forme de couples nom/valeur.

Le premier niveau contient également les pro­prié­tés "name","startDate","location","image","des­crip­tion","enddate","offers" et "performer", aux­quelles les in­for­ma­tions relatives à l'évé­ne­ment sont affectées sous forme de valeurs. Un moteur de recherche peut ainsi iden­ti­fier l'in­for­ma­tion "Séries de concerts de Jan Lieberman: voyage au cœur du jazz" comme le titre de l'évé­ne­ment (name) et "2017-04-24T19:30-08:00" comme l'heure prévue de l’événement (StartDate).

Tout comme RDFa et Microdata, la syntaxe JSON-LD est com­pa­tible avec l'im­bri­ca­tion (nesting). Une propriété n’a pas de valeur, mais un (sous) schéma déterminé grâce à des pro­prié­tés spé­ci­fiques. C’est le cas au deuxième niveau de l'exemple de code, lignes 08, 27 et 35.

Par exemple, ligne 08, la propriété d'évé­ne­ment "lo­ca­li­sa­tion" est définie comme un (sous) schéma de type "Lieu" (Place), et est fournie avec les pro­prié­tés "nom" (name) et "adresse" (adress). La propriété" adresse", à son tour, est définie dans la ligne 11 comme un (sous) schéma du type "Pos­ta­lAd­dress" et est balisée avec les pro­prié­tés spé­ci­fiques au schéma "stree­tAd­dress","ad­dress­Lo­ca­lity","pos­tal­Code","ad­dress­Re­gion" et "ad­dress­Coun­try".´

Chaque section imbriquée est encadrée par des accolades et ainsi séparée de la section su­pé­rieure.

Extrait des lignes 07 à 18 :

Schema.org met à la dis­po­si­tion des opé­ra­teurs de site Web des types de données sous forme d’une ar­bo­res­cence hié­rar­chi­sée, qui devient de plus en plus spé­ci­fique à partir du type de données le plus général Thing ("chose").

Dans l’étape suivante, nous vous montrons comment adapter l'exemple de Google pour le type de données "Event" à l'évé­ne­ment mentionné ci-dessus.

La do­cu­men­ta­tion Google ne contient que des exemples il­lus­trant comment les types de données ré­per­to­riés peuvent être dis­tin­gués sur JSON-LD. Si ceux-ci sont utilisés comme modèles pour votre propre balisage de mé­ta­don­nées, le code doit toujours être adapté de façon in­di­vi­duelle. Il peut être judicieux de se référer à la do­cu­men­ta­tion de Schema.org pour le type de données cor­res­pon­dant, afin d'en savoir plus sur l'uti­li­sa­tion d'un schéma par­ti­cu­lier et ses pro­prié­tés po­ten­tielles. L'exemple suivant montre une per­son­na­li­sa­tion in­di­vi­duelle de l’échan­til­lon de code Google pour le type de données Event :

Dans un premier temps, nous avons remplacé toutes les valeurs de la ma­jo­ra­tion d'échan­til­lon par les valeurs cor­res­pon­dantes de l'annonce d'évé­ne­ment men­tion­née ci-dessus. Les ca­té­go­ries et pro­prié­tés in­cor­rectes ont été rem­pla­cées. Par exemple, la propriété "ad­dress­Re­gion" a été retirée, car elle n’est pas per­ti­nente pour la France. Au lieu de "Per­for­ming­Group" on utilise le sous-système "Person" en-dessous de "performer", car il ne s’agit pas d’un groupe mais d’un seul acteur. Enfin, nous avons ajouté au balisage des in­for­ma­tions qui n'étaient pas incluses dans le modèle Google. Par exemple, les lignes 07 et 10 con­tien­nent les URL de l'évé­ne­ment ou du lieu de l'évé­ne­ment. Pour davantage d’in­for­ma­tions con­cer­nant les possibles pro­prié­tés, veuillez consulter la do­cu­men­ta­tion de Schema.org.

Même si l’on souhaite créer son balisage JSON-LD en partant de rien et sans utiliser de modèle, il est re­com­mandé de consulter la page de do­cu­men­ta­tion Google pour chaque type de données. Le leader du marché des moteurs de recherche y dresse la liste des pro­prié­tés requises et re­com­man­dées pour tous les types de données supportés.

Les exemples de la do­cu­men­ta­tion Google con­tien­nent toujours l’ensemble des pro­prié­tés requises et re­com­man­dées.

L'outil de va­li­da­tion fourni par Google permet de mieux vérifier si certaines pro­prié­tés im­por­tantes ne manquent pas dans votre balisage.

Lors de la va­li­da­tion, l'outil lit les données struc­tu­rées du balisage JSON-LD et vérifie qu’ils sont inscrits dans leur in­té­gra­lité. Les données lues sont affichées sous forme de tableaux, qui con­tien­nent également des notes et des aver­tis­se­ments : l'outil permet en effet de détecter des erreurs de syntaxe ou des données man­quantes.

3. Générer un aperçu

Outre la fonction de test, l’outil de test des données struc­tu­rées de Google propose également une fonction de pré­vi­sua­li­sa­tion. Ceci apporte aux opé­ra­teurs de sites Web un avant-goût de ce á quoi ressemble un résultat de recherche étendue basé sur des balisages validés au préalable.

Il est re­com­mandé de toujours utiliser les pages de do­cu­men­ta­tion de schema.org et de valider votre code JSON-LD en utilisant l'outil de test de données struc­tu­rées. Les Struc­tu­red Data General Gui­de­lines et les Webmaster Gui­de­lines de Google sont également des res­sources in­té­res­santes pour éviter d’en­freindre des règles qui peuvent conduire à l'ex­clu­sion du clas­se­ment des résultats de recherche avancée.