JSON-LD e SEO

TL;DR — JSON-LD è un piccolo blocco di codice che aggiungi a una pagina per spiegare di cosa tratta la pagina — che sia un articolo, un prodotto, una ricetta — in un formato che i motori di ricerca e i sistemi di intelligenza artificiale leggono facilmente. Si trova nel suo tag <script> e non cambia mai nulla di ciò che i visitatori vedono. Google lo consiglia rispetto agli altri due formati perché è il più semplice da aggiungere e mantenere in ordine. Non ti farà posizionare più in alto, ma può rendere i tuoi risultati più ricchi (stelle, prezzi, FAQ).

Cos’è JSON-LD

Quando pubblichi una pagina, una persona può leggerla e capire: «questa è una ricetta per il pane alla banana». Un motore di ricerca deve dedurlo dalle parole. I dati strutturati eliminano questa ambiguità: descrivi la pagina con codice leggibile dalle macchine, così i motori sanno che è una ricetta, chi è l’autore e qual è la valutazione.

JSON-LD è il modo più popolare per scrivere quell’etichetta. Il nome indica una notazione a oggetti JavaScript per dati collegati. Evidence for this claim JSON-LD is a structured-data format that can express Schema.org types and properties in a script block. Scope: Schema.org JSON-LD guidance; JSON-LD is a format, not the vocabulary itself. Confidence: high · Verified: 2026-07-14 Schema.org: JSON-LD Non devi sapere cosa significhi per usarlo. In pratica, JSON-LD è un blocco di codice che sembra un elenco di fatti etichettati, racchiuso in un tag <script>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Bake Banana Bread",
  "author": { "@type": "Person", "name": "Patrick Stox" },
  "datePublished": "2026-06-26"
}
</script>

Il punto chiave: quel blocco vive separatamente dalle parole sulla tua pagina. Non cambia una sola cosa di ciò che i tuoi visitatori vedono. Sono solo istruzioni per i robot.

Perché piace a Google

In realtà ci sono tre modi per scrivere dati strutturati — JSON-LD, Microdata e RDFa. Gli altri due funzionano spargendo codice extra nel tuo HTML visibile, intrecciato con titoli e paragrafi. JSON-LD tiene tutto in un unico contenitore ordinato.

Ecco perché Google consiglia JSON-LD: è il più semplice da aggiungere, il più semplice da mantenere corretto, e hai molte meno probabilità di rompere qualcosa. Nelle parole di Google, è “the easiest solution for website owners to implement and maintain at scale.” (traduzione) «la soluzione più semplice da implementare e mantenere su larga scala per i proprietari di siti web». Tutti e tre i formati vanno bene — JSON-LD è solo quello meno soggetto a errori.

Cosa fa davvero per te

Due cose oneste e un mito:

• Può rendere il tuo risultato di ricerca più ricco. Valutazioni di ricette, prezzi di prodotti, menu a tendina delle FAQ, date di eventi — quei “rich results” derivano dai dati strutturati.
• Aiuta i motori (e l’IA) a capire i tuoi contenuti. Collega la tua pagina a cose note — la tua attività, un autore, un prodotto.
• Non ti fa posizionare più in alto. Questo è il mito. Aggiungere JSON-LD non è un aumento del posizionamento. Google lo ha detto chiaramente e ripetutamente.

L’unica regola che conta

Contrassegna solo ciò che è effettivamente sulla pagina. Non dichiarare una valutazione a 5 stelle nel tuo JSON-LD se nessuna valutazione è mostrata ai visitatori. Non descrivere un prezzo che non c’è. I dati strutturati devono corrispondere alla pagina visibile — descrivere cose che non ci sono è contro le regole e può farti rimuovere i rich results.

Vuoi la versione precisa — la sintassi @context / @type / @id, il pattern @graph, la trappola dell’iniezione JavaScript che nasconde il tuo markup ai crawler IA, e come validarlo? Passa alla scheda Avanzate.

TL;DR — JSON-LD è una raccomandazione W3C del 2014: usa la sintassi JSON, mentre @context gli consente di esprimere dati collegati. Google raccomanda questo formato di dati strutturati perché è facile da implementare e mantenere su larga scala e non modifica l’HTML visibile; Microdata e RDFa sono ugualmente validi quando corretti. La struttura sintattica comprende @context (il vocabolario — di norma schema.org per il markup SEO, anche se la specifica consente altri contesti), @type (l’entità) e @id (un URI stabile, utile ma facoltativo, per i riferimenti incrociati tra entità — alla base di @graph, uno schema valido tra altri, non un requisito). Puoi inserirlo in <head> o <body>: Google accetta entrambi. Googlebot esegue JavaScript, quindi il JSON-LD inserito dinamicamente funziona per Google; diversi crawler IA, tra cui GPTBot e ClaudeBot nei test citati, non lo hanno eseguito. Poiché il comportamento dipende dal fornitore e dalla data, verifica il crawler pertinente e renderizza lato server ciò che non puoi confermare. I dati strutturati non sono un segnale di ranking: determinano l’idoneità ai risultati avanzati e aiutano a comprendere le entità, ma devono descrivere contenuti visibili sulla pagina.

JSON-LD è un formato, non un vocabolario

Prima di tutto, una distinzione che chiarisce molta confusione: JSON-LD è il formato; schema.org è il vocabolario. JSON-LD è come scrivi il markup; i tipi Article, Product, Organization di schema.org sono cosa dici. I rich result sono il livello di funzionalità sopra entrambi. Questa pagina riguarda il formato. (L’angolazione del vocabolario per l’AI vive in Schema Markup for AI.)

JSON-LD è una raccomandazione W3C, pubblicata per la prima volta nel 2014 — precede la sua adozione SEO ed è stato progettato per l’interoperabilità generale dei linked data sul web, non specificamente per la ricerca. Questa storia è il motivo per cui esiste una proprietà come @id, ed è il punto a livello di specifica che la maggior parte delle guide SEO salta: JSON-LD non è solo JSON. È costruito sulla sintassi JSON, ma la dichiarazione @context è ciò che rende i dati collegati — identificabili e collegabili attraverso il web. Rimuovi @context e hai dati che un parser non può interpretare.

JSON-LD non è nemmeno legato a schema.org. La specifica consente a @context di fare riferimento a qualsiasi vocabolario pubblicato — i suoi stessi esempi collegano a contesti non schema.org — quindi JSON-LD è la risposta giusta a “quale formato” mentre schema.org è una risposta, quella comune per il markup di ricerca e AI-search, a “quale vocabolario.” Una pagina potrebbe validamente usare JSON-LD con un vocabolario diverso; semplicemente non sarebbe più markup schema.org.

Confronto tra JSON-LD, Microdata e RDFa

Ci sono tre modi per esprimere dati strutturati, e Google li supporta tutti:

La raccomandazione di Google è esplicita ma di portata limitata: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (traduzione) «In generale, Google raccomanda di usare JSON-LD per i dati strutturati se la configurazione del tuo sito lo consente, poiché è la soluzione più semplice per i proprietari di siti web da implementare e mantenere su larga scala (in altre parole, meno soggetta a errori degli utenti).»

La sfumatura che i concorrenti di solito tralasciano — e quella che vale la pena mantenere — proviene dalla stessa pagina di Google: “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (traduzione) «Tutti e 3 i formati vanno ugualmente bene per Google, purché il markup sia valido e implementato correttamente secondo la documentazione della funzionalità.» Quindi la raccomandazione riguarda la facilità di implementazione e il tasso di errore, non la velocità di parsing o un vantaggio di ranking. Usare Microdata non è una penalità. JSON-LD vince solo in pratica perché non intreccia i dati strutturati con il markup che un designer potrebbe modificare domani.

La sintassi: @context, @type, @id, proprietà, annidamento

Ecco un blocco Article annotato:

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>

• @context — stabilisce il quadro semantico (il vocabolario). Per il markup SEO di schema.org è tipicamente "https://schema.org", ma è una convenzione, non una regola: @context mappa i termini agli identificatori e la specifica consente di puntare ad altri vocabolari. Dice al parser come interpretare ogni nome di proprietà che segue. Questa è la parte che lo rende dato collegato.
• @type — dichiara l’entità: Article, Product, Organization, BreadcrumbList, ecc. Si mappa a un tipo di schema.org. Usa il tipo applicabile più specifico — NewsArticle invece di Article se si adatta.
• @id — un URI univoco che identifica la risorsa. È il meccanismo che ti consente di fare riferimento a un’entità da un’altra (vedi @graph sotto) e vale la pena impostarlo su qualsiasi cosa a cui farai riferimento incrociato — ma non è universalmente richiesto. La specifica JSON-LD consente nodi vuoti non identificati, quindi un JSON-LD valido può omettere @id su entità a cui non devi mai fare riferimento altrove.
• Proprietà — normali coppie chiave/valore JSON, che usano termini del vocabolario dal @context.
• Annidamento — le entità figlie sono espresse come oggetti JSON annidati (l’oggetto author sopra) o array di oggetti.

Il pattern @graph (l’approccio scalabile)

La maggior parte delle pagine necessita di più di un’entità: un’Organization, un WebSite, una BreadcrumbList e l’Article o WebPage stesso. L’approccio ingenuo è quattro blocchi <script> separati che ripetono i dati. Un’alternativa scalabile è un singolo blocco con @graph — un array di entità, con riferimenti incrociati tramite @id. Né la specifica JSON-LD né Google impongono @graph come il pattern — è sintassi per esprimere un grafo, e esistono altri layout validi (blocchi tipizzati separati, oggetti annidati senza un @graph di livello superiore, nodi vuoti senza alcun @id) — ma su un sito con diverse entità con riferimenti incrociati, è il pattern che evita di ripetere gli stessi dati di Organization o WebSite su ogni pagina:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Definisci Organization una volta, poi punta ad essa con { "@id": "...#org" } ovunque altro invece di ripetere nome, logo e URL. È così che i principali plugin schema dei CMS costruiscono il loro output, ed è il motivo per cui esiste @id. Bing fa lo stesso ragionamento per l’annidamento di JSON-LD: “makes defining links and relationships between data and entities… easy because it supports nested data.” (traduzione) «rende facile definire collegamenti e relazioni tra dati ed entità… perché supporta dati annidati.»

Dove posizionarlo: <head> o <body>

Google conferma che entrambi funzionano — “You can put the JSON-LD data in the <head> or the <body> of the page.” (traduzione) «Puoi mettere i dati JSON-LD nella <head> o nel <body> della pagina.» <head> è convenzionale, ma molti plugin CMS lo iniettano vicino alla fine del <body>, e va bene. Bing concorda che può stare “in the header, body or foot of the page.” (traduzione) «nella testata, nel corpo o nel piè di pagina.» Non perdere tempo a spostare un blocco valido dal body alla head; non cambia nulla. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: 2026-07-14 Google: Structured data introduction

Generare JSON-LD dinamicamente — e l’inghippo del crawler AI

Puoi costruire JSON-LD al volo con JavaScript, e Google documenta due modi per farlo:

1. Google Tag Manager — un tag HTML personalizzato contenente il JSON-LD, che recupera i valori dalle variabili GTM. (Evita di duplicare i dati tra la pagina e il tag.)
2. JavaScript personalizzato — crea l’elemento script in modo programmatico:

   const script = document.createElement('script');
   script.setAttribute('type', 'application/ld+json');
   script.textContent = structuredDataText;
   document.head.appendChild(script);

Questo funziona per Googlebot, perché Google esegue il rendering della pagina: “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (traduzione) «Google Search può comprendere ed elaborare i dati strutturati disponibili nel DOM quando esegue il rendering della pagina.» Fin qui, tutto bene.

Ecco il punto che la maggior parte delle guide tralascia, detto con cautela. Diversi crawler IA — tra cui GPTBot e ClaudeBot nei test citati — non hanno eseguito JavaScript. Se il tuo JSON-LD esiste solo dopo l’esecuzione di uno script lato client, un crawler che salta JavaScript non lo vede mai — è invisibile per quel bot anche se Googlebot lo legge perfettamente, perché Google documenta il rendering del DOM prima di cercare i dati strutturati.

Due avvertenze oneste su quel comportamento dei crawler AI: è la documentazione di Google stessa a stabilire il lato Googlebot; il lato crawler AI deriva da test e segnalazioni su singoli provider, non da una specifica pubblicata da alcuno di essi, quindi è specifica per provider e data — il supporto JavaScript di un crawler può cambiare, e io non ho verificato direttamente ogni provider. Non trattare “i crawler AI saltano JavaScript” come una regola universale su cui costruire; trattalo come un motivo per verificare il crawler che ti interessa davvero (o per ripiegare sul rendering lato server quando non puoi verificare). Se non è nell’HTML renderizzato lato server e non hai confermato che il crawler esegua JavaScript, presupponi che non possa vederlo. Per la visibilità nella ricerca AI, esegui il rendering del JSON-LD lato server nell’HTML statico a meno che tu non abbia verificato diversamente. (Questo è il problema del rendering JavaScript da una prospettiva di dati strutturati — vedi JavaScript SEO.)

C’è una seconda avvertenza per l’ecommerce: Google avverte che il markup Product generato dinamicamente “can make Shopping crawls less frequent and less reliable,” (traduzione) «può rendere le scansioni di Shopping meno frequenti e meno affidabili,» che è un problema reale per prezzi e disponibilità in rapido cambiamento. Per i prodotti, preferisci il rendering lato server indipendentemente dall’AI.

Le policy (ora hanno mordente)

Le linee guida sui dati strutturati di Google sono brevi e fondamentali:

• “Don’t mark up content that is not visible to readers of the page.” (traduzione) «Non applicare markup a contenuti che non sono visibili ai lettori della pagina.»
• “Don’t mark up irrelevant or misleading content, such as fake reviews.” (traduzione) «Non applicare markup a contenuti irrilevanti o fuorvianti, come recensioni false.»
• “Put the structured data on the page that it describes.” (traduzione) «Inserisci i dati strutturati nella pagina che descrivono.»
• “Use the most specific applicable type and property names defined by schema.org.” (traduzione) «Usa il tipo applicabile più specifico e i nomi delle proprietà definiti da schema.org.»
• Non bloccare le tue pagine con dati strutturati da Googlebot tramite robots.txt o noindex.

La regola del contenuto visibile è quella da interiorizzare. Lo schema che descrive contenuti non mostrati sulla pagina è sempre stato una violazione; l’applicazione dello schema “invisibile” si è inasprite. Bing lo dice senza mezzi termini: “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (traduzione) «anche se il markup non è visibile sulla tua pagina, viene comunque letto dai motori di ricerca, e inserire dati spam nel markup può ostacolare la tua presenza.»

Errori comuni nel JSON-LD

• Markup che non corrisponde alla pagina visibile — il problema politico n. 1 (una valutazione nel JSON-LD che nessun visitatore vede).
• JSON malformato — una virgola finale, una virgoletta non escapata o virgolette intelligenti di Word (" invece di ") che rompono silenziosamente l’intero blocco. JSON-LD è rigoroso.
• Nomi di proprietà errati — inventare proprietà che non sono in schema.org, o scrivere male quelle reali, così il parser le ignora.
• Un tipo generico dove ne esiste uno specifico — Thing o Article dove Recipe o NewsArticle erano appropriati.
• Blocchi Organization duplicati e incoerenti tra pagine con nomi/loghi in conflitto.
• Proprietà richieste mancanti per il rich result che stai mirando (ogni funzionalità elenca i propri campi obbligatori).
• Markup iniettato via JS assunto come visibile a ogni crawler — Google lo renderizza, ma alcuni crawler AI non lo hanno fatto, e vale la pena verificarlo per ogni crawler (il problema sopra).

Validazione di JSON-LD

Quattro domande diverse vengono poste sotto “il mio JSON-LD è valido”, e non sono la stessa domanda — superarne una non supera le altre:

• Testa per URL, non con codice incollato, per pagine renderizzate via JS. La modalità di input del codice del Rich Results Test non esegue i tuoi script né risolve i riferimenti relativi come fa il test con URL live — non può dirti come appare un blocco iniettato lato client dopo la renderizzazione.
• Bing Webmaster Tools — Markup Validator — Bing ha validato JSON-LD da agosto 2018.
• Nessuno di questi test parla per i crawler che non renderizzano JavaScript (vedi l’avvertenza sui crawler AI sopra) — testare l’URL renderizzato conferma cosa vede Google, non cosa riceve un bot che salta JS.

JSON-LD aiuta la SEO?

Imposta le aspettative onestamente:

• Non è un segnale di ranking. John Mueller ha detto che i dati strutturati non faranno classificare meglio un sito. Punto.
• Idoneità per i rich result. È ciò che ti rende idoneo per funzionalità SERP avanzate (stelle, prezzi, FAQ, breadcrumb) — idoneità, non una garanzia.
• CTR, indirettamente. Risultati dall’aspetto più ricco possono ottenere più clic, che è il vero guadagno per la maggior parte dei siti.
• Comprensione delle entità. Aiuta i motori a collegare la tua pagina a entità note e al Knowledge Graph.
• Ricerca AI. Fabrice Canel (Bing) ha confermato nel 2025 che il markup schema aiuta gli LLM di Microsoft a comprendere i contenuti — ma nota l’avvertenza dello studio controllato in Schema Markup for AI: è infrastruttura per la disambiguazione, non una leva diretta per le citazioni.

Quindi: implementa JSON-LD per l’idoneità ai rich result, la chiarezza delle entità e la comprensione AI/LLM — non come un trucco per il ranking.

Questo articolo fa parte dell’hub structured data. Per l’approccio specifico all’IA sul vocabolario schema.org, vedi Schema Markup for AI; per i meccanismi di rendering dietro l’iniezione dinamica, vedi JavaScript SEO.

Riepilogo AI

Una sintesi della versione Advanced:

• Cos’è: JSON-LD è un formato di dati strutturati, non un vocabolario — un blocco <script type="application/ld+json">. Sul lato SEO è tipicamente abbinato al vocabolario schema.org, ma @context può puntare altrove. Raccomandazione W3C dal 2014; basato su JSON, ma @context è ciò che gli consente di esprimere dati collegati, non semplice JSON.
• Perché Google lo raccomanda: è “the easiest solution… to implement and maintain at scale” (traduzione) «la soluzione più semplice da implementare e mantenere su larga scala» e non tocca mai l’HTML visibile. Ma tutti e tre i formati (JSON-LD, Microdata, RDFa) sono ugualmente validi quando corretti — il vantaggio è il tasso di errore, non il parsing o il ranking.
• Struttura sintattica: @context (vocabolario — schema.org per la maggior parte del markup SEO, non l’unico valore valido) · @type (entità, usa la più specifica) · @id (utile, URI stabile opzionale per riferimenti incrociati; nodi anonimi non identificati sono anche JSON-LD valido) · proprietà (chiave/valore) · annidamento (oggetti/array).
• Struttura @graph: un blocco, un array di entità collegate tramite riferimenti @id — definisci Organization una volta e richiamala ovunque. È un approccio scalabile per pagine con più entità, non un requisito della specifica né di Google; esistono altre strutture di grafo valide.
• Posizionamento: <head> o <body> — Google accetta entrambi; non spostare blocchi validi.
• Inserimento dinamico + avvertenza IA: Googlebot esegue JavaScript, quindi il JSON-LD inserito funziona per Google; diversi crawler IA — tra cui GPTBot e ClaudeBot nei test citati — non hanno eseguito JS, ma questo dipende dal fornitore e dalla data, non è una regola universale; verifica quindi ogni crawler e renderizza lato server ciò che non puoi confermare. Il markup dinamico Product rischia anche scansioni Shopping meno frequenti.
• Norme: applica il markup solo a contenuti visibili; fai in modo che corrisponda alla pagina; usa il tipo più specifico; non bloccare la pagina ai crawler. L’applicazione dello schema “invisibile” è stata rafforzata.
• Errori comuni: markup non corrispondente/invisibile, JSON malformato (virgolette intelligenti, virgole finali), nomi di proprietà errati, tipi generici, proprietà obbligatorie mancanti.
• Validazione: quattro controlli separati (sintassi JSON, vocabolario schema.org, idoneità ai risultati avanzati di Google, analisi dei dati live in Search Console) che non si sostituiscono a vicenda — Rich Results Test (per URL, non codice incollato), Schema.org Validator, GSC Enhancements, Bing Markup Validator.
• Effetto SEO: non è un segnale di ranking. Determina l’idoneità ai risultati avanzati, il CTR, la comprensione delle entità e la comprensione da parte degli LLM (Canel, Bing, 2025).

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca e dalla specifica.

Google

• Introduzione al funzionamento del markup dei dati strutturati — la raccomandazione JSON-LD, la sfumatura “tutti e 3 i formati sono ugualmente validi” e il posizionamento <head>/<body>.
• Linee guida generali sui dati strutturati — le politiche: solo contenuto visibile, corrispondenza con la pagina, tipo più specifico, non bloccare i crawler.
• Generare dati strutturati con JavaScript — gli approcci di inserimento tramite GTM e JavaScript personalizzato, più l’avvertenza sulle scansioni Shopping per Product dinamico.
• Test dei risultati avanzati — valida l’idoneità (testa per URL per pagine renderizzate con JavaScript).

Bing / Microsoft

• Aggiungere dati strutturati al sito — Bing consiglia JSON-LD, accetta il posizionamento in intestazione, corpo o piè di pagina e mette in guardia dal markup non valido.
• Introduzione del supporto JSON-LD in Bing Webmaster Tools (agosto 2018) — quando Bing ha aggiunto la validazione JSON-LD.

Standard / vocabolario

• JSON-LD 1.1 — Raccomandazione W3C — la specifica stessa.
• json-ld.org — la casa del formato, con la definizione in linguaggio semplice.
• Primi passi con Schema.org — il vocabolario che JSON-LD esprime e la regola del contenuto visibile.
• Validatore di Schema.org — valida rispetto al vocabolario.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google, Bing e della specifica. Ogni link salta al passaggio citato nella pagina di origine dove la pagina espone il testo.

Documenti Google — la raccomandazione e la sfumatura

• “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (traduzione) «In generale, Google consiglia di usare JSON-LD per i dati strutturati se la configurazione del tuo sito lo consente, poiché è la soluzione più semplice da implementare e mantenere su larga scala per i proprietari di siti web (in altre parole, meno soggetta a errori degli utenti).» Vai alla citazione
• “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (traduzione) «Tutti e 3 i formati vanno ugualmente bene per Google, purché il markup sia valido e implementato correttamente secondo la documentazione della funzionalità.» Vai alla citazione
• “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (traduzione) «Google Search può comprendere ed elaborare i dati strutturati disponibili nel DOM quando esegue il rendering della pagina.» Vai alla citazione

Documenti Google — le policy

• “Don’t mark up content that is not visible to readers of the page.” (traduzione) «Non contrassegnare contenuti che non sono visibili ai lettori della pagina.» Vai alla citazione
• “Use the most specific applicable type and property names defined by schema.org.” (traduzione) «Usa i nomi di tipo e proprietà più specifici applicabili definiti da schema.org.» Vai alla citazione

John Mueller, Google — preferenza per JSON-LD e ranking

• “We currently prefer JSON-LD markup. I think most of the new structured data that kind of come out are for JSON-LD first. So that is what we prefer.” (traduzione) «Attualmente preferiamo il markup JSON-LD. Penso che la maggior parte dei nuovi dati strutturati che escono siano pensati prima di tutto per JSON-LD. Quindi è quello che preferiamo.» — Google Webmaster Hangout, marzo 2019. Copertura
• Sul ranking: “Structured data won’t make your site rank better.” (traduzione) «I dati strutturati non faranno posizionare meglio il tuo sito.» — 2025. (Riportato tramite Search Engine Roundtable; verifica la citazione esatta sul post originale.) Copertura

Bing / Microsoft

• JSON-LD “makes defining links and relationships between data and entities between the data present on your pages easy because it supports nested data.” (traduzione) «rende facile definire collegamenti e relazioni tra dati ed entità presenti nelle tue pagine perché supporta dati annidati.» — Documentazione di Bing Webmaster Tools. Vai alla citazione
• “Webmasters should be very alert as to not put invalid and incorrect information in the markup, as even though the markup is not visible on your page, it is still read by the search engines.” (traduzione) «I webmaster dovrebbero essere molto attenti a non inserire informazioni non valide o errate nel markup, perché anche se il markup non è visibile sulla tua pagina, viene comunque letto dai motori di ricerca.» — Documentazione di Bing Webmaster Tools. Vai alla citazione

Fabrice Canel, Microsoft Bing — schema e LLM

• Allo SMX Munich (marzo 2025), Canel ha confermato che il markup schema aiuta i modelli linguistici di grandi dimensioni di Microsoft a comprendere i contenuti web. (Parafrasato in tutta la copertura; conferma verbatim contro la registrazione della conferenza o LinkedIn prima di trattare qualsiasi singola formulazione come definitiva.) Copertura

La specifica — json-ld.org

• “JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.” (traduzione) «JSON-LD è un formato di Linked Data leggero. È facile da leggere e scrivere per gli esseri umani. Si basa sul già affermato formato JSON e fornisce un modo per aiutare i dati JSON a interoperare su scala Web.» Vai alla citazione

Sintassi JSON-LD — riferimento rapido

Il wrapper

<script type="application/ld+json">
{ ...your markup... }
</script>

Le parole chiave riservate

Single entity

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Widget",
  "offers": { "@type": "Offer", "price": "19.99", "priceCurrency": "USD" }
}

Annidamento — un’entità figlia è un oggetto annidato (o un array di oggetti):

"author": { "@type": "Person", "name": "Patrick Stox" }

Il pattern @graph — definisci una volta, riferisci tramite @id:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://ex.com/#org", "name": "Ex Co" },
    { "@type": "WebSite", "publisher": { "@id": "https://ex.com/#org" } }
  ]
}

Proprietà comuni per tipo

• Article / BlogPosting: headline, author, datePublished, image, publisher
• Product: name, image, brand, offers (→ price, priceCurrency, availability)
• Organization: name, url, logo, sameAs (URI social/Wikidata)
• BreadcrumbList: itemListElement → ListItem (position, name, item)
• FAQPage: mainEntity → Question → acceptedAnswer → Answer

Regole pratiche

• @context è "https://schema.org" per la maggior parte del markup SEO — è una convenzione, non un requisito della specifica. Usa virgolette dritte, mai virgolette intelligenti.
• Niente virgole finali — JSON è rigoroso.
• Usa il @type più specifico disponibile.
• Marca solo ciò che è visibile sulla pagina.
• Posiziona in <head> o <body> — entrambi validi.
• @id e @graph aiutano a fare riferimenti incrociati e organizzare le entità ma non sono obbligatori — anche i nodi vuoti e altri layout sono validi.
• Per i crawler che non hai verificato eseguano JavaScript (diversi crawler AI, inclusi GPTBot e ClaudeBot, non lo fanno nei test), esegui il rendering lato server.
• Valida come livelli separati: Rich Results Test (per URL) per l’idoneità di Google + Schema.org Validator per il vocabolario — uno che passa non significa che anche l’altro passi.

Strumenti per validare JSON-LD

• Schema.org Validator — il controllo del vocabolario più ampio. Un blocco può passare qui e fallire comunque le regole specifiche delle funzionalità di Google.
• Google Rich Results Test — testa l’URL distribuito quando il rendering conta, specialmente per il markup iniettato lato client. Questo test copre i rich results supportati da Google, non ogni tipo di schema.org.

Errori JSON-LD da evitare

Contrassegnare fatti che i visitatori non possono vedere. Una valutazione, un prezzo, un autore o un’altra affermazione in JSON-LD deve concordare con la pagina visibile. Dati strutturati nascosti o fuorvianti possono costare alla pagina l’idoneità ai rich result. Invece: genera il markup dalla stessa fonte di verità del contenuto visibile.

Trattare JSON valido come schema valido. Un parser può accettare JSON perfettamente formato i cui nomi di proprietà non esistono in schema.org. Invece: esegui sia un controllo del vocabolario JSON-LD sia i requisiti Google della funzionalità target.

Usare virgolette tipografiche o virgole finali. JSON è rigoroso; le virgolette tipografiche e una virgola dopo l’ultima proprietà possono invalidare l’intero blocco. Invece: serializza i dati piuttosto che assemblare stringhe JSON a mano.

Scegliere un tipo generico quando ne esiste uno specifico. Il markup Thing o Article generico butta via significato utile quando la pagina è chiaramente una Recipe, un Product o una NewsArticle. Invece: usa il tipo schema.org più specifico applicabile.

Duplicare entità con dettagli contrastanti. Più blocchi Organization con nomi, loghi o URL diversi rendono il grafo ambiguo. Invece: assegna all’entità un @id stabile, definiscila una volta e fai riferimento a quell’identificatore altrove.

Presumere che la validità schema.org garantisca un rich result Google. Google supporta un sottoinsieme di tipi e aggiunge proprietà obbligatorie e policy sui contenuti proprie. Invece: valida prima il vocabolario, poi testa l’idoneità per la specifica funzionalità Google.

Iniettare JSON-LD in JavaScript e presumere che ogni crawler lo veda. Google può rendere il markup lato client, ma i crawler AI che saltano JavaScript potrebbero non riceverlo mai. Invece: esegui il rendering lato server del JSON-LD quando quei consumatori contano, e testa l’URL live piuttosto che solo il codice incollato.

Dimostrare che una distribuzione JSON-LD ha avuto effetto

Test 1 — La pagina live contiene JSON-LD valido e corrispondente alla pagina

• Test da eseguire — Recupera l’URL distribuito con il Schema Markup Validator e confronta le entità e i valori rilevati con la pagina visibile.
• Risultato atteso — Il JSON viene analizzato, tutte le proprietà appartengono a schema.org, i riferimenti @id si risolvono all’interno del grafo dove previsto, e affermazioni come nomi, prezzi, valutazioni e date corrispondono a ciò che gli utenti vedono.
• Interpretazione del fallimento — Gli errori del parser indicano JSON malformato; gli avvisi sul vocabolario indicano proprietà errate o non supportate; i valori non corrispondenti indicano che contenuto e dati dello schema provengono da fonti separate che divergono.
• Finestra di monitoraggio — Immediata dopo la distribuzione e la pulizia della cache.
• Trigger di rollback — Rimuovi o ripristina il nuovo blocco se pubblica false affermazioni sul contenuto visibile, rompe un grafo precedentemente valido o non può essere analizzato.

Test 2 — La funzionalità di ricerca target riconosce il markup renderizzato

• Test da eseguire — Esegui l’URL distribuito attraverso il Rich Results Test di Google, poi usa il Rich-Result Eligibility Checker per ispezionare i campi obbligatori e consigliati mancanti per tipo.
• Risultato atteso — Google rileva il tipo supportato previsto senza errori critici; qualsiasi blocco generato lato client appare nell’HTML renderizzato.
• Interpretazione del fallimento — Un passaggio del Schema.org Validator abbinato a un fallimento Google di solito significa che il tipo non è una funzionalità Google supportata, manca un campo richiesto da Google, una policy sui contenuti non è soddisfatta o il renderer non ha mai ricevuto il blocco.
• Finestra di monitoraggio — Immediata in entrambi i test; le modifiche in Search Console attendono una nuova scansione.
• Trigger di rollback — Esegui il rollback dell’iniezione lato client se rende i dati strutturati precedentemente visibili sparire dal risultato renderizzato, o rimuovi le affermazioni di funzionalità non supportate dal lancio finché il contenuto richiesto non è presente.

Mettiti alla prova: JSON-LD

Cinque domande rapide sul formato JSON-LD. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Markup Schema: il modo semplice per ottenere risultati avanzati — la guida Ahrefs ai dati strutturati, ai tipi di Schema e ai risultati avanzati (il livello di funzionalità sopra JSON-LD).
• Guida introduttiva alla SEO tecnica — dove si collocano i dati strutturati nel quadro tecnico più ampio.
• Problemi di SEO JavaScript e buone pratiche — il lato rendering: perché il markup inserito via JavaScript si comporta diversamente per i crawler che non eseguono JavaScript.
• Alla scoperta dei nuovi crawler web — la mia analisi Cloudflare Radar dei crawler IA (GPTBot, ClaudeBot e altri) che saltano il markup Schema inserito via JavaScript.

Ufficiale

• Introduzione al funzionamento del markup dei dati strutturati di Google — la raccomandazione JSON-LD e la sfumatura dei “tutti e 3 i formati”, direttamente dalla fonte.
• Generare dati strutturati con JavaScript di Google — i metodi di inserimento dinamico e l’avvertenza su Product.
• JSON-LD 1.1 — Raccomandazione W3C e json-ld.org — il formato stesso.

Dal settore

• Quali dati strutturati preferisce Google? — Search Engine Journal — l’articolo sul commento di Mueller “we currently prefer JSON-LD” (traduzione) «attualmente preferiamo JSON-LD».
• Microsoft Bing Copilot usa Schema per i suoi LLM — Search Engine Land — la conferma di Fabrice Canel a SMX Monaco 2025 che Schema aiuta gli LLM di Bing.
• Che cosa sono i dati strutturati JSON-LD e perché servono? — Ignite Visibility — una solida guida introduttiva.
• Guida introduttiva allo Schema JSON-LD per SEO — SALT.agency — una guida pratica su sintassi e implementazione rivolta ai professionisti SEO.

Cronologia modifiche