Come uti­liz­za­re il lin­guag­gio di markup con JSON-LD basato su Schema.org

I dati strut­tu­ra­ti aiutano i motori di ricerca a com­pren­de­re meglio le pagine web. Un’an­no­ta­zio­ne semantica consente di creare dei col­le­ga­men­ti, di scan­sio­na­re au­to­ma­ti­ca­men­te le in­for­ma­zio­ni e di trasporle in altre forme di rap­pre­sen­ta­zio­ne. Google, il motore di ricerca più uti­liz­za­to dei giorni nostri, si basa sui dati strut­tu­ra­ti per mettere a di­spo­si­zio­ne degli utenti i Rich Search Results e gli altri elementi della SERP. Il vantaggio per i gestori dei siti è che i risultati di ricerca messi in evidenza in questo modo balzano subito agli occhi e aumentano la vi­si­bi­li­tà di un’offerta web.

Il pre­re­qui­si­to è che tutte le in­for­ma­zio­ni rilevanti vengano con­tras­se­gna­te ade­gua­ta­men­te con il lin­guag­gio di markup. Con il tempo la community Internet ha svi­lup­pa­to diversi standard per la strut­tu­ra­zio­ne dei dati. Quindi vi in­di­chia­mo perché dovreste preferire JSON-LD agli altri formati di dati al­ter­na­ti­vi, come i mi­cro­for­ma­ti, RDFa o i microdati.

JSON-LD è un metodo basato sul formato JSON che serve per l’in­te­gra­zio­ne dei dati strut­tu­ra­ti in un sito web. Con­tra­ria­men­te agli altri formati per la strut­tu­ra­zio­ne dei dati come i mi­cro­for­ma­ti, RDFa e i microdati, la se­gna­la­zio­ne non avviene come un’an­no­ta­zio­ne del codice sorgente, ma i metadati vengono im­ple­men­ta­ti sotto forma di un tag script separati dal contenuto del sito nell’elemento head o im­ple­men­ta­ti all’interno del body del documento HTML. Così JSON-LD si serve dell’an­no­ta­zio­ne JSON e la amplia di una sintassi con cui i dati si possono segnalare secondo uno schema uni­ver­sa­le e uniforme a livello globale.

La spe­ci­fi­ca­zio­ne JSON-LD è stata creata dal fondatore di Digital Bazaar, Manu Sporny, e dal 16 gennaio 2014 è con­si­glia­ta uf­fi­cial­men­te dal W3C.

L’acronimo JSON sta per Ja­va­Script Object Notation e indica un formato compatto basato sul testo per lo scambio di dati, facile da elaborare sia per gli esseri umani che per le macchine. Il formato JSON deriva da Ja­va­Script, ma si può uti­liz­za­re in­di­pen­den­te­men­te dal lin­guag­gio di pro­gram­ma­zio­ne su qualsiasi piat­ta­for­ma. Come formato dati per la se­ria­liz­za­zio­ne, cioè la ri­pro­du­zio­ne di oggetti pro­gram­ma­bi­li sotto forma di rap­pre­sen­ta­zio­ne se­quen­zia­le, JSON viene usato per la tra­spo­si­zio­ne e la me­mo­riz­za­zio­ne dei dati strut­tu­ra­ti nelle ap­pli­ca­zio­ni web e nelle app Mobile.

La sintassi di un oggetto JSON è es­sen­zial­men­te co­sti­tui­ta da coppie di nomi e valori (name-value pairs), che (ad eccezione dei valori numerici) sono racchiuse tra vir­go­let­te e vengono annotate se­pa­ra­ta­men­te da un doppio punto. Ogni coppia nome-valore comincia so­li­ta­men­te in una nuova riga e finisce con una virgola. L’unica eccezione è rap­pre­sen­ta­ta dall’ultima coppia nome-valore prima della parantesi graffa con­clu­si­va, che viene annotata senza virgola.

Il seguente esempio chiarisce lo schema di base della sintassi JSON:

In questa parte di testo si trova la coppia di parole “Manu Sporny”: un lettore in carne e ossa com­pren­de­rà subito per via del contesto che con questa sequenza di lettere viene indicato un nome e che viene inserito un link al sito dello svi­lup­pa­to­re di JSON-LD. Invece i programmi come browser e crawler hanno bisogno dei metadati per fare questa as­so­cia­zio­ne, possibile proprio ri­cor­ren­do a JSON.

Il codice di esempio indica entrambi gli elementi del nome “name“ e “homepage” con i loro ri­spet­ti­vi valori. Un programma, che scansiona una pagina web con questo oggetto JSON, è quindi in grado di iden­ti­fi­ca­re “Manu Sporny” come nome e “http://manu.sporny.org/about/” come homepage. 

Il markup con JSON funziona senza problemi all’interno di un sito, ma l’analisi dei dati con questo formato su diversi siti può portare a delle ambiguità. Di solito i programmi ana­liz­za­no molte pagine e valutano le in­for­ma­zio­ni raccolte nei database. Con­si­de­ran­do il codice sopra, non si può garantire che gli elementi “name” e “homepage” man­ten­ga­no sempre lo stesso valore su siti diversi. Quindi, per evitare ambiguità, il formato JSON-LD aggiunge alla classica an­no­ta­zio­ne JSON degli elementi di supporto al contesto, sulla base di Linked Data. Per essere più precisi si tratta di dati di­spo­ni­bi­li li­be­ra­men­te su Internet, che possono essere ri­chia­ma­ti tramite Uniform Resource Iden­ti­fier (URI).

Il seguente video di Manu Sporny, lo svi­lup­pa­to­re di JSON-LD, fornisce ulteriori in­for­ma­zio­ni sui Linked Data:

Per preparare JSON per i Linked Data, JSON-LD aggiunge le classiche coppie nome-valore dell’an­no­ta­zio­ne JSON tramite keyword (parole chiave), in­tro­dot­te dal simbolo @ anteposto. Sono molto im­por­tan­ti le keyword @context e @type. Mentre @context definisce il markup del vo­ca­bo­la­rio alla base, @type indica di quale tipo di dati (schema) si tratti.

Un database stan­dar­diz­za­to per la strut­tu­ra­zio­ne dei dati è fornito dal progetto schema.org. Sull’omonimo sito del progetto i gestori dei siti trovano diversi schemi di dati (types), oltre che queste “pro­per­ties“ (ca­rat­te­ri­sti­che) assegnate a questo tipo di dati, che con­sen­to­no un markup semantico det­ta­glia­to dei contenuti web.

Aggiunto con i ri­spet­ti­vi elementi di contesto, per l’esempio in­tro­dot­to sopra risulta il seguente codice:

La keyword @context nella riga 2 definisce il vo­ca­bo­la­rio alla base del markup semantico, che è in questo caso schema.org. Nella riga 3 viene in­tro­dot­to il tipo di dati “Person” ri­cor­ren­do alla keyword @type. Questo tipo di dati viene meglio spe­ci­fi­ca­to nelle righe 4 e 5 tramite le proprietà “name“ e “url“. Un programma, che analizza questo codice di esempio, può iden­ti­fi­ca­re così l’elemento testuale con­tras­se­gna­to come “name”, cioè “Manu Sporny”, ovvero il nome di una persona in base al tipo di dati “Person” ri­cor­ren­do a Schema.org. Le coppie di nomi e valori in­tro­dot­te con “name” e “URL” vengono elaborate come proprietà (pro­per­ties) dello schema “Person”. A stabilire quali proprietà si possano assegnare a uno schema è il vo­ca­bo­la­rio di base.

Su JSON-LD l’as­se­gna­zio­ne di schemi e proprietà per il markup semantico dei contenuti web avviene in maniera analoga agli altri formati. Se con­ver­ti­to in un’an­no­ta­zio­ne del codice sorgente, lo script di esempio in­tro­dot­to sopra si può mettere in evidenza anche tramite microdati e RDFa basati su Schema.org, senza rischiare di incorrere in una perdita di in­for­ma­zio­ni.

Sintassi dei microdati in base a Schema.org:

Sintassi RDFa in base a schema.org:

Rispetto agli altri formati con­cor­ren­ti, JSON-LD ha il vantaggio che i metadati non devono essere di­ret­ta­men­te integrati nel codice HTML, ma possono essere im­ple­men­ta­ti se­pa­ra­ta­men­te in un qualsiasi punto. Ciò è possibile grazie al tag <script> ri­cor­ren­do allo schema seguente:

Ri­fe­ren­do­si all’esempio in­tro­dot­to sopra ne emerge il seguente markup basato su schema.org:

La di­stin­zio­ne netta tra HTML e an­no­ta­zio­ne semantica non punta solo a una migliore leg­gi­bi­li­tà del codice sorgente, infatti un’im­ple­men­ta­zio­ne di questo tipo consente una ge­ne­ra­zio­ne dinamica dei dati strut­tu­ra­ti, in­di­pen­den­te­men­te dai contenuti visibili agli utenti. Con il formato JSON-LD i metadati possono essere gestiti dal back end, scan­sio­na­ti da un database e venir generati au­to­ma­ti­ca­men­te tramite template. Così è possibile una pratica an­no­ta­zio­ne semantica, anche per i contenuti dinamici che ac­qui­sta­no sempre più im­por­tan­za in rete.

Da giugno 2013 il progetto schema.org ha indicato JSON-LD come uno dei formati preferiti in assoluto e anche Google consiglia (se possibile) l'in­te­gra­zio­ne dei metadati basati su script tramite JSON-LD. Un markup di questo tipo rap­pre­sen­ta la base per diversi elementi della SERP che il motore di ricerca utilizza per pre­sen­ta­re agli utenti dei risultati di ricerca ampliati.

Google utilizza diverse forme di rap­pre­sen­ta­zio­ne per i risultati di ricerca: oltre ai Basic Results (i risultati di ricerca classici), da alcuni anni agli utenti vengono anche mostrati, a seconda della richiesta ef­fet­tua­ta, Featured Results e Knowledge Graph Results. Mentre i Basic Results a volte pre­sen­ta­no solo dei semplici am­plia­men­ti, come brea­d­crumbs, i Featured Results e i Knowledge Graph Results offrono po­ten­zial­men­te delle esten­sio­ni complete, chiamate da Google anche En­han­ce­men­ts o Search Result Features.

Al momento Google supporta il markup JSON-LD per le seguenti esten­sio­ni. Il motore di ricerca mette a di­spo­si­zio­ne per ogni Search Result Feature un esempio nella Search Gallery al­l'in­di­riz­zo de­ve­lo­pers.google.com.

• Brea­d­crumbs: questo tipo di na­vi­ga­zio­ne, chiamata brea­d­crumbs, indica la posizione della pagina web corrente nella gerarchia del sito. I gestori dei siti che segnalano se­man­ti­ca­men­te i brea­d­crumbs con­sen­to­no a Google di mostrarli nelle SERPs. I brea­d­crumbs rientrano tra le poche Search Results Features che Google fa comparire anche nei Basic Results.
• In­for­ma­zio­ni di contatto del­l'a­zien­da: se le in­for­ma­zio­ni di contatto del­l'a­zien­da sono state con­tras­se­gna­te se­man­ti­ca­men­te, Google può mostrarle nelle SERPs come Knowledge Graph Display, una forma di rap­pre­sen­ta­zio­ne del­l'al­go­rit­mo di Knowledge Graph.
• Loghi: con un markup del logo i gestori dei siti chia­ri­sco­no quale grafica deve uti­liz­za­re il motore di ricerca come logo del­l'a­zien­da, così Google amplia i risultati di ricerca della relativa azienda con il logo ap­pro­pria­to.
• Sitelinks Searchbox: Se un sito mette a di­spo­si­zio­ne una funzione di ricerca ed è stata segnalata se­man­ti­ca­men­te, Google mostra i risultati del sito anche con una Sitelinks Searchbox.
• Link ai profili social: se viene uti­liz­za­to un markup per i link ai profili dei social media, Google amplia il Knowledge Graph Display alle persone o alle or­ga­niz­za­zio­ni con i relativi pulsanti. Al momento Google supporta un markup con JSON-LD per Facebook, Twitter, Google+, Instagram, YouTube, LinkedIn, Myspace, Pinterest, Soun­d­Cloud e Tumblr.

I gestori di siti che vogliono po­si­zio­na­re i loro contenuti in maniera ben visibile nelle SERPs di Google hanno la pos­si­bi­li­tà di segnalare se­man­ti­ca­men­te i diversi tipi di dati. In questo caso bisogna fare at­ten­zio­ne al fatto che Google è il solo che sta­bi­li­sce se un risultato venga mostrato come Basic Result o con delle esten­sio­ni. Per ora Google supporta il markup JSON-LD per i seguenti tipi di dati e li utilizza per pre­sen­ta­re le in­for­ma­zio­ni sotto forma di Rich Search Results, Enriched Search Results o Knowledge Graph Results.

• Articolo: i gestori di siti che con­tras­se­gna­no se­man­ti­ca­men­te gli articoli dei blog o di news con­sen­to­no a Google di inserirli nel carosello tra le top stories o di ag­giun­ger­le nelle SERPs con Search Result Features, come titoli o immagini di anteprima.
• Libri: se i gestori dei siti offrono un markup JSON-LD per le in­for­ma­zio­ni che si ri­fe­ri­sco­no ai libri, Google crea una Knowledge Graph Card per le richieste rilevanti che non contiene solo in­for­ma­zio­ni esaustive sul libro, ma consente agli utenti anche l'ac­qui­sto di­ret­ta­men­te sul motore di ricerca, se richiesto.
• Musica (in­for­ma­zio­ni su musicisti e album): in modo analogo alle in­for­ma­zio­ni sui libri si possono annotare anche le offerte di musica. Ciò consente a Google di generare le Knowledge Graph Cards per contenuti musicali, così gli utenti non ricevono solo in­for­ma­zio­ni su album e musicisti, bensì hanno anche la pos­si­bi­li­tà di in­te­ra­gi­re con il contenuto, infatti possono ascoltare o ac­qui­sta­re la musica.
• Corsi: ai gestori dei siti che segnalano i corsi (ad esempio corsi di lingua) con un markup JSON-LD che consente di rilevare au­to­ma­ti­ca­men­te il titolo, una breve de­scri­zio­ne e l'or­ga­niz­za­to­re, Google dà la pos­si­bi­li­tà di mostrare queste in­for­ma­zio­ni come risultati di ricerca ampliati nelle SERPs.
• Eventi: gli or­ga­niz­za­to­ri degli eventi pubblici, come concerti e festival, hanno la pos­si­bi­li­tà di annotare in­for­ma­zio­ni rilevanti (ad esempio il luogo, la data e l'ora del­l'e­ven­to) tramite JSON-LD, di modo che Google estragga au­to­ma­ti­ca­men­te queste in­for­ma­zio­ni e le elenchi nelle SERPs o le possa indicare in altri servizi di Google, come Maps.
• Annunci di lavoro: anche le offerte di lavoro che gli or­ga­niz­za­to­ri pub­bli­ca­no sul loro sito si possono con­tras­se­gna­re, così che Google possa scan­sio­na­re le in­for­ma­zio­ni rilevanti per i risultati di ricerca ampliati.
• Im­mis­sio­ne di fornitori locali: i fornitori locali che uti­liz­za­no i dati strut­tu­ra­ti per il sito del loro negozio o il loro ri­sto­ran­te con­sen­to­no a Google di creare Knowledge Graph Cards, che vengono mostrate nei risultati di ricerca rilevanti nelle SERPs o su Google Maps. Se ad esempio un utente cerca un ri­sto­ran­te viet­na­mi­ta, Google attiva un carosello con i fornitori ap­pro­pria­ti che si trovano nei paraggi.
• Set di dati: anche set di dati come tabelle CSV o file in formati pro­prie­ta­ri si possono rendere ac­ces­si­bi­li per il motore di ricerca tramite il markup con JSON-LD.
• Podcast: Google supporta un markup con JSON-LD per le in­for­ma­zio­ni podcast. Le offerte con­tras­se­gna­te in modo ap­pro­pria­to possono essere indicate e attivate di­ret­ta­men­te nel motore di ricerca.
• Video: i fornitori di contenuti che mettono a di­spo­si­zio­ne i dati strut­tu­ra­ti per i video sul loro sito, come una de­scri­zio­ne, un link a un'im­ma­gi­ne di anteprima, la data di upload o la durata, con­sen­to­no a Google di estrarre queste in­for­ma­zio­ni e di attivarle come Rich Cards o sotto forma di carosello nelle SERPs.
• Film e show: se un sito presenta dei dati strut­tu­ra­ti per film e show, Google li riproduce nelle richieste cor­ri­spon­den­ti come Knowledge Graph Card sulle SERPs. Se ne­ces­sa­rio, si possono ampliare con elementi in­te­rat­ti­vi che con­sen­to­no di usufruire dell’offerta o di ac­qui­star­la.
• Ricette: da alcuni anni Google offre anche le ricette di cucina come Featured Result nel motore di ricerca. Il requisito è che chi mette a di­spo­si­zio­ne i contenuti inserisca tutte le in­for­ma­zio­ni rilevanti sulla ricetta sotto forma di dati strut­tu­ra­ti. Una possibile rap­pre­sen­ta­zio­ne nelle SERPs è un carosello con le ap­pro­pria­te Rich Cards in risposta alla richiesta ef­fet­tua­ta.
• Va­lu­ta­zio­ni: Google supporta le va­lu­ta­zio­ni per diversi tipi di dati basati su schema.org, come negozi locali, ri­sto­ran­ti, prodotti, libri, film o lavori creativi. La rap­pre­sen­ta­zio­ne dei relativi contenuti avviene tramite snippet. Qui Google distingue tra critiche dei singoli autori e post sui portali di re­cen­sio­ne. Se è presente un'an­no­ta­zio­ne semantica, entrambi i tipi di va­lu­ta­zio­ne vengono vi­sua­liz­za­ti nelle richieste cor­ri­spon­den­ti come Featured Results nelle SERPs.
• Prodotti: i com­mer­cian­ti online che mettono a di­spo­si­zio­ne sul loro sito in­for­ma­zio­ni dei prodotti come prezzi, di­spo­ni­bi­li­tà o va­lu­ta­zio­ni come dati strut­tu­ra­ti, con­sen­to­no a Google di far comparire queste in­for­ma­zio­ni nelle relative richieste come Rich Search Results.

I risultati di ricerca avanzati, in­di­pen­den­te­men­te dal fatto che si tratti di Featured Results o Knowledge Graph Displays, sono van­tag­gio­si per i gestori dei siti so­prat­tut­to per un motivo: risaltano nei risultati di ricerca nelle SERPs rispetto a quelli di altri siti.

Google presenta i risultati display e a carosello per i Featured Results nel punto pre­di­spo­sto sopra i Basic Results e quindi nella posizione zero. I Knowledge Graph Displays compaiono sia come carosello sul lato superiore della pagina che sulla destra de­li­mi­ta­ti da una cornice, accanto alla ricerca organica. I risultati di ricerca ampliati offrono ai gestori dei siti la pos­si­bi­li­tà di con­qui­sta­re così le prime posizioni delle SERPs, senza che debba essere investito tempo e denaro per mi­glio­ra­re il ranking organico.

Ma non è solo una posizione di primo piano a ri­sve­glia­re l'at­ten­zio­ne degli utenti e a in­vo­gliar­li a cliccare, con­tri­bui­sco­no a tal proposito anche i diversi am­plia­men­ti come immagini di anteprima, va­lu­ta­zio­ni, parti di testo ed elementi in­te­rat­ti­vi. I gestori dei siti possono partire dal pre­sup­po­sto che la Click Through Rate aumenti no­te­vol­men­te nei risultati ampliati rispetto a quella dei Basic Results.

Inoltre ai risultati di ricerca ampliati viene at­tri­bui­to un effetto positivo sulla frequenza di rimbalzo. A dif­fe­ren­za dei Basic Results, che com­pren­do­no so­li­ta­men­te solo i meta title, un URL e una breve de­scri­zio­ne, i risultati di ricerca ampliati danno agli utenti un'im­pres­sio­ne completa di quali contenuti si debbano aspettare dal link al sito collegato. Quindi un utente può ve­ri­fi­ca­re la rilevanza di un sito in relazione alla propria ricerca ancora prima di aprire la pagina e cliccarvi sopra solo se attinente alle sue aspet­ta­ti­ve.

Google non pri­vi­le­gia però come fattore di ranking la presenza o la mancanza di un markup semantico tramite JSON-LD, come già nel 2012 chiariva Matt Cutts, l'ex capo del team del web spam di Google, nel seguente video YouTube della serie di Google Web­ma­sters:

Come per il suo utilizzo, anche nel­l'in­di­ciz­za­zio­ne JSON-LD punta alla me­mo­riz­za­zio­ne del markup in parti di script separati. Rispetto alle an­no­ta­zio­ni al­ter­na­ti­ve, come i microdati o RDFa, JSON-LD consente, malgrado l'an­no­ta­zio­ne semantica, un codice sorgente leggero, che può essere ana­liz­za­to e in­di­ciz­za­to fa­cil­men­te dal Google bot e dagli altri crawler.

Tuttavia la me­mo­riz­za­zio­ne separata dei dati strut­tu­ra­ti presenta anche degli svantaggi. Es­sen­zial­men­te su Google e gli altri motori di ricerca vale la regola che devono essere con­tras­se­gna­ti i contenuti che devono leggere le macchine e che sono a di­spo­si­zio­ne dei vi­si­ta­to­ri in carne e ossa delle pagine. Però teo­ri­ca­men­te con JSON-LD si può im­ple­men­ta­re un qualsiasi markup, anche quando per i metadati indicati non c'è nessuna cor­ri­spon­den­za nel contenuto del sito vero e proprio. In questo caso sia al motore di ricerca sia al­l'u­ten­te viene at­tri­bui­to un possibile valore aggiunto che un sito abbellito in una maniera simile non offre. In altri termini sarebbe meglio tenersi alla larga da un pro­ce­di­men­to del genere, al­tri­men­ti i gestori del sito corrono il rischio di essere pe­na­liz­za­ti per via di azioni spam.

Per evitare che i webmaster superino inav­ver­ti­ta­men­te i limiti del­l'an­no­ta­zio­ne semantica conforme ai motori di ricerca, Google offre delle linee guida generali per i dati strut­tu­ra­ti, ovvero un re­go­la­men­to esaustivo che si può rias­su­me­re es­sen­zial­men­te nei seguenti punti:

• Formato: i dati strut­tu­ra­ti devono essere in uno dei tre formati affermati, cioè microdati, RDFa o JSON-LD. Google consiglia quest’ultimo.
• Ac­ces­si­bi­li­tà: le pagine con i dati strut­tu­ra­ti devono essere ac­ces­si­bi­li per il Google bot. I metodi di Access Control (ad esempio tramite robot.txt o l'at­tri­bu­to noindex) im­pe­di­sco­no la scansione dei metadati.
• Equi­va­len­za del contenuto: il markup JSON-LD può de­scri­ve­re solo entità che possono anche essere descritte nel codice HTML.
• Rilevanza: un markup JSON-LD dovrebbe riferirsi solo alle cor­ri­spon­den­ze rilevanti dei tipi di dati uti­liz­za­ti. Un gestore del sito che con­tras­se­gna delle istru­zio­ni tecniche come una ricetta infrange, ad esempio, il criterio della rilevanza.
• Com­ple­tez­za: tutti i tipi di dati (types) pre­sen­ta­ti nel markup JSON-LD devono essere completi e com­pren­si­vi della se­gna­la­zio­ne delle proprietà (pro­per­ties) richieste. I tipi di dati in cui mancano delle proprietà es­sen­zia­li non si adattano per i risultati di ricerca ampliati.
• Spe­ci­fi­ci­tà: i progetti di Linked Data, come schema.org, offrono una mol­te­pli­ci­tà di tipi di dati. Per qua­li­fi­ca­re i propri contenuti per una rap­pre­sen­ta­zio­ne dei risultati di ricerca ampliati, i gestori do­vreb­be­ro scegliere degli schemi i più specifici possibili.

Di seguito vi mostriamo con un esempio come potete ar­ric­chi­re il vostro sito nella maniera più ef­fi­cien­te possibile con i metadati rilevanti. Alla base di questo tutorial JSON-LD si trova il vo­ca­bo­la­rio del progetto schema.org.

L’im­ple­men­ta­zio­ne dei dati strut­tu­ra­ti è collegata con un certo tipo di impegno a seconda della com­ples­si­tà del progetto web. Ri­flet­te­te quindi pre­li­mi­nar­men­te su quali obiettivi volete rag­giun­ge­re con il markup semantico e quante ore di lavoro volete investire nell’an­no­ta­zio­ne.

So­li­ta­men­te un markup deve strut­tu­ra­re le in­for­ma­zio­ni del sito e offrirle in una forma leggibile per i motori di ricerca. L’obiettivo è quello di di­mo­stra­re a Google e agli altri motori di ricerca che un sito ot­ti­miz­za­to in questa maniera mette a di­spo­si­zio­ne le migliori risorse per le richieste rilevanti sul tema. Ponetevi perciò le seguenti domande:

• Quali sono i contenuti prin­ci­pa­li del vostro sito?
• Quale valore aggiunto offrono ai po­ten­zia­li vi­si­ta­to­ri?
• Quali contenuti sono così rilevanti per il tema prin­ci­pa­le del vostro sito, tanto da dover essere segnalati nel modo migliore per i motori di ricerca?

Create una lista di tutti i contenuti che offrono un valore aggiunto. Decidete su quali contenuti dovrebbe ricadere l’at­ten­zio­ne dei po­ten­zia­li vi­si­ta­to­ri già dalle SERPs.

Ad esempio Google consiglia un markup con JSON-LD per le in­for­ma­zio­ni che ri­guar­da­no gli eventi (events). Nell’HTML si possono pre­sen­ta­re le in­for­ma­zio­ni dell’evento per concerti, musical o rap­pre­sen­ta­zio­ni teatrali, seguendo ad esempio questo schema:

In­for­ma­zio­ni tipiche del tipo di dati “Event“ sono la data e l’ora, il prezzo, la di­spo­ni­bi­li­tà dei biglietti, l’indirizzo del luogo degli eventi, così come i link alle in­for­ma­zio­ni ag­giun­ti­ve sull’evento o sul luogo dello stesso. I vi­si­ta­to­ri reali sono in grado di desumere queste in­for­ma­zio­ni da una porzione di testo, da una tabella o da altre forme di rap­pre­sen­ta­zio­ne e as­se­gnar­le alla cor­ri­spon­den­te cor­re­la­zio­ne. I programmi come i crawler, invece, hanno bisogno di metadati che com­pren­do­no direttive su come vadano elaborate le in­for­ma­zio­ni offerte. JSON-LD li offre sotto forma di formati dati, che vengono aggiunti se­pa­ra­ta­men­te dal contenuto in un qualsiasi punto del codice sorgente HTML.

Schema.org mette a di­spo­si­zio­ne le regole generali su come rea­liz­za­re un markup con JSON-LD e su come in­te­grar­lo nel vostro sito.

Schema.org offre ai gestori di siti un vo­ca­bo­la­rio completo per la strut­tu­ra­zio­ne dei dati. Com­ples­si­va­men­te il database comprende quasi 600 tipi, che si possono spe­ci­fi­ca­re meglio con più di 860 proprietà.

Per la scelta dei tipi di dati adeguati è possibile valutare due strategie:

1. Teo­ri­ca­men­te siete liberi di con­fron­ta­re i contenuti stabiliti prima con i tipi di dati messi a di­spo­si­zio­ne dal vo­ca­bo­la­rio di schema.org e se­le­zio­na­re ri­spet­ti­va­men­te il tipo di dati specifico per il ri­spet­ti­vo elemento del content. Un simile pro­ce­di­men­to è lungo e ge­ne­ral­men­te inutile.
2. In pratica i gestori dei siti si limitano per la maggior parte a un sot­toin­sie­me dei tipi di dati di schema.org: se ri­cor­ren­do al markup con JSON-LD per­se­gui­te solo lo scopo di mettere a di­spo­si­zio­ne del motore di ricerca i dati strut­tu­ra­ti, basta prima di tutto limitarsi ai tipi di dati che sono at­tual­men­te sup­por­ta­ti da Google e descritti esau­rien­te­men­te nella sezione Google Developer.

Vi con­si­glia­mo la strategia “b” per il seguente motivo: Google mette a di­spo­si­zio­ne una do­cu­men­ta­zio­ne esau­rien­te per tutti i tipi di dati sup­por­ta­ti dal motore di ricerca. Per ogni tipo di dati viene indicato un markup di esempio.

Per inserire i dati strut­tu­ra­ti nel vostro sito, non dovete fare nulla di così com­pli­ca­to. Anche se non avete alcuna espe­rien­za con la sintassi di JSON-LD, ri­spar­mia­te tempo ed energia ri­cor­ren­do agli schemi già pronti, al posto di ri­scri­ve­re di nuovo da zero il markup per ogni tipo di dati.

Nella do­cu­men­ta­zio­ne di Google i gestori dei siti trovano il seguente esempio di markup per gli eventi:

I tag script de­fi­ni­sco­no l’elemento dalla riga 01 a quella 39 come script del tipo “ap­pli­ca­tion/ld+json“. Le in­for­ma­zio­ni suc­ces­si­ve si orientano così a programmi che sono in grado di scan­sio­na­re i Linked Data nel formato JSON.

Sul primo livello si trovano le parole chiave “@context“ e “@type“ con i valori “http://schema.org” e “Event” (Righe 03 e 04). Un programma di parsing riceve l’istru­zio­ne che le seguenti in­for­ma­zio­ni sono da at­tri­bui­re allo schema “Event” in base a schema.org; si tratta così di spe­ci­fi­che proprietà dell’evento descritto, rap­pre­sen­ta­te sotto forma di coppie nome-valore.

Sempre sul primo livello si trovano le proprietà “name“, “startDate“, “location“, “image“, “de­scrip­tion“, “enddate“, “offers“ e “performer“ alle quali sono assegnate come valori le ri­spet­ti­ve in­for­ma­zio­ni dell’evento. Un crawler può così iden­ti­fi­ca­re senza alcun dubbio l’in­for­ma­zio­ne “Jan Lieberman Concert Series: Journey in Jazz“ come titolo dell’evento (name) e “2017-04-24T19:30-08:00“ come punto di inizio esatto (StartDate).

Ana­lo­ga­men­te a RDFa e microdati anche la sintassi JSON-LD supporta gli an­ni­da­men­ti (nesting). Così non viene assegnato alcun valore a una proprietà, bensì un (sotto)schema che può essere di nuovo spe­ci­fi­ca­to meglio con proprietà spe­ci­fi­che. Un caso di questo tipo si trova sul secondo livello del codice di esempio nelle righe 08, 27 e 35.

Ad esempio nella riga 08 viene definita la proprietà Event “location” come (sotto)schema del tipo “Place” e dotato delle proprietà “name” e “address”. La proprietà “address” viene definita di nuovo nella riga 11 come (sotto)schema del tipo “Po­sta­lAd­dress” e segnalato a sua volta con le proprietà, spe­ci­fi­che dello schema, “stree­tAd­dress“, “ad­dres­sLo­ca­li­ty“, “po­stal­Co­de“, “ad­dres­sRe­gion“ e “ad­dres­sCoun­try“.

Ogni livello annidato viene racchiuso tra parentesi graffe e de­li­mi­ta­to così dal livello so­vraor­di­na­to.

Parte di codice (righe da 07 fino a 18)

Schema.org mette così a di­spo­si­zio­ne dei gestori dei siti i tipi di dati sotto forma di una struttura ad albero ge­rar­chi­ca, che diventa sempre più specifica a partire dal tipo di dati più generale “Thing” (cosa).

Nel paragrafo seguente vi in­di­chia­mo come potete adattare l’esempio di Google al tipo di dati “Event” con le in­for­ma­zio­ni dell’evento pre­sen­ta­te sopra.

La do­cu­men­ta­zio­ne di Google comprende solo esempi che mostrano come i tipi di dati pre­sen­ta­ti si possano segnalare tramite JSON-LD. Se vengono uti­liz­za­ti come modelli per un proprio markup di metadati, il codice deve essere in ogni caso adattato in­di­vi­dual­men­te. In alcune cir­co­stan­ze è utile ricorrere alla do­cu­men­ta­zio­ne di schema.org per il ri­spet­ti­vo tipo di dati, per saperne di più sull’uso di un preciso schema e delle possibili proprietà. Il seguente esempio indica una per­so­na­liz­za­zio­ne del codice di esempio di Google per il tipo di dati Event:

Nel primo passaggio abbiamo so­sti­tui­to tutti i valori del markup di esempio con i valori cor­ri­spon­den­ti delle in­for­ma­zio­ni dell’evento pre­sen­ta­te sopra. Così sono stati so­sti­tui­ti i (sotto)schemi non ap­pro­pria­ti e le relative proprietà. Ad esempio abbiamo tra­la­scia­to la proprietà “ad­dres­sRe­gion“, visto che questa in­di­ca­zio­ne non è così comune. Al posto di “Per­for­ming­Group” alla voce “performer” uti­liz­zia­mo il (sotto)schema “Person”, visto che non abbiamo a che fare con una band, ma con una persona singola. Infine abbiamo aggiunto le in­for­ma­zio­ni al markup che non erano state incluse nel modello di Google. Così si trovano nelle righe 07 e 10, ad esempio, gli URL all’evento o al luogo dello stesso. Se ne­ces­sa­rio, desumete delle possibili proprietà dalla do­cu­men­ta­zio­ne di schema.org.

Anche se create il markup con JSON-LD da zero, senza ricorrere ad alcun modello, dovreste con­trol­la­re il cor­ri­spet­ti­vo tipo di dati sulla pagina di do­cu­men­ta­zio­ne di Google. Qui il leader dei motori di ricerca indica per tutti i tipi di dati sup­por­ta­ti sia le proprietà ne­ces­sa­rie che quelle con­si­glia­te.

Gli esempi pre­sen­ta­ti nella do­cu­men­ta­zio­ne di Google com­pren­do­no sempre tutte le proprietà ne­ces­sa­rie e con­si­glia­te.

Se al vostro markup mancano delle proprietà im­por­tan­ti, testatele con il tool di va­li­da­zio­ne messo a di­spo­si­zio­ne da Google.

3. Create un’anteprima

Oltre alla funzione di test lo strumento di test di Google per i dati strut­tu­ra­ti mette a di­spo­si­zio­ne una modalità anteprima che dà ai webmaster un’idea di come potrebbe apparire un risultato di ricerca ampliato sulla base del markup testato e con­va­li­da­to.

Uti­liz­za­te sempre le pagine di do­cu­men­ta­zio­ne di schema.org e con­va­li­da­te il vostro codice JSON-LD grazie allo strumento di test per i dati strut­tu­ra­ti. Inoltre prestate at­ten­zio­ne alle linee guida generali dei dati strut­tu­ra­ti, oltre alle linee guide generali di Google Web­ma­sters per evitare di in­fran­ge­re le regole, cosa che potrebbe portare all’esclu­sio­ne dal ranking dei risultati di ricerca ampliati.