I tuoi prezzi, le FAQ, il catalogo sono sepolti nel testo della pagina? L'AI deve estrarli leggendo, e spesso sbaglia o li ignora del tutto — il che significa clienti che ricevono informazioni sbagliate o incomplete sul tuo conto. Esiste un formato tecnico che consegna quei dati all'AI già pronti, senza margine di errore. Chi lo adotta viene citato con precisione, guadagna credibilità e trasforma ogni risposta dell'AI in un canale di acquisizione affidabile.
Hai una pagina prodotto con prezzo, disponibilità, rating medio, specifiche tecniche. Tutte sparse tra paragrafi, tabelle, sidebar. Un visitatore umano le trova perché ha gli occhi e il contesto. Un sistema AI che processa quella pagina come testo piatto deve prima capire dove sono i dati, poi estrarre il valore, poi verificare che sia aggiornato. Tre passaggi, tre possibilità di errore.
JSON-LD elimina quei tre passaggi. È un blocco di codice invisibile al visitatore, perfettamente leggibile per qualsiasi parser, dove ogni dato è etichettato, tipizzato e associato a un’entità precisa. Prezzo: 149 euro. Valuta: EUR. Disponibilità: InStock. Zero ambiguità, zero interpretazione.
Come funziona JSON-LD e perché è diverso dal testo
JSON-LD sta per JavaScript Object Notation for Linked Data. In pratica, è un blocco ` inserito nell’head o nel body della pagina.
La differenza rispetto al testo è sostanziale. Quando scrivi “Il nostro servizio di consulenza costa 1.500 euro a giornata”, il dato è annegato nella sintassi. Un parser deve fare analisi del linguaggio naturale per estrarre il numero e associarlo al servizio menzionato due righe sopra. Con JSON-LD, quella stessa informazione diventa:
“json { “@type”: “Service”, “name”: “Consulenza strategica AI”, “offers”: { “price”: “1500”, “priceCurrency”: “EUR” } } “
Il dato è già nel formato che il sistema consuma. È questo non vale solo per Google e Bing — vale per qualsiasi pipeline che sappia leggere dati strutturati.
Il punto critico: i sistemi RAG non leggono JSON-LD
Qui devo essere onesto, perché su questo tema c’è molta confusione. JSON-LD è potentissimo per i motori di ricerca tradizionali e per i knowledge graph. Ma la maggior parte dei sistemi RAG che alimentano i motori AI generativi non lo processa.
Lo studio di Volpini et al. (2026) sui dati strutturati collegati come layer di memoria per il retrieval lo documenta in modo esplicito:
“However, JSON-LD markup remains valuable for search engines with dedicated parsers (Google, Bing), but it provides no measurable benefit in RAG-based systems that treat pages as flat text.”
(Structured Linked Data as a Memory Layer for Agent-Orchestrated Retrieval)
Fermati su questo passaggio. Non dice che JSON-LD è inutile — dice che non produce benefici misurabili nei sistemi RAG che trattano le pagine come testo piatto. È questa è una distinzione fondamentale, perché ti dice esattamente dove JSON-LD funziona e dove no, e di conseguenza come devi usarlo.
I motori di ricerca tradizionali — Google, Bing — hanno parser dedicati che leggono il blocco JSON-LD, lo interpretano e lo usano per i rich snippet, per il Knowledge Panel, per le risposte dirette. Quando Google mostra il prezzo del tuo prodotto direttamente nei risultati di ricerca, sta leggendo il tuo JSON-LD. E quando i motori AI attingono dai risultati di Google per costruire le loro risposte — cosa che accade regolarmente — quel dato strutturato arriva indirettamente anche a loro.
La strategia doppia: JSON-LD più testo strutturato
Da questa evidenza segue un approccio operativo preciso. Non devi scegliere tra JSON-LD e testo ben strutturato. Devi usarli entrambi, ciascuno per quello che sa fare meglio.
JSON-LD per i parser dedicati. Google, Bing e i sistemi che leggono i dati strutturati ricevono le tue informazioni in formato machine-parsable, senza ambiguità. Questo alimenta i knowledge graph, i rich snippet e — indirettamente — le risposte AI che attingono da queste fonti.
Testo strutturato per i sistemi RAG. I crawler che processano la pagina come testo piatto — e sono la maggioranza delle pipeline AI generative — hanno bisogno che le stesse informazioni siano presenti nel corpo della pagina in formato leggibile. Ne ho parlato a fondo nell’articolo sulle tabelle HTML come chunk strutturato: una tabella con header chiari e valori testuali è il formato più efficace per rendere i dati estraibili dal retrieval.
Nel survey di Gao et al. (2024) sui sistemi RAG, la distinzione tra fonti di dati è netta:
“Structured data, such as knowledge graphs (KGs), which are typically verified and can provide more precise information.”
(Retrieval-Augmented Generation for Large Language Models: A Survey)
I dati strutturati sono tipicamente verificati e forniscono informazioni più precise. JSON-LD alimenta esattamente quei knowledge graph. Ogni volta che dichiari un’entità Product, Service o LocalBusiness con i campi corretti, stai contribuendo alla base di conoscenza strutturata da cui i motori AI attingono per dare risposte precise.
Quali schemi implementare e con quali campi
Non tutti gli schemi JSON-LD hanno lo stesso impatto. Tre tipologie coprono la stragrande maggioranza dei casi d’uso per un’azienda che vuole essere visibile nelle risposte AI.
Product. Se vendi prodotti, ogni pagina prodotto dovrebbe avere uno schema Product con: name, description, brand, offers (con price, priceCurrency, availability), aggregateRating (se hai recensioni), image, sku. Questi sono i campi che Google legge per i rich snippet e che alimentano le risposte a query tipo “quanto costa X” o “X è disponibile?”.
Service. Se offri servizi, lo schema Service ti permette di dichiarare: name, description, provider (la tua azienda), areaServed, serviceType. Aggiungi offers se hai un pricing definito. Questo schema è meno diffuso di Product, il che significa meno concorrenza — e più probabilità che i tuoi dati emergano quando qualcuno chiede “chi offre il servizio Y nella zona Z”.
LocalBusiness. Per qualsiasi attività con una sede fisica o un’area di servizio definita: name, address, telephone, openingHours, geo (coordinate), sameAs (link ai profili social e directory). Questo schema dialoga direttamente con Google Business Profile e con i knowledge graph locali — una miniera per chi vuole comparire nelle risposte a query geolocalizzate.
Per ognuno di questi schemi, la regola è una: compila tutti i campi per cui hai dati reali. Un campo compilato con dati inventati è peggio di un campo vuoto, perché i sistemi di verifica incrociano le informazioni e penalizzano le incongruenze.
L’errore che vedo più spesso
L’errore non è “non ho JSON-LD”. L’errore è “ho JSON-LD ma è incompleto o scollegato dal contenuto della pagina”.
Ho analizzato decine di siti di aziende italiane. La situazione tipica: uno schema Organization nel footer del sito, uguale su tutte le pagine, con nome e logo. Stop. Nessuno schema Product sulle pagine prodotto. Nessuno schema Service sulle pagine servizio. A volte uno schema FAQ implementato dal plugin SEO ma con domande generiche che non corrispondono a nessun contenuto reale della pagina.
Il secondo errore è la discrasia tra JSON-LD e testo. Se il tuo JSON-LD dichiara un prezzo di 149 euro ma nella pagina il prezzo visibile è 159 euro (magari perché hai aggiornato uno e non l’altro), il sistema di verifica rileva l’incongruenza. Il risultato: il dato non viene usato perché non è affidabile.
Lo stesso survey lo ribadisce: il testo non strutturato resta la fonte di retrieval più utilizzata:
“Unstructured Data, such as text, is the most widely used retrieval source, which are mainly gathered from corpus.”
(Retrieval-Augmented Generation for Large Language Models: A Survey)
Se il testo della pagina è la fonte primaria per i sistemi RAG, allora JSON-LD da solo non basta. Ma se aggiungi JSON-LD al testo strutturato, copri entrambi i canali: i parser dedicati e il retrieval testuale. E chi copre entrambi i canali ha un vantaggio su chi ne copre solo uno.
Un check di partenza sulle tue pagine
Apri una pagina chiave del tuo sito — quella del prodotto di punta o del servizio principale. Vai su Google Rich Results Test e incolla l’URL. Se il tool non rileva nessuno schema, il primo passo è implementarlo. Se rileva uno schema generico (solo Organization), il passo è aggiungere gli schemi specifici per il tipo di contenuto.
Poi confronta i dati nel JSON-LD con quelli visibili nella pagina. Prezzo, disponibilità, nome del prodotto, rating: devono coincidere. Una discrepanza è un problema che puoi risolvere in dieci minuti e che potrebbe star bloccando la citazione dei tuoi dati.
È un controllo di superficie, naturalmente. Per capire come i crawler AI stanno processando le tue pagine e se i tuoi dati strutturati arrivano fino alle risposte servono strumenti più profondi. Ma questo check ti dice già se stai giocando la partita o se sei seduto in tribuna.
Se vuoi approfondire gli altri formati che rendono i tuoi contenuti citabili dalle pipeline AI, nell’articolo sullo schema FAQ, HowTo e Article ti spiego come questi schemi dialogano direttamente con i motori AI. In quello sulle citazioni e bibliografia in-content trovi il formato che l’AI riconosce e riproduce quasi letteralmente. E se stai pensando a come trasformare i tuoi contenuti migliori in asset autonomi, ho scritto un approfondimento sui contenuti downloadable come segnale di authority.
Ogni dato che oggi è sepolto nel testo senza un’etichetta machine-readable è visibilità che stai regalando a chi quell’etichetta l’ha messa. JSON-LD più testo strutturato è la combinazione che copre tutti i canali — quelli di oggi e quelli di domani.
