Se l'AI deve indovinare di cosa parla il tuo sito leggendo il testo libero, stai cedendo terreno a chi ha reso quelle informazioni leggibili direttamente. I dati strutturati sono l'equivalente di una carta d'identità verificabile: Organization, FAQ, Product — ogni tipo aggiunge un livello di chiarezza che riduce l'ambiguità. Si implementa una volta sola e funziona su tutte le pagine interessate. Ti spiego quali schemi hanno più impatto e come installarli senza toccare il codice.
C’e una convinzione diffusa tra chi lavora con schema.org: aggiungi il markup JSON-LD, Google mostra il rich snippet, fine della storia. Per anni ha funzionato così. Il dato strutturato era un bonus cosmetico — la stellina nelle SERP, il prezzo nel risultato, il breadcrumb sotto il titolo.
Ma adesso la partita si gioca su un campo diverso. I modelli AI che alimentano le risposte di ChatGPT, Perplexity e Gemini non cercano rich snippet. Cercano informazioni verificabili, machine-readable, che possano usare per decidere se fidarsi di una fonte. E qui i dati strutturati entrano in gioco in un modo che nella mia pratica professionale ho visto pochissimi considerare — e con un paradosso che ti spiego partendo dai dati.
Il paradosso del JSON-LD: utile ma non come pensi
Partiamo dal dato che rompe lo schema mentale di chi lavora con il markup. Un paper del 2026 di Volpini et al. ha analizzato l’impatto reale dei dati strutturati sui sistemi RAG — quelli che cercano informazioni in tempo reale prima di generare una risposta:
“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.” — Volpini et al., 2026
Fermati un secondo su questo. JSON-LD, il formato che usiamo per implementare schema.org, non produce benefici misurabili nei sistemi RAG che trattano le pagine come testo piatto. E la maggior parte dei sistemi RAG fa esattamente questo: prende la tua pagina, la converte in testo, la processa.
Se stai pensando “allora i dati strutturati non servono a nulla per l’AI”, la conclusione e sbagliata. E lo stesso paper a spiegare perché. Ma prima serve capire cosa vedono davvero i sistemi AI quando visitano il tuo sito.
Cosa vede l’AI: testo, non markup
Il survey di Gao et al. del 2024, uno dei riferimenti più completi sui sistemi RAG, chiarisce un punto fondamentale sulla fonte dei dati:
“Unstructured Data, such as text, is the most widely used retrieval source.” — Gao et al., 2024
Il testo non strutturato e la fonte di recupero più usata. Non il JSON-LD, non il markup schema.org, non i knowledge graph. Testo. Paragrafi, frasi, parole in sequenza.
Questo significa che quando un sistema RAG crawla la tua pagina per decidere se usarla come fonte in una risposta, nella stragrande maggioranza dei casi sta leggendo il testo visibile. Il blocco JSON-LD che hai inserito nell’head della pagina — quello con Organization, Person, i tuoi dati aziendali — e invisibile per quel sistema. E li, nel codice, ma non viene processato come fonte di recupero.
Ora, la domanda diventa: se il RAG legge solo il testo, a cosa serve il dato strutturato?
La svolta: materializzare i dati strutturati nel testo
Qui arriva l’insight che cambia la strategia. Lo stesso paper di Volpini et al. ha testato un approccio diverso: invece di lasciare i dati strutturati sepolti nel JSON-LD, li hanno materializzati in pagine leggibili — le chiamano “enhanced entity pages”. Pagine dove le informazioni dello schema (chi sei, cosa fai, dove sei, quali relazioni hai con altre entita) vengono esposte come testo strutturato e leggibile.
Il risultato:
“Enhanced pages achieved +29.6% accuracy improvement for standard RAG.” — Volpini et al., 2026
Più 29.6% di accuratezza. Non visibilità, non ranking — accuratezza. Il sistema RAG, quando trova una pagina che presenta i dati strutturati in formato leggibile, produce risposte più corrette. E una risposta più corretta e una risposta più probabile — i sistemi tendono a preferire fonti che riducono l’incertezza.
La differenza tra il JSON-LD nascosto e la pagina enhanced e esattamente questa: nel primo caso le informazioni esistono ma l’AI non le vede; nel secondo caso le informazioni sono nel testo, nel flusso che il sistema processa, e diventano parte della risposta.
La doppia strategia: parser e RAG
Questo non significa che devi abbandonare il JSON-LD. Significa che devi giocare su due tavoli contemporaneamente.
Il primo tavolo e quello dei motori di ricerca tradizionali. Google e Bing hanno parser dedicati per JSON-LD. Leggono il tuo schema Organization, il tuo schema Person, le tue FAQ markup, e li usano per alimentare il Knowledge Graph, mostrare rich snippet, validare la tua entita. Per questo canale, il JSON-LD continua a funzionare esattamente come prima — e se hai già un Knowledge Panel, e in parte grazie a quello.
Il secondo tavolo e quello dell’AI generativa. Qui il JSON-LD da solo non basta. Servono pagine che rendano esplicite, in testo leggibile, le informazioni che normalmente nascondi nel markup. Chi sei, cosa fa la tua azienda, quali sono i tuoi servizi, chi sono le persone chiave, quali certificazioni hai, dove operi.
In pratica: se il tuo schema Organization dice `”name”: “Azienda X”, “foundingDate”: “2010”, “areaServed”: “Italia”`, queste informazioni devono esistere anche come testo visibile sulla tua pagina About. Non perché Google ne abbia bisogno — quello le legge dal JSON-LD. Ma perché l’AI generativa legge il testo.
Cosa implementare: dal markup al contenuto
La strategia si divide in due livelli. Il primo e quello che probabilmente stai già facendo (o dovresti): implementare schema.org in JSON-LD sulle pagine chiave del sito.
Ma il secondo livello e quello che fa la differenza per l’AI, e quasi nessuno lo sta facendo: creare pagine che materializzano quei dati in contenuto leggibile.
Ecco cosa significa in pratica. Se hai implementato schema Organization con i tuoi dati aziendali, la tua pagina About deve contenere quelle stesse informazioni in formato discorsivo — non un elenco puntato secco, ma testo che un sistema RAG può estrarre e usare come fonte. Se hai schema Person per i tuoi autori, ogni autore deve avere una pagina profilo che espone competenze, esperienze e affiliazioni in testo leggibile. Se hai schema FAQ, le domande e risposte devono essere presenti nella pagina come contenuto visibile, non solo nel markup.
Il principio e semplice: tutto cio che metti nel JSON-LD deve esistere anche nel testo. Il JSON-LD parla ai parser di Google e Bing. Il testo parla all’AI generativa. Se hai solo il primo, stai parlando a meta del pubblico.
L’errore più comune: markup senza contenuto
L’errore che vedo più spesso e esattamente questo: siti con uno schema.org tecnicamente impeccabile, validato senza errori, ma con pagine che non espongono quelle informazioni in testo leggibile.
Hanno il JSON-LD Organization completo nell’head, ma la pagina About e tre righe generiche. Hanno schema Person per ogni autore, ma le pagine autore sono stub con nome e foto. Hanno FAQ markup, ma le FAQ esistono solo nel codice, non nella pagina.
Per Google, funziona. Il parser legge il JSON-LD e ignora il testo. Per l’AI generativa, e come avere una carta d’identità in una cassaforte chiusa: esiste, ma nessuno la vede.
Un check rapido che puoi fare subito: prendi le tre pagine più importanti del tuo sito. Guarda il JSON-LD implementato. Poi guarda il testo visibile della pagina. Le informazioni coincidono? Il testo contiene tutto cio che il markup dichiara? Se ci sono gap, quelli sono i punti dove l’AI perde informazioni su di te. E un primo passo per capire dove stai — l’implementazione completa richiede un lavoro sistematico su architettura delle pagine e struttura dei contenuti.
Perché questo e un vantaggio competitivo
La buona notizia e che quasi nessuno sta facendo questa doppia implementazione. La maggior parte dei siti che ha schema.org si e fermata al primo livello — il markup tecnico. Pochissimi hanno capito che quel markup deve diventare contenuto.
Questo si collega direttamente a quello di cui ho parlato negli articoli sul peso delle menzioni implicite e sui backlink come segnale di citazione: la visibilità AI si costruisce su più livelli simultanei. I dati strutturati sono uno di quei livelli — ma solo se li rendi visibili a tutti i sistemi, non solo a Google.
Chi implementa la doppia strategia adesso — JSON-LD per i parser, contenuto materializzato per l’AI — sta costruendo un vantaggio che si consolida nel tempo. Più i sistemi RAG diventano la modalita dominante di ricerca, più quel +29.6% di accuratezza si traduce in visibilità concreta. E meccanica, non profezia: i sistemi preferiscono fonti che rendono le informazioni facilmente estraibili.
La topical authority si rafforza quando le tue pagine non solo parlano del tuo tema, ma lo fanno in un formato che l’AI può processare senza ambiguità. I dati strutturati materializzati nel testo sono esattamente questo: informazioni chiare, verificabili, pronte per essere estratte.
