Schema.org e JSON-LD: cosa sono e perché rendono il tuo e-commerce leggibile a Google e all’AI (guida 2026)

Cos’è schema.org (e cosa non è)

Schema.org è un vocabolario condiviso — nato nel 2011 da una collaborazione tra Google, Bing, Yahoo e Yandex — che definisce un insieme di “etichette” standard per descrivere cose nel web: un prodotto, una ricetta, un evento, una recensione, una domanda frequente. Non è un linguaggio di programmazione e non è specifico di un motore di ricerca: è una specifica che dice, in pratica, “se vuoi descrivere un prodotto in un modo che le macchine capiscono in modo inequivocabile, usa questi campi”.

Da solo, schema.org non fa nulla: è solo il dizionario. Quello che rende i dati leggibili sul tuo sito è il formato con cui li scrivi — ed è qui che entra in gioco JSON-LD.

Cos’è JSON-LD, e perché è il formato preferito da Google

JSON-LD (JavaScript Object Notation for Linked Data) è il formato con cui, in pratica, la maggior parte dei siti implementa oggi lo schema.org. La caratteristica che conta di più per chi gestisce un e-commerce: JSON-LD vive in un blocco <script type="application/ld+json"> separato dal resto dell’HTML, invece di essere sparso dentro i singoli tag della pagina (come richiedeva il vecchio formato Microdata).

Concretamente questo significa che il blocco di dati strutturati può essere generato dinamicamente dal CMS o dal gestionale del catalogo, senza dover toccare il template grafico della pagina — motivo per cui oggi è il formato raccomandato da Google stesso e il più usato in assoluto.

I tag che contano davvero su una scheda prodotto

Non serve implementare tutto quello che schema.org offre. Per un e-commerce, quattro blocchi coprono la maggior parte del valore:

Product — l’oggetto principale: nome, descrizione, immagine, marca (brand), identificativi come SKU, GTIN o MPN. Gli identificativi globali (GTIN/MPN) contano più di quanto sembri: senza di essi, diventa più difficile per un motore di ricerca — o per un’AI che confronta prodotti tra siti diversi — capire che il “tuo” prodotto e quello venduto da un competitor sono lo stesso articolo.

Offer — prezzo, valuta (in formato ISO 4217, es. EUR), disponibilità (InStock/OutOfStock/PreOrder), e idealmente priceValidUntil per indicare fino a quando quel prezzo è garantito. È il blocco più delicato da mantenere aggiornato: un prezzo o una disponibilità disallineati tra quello che l’utente vede sulla pagina e quello dichiarato nello schema sono un problema sia per Google che per un agente AI che sta valutando se fidarsi del sito.

AggregateRating e Review — il voto medio e le recensioni, in forma strutturata e non solo come testo libero. Qui vale una regola semplice ma spesso ignorata: il numero di recensioni e la valutazione media dichiarati nello schema devono coincidere esattamente con quelli visibili sulla pagina. Un disallineamento è uno dei motivi più comuni di penalizzazione manuale da parte di Google per markup considerato ingannevole.

FAQPage — domande e risposte specifiche del prodotto (non generiche sull’azienda), marcate separatamente. Ne parliamo in modo più approfondito nell’articolo dedicato alle FAQ, ma vale la pena anticipare che è uno dei tipi di schema con il tasso di ripresa più alto da parte dei sistemi AI generativi.

Un esempio reale di JSON-LD per un prodotto

Una versione semplificata ma corretta, da adattare al proprio catalogo:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Nome del prodotto",
  "image": "https://tuosito.it/immagini/prodotto.jpg",
  "description": "Descrizione reale del prodotto, non generica.",
  "sku": "ABC12345",
  "gtin13": "1234567890123",
  "brand": {
    "@type": "Brand",
    "name": "Nome del brand"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://tuosito.it/prodotto",
    "priceCurrency": "EUR",
    "price": "49.90",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}

Ogni CMS e-commerce (WooCommerce, Shopify, PrestaShop, soluzioni custom) ha un modo per generare questo blocco automaticamente a partire dai dati già presenti nel catalogo — il punto è verificare che lo faccia bene, non scriverlo a mano prodotto per prodotto.

Cosa dice Google esattamente

Google distingue due livelli di implementazione per il Product markup: quello che abilita gli snippet di prodotto (recensioni, prezzo, disponibilità nel risultato di ricerca) e quello più completo richiesto per comparire come merchant listing (con informazioni su taglie, spedizione, resi) all’interno di esperienze come lo Shopping Knowledge Panel e Google Images.

Google non pubblica un elenco fisso e definitivo di “campi minimi obbligatori” identico per ogni tipo di risultato: la raccomandazione ufficiale è fornire quante più informazioni rilevanti possibile e verificare l’idoneità con i propri strumenti (vedi sezione successiva). In pratica, per la maggior parte dei cataloghi, i campi dell’esempio sopra coprono la base che serve.

Il collegamento con la visibilità AI (GEO)

Qui si chiude un cerchio utile da avere in mente: i dati strutturati non sono solo un requisito tecnico per i rich result di Google. Sono, insieme alle citazioni di terze parti e al contenuto editoriale, uno dei tre fattori che contano di più per la visibilità di un e-commerce nelle risposte di ChatGPT, Perplexity e Gemini — ne parliamo nel dettaglio nel framework di audit GEO. Un catalogo con Product/Offer/AggregateRating puliti rende ai sistemi AI esplicito e verificabile quello che altrimenti dovrebbero dedurre da testo non strutturato — con margine di errore molto più alto.

Come verificare se il tuo sito ce l’ha già

Non serve intuito, ci sono strumenti gratuiti che danno una risposta in pochi secondi:

• Rich Results Test di Google (search.google.com/test/rich-results) — mostra esattamente quali rich result la pagina è idonea a ottenere, ed evidenzia errori e avvisi.
• Schema Markup Validator (validator.schema.org) — verifica la sintassi JSON-LD indipendentemente dai requisiti specifici di Google, utile per controllare la correttezza generale del markup.
• L’ispettore URL di Google Search Console mostra anche eventuali problemi di dati strutturati rilevati sulle pagine già indicizzate.

Errori comuni

• Identificativi mancanti (SKU, GTIN, MPN) — rende più debole il matching tra il prodotto e le fonti che ne parlano altrove.
• Prezzo o disponibilità nello schema disallineati da quelli reali sulla pagina.
• Voto medio o numero di recensioni “abbelliti” rispetto a quelli mostrati agli utenti — rischio concreto di penalizzazione manuale.
• Markup statico che non si aggiorna quando cambiano prezzo o disponibilità nel gestionale.
• FAQPage usata per contenuti generici sull’azienda invece che per domande specifiche sul prodotto.

Checklist pratica

1. Verifica con il Rich Results Test se le tue schede prodotto principali hanno già un markup Product valido.
2. Controlla che SKU, GTIN/MPN siano presenti e corretti — non lasciati vuoti “per ora”.
3. Verifica che prezzo, valuta e disponibilità nello schema corrispondano esattamente a quelli mostrati sulla pagina.
4. Controlla che il numero di recensioni e il voto medio nello schema coincidano con quelli visibili.
5. Se il markup è statico, valuta di passare a una generazione dinamica collegata al gestionale del catalogo.