I dati strutturati servono a rendere esplicito a una macchina il significato di ciò che una pagina già dice: non migliorano da soli il posizionamento e non garantiscono alcun formato di risultato arricchito. Sono un livello di traduzione. Prendono un testo scritto per le persone e lo riformulano in affermazioni leggibili da un software. Chi li adotta aspettandosi un guadagno di ranking resta quasi sempre deluso. Chi li usa per farsi interpretare correttamente ottiene un vantaggio più modesto, ma reale e duraturo.
Questa guida spiega che cosa sono i dati strutturati e quale problema risolvono, dove passa la differenza fra rendere esplicito un significato e migliorare una posizione, che cosa dichiara Google sul loro ruolo nelle esperienze AI, quali tipi hanno senso per la maggior parte dei siti e quali non servono quasi a nessuno. Poi entra nel merito operativo: il formato JSON-LD e le ragioni della sua diffusione, l’errore di marcare informazioni assenti dalla pagina, il rapporto con le entità, la validazione, che cosa fare quando i risultati arricchiti non compaiono comunque, l’ordine degli interventi rispetto alle altre priorità e gli errori più frequenti.
Indice
- Che cosa sono i dati strutturati e quale problema risolvono?
- Rendere esplicito un significato migliora il posizionamento?
- Che cosa dice Google sul loro ruolo nelle esperienze AI?
- Quali tipi hanno senso per la maggior parte dei siti?
- Quali marcature non servono quasi a nessuno?
- Perché JSON-LD è il formato preferito?
- Perché è un errore marcare informazioni non visibili in pagina?
- Che rapporto c’è fra dati strutturati ed entità?
- Come si validano i dati strutturati?
- Che cosa fare se i risultati arricchiti non compaiono?
- In che ordine intervenire rispetto alle altre priorità?
- Quali sono gli errori più comuni?
- Domande frequenti
Che cosa sono i dati strutturati e quale problema risolvono?
I dati strutturati sono un codice aggiuntivo che descrive il contenuto di una pagina in un formato standard, comprensibile da un software. Non modificano ciò che l’utente vede. Risolvono un problema preciso: l’ambiguità. Un motore di ricerca legge un testo e ne ricava ipotesi; con il markup legge affermazioni dichiarate.
Il vocabolario di riferimento è Schema.org, un progetto condiviso dai principali motori di ricerca. Definisce tipi, come Organization, Person, Article o Product, e proprietà associate a ciascun tipo: il nome, l’autore, la data di pubblicazione, il prezzo. Quando dichiari che una certa stringa è il nome di un’organizzazione e un’altra è il suo indirizzo, stai passando da un testo interpretabile in molti modi a un’affermazione con un solo significato possibile.
Il problema che risolvono è più antico del web: la disambiguazione. Una parola come «Verona» può essere una città, un cognome, il titolo di un’opera. Un lettore umano capisce dal contesto. Una macchina formula ipotesi probabilistiche, e talvolta sbaglia. I dati strutturati sostituiscono l’ipotesi con una dichiarazione. È tutto qui, e non è poco.
Va detto subito il rovescio della medaglia. Una dichiarazione vale quanto la fonte che la emette. I motori trattano i dati strutturati come un suggerimento verificabile, da confrontare con il contenuto visibile e con ciò che il resto del web afferma. Il markup aiuta a farsi capire, non basta a farsi credere.
Rendere esplicito un significato migliora il posizionamento?
No, non in modo diretto. I dati strutturati non sono un fattore di ranking generico. Aiutano un motore a interpretare correttamente una pagina e la rendono idonea a formati di presentazione più ricchi, ma non aumentano di per sé rilevanza e autorevolezza. Confondere i due piani è l’errore più diffuso in materia.
Conviene separare tre effetti distinti. Il primo è la comprensione: il motore capisce con maggiore sicurezza di che cosa parla la pagina e a quali entità si riferisce. Il secondo è la presentazione: alcuni tipi rendono la pagina eleggibile a formati arricchiti, cioè risultati con elementi visivi o informativi aggiuntivi. Il terzo è il posizionamento vero e proprio, che dipende da rilevanza, qualità, esperienza dell’utente e segnali esterni.
Solo il primo e il secondo effetto dipendono dal markup. Il terzo no. Quando si osserva un miglioramento apparente dopo l’implementazione, quasi sempre è indiretto: una presentazione più informativa può aumentare la percentuale di clic a parità di posizione, e una pagina interpretata correttamente smette di essere associata a intenti sbagliati. Sono guadagni reali, ma di natura diversa da un avanzamento di ranking.
| Che cosa fanno i dati strutturati | Che cosa non fanno |
|---|---|
| Dichiarano il tipo di entità descritta dalla pagina | Non aumentano la rilevanza rispetto a una query |
| Rendono espliciti attributi altrimenti inferiti | Non sostituiscono un contenuto povero |
| Rendono la pagina idonea a formati arricchiti | Non garantiscono che tali formati compaiano |
| Riducono le interpretazioni errate | Non conferiscono autorevolezza al sito |
| Collegano una pagina a identificatori esterni | Non creano un’entità che il web non riconosce |
Che cosa dice Google sul loro ruolo nelle esperienze AI?
La guida ufficiale di Google all’ottimizzazione per le esperienze AI è netta: i dati strutturati sono utili per i risultati arricchiti, ma non sono obbligatori per comparire nelle esperienze AI. Nella stessa guida Google dichiara non necessari anche llms.txt, il frazionamento artificiale dei contenuti e le riscritture o le marcature pensate specificamente per l’AI.
Il passaggio decisivo è un altro. Google afferma che «Le best practice SEO continuano a essere rilevanti perché le nostre funzioni AI si basano sui sistemi di ranking e qualità core di Search». Tradotto: non esiste un canale parallelo con regole proprie. Le stesse valutazioni che governano i risultati tradizionali governano le risposte generative, perché condividono l’infrastruttura sottostante.
Questo ridimensiona una narrazione molto diffusa negli ultimi anni, secondo cui basterebbe aggiungere markup per essere citati dai sistemi generativi. Non è così. Il markup resta uno strumento di chiarezza, non un lasciapassare. Chi lo presenta come la leva principale per la visibilità nelle risposte AI sta descrivendo un meccanismo che il fornitore del motore ha esplicitamente smentito.
Quali tipi hanno senso per la maggior parte dei siti?
Pochi tipi coprono la quasi totalità dei casi reali. Un sito ben marcato dichiara chi è, come sono organizzate le sue pagine e che cosa offre. Tutto il resto è specializzazione. Aggiungere tipi oltre il necessario non produce vantaggi e aumenta la superficie di errore da mantenere nel tempo.
La base è quasi sempre la stessa. Organization identifica il soggetto che pubblica il sito e va dichiarata una sola volta, in modo coerente su tutte le pagine. BreadcrumbList descrive la posizione della pagina nella gerarchia del sito e rende leggibile la struttura. Article ha senso sui contenuti editoriali, dove la paternità e la data hanno un peso informativo. Person serve quando esiste una figura professionale riconoscibile, tipicamente l’autore o il titolare.
Poi ci sono i tipi legati al modello di business. Product è pertinente su un sito di commercio elettronico, dove descrive un oggetto realmente acquistabile. LocalBusiness riguarda le attività con una presenza fisica e un bacino geografico definito. FAQPage è utile solo dove esistono davvero domande e risposte visibili nella pagina, e va usato con parsimonia: è il tipo più abusato in assoluto.
| Tipo | A chi serve | Che cosa dichiara |
|---|---|---|
| Organization | Praticamente ogni sito | L’identità del soggetto che pubblica |
| BreadcrumbList | Siti con più livelli di navigazione | La posizione della pagina nella gerarchia |
| Article | Blog, testate, sezioni editoriali | Titolo, autore, date del contenuto |
| Person | Professionisti e autori riconoscibili | Identità e ruolo di una persona |
| Product | Commercio elettronico | Caratteristiche di un bene in vendita |
| LocalBusiness | Attività con sede fisica | Sede, contatti, tipologia di attività |
| FAQPage | Pagine con domande e risposte reali | Coppie domanda-risposta già visibili |
Quali marcature non servono quasi a nessuno?
Schema.org contiene centinaia di tipi, pensati per settori molto diversi fra loro. La maggior parte non riguarda il sito medio. Marcare entità marginali, ripetere la stessa dichiarazione in più punti o annidare strutture complesse senza una ragione operativa non produce alcun effetto misurabile e complica la manutenzione.
Il criterio di selezione è semplice: un tipo ha senso se descrive qualcosa che la pagina contiene davvero. Se devi cercare una giustificazione per usarlo, non ti serve.
Ci sono poi casi in cui un tipo è tecnicamente valido ma praticamente inutile. Marcare come Article una pagina di servizio commerciale, dichiarare un Product per un’offerta che non è acquistabile online, applicare FAQPage a un elenco di domande costruito solo per ottenere spazio nei risultati: sono forzature che i motori riconoscono e che, nel migliore dei casi, vengono semplicemente ignorate.
Perché JSON-LD è il formato preferito?
JSON-LD è un blocco di codice separato, inserito nella pagina e indipendente dal markup visibile. Gli altri formati storici, microdata e RDFa, richiedono invece di intrecciare gli attributi direttamente nell’HTML del contenuto. La separazione è il motivo principale della preferenza: rende il markup più semplice da generare, aggiornare, testare e rimuovere.
La differenza si sente soprattutto nella manutenzione. Con i formati intrecciati, ogni modifica al template rischia di rompere le dichiarazioni, perché il markup semantico e la presentazione condividono gli stessi elementi. Con JSON-LD il blocco è autonomo: puoi rigenerarlo da una fonte dati, versionarlo, sostituirlo per intero senza toccare il layout. Anche la lettura da parte di uno sviluppatore è immediata.
C’è però un rovescio, ed è la stessa proprietà vista da un’altra angolazione. Proprio perché il blocco è separato, è facile che si disallinei dal contenuto visibile: il testo cambia, il markup resta fermo.
| Formato | Come si integra | Manutenzione |
|---|---|---|
| JSON-LD | Blocco separato dal contenuto visibile | Semplice, ma richiede controlli di allineamento |
| Microdata | Attributi inseriti negli elementi HTML | Fragile a ogni modifica del template |
| RDFa | Attributi inseriti negli elementi HTML | Fragile e più verbosa da leggere |
Perché è un errore marcare informazioni non visibili in pagina?
Perché i dati strutturati descrivono la pagina, non la integrano. Dichiarare nel markup contenuti che l’utente non può vedere significa affermare qualcosa che la pagina non sostiene. È una violazione esplicita delle linee guida e, sul piano concettuale, un fraintendimento della funzione stessa dello strumento.
Il caso tipico riguarda le domande frequenti dichiarate ma assenti dal testo, le valutazioni non mostrate agli utenti, gli attributi di prodotto scritti solo nel codice. In tutti questi casi la discrepanza è verificabile in modo automatico, perché il motore confronta ciò che il markup afferma con ciò che la pagina renderizzata contiene. Quando la verifica fallisce, la marcatura viene ignorata; nei casi più gravi il sito può subire un provvedimento manuale per spam nei dati strutturati.
La regola pratica è una sola e non ammette eccezioni: se un’informazione non è leggibile dall’utente sulla pagina, non va dichiarata. Il markup è uno specchio, non un’aggiunta. Quando serve dichiarare qualcosa, la strada corretta è metterlo nella pagina e poi marcarlo, mai il contrario.
Che rapporto c’è fra dati strutturati ed entità?
Un’entità è una cosa identificabile in modo univoco: un’azienda, una persona, un luogo, un prodotto. I dati strutturati sono uno dei modi con cui un sito dichiara a quale entità si riferisce, ma non creano l’entità. Il riconoscimento nasce dalla convergenza di fonti indipendenti, non da un’autodichiarazione.
La distinzione è importante perché molte implementazioni nascono da un equivoco: si marca l’organizzazione sperando che questo la faccia esistere agli occhi del motore. Non funziona così. Il markup rende esplicito il collegamento fra la pagina e i riferimenti esterni già associati a quel soggetto, per esempio profili ufficiali e schede in fonti riconosciute. Se quei riferimenti non esistono, il markup dichiara un collegamento a vuoto.
Detto questo, il markup ha un ruolo reale nel consolidamento. Dichiarazioni coerenti e ripetute nel tempo, coerenti anche con quanto il sito mostra e con quanto altre fonti confermano, riducono l’incertezza. È un lavoro lento, che si nota solo dopo mesi e che nessun singolo intervento tecnico può accelerare.
Come si validano i dati strutturati?
La validazione si fa su due livelli. Il primo è sintattico: verificare che il codice sia formalmente corretto e coerente con il vocabolario Schema.org, tramite il validatore messo a disposizione da Schema.org stesso. Il secondo è di idoneità: verificare, con il test dei risultati arricchiti di Google, se la pagina soddisfa i requisiti di un formato specifico.
I due controlli rispondono a domande diverse e vanno fatti entrambi. Un markup sintatticamente valido può non essere idoneo ad alcun formato arricchito, semplicemente perché il tipo dichiarato non ne prevede uno. Al contrario, un errore di sintassi rende inutilizzabile anche una dichiarazione concettualmente corretta.
Il terzo livello è il monitoraggio nel tempo, che si fa in Search Console. I rapporti dedicati mostrano quali elementi sono stati riconosciuti sull’insieme delle pagine, quali presentano avvisi e quali errori bloccanti. È l’unico controllo che intercetta i problemi introdotti da una modifica al template, che i test su singola pagina non fanno emergere finché non si prova proprio quella pagina.
Che cosa fare se i risultati arricchiti non compaiono?
Accettare che nessuna implementazione li garantisce. Un markup valido e idoneo rende la pagina candidata, non selezionata. La decisione di mostrare un formato arricchito resta del motore e dipende da fattori che non si controllano: qualità della pagina, tipo di query, dispositivo, lingua, affollamento della schermata dei risultati.
Prima di concludere che si tratta di una scelta del motore, però, conviene escludere le cause banali. La pagina è indicizzata? Il markup è presente nella versione renderizzata e non solo nel codice sorgente iniziale? Il test di idoneità restituisce errori bloccanti o solo avvisi? Search Console segnala anomalie su quel tipo? Nella maggior parte dei casi il problema è in questa lista, non in una valutazione qualitativa.
Se tutti i controlli sono puliti e non succede nulla, la risposta corretta è smettere di intervenire sul markup. Continuare ad aggiungere proprietà o tipi nella speranza di sbloccare qualcosa è tempo sottratto ad attività che incidono davvero. In quel punto il collo di bottiglia non è più tecnico.
In che ordine intervenire rispetto alle altre priorità?
I dati strutturati vengono dopo. Prima viene l’accessibilità tecnica delle pagine, poi la qualità e la profondità del contenuto, poi l’esperienza d’uso, e solo a quel punto la marcatura semantica. Invertire l’ordine è il modo più rapido per spendere giornate di lavoro su un intervento che non sposta niente.
Il motivo è che il markup amplifica un segnale esistente, non lo produce. Su una pagina che nessuno indicizza, o che risponde male alla domanda dell’utente, non c’è nulla da amplificare. Su una pagina già solida, la marcatura corretta evita che il lavoro fatto venga interpretato male. È una differenza di ruolo, non di importanza teorica.
Anche i dati di domanda dicono qualcosa sul peso relativo di questi temi. La tabella riporta volumi e metriche competitive rilevate su SeoZoom, database Italia. KD indica l’autorevolezza dei siti in prima pagina; KO misura, su scala da 0 a 100, il livello di ottimizzazione dei contenuti già posizionati.
| Keyword | Volume mensile | KD | KO | CPC |
|---|---|---|---|---|
| core web vitals | 590 | 51 | 33 | 1,24 € |
| dati strutturati | 390 | 60 | 31 | 0,31 € |
| knowledge graph google | 210 | 58 | 70 | 1,58 € |
| featured snippet | 170 | 49 | 30 | 0,50 € |
| schema markup | 90 | 41 | 43 | 0,27 € |
| json-ld | non rilevato | 34 | 47 | – |
| entity seo | non rilevato | 20 | 55 | – |
Su «dati strutturati» la combinazione di KD 60 e KO 31 descrive una prima pagina presidiata da fonti autorevoli e già ben ottimizzate: è una query difficile da attaccare frontalmente, e chi ci prova con un contenuto generico spreca risorse. Le query più laterali, come «json-ld» o «entity seo», mostrano un’autorevolezza media più bassa ma volumi non rilevati: hanno senso come approfondimenti interni, non come obiettivi principali.
Un ultimo elemento aiuta a fissare le proporzioni. La ricerca sulla Generative Engine Optimization di Aggarwal e colleghi, pubblicata su arXiv con identificativo 2311.09735, ha misurato l’effetto di diverse tecniche sulla visibilità nelle risposte generative: le citazioni dirette hanno prodotto un incremento del 40%, l’inserimento di statistiche fra il 30 e il 40%, la citazione esplicita delle fonti il 30%, mentre l’accumulo forzato di parole chiave ha causato un calo del 10%. Tutte le leve più efficaci riguardano il contenuto, nessuna riguarda il markup.
Quali sono gli errori più comuni?
Gli errori ricorrenti sono pochi e si ripetono con notevole costanza. Quasi tutti nascono da due convinzioni sbagliate: che più markup equivalga a più risultati, e che il markup possa dichiarare qualcosa che la pagina non contiene. Corretti questi due presupposti, la maggior parte dei problemi scompare da sola.
| Errore | Perché è un problema | Come si corregge |
|---|---|---|
| Marcare contenuti non visibili | Viola le linee guida e può portare a provvedimenti | Rendere visibile l’informazione o rimuovere la dichiarazione |
| Dichiarazioni incoerenti fra pagine | Genera segnali contraddittori sull’identità del sito | Centralizzare i dati dell’organizzazione in un’unica fonte |
| Markup mai aggiornato dopo modifiche | Il blocco descrive una pagina che non esiste più | Generare il markup dai dati reali del contenuto |
| Uso indiscriminato di FAQPage | Forzatura riconoscibile e priva di effetto | Limitarlo alle pagine con domande e risposte reali |
| Duplicazione dello stesso tipo | Ambiguità su quale dichiarazione sia valida | Una sola dichiarazione per entità e per pagina |
| Markup inserito solo lato client | Può non essere raccolto in modo affidabile | Verificare la presenza nella pagina renderizzata |
| Attendersi ranking dal markup | Sposta risorse dalle attività che incidono | Trattarlo come manutenzione, non come strategia |
Il rimedio è di metodo, non di codice. I dati strutturati sono manutenzione ordinaria: si implementano una volta bene, si generano dai dati reali del contenuto, si ricontrollano quando il template cambia. Non sono una strategia. Sono il modo in cui un sito dice con precisione quello che già dice.
Domande frequenti
I dati strutturati sono obbligatori?
No. Non sono obbligatori per essere indicizzati, non lo sono per posizionarsi e Google dichiara esplicitamente che non lo sono nemmeno per comparire nelle esperienze AI. Restano utili per l’idoneità ai risultati arricchiti e per ridurre le interpretazioni errate, che è già una ragione sufficiente per implementarli con criterio.
Quale formato conviene usare?
JSON-LD, nella quasi totalità dei casi. Il blocco è separato dal contenuto visibile, quindi si genera, si aggiorna e si rimuove senza toccare il template. Microdata e RDFa restano tecnicamente validi, ma intrecciano le dichiarazioni con l’HTML della pagina e diventano fragili a ogni modifica del layout.
Serve marcare tutte le pagine del sito?
No. Ha senso marcare ciò che descrive un’entità reale e centrale per la pagina. Una base di Organization e BreadcrumbList copre bene l’intero sito; i tipi specifici si aggiungono dove sono pertinenti. Estendere la marcatura ovunque aumenta soltanto la superficie di errore da mantenere nel tempo.
Se il markup è valido, i risultati arricchiti compariranno?
Non necessariamente. La validità e l’idoneità rendono la pagina candidata, ma la decisione resta del motore e dipende da qualità della pagina, tipo di query, lingua e dispositivo. Nessuna implementazione può garantire un formato arricchito, e chi lo promette sta descrivendo un meccanismo che non esiste.
I dati strutturati aiutano a essere citati dai sistemi generativi?
Non in modo diretto. La guida di Google indica che non sono richiesti per le esperienze AI e che le funzioni generative si appoggiano ai sistemi core di ranking e qualità. La ricerca disponibile mostra che le leve più efficaci riguardano il contenuto: citazioni, statistiche, fonti esplicite.
Ogni quanto vanno controllati?
Ogni volta che cambia il template o la struttura dei contenuti, più un controllo periodico in Search Console. Il rischio principale non è l’errore iniziale, che di solito emerge subito, ma il disallineamento silenzioso: la pagina evolve, il blocco resta fermo e continua a descrivere una versione che non esiste più.
Metodologia: i dati di volume di ricerca, difficoltà (KD), livello di ottimizzazione dei contenuti posizionati (KO) e costo per clic citati in questa guida provengono da SeoZoom, database Italia, rilevazione del 7 agosto 2026. I riferimenti alle indicazioni di Google rimandano alla guida ufficiale all’ottimizzazione per le esperienze AI. I dati sulla Generative Engine Optimization provengono dalla ricerca di Aggarwal e colleghi, arXiv 2311.09735.
A cura di Massimiliano Dal Prà, consulente GEO e SEO. Ultimo aggiornamento: 7 agosto 2026.