Dati strutturati: quali usare, come si scrivono, come si testano

I dati strutturati sono informazioni sulla pagina scritte in un formato che i motori di ricerca leggono senza interpretare il testo: tipo di contenuto, autore, date, prezzo, percorso di navigazione. Google li usa per capire la pagina e, quando il tipo lo prevede e la pagina è idonea, per mostrare i risultati multimediali (in inglese rich results), con stelle, immagini o dettagli in più.

Su seo.srl li genera il template, non li scrivo a mano pagina per pagina. In questa guida leggi quali tipi Google supporta oggi e quali ha ritirato, in che formato scriverli, che regole rispettare, come testarli. In mezzo c'è il JSON-LD vero del sito, letto nel codice, con il modo in cui i nodi si collegano tra loro.

Cosa fanno i dati strutturati e cosa non garantiscono#

Nella documentazione di Google sui dati strutturati (ultimo aggiornamento della pagina: 10 dicembre 2025) il ruolo è descritto in due parti. Google legge il markup per capire il contenuto della pagina e per raccogliere informazioni sulle entità, come persone, libri o aziende. Inoltre il markup può rendere la pagina idonea a un risultato multimediale, che rende la scheda più interessante nei risultati.

Idonea non significa mostrata. Le linee guida generali di Google (aggiornate il 10 luglio 2026) lo scrivono chiaro: rispettarle non garantisce che il risultato multimediale compaia. Il markup rende possibile una funzione, ma non ne assicura la comparsa.

Ne ricavo due regole di lavoro.

• Il markup descrive, non promette. Lo scrivo perché la pagina diventi più chiara per un sistema automatico, senza contare su un aspetto particolare nei risultati.
• Si parte dal contenuto. Un dato strutturato che non corrisponde a niente di visibile nella pagina non serve e, come vedi più avanti, può diventare un problema.

Il lavoro sui dati strutturati sta dentro il controllo tecnico di un sito. La mappa completa è nella guida alla SEO tecnica.

I tre formati: JSON-LD, microdata, RDFa#

Google accetta tre formati, purché il markup sia valido e segua la documentazione di ogni funzione.

La descrizione dei tre formati e la raccomandazione di JSON-LD vengono dalla stessa pagina di Google sull'introduzione ai dati strutturati. Il vocabolario è schema.org, un insieme di vocabolari condivisi che i principali motori di ricerca (Google, Microsoft, Yandex e Yahoo!) sanno interpretare e che si possono scrivere in microdata, RDFa o JSON-LD. JSON-LD è definito dal W3C come formato basato su JSON per serializzare Linked Data (Recommendation del 16 luglio 2020, versione 1.1).

Il vantaggio pratico di JSON-LD è che il blocco non si mescola con il markup visibile. Un redattore che cambia il testo non rompe il dato, e uno sviluppatore genera tutto da un punto solo. Per questo il sito usa solo JSON-LD.

Quali tipi usa Google oggi e quali ha ritirato#

La galleria dei dati strutturati supportati di Google (aggiornata il 15 giugno 2026) elenca 25 tipi: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental, Video.

La lista cambia. Questo è quanto riporta il registro degli aggiornamenti della documentazione di Search Central, che ho letto voce per voce.

Il caso FAQ merita una nota. Dal 14 settembre 2023 Google lo mostrava solo per siti governativi e sanitari noti e autorevoli. Dal 7 maggio 2026, secondo lo stesso registro, non appare più in Google Search. Chi ha ancora una tabella di lavoro con "FAQPage = risultato con domande espandibili" ha un'informazione superata.

Per tutto ciò che non è nel registro, il riferimento è la pagina della singola funzione. Nel resto della guida cito quelle di Article, Breadcrumb, Organization, Profile page, Speakable e Local business.

Le linee guida generali e le azioni manuali#

Le stesse linee guida generali fissano le regole valide per ogni tipo. Le raggruppo come le uso in revisione.

• Accesso. La pagina con il markup non deve essere bloccata a Googlebot da robots.txt, noindex o altri controlli di accesso. Del robots.txt ho scritto a parte.
• Visibilità. Non si marca contenuto che i lettori non vedono. L'HTML della pagina deve descrivere gli stessi elementi del markup.
• Accuratezza. Il markup deve rappresentare davvero la pagina: niente contenuti irrilevanti o fuorvianti, come recensioni false, e niente dati strutturati per ingannare, impersonare persone o organizzazioni, o travisare proprietà e scopo.
• Completezza. Servono tutte le proprietà richieste dal tipo, altrimenti l'elemento non è idoneo. Le proprietà consigliate migliorano la qualità del risultato. Se la pagina mostra più recensioni, si marcano tutte.
• Specificità. Si usano i tipi e le proprietà schema.org più specifici che si applicano, e il markup sta nella pagina che descrive.
• Freschezza e originalità. Le informazioni vanno tenute aggiornate; un contenuto legato al tempo e non più attuale non ottiene il risultato multimediale.
• Più elementi. Gli elementi si possono annidare sotto l'elemento principale o elencare separati. Google indica di usare @id per collegare elementi correlati e di includere il tipo principale che riflette il focus della pagina.

Secondo la stessa pagina, un problema di dati strutturati può portare a un'azione manuale, che toglie alla pagina l'idoneità ai risultati multimediali. L'azione compare nel rapporto Azioni manuali di Search Console, che trovi spiegato nella guida a Google Search Console.

Un'altra precisazione: non tutti i tipi hanno le stesse regole. Per ogni funzione la sua pagina di documentazione aggiunge requisiti propri, e sono quelli che valgono al momento di scegliere le proprietà.

Il JSON-LD di seo.srl, letto nel codice#

I nodi che seguono sono quelli che il codice di seo.srl genera davvero. Non ti dico quanto funzionino: il codice mostra cosa esce nella pagina, non cosa Google ne fa.

Organization e Person, con un identificativo stabile#

Il sito ha due entità di riferimento. L'organizzazione ha @id https://seo.srl/#organization ed è dichiarata sia come Organization sia come ProfessionalService. Il suo areaServed elenca solo Paesi: l'Italia e i sette Paesi esteri dichiarati in COUNTRIES_ABROAD (Svizzera, Regno Unito, Spagna, Portogallo, Germania, Francia, Stati Uniti), senza città né regioni. Lavoriamo online, quindi non descrivo sedi che non ci sono. La sede legale resta come dato obbligatorio della S.r.l., nel nodo address.

La persona è Eugenio Tommasi, con @id https://seo.srl/#eugenio. Il nodo è definito una sola volta nel codice e riporta, tra le altre cose, ruolo, pagina autore, lingue e il rimando all'organizzazione con worksFor. L'organizzazione, a sua volta, rimanda alla persona con founder.

I due nodi completi stanno nella home e nella pagina Chi siamo. Altrove i nodi WebPage, WebSite e CollectionPage li richiamano con l'identificativo, con proprietà come publisher, about e isPartOf. Google, nella pagina su Organization (aggiornata l'8 settembre 2026), dice che il markup aiuta a distinguere la tua organizzazione dalle altre e può incidere sul logo mostrato; non ci sono proprietà obbligatorie, e tra le consigliate ci sono name, url, logo e sameAs.

Come i nodi si collegano con @id#

L'@id è il nome stabile di un nodo. Il W3C lo definisce come l'elemento che identifica in modo univoco i nodi descritti nel documento, e un riferimento a un nodo è un oggetto che contiene soltanto @id. Il vantaggio è che la stessa entità resta riconoscibile in pagine diverse, anche quando il nodo compare più volte. Google lo cita per la stessa funzione: collegare elementi correlati.

Questo è un estratto semplificato del JSON-LD del sito (ho tolto proprietà come logo, contatti e dati societari; i valori sono quelli veri):

[
  {
    "@type": [
      "Organization",
      "ProfessionalService"
    ],
    "@id": "https://seo.srl/#organization",
    "name": "SEO SRL",
    "url": "https://seo.srl/",
    "founder": {
      "@id": "https://seo.srl/#eugenio"
    },
    "areaServed": [
      {
        "@type": "Country",
        "name": "Italia"
      },
      {
        "@type": "Country",
        "name": "Svizzera"
      },
      {
        "@type": "Country",
        "name": "Spagna"
      }
    ]
  },
  {
    "@type": "Person",
    "@id": "https://seo.srl/#eugenio",
    "name": "Eugenio Tommasi",
    "jobTitle": "Fondatore di SEO SRL",
    "url": "https://seo.srl/autore/eugenio-tommasi/",
    "worksFor": {
      "@id": "https://seo.srl/#organization"
    }
  }
]

E questo è l'articolo che stai leggendo, sempre semplificato, nella forma in cui il template lo costruisce:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://seo.srl/seo-tecnica/dati-strutturati/#articolo",
  "headline": "Dati strutturati: quali usare, come si scrivono, come si testano",
  "inLanguage": "it-IT",
  "author": {
    "@type": "Person",
    "@id": "https://seo.srl/#eugenio",
    "name": "Eugenio Tommasi"
  },
  "publisher": {
    "@id": "https://seo.srl/#organization",
    "@type": "Organization",
    "name": "SEO SRL"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://seo.srl/seo-tecnica/dati-strutturati/"
  },
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".in-sintesi",
      ".definizione"
    ]
  },
  "isPartOf": {
    "@type": "CollectionPage",
    "@id": "https://seo.srl/guide/seo-tecnica/"
  }
}

Dal codice si leggono alcuni dettagli che nei riassunti si perdono.

• Il tipo è BlogPosting, uno dei tre che Google ammette per gli articoli insieme ad Article e NewsArticle. Nella pagina su Article non ci sono proprietà obbligatorie; tra le consigliate: author, datePublished, dateModified, headline, image.
• L'autore è il nodo Person completo, ripetuto in ogni articolo di Eugenio, con lo stesso @id. Non è un rimando nudo: il template copia il nodo, e l'identificativo fa riconoscere che è sempre la stessa persona. Il publisher invece porta @id più nome, indirizzo del sito e logo.
• isPartOf punta alla guida. L'identificativo della CollectionPage è l'indirizzo della guida (https://seo.srl/guide/seo-tecnica/), che a sua volta dichiara la propria lista di capitoli. È il collegamento tra articolo e guida che il lettore vede nelle briciole.
• Speakable indica i selettori CSS del box "In sintesi" e della definizione. Google descrive Speakable come funzione in beta, per l'ascolto di notizie su Google Assistant, che funziona solo per utenti negli Stati Uniti con dispositivi Google Home impostati in inglese. Su un sito in italiano non mi aspetto un effetto in Google; lo lascio perché indica quali sono le frasi da isolare.

BreadcrumbList, FAQPage e le altre pagine#

Ogni articolo ha una BreadcrumbList con lo stesso percorso della briciola in pagina (Home, Guide, la guida, l'articolo). Google richiede almeno due elementi, e per ognuno name e position, più item con l'indirizzo, che per l'ultimo si può omettere; la funzione vale su desktop in tutte le regioni e lingue, secondo la pagina su breadcrumb.

Sul FAQPage serve una precisazione. Il template lo emette per ogni pagina che ha domande frequenti, compresa questa. Non lo faccio per ottenere un risultato multimediale: per quanto detto sopra, quel risultato oggi non esiste più. Resta un markup valido in schema.org, dove FAQPage è il tipo di pagina che presenta domande frequenti, e le domande sono tutte visibili in pagina, come chiede la regola sulla visibilità. Non ti prometto nessun vantaggio: lo tengo perché descrive in modo corretto ciò che la pagina contiene, non per un effetto misurato.

Le altre pagine del sito usano tipi diversi, scelti in base a cosa sono.

Due note sulle ultime righe. Per ProfilePage Google richiede mainEntity di tipo Person o Organization e un nome; la pagina deve essere centrata su una sola persona o organizzazione legata al sito, come una pagina autore. Quanto al Service, i prezzi non li scrivo nel JSON-LD a mano: li legge lo stesso listino che alimenta la pagina visibile, così il dato strutturato e il prezzo mostrato non possono divergere. È la regola della visibilità applicata con il codice.

Il sito non usa LocalBusiness, che Google descrive come markup per i dati di un'attività con address e name obbligatori, utile per pannelli e caroselli. Ha senso per chi ha un luogo fisico; il lavoro sul profilo locale è nella pagina sulla local SEO.

Come scrivere i dati strutturati di una pagina, passo per passo#

Il metodo che seguo quando devo aggiungerli a un sito.

1. Parti dal tipo di pagina, non dal tipo di markup. Una pagina articolo, una pagina prodotto, un profilo. Apri la galleria di Google e verifica che il tipo che ti serve sia ancora tra i supportati.
2. Leggi la pagina della funzione. Ti dice quali proprietà sono obbligatorie e quali consigliate, e le regole di contenuto proprie del tipo.
3. Controlla che ogni valore sia visibile in pagina. Prezzo, autore, data, domande: se non ci sono nel testo, non vanno nel markup.
4. Dai un @id alle entità che ricorrono. Organizzazione, persona, guida: un solo nodo completo e riferimenti dagli altri.
5. Genera il blocco dal template. Se una data o un prezzo cambiano nella pagina, devono cambiare nel markup. Scrivere JSON a mano pagina per pagina porta a incoerenze.
6. Testa prima di pubblicare, poi monitora dopo. È la sezione che segue.

Come testare i dati strutturati#

Servono strumenti diversi, perché rispondono a domande diverse.

La differenza tra i primi due è nel post con cui schema.org ha presentato lo Schema Markup Validator (21 maggio 2021): il Rich Results Test è legato a funzioni specifiche di Google e dà errori e avvisi su quelle; il validatore di schema.org verifica che il markup dica ciò che intendi in modo generale e non controlla i requisiti di un servizio particolare. Un markup può passare il secondo e non superare il primo.

Per i rapporti, la guida di Search Console spiega che un rapporto compare solo se Google trova markup valido di un tipo supportato. Le voci sono tre: valido (nessun problema critico, può apparire come risultato multimediale), non valido (almeno un problema critico che lo impedisce), non critico (non blocca, ma incide sull'aspetto). Search Console non ha un pulsante per correggere: la modifica si fa nel codice del sito.

Dopo il rilascio, la documentazione di Google suggerisce due controlli oltre ai rapporti: il Controllo URL per confermare che Google abbia trovato i dati, e un test prima e dopo su poche pagine, confrontando il rapporto Rendimento filtrato per URL.

Il controllo dei dati strutturati è una voce dell'audit SEO e si fa dopo ogni cambio di template, perché un errore nel modello colpisce tutte le pagine che lo usano.

Errori frequenti#

Il rapporto tra dati strutturati e risposte generate dall'intelligenza artificiale lo trovi nelle guide su GEO e su come comparire nelle risposte AI, e per il file di indice rivolto alle AI nella pagina su llms.txt.