Dati strutturati: a cosa servono davvero ai motori di ricerca

Compra idoneità, e l'idoneità non è una promessa

Il modello mentale che causa più delusione è quello in cui il markup è una leva: aggiungi schema, ottieni una spinta. Non è così. I dati strutturati sono uno strato di traduzione. La tua pagina dice, in prosa pensata per una persona, che questo articolo è stato scritto da Camille Laurent il 18 agosto e aggiornato a settembre. Il markup dice la stessa cosa in una forma che un parser può leggere senza indovinare. Nulla di nuovo entra nella pagina; la macchina semplicemente smette di dover dedurre.

Ciò che quella traduzione compra è una cosa precisa e delimitata: l'idoneità a un rich result. Le linee guida di Google lo mettono in un avviso in evidenza — non garantisce che i tuoi dati strutturati compaiano nei risultati, anche se la pagina è marcata correttamente. Che la funzione venga disegnata dipende dalla query, dal dispositivo, dall'impaginazione di quella specifica pagina di risultati e dal fatto che Google si fidi abbastanza del tuo sito da renderizzarla. Un markup corretto ti porta da non idoneo a idoneo. Nulla in esso ti fa salire di una posizione.

La conferma più netta che markup e posizionamento sono sistemi separati arriva dal lato della sanzione. Google descrive un'azione manuale sui dati strutturati come qualcosa che fa perdere a una pagina l'idoneità a comparire come rich result, e precisa che non incide su come quella pagina si posiziona nella ricerca web. Due manopole indipendenti. Se il markup potesse spingere i posizionamenti verso l'alto, abusarne li spingerebbe verso il basso — e la sanzione documentata non fa nulla del genere.

JSON-LD ha vinto, e la ragione è la manutenzione

Ci sono tre sintassi per mettere schema.org in una pagina. Microdata e RDFa si basano su attributi: si cospargono itemscope, itemprop e typeof sugli elementi HTML che già contengono i valori, così il markup vive dentro il markup. JSON-LD è un blocco autonomo, un tag script di tipo application/ld+json con un normale oggetto JSON, di solito messo nell'head o in fondo al body. Tutte e tre vengono analizzate. Google raccomanda JSON-LD per i dati strutturati se la configurazione del sito lo consente, e lo definisce la soluzione più facile da implementare e mantenere su larga scala.

La ragione non è l'eleganza, è l'accoppiamento. Il markup ad attributi è saldato al DOM: cambia il template, sposta il prezzo in un altro componente, lascia che un designer scambi uno span con un div, e l'itemprop se ne va con lui o sparisce in silenzio. JSON-LD è del tutto disaccoppiato dalla presentazione, quindi sopravvive ai restyling, può essere assemblato lato server dagli stessi dati che rendono la pagina, e si rilegge in una pull request come un unico oggetto leggibile invece che come quindici attributi sparsi. Quel disaccoppiamento è anche il suo pericolo, ed è esattamente l'oggetto della sezione dopo la prossima.

Quali tipi producono ancora qualcosa di visibile

È qui che la maggior parte dei consigli pubblicati si è guastata, quindi controlla la data di tutto ciò che leggi, questo compreso. Google mantiene una galleria dei tipi di dati strutturati che supporta, e quella galleria è l'unica autorità di cui fidarsi sulla questione. Oggi elenca Article, Breadcrumb, Product, Event, Recipe, Video, Job posting, Local business, Organization, Review snippet, Q&A, Dataset, Software app, Vacation rental, Discussion forum, Profile page e una manciata di altri. Due nomi che stavano su ogni checklist SEO non ci sono.

HowTo non c'è più. Google ha ritirato i rich result HowTo nel corso del 2023, prima da mobile e poi da desktop, e ha rimosso la documentazione. FAQPage è durato di più ma è sparito anche lui: da agosto 2023 è stato ristretto a siti governativi e sanitari noti e autorevoli, e il 7 maggio 2026 ha smesso di comparire del tutto. La documentazione di FAQPage è stata rimossa il 15 giugno 2026, e la reportistica collegata — il filtro di aspetto nei risultati, il rapporto sui rich result, il supporto nel test dei risultati avanzati — è andata dietro. Se una checklist ti dice di aggiungere schema FAQ per guadagnare spazio nel risultato, quella checklist è vecchia di almeno un anno e probabilmente di tre.

Questo non rende il markup inutile, e non significa che tu debba strapparlo via. La posizione di Google sulle funzioni ritirate è che non serve rimuoverle, perché altri motori e servizi potrebbero ancora usarle. Schema.org è un vocabolario condiviso, non un prodotto Google: assistenti, aggregatori, altri motori e un numero crescente di catene di recupero dei modelli linguistici analizzano lo stesso JSON. La formulazione onesta è che FAQPage e HowTo sono passati da un ritorno visibile e misurabile a uno speculativo — il che cambia davvero quanto tempo di ingegneria meritano.

Obbligatorio contro consigliato, per i tre che rendono ancora

Article è il caso sorprendente: non ha alcuna proprietà obbligatoria. Google consiglia di aggiungere le proprietà che si applicano al tuo contenuto, e cita author, datePublished, dateModified, headline e image come consigliate. Non è un permesso per saltarle. Una proprietà consigliata è una la cui assenza non invalida l'oggetto ma riduce ciò che un consumatore può farne — un Article senza author è un Article che a valle non può reggere alcuna firma. Fornisci quelle che puoi fornire con esattezza, e il consiglio di Google è preferire poche proprietà consigliate complete e accurate a tutte le possibili compilate male.

BreadcrumbList è il più severo dei tre e il più economico da fare bene. Richiede itemListElement, un array ordinato di oggetti ListItem, e ogni ListItem richiede position e name. La proprietà item — l'URL a cui quella briciola punta — è obbligatoria su ogni voce tranne l'ultima, dove Google ripiega sull'URL della pagina corrente. La lista deve contenere almeno due ListItem per essere mostrata; una briciola sola non è un percorso. È il tipo con il miglior rapporto tra effetto visibile e sforzo di implementazione, perché scambia un URL brutto nel risultato con un percorso leggibile, e perché su un sito con struttura di URL disciplinata il percorso si genera dal path stesso.

Product sta nel mezzo. Per uno snippet di prodotto le proprietà obbligatorie sono name più almeno uno tra review, aggregateRating e offers — ne basta uno dei tre. In pratica è offers a guadagnarsi il posto, perché un prezzo e uno stato di disponibilità dentro il risultato rispondono alle due domande che un acquirente ha prima di cliccare. Nota l'avviso che il test dei risultati avanzati può sollevare se fornisci offers senza alcuna valutazione: è un avviso, non un errore, e inventare una valutazione per zittirlo è esattamente il comportamento di cui parla la prossima sezione.

La regola che decide tutto: marcare ciò che è visibile

Le linee guida di Google sui dati strutturati contengono un'istruzione che causa più azioni manuali di tutti gli errori tecnici messi insieme: non marcare contenuto che non sia visibile ai lettori della pagina. Sembra ovvio finché non noti quanto JSON-LD renda facile violarla. Il blocco vive separato dall'HTML, è generato da un template, non viene mai renderizzato — quindi nessuno nel team lo guarda mai affiancato alla pagina. È proprio per questo che va alla deriva.

Le modalità di fallimento sono banali, non malevole. Un template di prodotto emette aggregateRating da un campo di catalogo mentre la pagina non mostra recensioni perché non ne è stata ancora scritta nessuna. Una pagina prezzi renderizza un prezzo lato server dopo una conversione di valuta, ma il JSON-LD è stato costruito dal prezzo base e ora contraddice ciò che il visitatore legge. Un blocco articolo porta un dateModified che il CMS incrementa a ogni ripubblicazione mentre la pagina mostra la data originale. Ognuno di questi casi è markup che descrive qualcosa che il lettore non può verificare, e ognuno è la stessa violazione del falsificare deliberatamente cinque stelle.

La correzione ingegneristica sta in un principio: non costruire mai il JSON-LD da una seconda fonte di verità. Assemblalo esattamente dagli stessi oggetti che rendono la pagina visibile, nella stessa richiesta, così che un valore non possa comparire nell'uno e non nell'altro. Se il prezzo mostrato viene da una stringa formattata, ricava il prezzo del markup dal numero dietro quella stringa, non da una query separata. Poi aggiungi un test per template che verifichi che ogni valore marcato compaia da qualche parte nell'HTML renderizzato. Quel test intercetta la deriva del template il giorno in cui accade, invece che in un messaggio della Search Console tre mesi dopo.

Testare: tre strumenti, tre domande diverse

Il validatore di schema.org risponde alla domanda sul vocabolario: è schema.org valido, i tipi esistono, le proprietà sono scritte bene, gli oggetti annidati rientrano negli intervalli attesi. Di Google non sa nulla. Il test dei risultati avanzati risponde alla domanda di idoneità per Google in particolare: con questo markup, la pagina è idonea a una funzione che Google supporta oggi, e in caso contrario quale proprietà obbligatoria manca. I rapporti sui rich result della Search Console rispondono alla terza e più importante: che cosa sta succedendo sul sito in produzione, su scala, su tutti gli URL, dopo che il template è andato online.

Usali in quest'ordine e fermati al terzo. Il consiglio di Google è testare durante lo sviluppo e poi monitorare la validità dopo il rilascio, perché i problemi compaiono dopo la pubblicazione, per questioni di template e di erogazione che nessun controllo preventivo può vedere. Una pagina che ha passato il test dei risultati avanzati sul portatile di uno sviluppatore può fallire in produzione perché uno strato di cache toglie il tag script, perché un banner di consenso ritarda il rendering oltre il punto in cui il crawler ha rinunciato, o perché una categoria su quaranta ha un null nel campo che alimenta name.

Domande frequenti

I dati strutturati sono un fattore di posizionamento?

No. Il markup rende una pagina idonea ai rich result; non la sposta né su né giù nei risultati web ordinari. La prova più netta è la sanzione: Google descrive un'azione manuale sui dati strutturati come costo dell'idoneità a comparire come rich result, precisando che non incide sul posizionamento nella ricerca web. Due sistemi separati. Ogni beneficio indiretto viene da un risultato più informativo che attira più clic, non da un markup che venga valutato.

Devo rimuovere lo schema FAQ e HowTo ora che non producono nulla?

No, e Google lo dice esplicitamente per le funzioni ritirate: non serve rimuoverle, perché altri motori e servizi potrebbero ancora usarle. Schema.org è un vocabolario condiviso che Google non possiede. Ciò che deve cambiare è il tuo budget, non il tuo HTML — smetti di costruire nuovo markup FAQ aspettandoti un ritorno visibile in Google, e smetti di rendicontare una funzione il cui rapporto in Search Console non esiste più. Se il markup è già generato da un template la cui manutenzione non costa nulla, lasciarlo è la decisione più economica.

Il mio markup è valido e il test dei risultati avanzati passa, ma non compare alcun rich result. Perché?

Perché superare il test dimostra l'idoneità, e l'idoneità non è la visualizzazione. Google afferma di non garantire la comparsa dei dati strutturati nemmeno con una pagina marcata correttamente. La decisione dipende dalla query, dal dispositivo, dall'impaginazione di quella specifica pagina di risultati e dalla fiducia di Google nel sito. Non c'è leva da tirare. La risposta produttiva è verificare che la pagina sia indicizzata, che il rapporto della Search Console mostri l'elemento come valido in produzione e non solo nello strumento di test, e poi aspettare — la visualizzazione spesso comincia settimane dopo la prima scansione del markup.

Posso mettere il JSON-LD nell'head, o deve stare nel body?

Vanno bene entrambe. Google analizza il tag script ovunque compaia nel documento, e non c'è differenza di posizionamento o di idoneità tra le due posizioni. Conta molto di più che il tag arrivi al crawler. Se il blocco è iniettato da JavaScript lato client, dipende dal completamento del rendering, il che introduce un modo di fallimento che il markup renderizzato lato server non ha. Emettilo lato server se il tuo stack lo consente, e se deve essere lato client, verifica con lo strumento di ispezione URL che l'HTML renderizzato visto da Google lo contenga davvero.

Che cosa fa scattare esattamente un'azione manuale sui dati strutturati?

Markup che descrive qualcosa che il lettore non può vedere. Le linee guida di Google dicono chiaramente di non marcare contenuto non visibile ai lettori della pagina, e il contenuto marcato nascosto è indicato come motivo per cui i dati non compaiono. In pratica le colpe sono: valutazioni per prodotti senza recensioni sulla pagina, prezzi che non corrispondono a quello mostrato, tipi che non corrispondono allo scopo reale della pagina, e date inventate dal CMS. La conseguenza è la perdita dell'idoneità ai rich result, non un crollo di posizione — ma l'idoneità era l'intera ragione per aggiungere il markup.

Un generatore di markup schema produce qualcosa che posso pubblicare così com'è?

Produce uno scheletro corretto, che è davvero la metà noiosa del lavoro — il tipo giusto, le proprietà obbligatorie presenti, l'annidamento valido, il JSON ben formato. Ciò che non può fare è conoscere la tua pagina. Due cose restano tue: verificare che ogni valore che incolli sia un valore visibile sulla pagina renderizzata, e collegare il blocco ai tuoi dati perché resti vero dopo la prossima modifica di contenuto. Un generatore è lo strumento giusto per una pagina singola o un primo template; è lo strumento sbagliato per un catalogo di quarantamila prodotti, che ha bisogno di generazione dagli stessi oggetti che rendono la pagina.