Dati strutturati e schema markup: parlare la lingua di Google

Immagina di porgere il menu di una trattoria pugliese a qualcuno che non ha mai visto la lingua italiana in vita sua. Riconoscerà che ci sono delle lettere, forse intuirà che si tratta di un elenco, ma non saprà mai dire quale riga è un piatto, quale un prezzo, quale un orario di apertura e quale il nome del proprietario. Vedrà del testo, non dei significati. Ecco, per quanto possa sembrare incredibile dopo decenni di progressi, è più o meno così che Google guarda una pagina web prima che qualcuno gli spieghi cosa sta leggendo.

Il motore è straordinariamente bravo a comprendere il linguaggio naturale, è vero. Ma “comprendere” e “sapere con certezza” non sono la stessa cosa. Davanti a una stringa come “49”, Google può intuire dal contesto che si tratti di un prezzo, di un’età, di un anno o del numero civico di una via, e nella maggior parte dei casi ci azzecca. Il punto è che intuire lascia sempre un margine di errore, e in un mondo dove la visibilità si gioca sui dettagli, quel margine costa caro. I dati strutturati nascono per eliminarlo: sono il modo con cui smettiamo di sperare che Google capisca e cominciamo a dirglielo, in modo esplicito e inequivocabile.

Cosa sono i dati strutturati (e perché Google ne ha bisogno)

I dati strutturati sono un linguaggio standardizzato con cui si etichetta il significato preciso degli elementi di una pagina. Invece di lasciare che sia l’algoritmo a indovinare, dichiariamo noi che quel numero è un prezzo, che quella stringa è un orario di apertura, che quel testo è una recensione con un certo punteggio in stelle, che quell’elenco è una sequenza di passaggi di una ricetta. È la differenza tra consegnare a un bibliotecario una pila disordinata di fogli e consegnargli gli stessi fogli già catalogati per autore, titolo e argomento: nel primo caso dovrà leggere tutto e tirare a indovinare, nel secondo sa esattamente dove mettere ogni cosa.

Il beneficio, per chi pubblica contenuti, è doppio e va in due direzioni opposte ma complementari. Da un lato i dati strutturati aiutano l’algoritmo a interpretare la pagina senza ambiguità, rafforzando la fiducia del motore nel contenuto e nella sua pertinenza rispetto a una ricerca. Dall’altro abilitano i cosiddetti risultati arricchiti, gli elementi visivi che trasformano un anonimo link blu in qualcosa che cattura l’occhio nella pagina dei risultati. In un’epoca in cui ogni frazione di attenzione conta, dichiarare con precisione cosa contiene una pagina non è più una raffinatezza tecnica: è una leva concreta di visibilità.

C’è poi un terzo motivo, più sottile e sempre più urgente, di cui parleremo più avanti. I contenuti, oggi, non devono essere comprensibili soltanto alle persone e ai motori di ricerca tradizionali, ma anche ai sistemi di intelligenza artificiale che sintetizzano risposte attingendo dal web. E per essere scelti come fonte da una macchina, bisogna prima di tutto essere leggibili da una macchina. I dati strutturati sono esattamente questo: contenuto reso leggibile dalle macchine.

schema.org e JSON-LD: il vocabolario e la grammatica

Perché tutto questo funzioni serve un linguaggio condiviso, altrimenti ognuno etichetterebbe i propri contenuti a modo suo e regnerebbe il caos. Questo linguaggio esiste, si chiama schema.org ed è un vocabolario nato dalla collaborazione tra i principali motori di ricerca — Google, Microsoft Bing, Yahoo e Yandex — proprio per parlare tutti la stessa lingua. Schema.org definisce centinaia di tipi di entità (un prodotto, un evento, una persona, un’azienda, un articolo, una ricetta) e le proprietà che li descrivono (il prezzo di un prodotto, la data di un evento, l’autore di un articolo). È un dizionario sterminato, in costante evoluzione, da cui si attinge il termine giusto per ogni occasione.

Se schema.org è il vocabolario, serve poi una grammatica per scriverlo all’interno delle pagine. Esistono tre modi tecnici per farlo — microdata, RDFa e JSON-LD — ma uno solo è oggi raccomandato da Google e ha vinto la partita sul campo: il JSON-LD. La sua forza sta nella separazione: invece di intrecciarsi al codice HTML visibile, come facevano i formati più vecchi, il JSON-LD vive in un blocco di codice a sé stante, di solito inserito nella sezione <head> della pagina. Questo lo rende molto più semplice da scrivere, da leggere e soprattutto da mantenere nel tempo, perché modificare i dati strutturati non significa più mettere le mani in mezzo al contenuto.

È proprio in questa fase che i dati strutturati rivelano la loro doppia natura, a metà strada tra editoria e ingegneria. Si pensano ragionando sul significato — cosa rappresenta davvero questa pagina, quali sono le sue entità, come vanno descritte — ma si implementano nel codice, ed è per questo che rientrano a pieno titolo nel territorio della SEO tecnica: vanno scritti correttamente, validati e gestiti come qualsiasi altra componente strutturale del sito, dove un errore di sintassi può rendere inutile l’intero sforzo.

I rich result: quando lo snippet si accende

Veniamo alla parte più visibile e gratificante, quella che si tocca con mano. Quando i dati strutturati sono implementati bene e Google li ritiene affidabili, lo snippet del sito nei risultati può “accendersi” e diventare un rich result, un risultato arricchito. Al posto del solito triplete di titolo, URL e descrizione compaiono elementi aggiuntivi: le stelle di una recensione, il prezzo e la disponibilità di un prodotto, le miniature di una ricetta, le domande espandibili di una sezione di approfondimento, le date di un evento, le briciole di pane della navigazione.

L’effetto è facile da immaginare. In una pagina di risultati affollata, dove dieci link si contendono lo stesso sguardo distratto, quello che mostra cinque stelline dorate o un prezzo in evidenza attira l’occhio prima degli altri e si guadagna il clic. Non è un vantaggio di posizionamento in senso stretto — un rich result non garantisce di salire in classifica — ma è un potente moltiplicatore del tasso di clic a parità di posizione. Conviene tenere a mente, però, una regola che Google ripete con insistenza: i rich result non sono mai garantiti. Si forniscono i dati corretti, e poi è il motore a decidere se, quando e come mostrarli. Il nostro compito è rendere la pagina degna e tecnicamente impeccabile; la decisione finale resta dall’altra parte.

I tipi che contano di più

Non tutti i tipi di schema servono a tutti. La scelta dipende dalla natura del sito e dei suoi contenuti, e concentrarsi su quelli giusti vale più che marcare tutto a tappeto. Un negozio online trae beneficio dai tipi dedicati ai prodotti, con prezzo, disponibilità e valutazione aggregata derivata dalle recensioni. Un sito editoriale o un blog lavora sul tipo che descrive gli articoli, indicando autore, data di pubblicazione e testata, segnali che rafforzano anche la percezione di affidabilità del contenuto.

Chi gestisce contenuti con domande e risposte può strutturarli per renderli espandibili direttamente nei risultati, guadagnando spazio prezioso nella pagina. Quasi ogni sito, infine, beneficia del tipo che descrive la navigazione a briciole di pane, che mostra il percorso gerarchico della pagina al posto del nudo URL, e di quello che descrive l’organizzazione o la persona dietro al sito, un tassello sempre più importante per costruire un’identità riconoscibile agli occhi di Google. Per un’attività che lavora su un territorio, poi, il tipo che descrive l’attività locale è semplicemente irrinunciabile: dichiara nome, indirizzo, telefono, orari e zona servita, gli stessi dati su cui si regge tutta la visibilità di prossimità.

Dati strutturati e GEO: farsi capire (e citare) dalle macchine

Qui arriviamo al motivo per cui i dati strutturati, da accessorio utile, sono diventati negli ultimi anni un investimento strategico. Il modo in cui le persone cercano informazioni è cambiato in profondità: accanto ai classici dieci link blu sono comparse le risposte sintetizzate dall’intelligenza artificiale, le panoramiche generative che si piazzano in cima ai risultati, e più in generale i chatbot e gli assistenti che confezionano risposte attingendo a fonti diverse. In questo scenario l’obiettivo non è più soltanto comparire tra i link, ma entrare dentro la risposta, come fonte citata e riconosciuta.

E indovina cosa rende un contenuto facile da estrarre, interpretare e citare per un sistema generativo? Esatto: l’essere strutturato in modo inequivocabile. Un’informazione etichettata con chiarezza — questo è un prezzo, questo è un autore, questo è un passaggio di una procedura — è infinitamente più facile da isolare e riutilizzare per una macchina rispetto allo stesso dato annegato in un paragrafo discorsivo. I dati strutturati non sono l’unico fattore che determina se un’intelligenza artificiale ti citerà, ma sono uno dei mattoni fondamentali su cui si costruisce questa nuova forma di visibilità. Detto altrimenti: nell’era delle risposte generative, rendere il contenuto leggibile dalle macchine è parte integrante del farsi trovare (e citare) sui motori di ricerca, non un di più da rimandare a tempi migliori.

Un esempio concreto rende l’idea meglio di qualsiasi spiegazione astratta. Immagina un’attività ricettiva che descriva i propri prezzi, gli orari di check-in e i servizi inclusi all’interno di un lungo paragrafo discorsivo: un lettore umano lo capisce senza fatica, ma una macchina deve sforzarsi di estrarre ogni singolo dato dal flusso del testo, con il rischio di sbagliare o di rinunciare. La stessa identica informazione, etichettata con i dati strutturati appropriati, diventa invece un insieme di campi netti e separati, pronti per essere prelevati e riutilizzati in una risposta sintetizzata. A parità di contenuto, la versione strutturata ha molte più probabilità di essere scelta come fonte. È una differenza invisibile all’occhio, ma enorme per chi quel contenuto deve interpretarlo a macchina.

La buona notizia, per chi teme l’ennesima rincorsa tecnologica, è che non si tratta di rifare tutto da capo. Le fondamenta che servono per posizionarsi bene nei risultati tradizionali — contenuti chiari, dati ordinati, struttura pulita — sono in larghissima parte le stesse che servono per farsi citare dalle intelligenze artificiali. I dati strutturati sono uno dei rari investimenti che lavorano contemporaneamente per il presente e per il futuro della ricerca.

Come si implementano nella pratica

A questo punto è lecito chiedersi quanto sia complicato, in concreto, mettere i dati strutturati su un sito. La risposta rassicurante è che, per la stragrande maggioranza dei casi, oggi non serve scrivere una sola riga di codice a mano. La maggior parte dei siti gira su sistemi di gestione dei contenuti come WordPress, e i principali plugin dedicati all’ottimizzazione generano automaticamente i tipi di schema più comuni — l’articolo, l’organizzazione, le briciole di pane della navigazione — senza alcun intervento manuale, popolandoli con i dati che già inseriamo normalmente quando pubblichiamo. È il punto di partenza ideale: copre le fondamenta con uno sforzo prossimo allo zero e mette al riparo dagli errori di sintassi più banali.

Per i tipi più specifici, però, spesso serve qualcosa in più. Marcare correttamente un prodotto con prezzo e disponibilità, una ricetta con i suoi passaggi, un evento con luogo e data, oppure un’attività locale con tutti i suoi dettagli, richiede di solito un plugin dedicato, un’impostazione apposita del tema o, nei casi più articolati, l’inserimento manuale del codice. Per produrlo senza partire da zero esistono i generatori, strumenti che permettono di compilare un modulo e ottenere il blocco JSON-LD già pronto da incollare nella pagina, oltre all’assistente ufficiale messo a disposizione da Google per i tipi più diffusi. Chi ha esigenze davvero su misura, infine, può sempre affidarsi a uno sviluppatore che scriva il markup a mano, ritagliandolo con precisione attorno al contenuto.

Qualunque sia la strada scelta, due principi non cambiano mai. Il primo è che i dati strutturati devono sempre rispecchiare ciò che è realmente visibile sulla pagina, perché lo strumento non aggiunge informazioni, le etichetta soltanto. Il secondo è di buon senso strategico: non conviene marcare tutto a tappeto fin dal primo giorno, ma partire dai tipi che corrispondono davvero alla natura del proprio sito e che hanno una concreta possibilità di generare risultati arricchiti, per poi ampliare gradualmente man mano che il contenuto cresce. Meglio pochi tipi implementati e validati alla perfezione che una decina abbozzati e mai controllati.

Errori da evitare e come validare il markup

Come ogni strumento potente, anche i dati strutturati si possono usare male, e alcuni errori non si limitano a essere inutili: sono attivamente dannosi. Il più grave, e purtroppo il più diffuso tra chi cerca scorciatoie, è marcare contenuti che non sono realmente presenti e visibili sulla pagina. Dichiarare recensioni a cinque stelle che l’utente non trova da nessuna parte, o strutturare informazioni inventate per gonfiare lo snippet, viola apertamente le linee guida di Google e può tradursi in un’azione manuale, cioè in una penalizzazione esplicita. La regola d’oro è semplice: i dati strutturati devono descrivere fedelmente ciò che è davvero sulla pagina, non ciò che vorremmo che ci fosse.

Altri errori sono meno gravi ma altrettanto frustranti, perché vanificano il lavoro in silenzio: scegliere il tipo di schema sbagliato per il contenuto, dimenticare le proprietà che Google considera obbligatorie per attivare un certo rich result, o commettere errori di sintassi che mandano in tilt l’intero blocco di codice. Per questo nessuna implementazione andrebbe mai data per buona senza una verifica. Esistono strumenti gratuiti e ufficiali pensati proprio per questo: il test dedicato ai risultati arricchiti, che dice se una pagina è idonea a generare rich result e quali, e il validatore generale del markup, che controlla la correttezza formale del codice secondo lo standard. A questi si affianca il monitoraggio nel tempo offerto dagli strumenti per i proprietari di siti, che segnalano gli eventuali errori rilevati sulle pagine già pubblicate. Vale la pena ripetere queste verifiche ogni volta che si modifica un modello di pagina o si aggiorna un plugin, perché un intervento apparentemente innocuo può rompere il markup senza alcun preavviso visibile.

La logica, in fondo, è la stessa che governa l’intera disciplina: non basta fare, bisogna verificare di aver fatto bene. Un dato strutturato scritto a metà o validato male è come un’etichetta attaccata storta sul barattolo sbagliato: peggiora la situazione invece di migliorarla. Implementati con cura e controllati con metodo, invece, i dati strutturati restano uno dei pochi interventi capaci di lavorare su tre fronti insieme — chiarezza per il motore, visibilità per l’utente, citabilità per l’intelligenza artificiale — con un rapporto tra fatica investita e ritorno ottenuto difficile da battere. Sono la prova che, a volte, il modo migliore per farsi capire da una macchina è semplicemente prendersi la briga di parlarle chiaro.