Dati strutturati con JSON-LD: esempi da copiare e testare

Risposta breve: i dati strutturati descrivono il contenuto di una pagina in una forma che i motori di ricerca possono leggere direttamente. Google consiglia il formato JSON-LD, un blocco JSON dentro un tag <script type="application/ld+json">. Copia uno dei due esempi qui sotto, sostituisci i valori con example.com con fatti visibili sulla tua pagina e controlla il risultato nel Rich Results Test di Google. Un codice valido rende una pagina idonea ai rich result; che compaiano davvero, Google non lo garantisce.

Che cosa sono i dati strutturati e che cosa fa Google con JSON-LD?

Google definisce i dati strutturati come «a standardized format for providing information about a page and classifying the page content» (Google), cioè un formato standard per fornire informazioni su una pagina e classificarne il contenuto. Gran parte del vocabolario viene da schema.org, e JSON-LD è uno dei tre modi per scriverlo. Gli altri due, Microdata e RDFa, aggiungono attributi al codice HTML visibile. JSON-LD tiene invece tutto in un blocco separato, che puoi aggiungere o riparare senza toccare il layout.

Secondo Google tutti e tre i formati vanno ugualmente bene, purché il markup sia valido e implementato correttamente. Consiglia comunque JSON-LD, se la tua configurazione lo permette, perché è «the easiest solution for website owners to implement and maintain at scale», la soluzione più semplice da realizzare e da mantenere su larga scala (Google).

Che cosa puoi ottenere: Google scrive che i dati strutturati «can enable search results that are more engaging to users», e chiama rich result questi risultati. Tiene una galleria delle funzionalità supportate, tra cui Article, Breadcrumb, Event, Organization, Product e Recipe. Un altro punto dall’introduzione di Google: per capire come si comporta la Ricerca conta la documentazione di Google, non quella di schema.org, che conosce più attributi e oggetti di quanti ne usi Google Search.

Prima di scrivere una riga di codice valgono tre regole tratte dalle linee guida generali sui dati strutturati di Google:

• Descrivi la pagina in cui si trova il markup, e solo ciò che i visitatori vi vedono.
• Non bloccare a Googlebot le pagine che contengono dati strutturati, né con robots.txt né con noindex o simili.
• Compila ogni proprietà obbligatoria del tipo che usi. Gli elementi a cui ne manca una «are not eligible for rich results».

Esempio 1: Organization per la tua home page

Google consiglia di mettere il markup Organization sulla home page oppure su un’unica pagina che descrive l’organizzazione, come «Chi siamo». Non serve su ogni pagina (Google). Il tipo non ha proprietà obbligatorie; Google consiglia di aggiungere quelle consigliate che ti riguardano. Sostituisci ogni valore:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Esempio Biciclette",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "Esempio Biciclette costruisce biciclette su misura.",
  "email": "contatti@example.com"
}
</script>

Che cosa fanno le proprietà, secondo la pagina di Google:

• name: usa lo stesso nome che usi come nome del sito.
• url: l’indirizzo del tuo sito, che aiuta Google a riconoscere in modo univoco l’organizzazione.
• logo: almeno 112 × 112 px, scansionabile e indicizzabile. Può aiutare Google a decidere quale logo mostrare nei risultati di ricerca e nei knowledge panel.
• description e email: dettagli facoltativi. Aggiungi address, contactPoint o sameAs (la pagina di un profilo su un altro sito) solo se ti riguardano.

Se si adatta un sottotipo più specifico, Google consiglia di usarlo, per esempio OnlineStore per un negozio o un sottotipo di LocalBusiness per un ristorante.

Esempio 2: Article e breadcrumb per un articolo del blog

Google capisce più elementi su una stessa pagina, che tu li annidi o li elenchi separatamente (Google). Questo esempio elenca due elementi in un array JSON, ciascuno con il proprio @context, il modello che Google mostra per i singoli elementi:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Come scegliere un casco da bici",
    "image": [
      "https://www.example.com/photos/casco-16x9.jpg",
      "https://www.example.com/photos/casco-4x3.jpg",
      "https://www.example.com/photos/casco-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "Mario Rossi",
        "url": "https://www.example.com/team/mario-rossi"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "Ciclismo", "item": "https://www.example.com/blog/ciclismo" },
      { "@type": "ListItem", "position": 3, "name": "Come scegliere un casco da bici" }
    ]
  }
]
</script>

Article. Google accetta Article, NewsArticle e BlogPosting. Non indica proprietà obbligatorie e consiglia author, datePublished, dateModified, headline e image, per aiutare Google a «show better title text, images, and date information» (Google). Scrivi le date in formato ISO 8601 con il fuso orario; senza, Google usa il fuso orario di Googlebot. Elenca ogni autore come voce a sé, con tipo, nome e URL. Tieni breve il titolo (headline), perché «long titles may be truncated on some devices». Per le immagini Google consiglia più file ad alta risoluzione nei rapporti 16x9, 4x3 e 1x1, pertinenti all’articolo e non loghi.

Breadcrumb. Qui le regole sono rigide. Una BreadcrumbList richiede almeno due voci ListItem, e ognuna di norma ha bisogno di position, name e item (l’indirizzo). Solo l’ultima può omettere item; in quel caso Google usa l’indirizzo della pagina stessa (Google). Google consiglia un percorso tipico dell’utente e non una copia della struttura degli URL, e indica la funzionalità come disponibile su desktop. La nostra lettura delle linee guida: mostra lo stesso percorso anche sulla pagina, perché il markup per cose che i lettori non vedono non è consentito.

Come testi JSON-LD prima e dopo la pubblicazione?

1. Rich Results Test (search.google.com/test/rich-results). Google lo chiama «the official Google tool for testing your structured data». La pagina dello strumento accetta un indirizzo oppure del codice incollato, quindi puoi provare un esempio prima che vada online. Correggi prima gli errori critici; secondo Google i suggerimenti non critici sono facoltativi per l’idoneità.
2. Schema Markup Validator (validator.schema.org). La pagina di Google sui test lo descrive come uno strumento che controlla tutto il markup basato su schema.org «without Google feature specific warnings». Usalo quando nessuna funzionalità di Google si adatta al tuo tipo.
3. Controllo URL in Search Console, dopo aver pubblicato qualche pagina. Google ti chiede di verificare che la pagina non sia bloccata da robots.txt, noindex o un login; la scansione di una pagina nuova può richiedere diversi giorni.
4. Report sui rich result in Search Console. Google osserva che il markup può rompersi dopo la pubblicazione a causa dei template o di problemi di erogazione, quindi ricontrolla dopo ogni modifica ai template (Google).

Come abbiamo controllato i due esempi qui sopra il 4 novembre 2026: entrambi i blocchi vengono letti come JSON valido (modulo json di Python), e le proprietà seguono le pagine di Google su Organization, Article e Breadcrumb (ultimo aggiornamento 8 settembre 2026). Non li abbiamo incollati nello strumento di Google, quindi il primo tentativo con il tuo codice è il vero test.

Che cosa non fa JSON-LD

• Non garantisce un rich result. Google scrive: «Google does not guarantee that your structured data will show up in search results» (Google). Tra i motivi, il fatto che l’algoritmo può ritenere più adatto un risultato di solo testo e che il markup può essere sbagliato in modi che il test non rileva.
• Non è una promessa di posizionamento. Su queste pagine di Google non abbiamo trovato alcuna affermazione secondo cui i dati strutturati migliorino le posizioni. Google descrive il vantaggio come idoneità ai rich result. Un’azione manuale sui dati strutturati, aggiunge Google, toglie questa idoneità e «doesn't affect how the page ranks in Google web search».
• Le risposte di IA non ne hanno bisogno. La guida di Google alle funzionalità di IA generativa dice: «Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add» (Google). Per l’idoneità ai rich result la considera comunque una buona idea. SEOgrinder non misura se un sistema di IA nomini il tuo sito.
• Il markup FAQ non ha più un risultato su Google. Il registro delle modifiche di Google dice: «This feature will no longer appear in Google Search starting May 7, 2026» (Google). Non aggiungere markup FAQPage per questo scopo.

Errori comuni: 5 errori con JSON-LD

1. Contrassegnare ciò che nessuno vede

La linea guida di Google: «Don't mark up content that is not visible to readers of the page.» L’esempio di Google stesso: se il markup descrive un artista, il testo della pagina deve descrivere proprio quell’artista.

2. JSON rotto

Un solo errore di sintassi rende inutilizzabile l’intero blocco. Il report sui dati strutturati non analizzabili di Google in Search Console (in inglese «Unparsable structured data report») cita tipi di errore come una virgola o una parentesi di chiusura mancante, i due punti mancanti e una sequenza di escape non valida in una stringa, per esempio un backslash isolato come \q dentro un valore di testo. Il consiglio di Google per trovare l’errore: parti da un oggetto vuoto e reinserisci il codice un pezzo alla volta.

3. Proprietà obbligatorie mancanti

Secondo Google, gli elementi privi delle proprietà obbligatorie non sono idonei ai rich result. Il caso più frequente sono le voci breadcrumb senza position, name o item.

4. Un tipo che non corrisponde alla pagina

Google chiede il tipo applicabile più specifico. I suoi esempi di markup non pertinente: un sito di streaming sportivo che etichetta le trasmissioni come eventi locali e un sito di falegnameria che etichetta le istruzioni come ricette.

5. Bloccare la pagina o le sue immagini

Le pagine con dati strutturati devono restare aperte a Googlebot, e gli URL delle immagini nel markup devono essere scansionabili e indicizzabili. Una regola Disallow per la cartella delle immagini può annullare un markup curato.

Come controlla SEOgrinder i dati strutturati?

SEOgrinder è il nostro strumento, e lo costruiamo noi. Analizza una pagina, apri la scheda «Pagina su Google» e guarda due riquadri. «Dati strutturati» elenca i tipi trovati in JSON-LD e Microdata. «Controllo dei campi» conta le entità e mostra quante sono «Non valide» (manca un campo obbligatorio) o «Incomplete» (mancano solo campi consigliati), con i nomi dei campi mancanti. Nell’elenco delle attività compaiono come «Ai dati strutturati mancano campi obbligatori», «Dati strutturati incompleti», «Nessun dato strutturato» e, per il codice che non si riesce a leggere, «Un blocco di dati strutturati rotto». Dopo una correzione premi Ricontrolla.

Quattro limiti. SEOgrinder legge l’HTML che il tuo server consegna, quindi non vede il JSON-LD che solo uno script aggiunge nel browser, anche se Google lo sa leggere. Legge JSON-LD e Microdata, non RDFa. Conosce i campi obbligatori di un elenco di tipi comuni, non di ogni tipo. E non decide se Google mostrerà un rich result: quell’anteprima la dà il Rich Results Test.

Abbiamo letto le nostre pagine nello stesso modo il 4 novembre 2026. Questo comando stampa 1 per un articolo e 0 per la home page:

curl -sS https://seogrinder.com/it/blog/checklist-audit-seo | grep -c 'application/ld+json'

L’unico blocco dell’articolo contiene un BlogPosting e una BreadcrumbList con tre voci (SEOgrinder, Blog, l’articolo). Sulla home page non abbiamo dati strutturati.

Domande frequenti

JSON-LD è meglio di Microdata?

Per Google tutti e tre i formati sono equivalenti, se il markup è valido. Consiglia JSON-LD perché è il più semplice da inserire e da mantenere su larga scala.

Mi servono dati strutturati su ogni pagina?

No. Aggiungi un tipo solo dove si adatta alla pagina: Organization sulla home page o su «Chi siamo», Article sugli articoli. Per molte pagine non esiste un tipo adatto, e va bene così.

Posso aggiungere JSON-LD con un plugin o con JavaScript?

Sì. Google scrive che in un CMS spesso trovi una pagina di impostazioni o un plugin per i dati strutturati e che Google sa leggere il JSON-LD inserito tramite script (Google). Controlla il risultato con il Rich Results Test e ricorda che SEOgrinder vede solo ciò che il server consegna.

JSON-LD migliora il mio posizionamento?

Le pagine di Google descrivono l’idoneità ai rich result, non posizioni migliori. Nessuno può promettere un posizionamento.

Il prossimo passo

Scegli la pagina che conta di più. Incolla l’esempio 1 o 2 nel Rich Results Test con i tuoi valori e correggi ciò che segnala. Pubblica, poi analizza la pagina con SEOgrinder, apri «Pagina su Google» e leggi il riquadro «Controllo dei campi». Per il quadro più ampio, la nostra checklist audit SEO mostra dove stanno i dati strutturati tra gli altri controlli.

Per approfondire

• Title tag: lunghezza, keyword all’inizio e 5 esempi prima e dopo
• Lunghezza meta description: quanto deve essere lunga (+ 3 esempi)
• SEO checker WordPress: 6 cose da leggere nella pagina, non nel plugin