2026-01-14 · Redazione Baduno · 7 blog.readMin · Blog & Conoscenza
Dati strutturati: Schema.org spiegato in modo comprensibile
Le informazioni aggiuntive leggibili dalle macchine trasformano i risultati di ricerca in rich snippet con valutazioni, FAQ e dati aziendali. Ecco come funziona.
Cosa sono i dati strutturati
Blocchi JSON invisibili nel codice sorgente descrivono cosa c'è nella pagina: questa è un'azienda con questo indirizzo, questo è un articolo con questa data, questa è una FAQ con queste domande. I motori di ricerca non devono indovinare – leggono.
Cosa offre
Idoneità per visualizzazioni avanzate (estratte FAQ, breadcrumb, pannello organizzazione), migliore comprensione delle relazioni e voci più pulite nel Knowledge Graph. Non un turbo di ranking – ma più spazio e fiducia nei risultati di ricerca.
I tipi più importanti per le aziende
Organization con dati di registrazione, WebSite, Service o Product con Offer, Article per articoli tecnici, FAQPage e BreadcrumbList. Per il multilingue: ogni versione linguistica porta la propria marcatura tradotta.
Non dimenticare di validare
Il Rich-Results-Test mostra cosa legge Google, lo Schema-Validator controlla la sintassi. Una marcatura errata è peggiore di nessuna – costa fiducia e, nel peggiore dei casi, la visualizzazione avanzata.
Dati strutturati e hreflang: perfetta sinergia per siti multilingue
Una frequente fonte di errore nei siti multilingue è l'uso incoerente di dati strutturati e tag hreflang. Mentre hreflang segnala ai motori di ricerca le alternative linguistiche e regionali di una pagina, i dati strutturati rivelano il tipo di contenuto. I due sono indipendenti ma si completano: una pagina prodotto tedesca dovrebbe sia includere un tag hreflang che punta alla variante inglese, sia contrassegnare nel blocco di dati strutturati lo stesso ID prodotto con offerte e lingue diverse. Importante: ogni versione linguistica riceve il proprio blocco JSON-LD con valori appropriati – altrimenti si creano contraddizioni. Il test Rich Results di Google mostra spesso errori quando, ad esempio, l'organizzazione nella versione tedesca contiene un indirizzo inglese. Pertanto, dopo ogni rollout linguistico, verificate sempre entrambe le marcature in parallelo.
Manutenzione e aggiornamento: chi gestisce i dati?
I dati strutturati non sono un progetto una tantum. Se cambiano prezzi, orari di apertura o dettagli del prodotto, i blocchi JSON-LD devono essere aggiornati. Idealmente, il sistema di gestione dei contenuti si occupa del popolamento dinamico. In assenza di automazione, è necessario un responsabile chiaro nel team – ad esempio il redattore per i dati di articoli e FAQ, lo sviluppatore per i dati organizzativi. Evitate i silos di dati: un numero di telefono obsoleto nel blocco Organization danneggia la fiducia. Pianificate revisioni trimestrali di tutti i dati strutturati, almeno prima di ogni grande rilancio. È utile una dashboard centrale che mostri tutte le pagine marcate e il loro stato di validazione.
Creazione e verifica dei dati strutturati assistite dall'IA
Gli strumenti di IA moderni possono generare automaticamente JSON-LD da testo non strutturato – ad esempio per pagine FAQ o articoli. Ciò accelera il lavoro, ma comporta rischi: l'IA spesso trascura le sfumature contestuali (es. prezzo errato o data obsoleta). Pertanto, la verifica in lingua madre da parte di un redattore è indispensabile. Utilizzate l'IA per la bozza iniziale, poi fate validare i valori da un umano. Anche per siti multilingue, l'IA aiuta con le traduzioni dei dati strutturati, ma i tag hreflang e gli ID specifici della lingua devono essere impostati manualmente. Un approccio collaudato: l'IA crea il blocco standard inglese, un redattore locale corregge e integra i campi specifici del paese.
Le informazioni aggiuntive leggibili dalle macchine trasformano i risultati di ricerca in rich snippet con valutazioni, FAQ e dati aziendali. Ecco come funziona.
Contrassegnare contenuti dinamici: FAQ, recensioni e prodotti
Errori frequenti si verificano nei contenuti dinamici. Le pagine FAQ dovrebbero avere una voce JSON-LD per ogni domanda, non l'intero elenco come un unico oggetto Question. Per le recensioni, la scala di valutazione deve essere indicata correttamente (ad es. bestRating e worstRating). Le pagine prodotto con varianti richiedono blocchi AggregateOffer con tutte le informazioni su prezzo e disponibilità. Utilizzate template nel CMS che generano automaticamente i tipi corretti. Testate ogni pagina dinamica singolarmente con il test Rich Results, poiché gli errori diventano visibili solo con valori concreti. Un errore comune: usare 'Review' invece di 'AggregateRating' per le valutazioni medie.
Combinazione di più tipi Schema.org su una pagina
Su una singola pagina è possibile contrassegnare più tipi Schema.org in parallelo, purché descrivano diversi aspetti del contenuto. Una pagina prodotto potrebbe includere contemporaneamente un blocco Product (con prezzo, disponibilità), un blocco Organization (per il produttore) e un blocco Review (per le valutazioni). È importante che ogni tipo sia in un proprio script JSON-LD o collegato coerentemente tramite @id. Esempio: il blocco Product fa riferimento al blocco Organization con "brand": {"@id": "#organisation"}. Evitate informazioni contraddittorie – ad esempio indirizzi diversi nei blocchi Organization e LocalBusiness. Ogni tipo deve essere contrassegnato correttamente e specifico per lingua: una pagina francese riceve valori francesi in tutti i blocchi. Utilizzate il CMS per gestire i tipi in modo modulare, in modo da non dover adattare manualmente ogni blocco. Verificate con il Rich-Results-Test se tutti i blocchi vengono accettati – alcuni test mostrano solo il primo blocco. Una combinazione pulita di più tipi aumenta le probabilità di ottenere risultati avanzati come carosello, box prodotto o pannello organizzazione.
Lavorare con @id e riferimenti per dati collegati
Schema.org consente di referenziare oggetti tramite @id, evitando così dati ridondanti. Invece di ripetere l'intera organizzazione su ogni pagina, definite un blocco Organization centrale con un @id univoco (ad es. "https://esempio.de/#azienda") e fate riferimento ad esso in altri blocchi tramite "@id": "https://esempio.de/#azienda". Ciò è particolarmente utile per siti multilingua: l'organizzazione rimane la stessa, cambiano solo i campi specifici della lingua come "name" o "description". Assicuratevi che l'@id sia coerente in tutte le versioni linguistiche, quindi lo stesso URI per tedesco, inglese, ecc. I riferimenti possono essere utilizzati anche per autori di articoli, marchi di prodotti o elementi di recensioni. Convalidate con il Schema-Validator che tutti i riferimenti @id siano risolvibili. Un errore: se l'@id referenziato non è definito nello stesso sorgente della pagina o in un'altra pagina, la validazione fallisce. Pertanto, memorizzate le entità centrali in un file globale (ad es. organizzazione.json) e includetelo tramite JavaScript, oppure utilizzate il CMS per l'inclusione dinamica. Una struttura @id pulita facilita ai motori di ricerca il collegamento delle informazioni e migliora la coerenza nel Knowledge Graph.
Contrassegnare correttamente BreadcrumbList: suggerimenti e insidie
Contrassegnare BreadcrumbList può sembrare semplice, ma in pratica si riscontrano spesso errori che compromettono il successo dei rich snippet. Un'implementazione corretta inizia con la comprensione della gerarchia: ogni voce nell'elenco necessita di un oggetto ItemListElement, che a sua volta contiene un oggetto ListItem. Fondamentale è la proprietà position: numera gli elementi in ordine crescente, iniziando con 1 per la home page. Evitate di omettere la home page – anche se non appare nel breadcrumb visibile, dovrebbe essere presente nei dati strutturati. Un errore comune è l'uso di URL assoluti senza considerare la versione linguistica: assicuratevi che l'URL nel breadcrumb punti alla variante linguistica corretta, ad esempio /de/produkte anziché /en/products. Anche la denominazione degli elementi deve essere specifica per lingua – 'Startseite' in tedesco, 'Home' in inglese. Utilizzate il campo name per il testo visualizzato ed evitate abbreviazioni o acronimi che potrebbero essere fraintesi dai motori di ricerca. Dopo l'implementazione, verificate ogni percorso con il Rich-Results-Test, poiché specialmente nei breadcrumb generati dinamicamente è facile scambiare le posizioni o creare voci duplicate. Inoltre, Google mostra al massimo dieci elementi – una navigazione più breve e precisa è quindi preferibile a una eccessivamente lunga.
Oggetti annidati e riferimenti: @id e @context
I dati strutturati complessi utilizzano spesso il collegamento di più tipi tramite riferimenti @id. Un esempio tipico è una pagina Product che contiene sia un Offer che una Review. Invece di inserire tutti i dati in un blocco monolitico, è più pulito definire blocchi separati con valori @id univoci e poi referenziarli. Il valore @id deve essere univoco all'interno della pagina e dell'intero dominio – idealmente utilizzate l'URL assoluto dell'oggetto con un frammento come #product-1. Evitate ID generici come #product, poiché possono causare conflitti su più pagine. Un altro aspetto importante è il @context: di default viene utilizzato il vocabolario Schema.org, ma per estensioni proprietarie è possibile specificare un contesto personalizzato. Fate attenzione che estensioni verificate come health-lifesci o bib non finiscano accidentalmente su pagine commerciali. Per pagine multilingue, i riferimenti @id devono essere specifici per lingua: la pagina prodotto tedesca referenzia l'ID Offer tedesco, non quello inglese. Una tecnica utile è l'uso di @reverse per relazioni inverse, ad esempio quando un Product fa riferimento a un'Organizzazione, ma l'Organizzazione non mantiene un elenco diretto di tutti i prodotti. Testate tali concatenazioni nel validatore Schema, poiché anche un solo due punti mancante causa un errore di validazione. Prevedete tempo sufficiente per il debug degli oggetti referenziati – sono una fonte comune di errori in implementazioni estese.
blog.faqT
Posso aggiungere dati strutturati anche successivamente su pagine vecchie?
Sì, i dati strutturati possono essere aggiunti in qualsiasi momento. Assicuratevi che tutte le informazioni siano aggiornate. Utilizzate il Rich-Results-Test di Google per verificare la corretta implementazione. Per molte pagine, si consiglia un approccio graduale per tipo di contenuto.
Con quale frequenza dovrebbero essere aggiornati i dati strutturati?
Sempre quando cambiano le informazioni sottostanti (prezzi, orari di apertura, dettagli del prodotto). Programmate almeno un controllo trimestrale completo. I sistemi dinamici possono popolare automaticamente i dati, riducendo lo sforzo di aggiornamento e le fonti di errore.
