Dati strutturati per l'AI: cosa serve e cosa è teatro

Dichiara. Prende informazioni che sulla pagina sono espresse in prosa e in grafica, e le riscrive in una forma che una macchina può leggere senza interpretare: questo è un prodotto, questo è il prezzo, questa è la valuta, questo è lo stato di disponibilità. È traduzione, non ottimizzazione.

La confusione nasce dal fatto che il markup viene venduto da anni come una leva di posizionamento. Non lo è, e la documentazione di Google è abbastanza chiara sul punto: i dati strutturati servono a comprendere il contenuto di una pagina e a presentarlo in una forma più ricca nei risultati. Comprensione e presentazione, non graduatoria.

La versione utile di questa distinzione è economica. Se pensi che lo schema faccia salire una pagina, lo aggiungi dove vuoi salire, cioè dove hai un problema di competizione. Se capisci che dichiara, lo aggiungi dove hai un problema di ambiguità, che è un posto diverso e spesso più noioso.

Tre posizioni, tutte pubbliche, e vale conoscerle testualmente perché sono l'argomento più forte che hai quando qualcuno ti promette risultati.

La prima: il markup corretto non garantisce la comparsa. Google scrive che non assicura che i tuoi dati strutturati compaiano nei risultati, anche se la pagina è marcata correttamente. È l'algoritmo a decidere quale forma serve meglio l'utente in quel contesto.

La seconda: l'elenco dei tipi che producono qualcosa è finito e pubblicato. Articolo, prodotto, organizzazione, attività locale, evento, ricetta, offerta di lavoro, breadcrumb, recensione, discussione, video, dataset e un numero limitato di altri. Quell'elenco cambia nel tempo, in entrambe le direzioni: alcuni tipi vengono ritirati quando la funzionalità che alimentavano non esiste più.

La terza, la più sottovalutata: una violazione delle policy sui dati strutturati fa perdere l'idoneità al risultato ricco e non cambia il posizionamento della pagina nella ricerca web. Letta al contrario, dice esattamente cosa è il markup: una leva di idoneità, non di ranking. Se non fosse così, la sanzione avrebbe toccato il ranking.

Il criterio è se il tipo è nell'elenco documentato o no. Fuori da quell'elenco puoi scrivere schema perfettamente valido secondo lo standard, e non attiva niente, perché non esiste una funzionalità collegata. Non è dannoso, è inerte, e il costo è il tempo che ci hai messo.

Perché smette di essere un dato mancante e diventa un'affermazione falsa fatta da te. Le policy sono esplicite su due punti collegati: non marcare contenuto che non è visibile al lettore della pagina, e non marcare contenuto irrilevante o fuorviante. Un prezzo nello schema diverso dal prezzo a schermo viola entrambi.

La conseguenza tecnica è la perdita di idoneità, e nei casi peggiori un intervento manuale. Ma il danno più grande è a monte: un sistema che trova una divergenza tra ciò che dichiari e ciò che mostri ha imparato qualcosa su quanto sono affidabili le tue dichiarazioni in generale, e quel giudizio si estende ai campi corretti.

Il caso che vedo più spesso non è disonestà, è disallineamento. Lo schema viene generato da una fonte diversa da quella che alimenta la pagina, e le due si scollano nel tempo: il prezzo cambia nel gestionale, la pagina si aggiorna, lo schema resta al valore vecchio. Nessuno ha deciso di mentire, e il sistema legge una menzogna.

Da qui una regola implementativa che vale più di qualsiasi scelta di tipo: lo schema deve essere generato dagli stessi dati che generano la pagina visibile. Se è compilato a mano, o viene da un secondo sistema, il disallineamento è questione di tempo.

Cambia lo scopo. Il risultato ricco è una funzionalità della ricerca tradizionale: prendi il markup, ottieni un formato di visualizzazione. In un motore generativo non c'è un formato da attivare, c'è una risposta da costruire, quindi il markup serve a un'altra cosa: risolvere ambiguità.

Il beneficio reale è quello. Un prezzo dichiarato in un campo con la sua valuta non richiede di essere dedotto da una stringa. Uno stato di disponibilità dichiarato non richiede di essere interpretato da un'etichetta grafica. Un'organizzazione dichiarata con il suo indirizzo e i suoi profili non richiede di essere indovinata tra omonimi. In tutti e tre i casi il markup non convince nessuno: rimuove un passaggio di interpretazione, e quel passaggio è dove le cose si rompono.

Quello che va detto con altrettanta chiarezza è che nessun fornitore di motori generativi ha dichiarato che i dati strutturati aumentino le probabilità di essere citati. Chi lo afferma sta inferendo. L'inferenza è ragionevole, perché un dato non ambiguo è più facile da usare di uno ambiguo, ma resta un'inferenza, e va presentata come tale.

Ne segue l'ordine di priorità corretto: il markup viene dopo l'accessibilità e la coerenza dell'entità, non prima. Marcare una pagina che i crawler non riescono a leggere è tempo speso su un campo che nessuno legge.

Per tipo di pagina e per ambiguità presente, non per copertura. L'obiettivo non è marcare tutto: è togliere interpretazione dove l'interpretazione può sbagliare.

Non fa posizionare. Vale ripeterlo perché è la promessa che si vende meglio: nella documentazione il markup produce comprensione e idoneità a una presentazione, e la sanzione per averlo usato male non tocca il ranking. Le due cose insieme chiudono la questione.

Non garantisce il risultato ricco nemmeno quando è perfetto. Questa non è cautela mia, è scritto dal fornitore.

Non rende leggibile una pagina che non lo è. Se il contenuto arriva solo dopo il rendering nel browser, lo schema iniettato dallo stesso script arriva insieme a lui, cioè non arriva.

Non sostituisce il testo. Un attributo dichiara un valore, non spiega perché quel valore conta per chi compra. La risposta che un motore costruisce è fatta di prosa, e la prosa la scrivi tu.