Vai al contenuto principale
Bethemesh
GuidaBuone pratiche

Schema.org e JSON-LD: aggiungere dati strutturati utili senza promettere troppo

Comprendi come Schema.org e JSON-LD descrivono esplicitamente una pagina, quali tipi scegliere, come evitare markup fuorviante e perché i rich result non sono mai garantiti.

Pubblicato 29 agosto 2026Lettura : 3 minDi Team Bethemesh
Intermedio
Mostra indice
  1. Schema.org non è un formato di file
  2. Esempio di JSON-LD
  3. Il markup deve descrivere la pagina reale
  4. JSON-LD non sostituisce il contenuto visibile
  5. Scegliere il tipo più preciso senza forzare
  6. Schema.org e requisiti dei motori sono cose diverse
  7. Un rich result non è garantito
  8. URL e immagini devono essere reali e coerenti
  9. Evitare dati duplicati ma contraddittori
  10. Generare e poi rileggere
  11. Meglio uno schema piccolo ma esatto

Una pagina Web contiene già molte informazioni comprensibili da una persona: titolo, autore, data, prezzo, organizzazione o una sequenza di passaggi. I dati strutturati esprimono alcune di queste informazioni in modo più esplicito per le macchine.

Schema.org fornisce il vocabolario; JSON-LD è uno dei modi più pratici per scriverlo.

Schema.org non è un formato di file

Schema.org definisce tipi e proprietà, per esempio:

Article
Organization
Product
BreadcrumbList
Person
Event

Un Article può avere proprietà come headline, author, datePublished e image. Lo stesso vocabolario può essere rappresentato con sintassi diverse. JSON-LD è comodo perché può essere inserito in un blocco separato dal contenuto HTML visibile.

Esempio di JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Comprendere il SEO tecnico",
  "datePublished": "2026-08-29"
}
</script>

Un generatore può aiutare a costruire questa struttura evitando errori di sintassi, ma non può decidere se i dati dichiarati sono corretti.

Il markup deve descrivere la pagina reale

È la regola più importante. Se una pagina non mostra alcun prezzo, aggiungere un Product con un prezzo inventato per tentare di ottenere un rich result è una cattiva pratica.

Lo stesso vale per recensioni, valutazioni, autori, date, eventi, FAQ e disponibilità. I dati strutturati non devono diventare una seconda versione immaginaria della pagina.

JSON-LD non sostituisce il contenuto visibile

Se il blocco dichiara:

{
  "@type": "Article",
  "headline": "Guida completa a robots.txt"
}

ma la pagina parla quasi esclusivamente di CSS, lo schema non obbliga il motore a credere a quella descrizione. Il markup deve rafforzare informazioni già coerenti con contenuto, title, H1, URL e contesto generale.

Scegliere il tipo più preciso senza forzare

Se la pagina è davvero un articolo, Article è più descrittivo di un’entità generica. Ma non esiste un tipo “più SEO” da scegliere a tutti i costi. La domanda corretta è: quale tipo descrive onestamente questa risorsa?

Una pagina può includere più entità collegate quando ciò riflette la realtà, per esempio un’organizzazione che pubblica un articolo e una BreadcrumbList che descrive la navigazione.

Schema.org e requisiti dei motori sono cose diverse

Schema.org offre moltissime proprietà. I motori che propongono esperienze arricchite possono però richiedere soltanto un sottoinsieme specifico.

vocabolario Schema.org

requisiti di una funzionalità del motore

Un JSON-LD può essere sintatticamente valido ma non idoneo a un particolare rich result.

Un rich result non è garantito

Anche con markup valido, completo, conforme alle linee guida e correttamente indicizzato, il motore può decidere di non mostrare alcun arricchimento. Schema.org non è un pulsante per “attivare le stelle su Google”.

Il beneficio principale è prima di tutto la chiarezza semantica.

URL e immagini devono essere reali e coerenti

Proprietà come url e image devono puntare a risorse accessibili e coerenti con la pagina. Evita, senza una ragione precisa, situazioni come:

canonical : https://example.com/articolo
JSON-LD url : https://example.com/articolo?source=test

Se dichiari un’immagine, verifica che l’URL sia pubblico, che il file esista, che il formato sia utilizzabile e che l’immagine rappresenti davvero il contenuto.

Evitare dati duplicati ma contraddittori

La stessa informazione può apparire in più punti:

H1       → "Guida SEO tecnico"
title    → "SEO tecnico: guida completa"
headline → "Guida SEO 2024"

Una variazione di formulazione è normale; una data o un titolo diventati obsoleti sono invece un problema. In particolare, non dichiarare una nuova data di aggiornamento soltanto perché la pagina è stata ricostruita tecnicamente se il contenuto non è cambiato.

Generare e poi rileggere

Dopo aver generato il JSON-LD controlla sempre:

  1. il tipo scelto;
  2. nomi e date;
  3. URL;
  4. immagini;
  5. proprietà vuote;
  6. corrispondenza con il contenuto visibile.

Meglio uno schema piccolo ma esatto

Aggiungere decine di proprietà aumenta il rischio di dati scaduti, URL incoerenti, campi inventati ed errori durante gli aggiornamenti. Inizia dalle informazioni che puoi mantenere con certezza.

I dati strutturati funzionano meglio come parte del processo di pubblicazione: contenuto finalizzato, URL definitiva, metadati coerenti, JSON-LD pertinente, validazione e controllo della pagina realmente pubblicata.

Strumenti correlati

Fonti e riferimenti

  1. 1.Schema.org
  2. 2.Google Search Central — Structured data

Raccolta

Padroneggiare la SEO tecnica di un sito web

  1. 01SEO tecnica: capire come i motori esplorano e interpretano una pagina
  2. 02Title, meta description, canonical e Open Graph: impostare correttamente i metadati
  3. 03robots.txt: comprendere crawl, indicizzazione ed errori da evitare
  4. 04Schema.org e JSON-LD: aggiungere dati strutturati utili senza promettere troppo
  5. 05Creare URL pulite: slug, parametri e normalizzazione
  6. 06Checklist SEO tecnica prima di pubblicare una pagina Web

Questo articolo ti è stato utile?