A volte il markup c’è, è corretto, e in SERP non cambia nulla. È qui che molti si bloccano. I dati strutturati vengono spesso raccontati come una leva tecnica da aggiungere al sito, ma il punto vero è un altro: servono a far capire meglio a Google che cosa contiene una pagina, come sono collegati i suoi elementi e quali informazioni meritano di essere lette senza ambiguità. Entrano quindi in gioco termini come Schema.org, markup semantico, JSON-LD, rich snippet e rich results. Se gestisci un sito aziendale, un ecommerce o un progetto editoriale, capire come funzionano ti evita lavoro sprecato e aspettative fuori fuoco. Qui analizziamo cosa sono davvero, come scegliere i markup utili, come testarli con Google Search Console e con il test dei risultati avanzati, e quali errori evitare prima di metterci mano.
Cosa sono davvero i dati strutturati sul web
Definizione semplice: informazioni organizzate per i motori di ricerca
In pratica, i dati strutturati sono un modo standardizzato per descrivere il contenuto di una pagina. Non cambiano ciò che l’utente vede. Cambiano, piuttosto, il modo in cui una macchina può interpretarlo.
Facciamo un esempio semplice: in una pagina prodotto puoi avere nome, prezzo, disponibilità e recensioni. Per una persona è tutto chiaro. Per un motore di ricerca, senza segnali aggiuntivi, quei dati sono solo testo dentro il codice HTML. Con i dati strutturati SEO, invece, indichi che “149 euro” è il prezzo, che “disponibile” è lo stato del prodotto e che “4,6 su 5” è una valutazione.
Detta in modo ancora più diretto: stai etichettando informazioni. E lo fai seguendo una sintassi che i motori possono leggere con meno margine di errore.
Qui sta il punto.
Non parliamo del significato “database” del termine. Nel contesto SEO, i dati strutturati sono markup semantico applicato alle pagine web per descrivere entità e attributi in una forma comprensibile ai sistemi di ricerca.
La differenza tra dati strutturati, Schema.org e rich results
Qui nasce molta confusione. Conviene quindi separare bene i piani.
- Dati strutturati: sono le informazioni codificate in un formato leggibile dai motori
- Schema.org: è il vocabolario più usato per definire tipi e proprietà del markup
- Rich results: sono i risultati avanzati che Google può mostrare in SERP usando quei dati
- Rich snippet: termine spesso usato come sinonimo pratico di risultato arricchito, anche se oggi Google parla più spesso di rich results
Schema.org, quindi, non è “il dato strutturato”. È il dizionario da cui prendi etichette come `Product`, `Article`, `FAQPage` o `BreadcrumbList`.
Quanto ai rich results, non sono automatici. Puoi avere markup valido e non ottenere alcun risultato avanzato visibile. È normale. Google valuta idoneità, qualità della pagina, pertinenza della query e altri segnali.
Perché contano per SEO e visibilità in SERP
Aiutano Google a interpretare meglio entità, relazioni e contesto
Un sito non viene letto come farebbe una persona. Viene interpretato per segnali. I dati strutturati aggiungono contesto a questi segnali.
Se in una pagina compaiono un nome aziendale, un indirizzo, un numero di telefono e un orario, il markup può chiarire che si tratta di una sede locale e non di testo generico. In un articolo, invece, puoi rendere esplicita la relazione tra autore, data e titolo.
È un passaggio utile soprattutto nei siti con contenuti simili tra loro, template ripetitivi o pagine dove il significato non è immediato. Un ecommerce con cento schede prodotto, per dire, beneficia di una struttura chiara molto più di quanto sembri a prima vista.
A ben vedere, il valore SEO non sta solo nel “farsi notare”, ma nel ridurre l’ambiguità con cui Google interpreta una pagina.
Quando possono attivare risultati avanzati e quando no
Qui serve realismo. Il markup non è un interruttore.
Google può usare i dati strutturati per mostrare rich results, ma non è obbligato a farlo. Conviene tenere distinti tre livelli:
- Markup valido: il codice è corretto e leggibile
- Markup idoneo: il tipo di pagina e le proprietà rispettano i requisiti richiesti
- Rich result mostrato: Google decide effettivamente di visualizzarlo
Sono tre cose diverse. E spesso vengono confuse.
Un caso tipico: inserisci `FAQPage`, il test non segnala errori, ma in SERP non appare nulla. Non significa che “non funziona”. Significa che la pagina è valida, ma Google può scegliere di non mostrare quel formato per quella query, per quel sito o in quel momento. In altre parole, il coltello dalla parte del manico ce l’ha Google.
Benefici indiretti: CTR, chiarezza del risultato e coerenza del sito
Il vantaggio non si misura solo sul ranking. Anzi, spesso si vede altrove.
Un risultato più chiaro può aumentare il CTR perché l’utente capisce meglio cosa troverà cliccando. Un breadcrumb corretto migliora la leggibilità del percorso. Un prodotto con prezzo e disponibilità espliciti rende il risultato più informativo. Un articolo ben descritto aiuta a rafforzare coerenza editoriale e classificazione del contenuto.
Spesso il beneficio è indiretto. Ma concreto.
Pensiamo a due pagine prodotto quasi identiche per contenuto e autorevolezza: se una comunica con precisione attributi, stato e struttura, ha più possibilità di risultare comprensibile sia al motore sia all’utente. Non è una scorciatoia SEO. È chiarezza applicata.
Quali dati strutturati usare in base al tipo di pagina
Pagine prodotto, categorie e recensioni
Se hai un ecommerce, la priorità parte quasi sempre dalle schede prodotto. Qui il Product schema è il markup più utile, perché descrive un’entità commerciale con attributi chiari: nome, immagine, brand, prezzo, valuta, disponibilità, eventuale valutazione aggregata.
Un esempio concreto: vendi scarpe antinfortunistiche. Nella scheda puoi marcare il nome del modello, il prezzo corrente, lo stato “in stock” e il brand. Se questi dati in pagina sono aggiornati e coerenti, stai dando a Google un quadro pulito.
Le categorie, invece, richiedono più cautela. Non sempre ha senso applicare markup da prodotto a una pagina listing. Se una categoria mostra molti articoli senza una scheda dettagliata unica, meglio concentrarsi su breadcrumb, struttura interna e contenuto descrittivo, invece di forzare un tipo semantico poco adatto.
Quanto alle recensioni, occhio. Le valutazioni aggregate vanno usate solo quando sono reali, verificabili e coerenti con ciò che appare all’utente.
Articoli, guide, FAQ e breadcrumb
Nei siti editoriali o corporate, il pacchetto più frequente è questo:
- `Article` o tipi affini per articoli e approfondimenti
- `FAQPage` per sezioni domanda-risposta realmente presenti in pagina
- `BreadcrumbList` per il percorso di navigazione
Sono markup trasversali. E spesso bastano per iniziare bene.
Per un blog aziendale, ad esempio, un articolo può indicare titolo, autore, data di pubblicazione e immagine principale. In una guida pratica con domande finali, `FAQPage` ha senso solo se quelle FAQ sono parte del contenuto visibile, non un’aggiunta artificiale. Il breadcrumb, invece, è uno dei casi più puliti: aiuta a chiarire gerarchia e collocazione della pagina nel sito.
Qui molti sbagliano per eccesso. Inseriscono markup ovunque, anche dove non serve. Meglio poco ma coerente che un catalogo di tipi scelti a caso.
Attività locali, contatti, eventi e ricette
Per una PMI con presenza sul territorio, le pagine legate all’attività locale meritano attenzione. Se hai sedi, contatti, orari o aree servite, il markup può aiutare a definire l’identità della pagina e dell’azienda.
Eventi e ricette hanno formati specifici molto chiari, ma vanno usati solo se il contenuto rispetta davvero il modello richiesto. Una pagina “evento” senza data, luogo e informazioni verificabili è debole. Una ricetta senza ingredienti, tempi e istruzioni è solo una pagina di testo con un’etichetta sbagliata.
Un criterio semplice per decidere da dove partire:
- pagine che generano business diretto
- pagine con attributi chiari e aggiornabili
- pagine già ben strutturate a livello editoriale
- pagine che Google può interpretare meglio grazie al markup
Se vuoi stabilire priorità, parti da quelle. Il resto viene dopo.
Formati disponibili: perché oggi il riferimento è JSON-LD
JSON-LD, Microdata e RDFa: differenze essenziali
I dati strutturati possono essere implementati in diversi formati. I più citati sono JSON-LD, Microdata e RDFa.
La differenza pratica è questa: Microdata e RDFa inseriscono attributi direttamente dentro l’HTML della pagina; JSON-LD, invece, separa il markup dal contenuto visivo e lo colloca in un blocco script leggibile dai motori.
Questo cambia molto nella gestione quotidiana. Con Microdata, ogni modifica al layout può toccare anche il markup. Con JSON-LD, di solito, il codice resta più ordinato e più semplice da aggiornare.
Pochi fronzoli.
Per chi lavora con CMS, template e plugin, questa distinzione pesa. Soprattutto quando il sito cresce e le pagine da mantenere diventano decine o centinaia.
Perché JSON-LD è spesso la scelta più semplice da gestire
Google supporta più formati, ma JSON-LD è spesso la scelta più pratica. Non perché sia “migliore” in astratto, ma perché riduce attriti operativi.
Puoi generarlo lato CMS, inserirlo via template o gestirlo con plugin dedicati senza sporcare il markup HTML della pagina. Questo aiuta in tre casi frequenti:
- siti WordPress o ecommerce con molte pagine simili
- progetti dove sviluppatore e redazione lavorano separati
- contesti in cui il contenuto cambia spesso, come prezzi o disponibilità
Se il dato cambia, il markup deve seguirlo. Altrimenti nasce il problema più comune — e qui molti se ne accorgono tardi —: codice formalmente corretto, ma incoerente con ciò che l’utente legge a schermo.
Come implementare i dati strutturati senza complicarsi il lavoro
Inserimento manuale nel codice o tramite CMS/plugin
Hai due strade. Manuale o assistita.
L’inserimento manuale è adatto quando hai un sito custom, uno sviluppatore a disposizione e la necessità di controllare con precisione ogni proprietà. È il caso, per esempio, di un ecommerce con logiche particolari su varianti, stock o prezzi.
L’approccio tramite CMS o plugin, invece, è spesso sufficiente per blog, siti aziendali e cataloghi semplici. WordPress, Shopify e molte piattaforme offrono estensioni che generano parte del markup in automatico. La comodità, però, non basta: va sempre verificato cosa producono davvero.
Un micro-caso concreto: plugin attivo, `Product schema` generato, ma prezzo preso dal template vecchio e disponibilità dal campo sbagliato. Il test passa. La pagina no. Succede più spesso di quanto si pensi.
Esempio minimo di markup per capire la logica entità-attributi
Prima del codice, conta la logica. Ogni markup descrive un’entità e i suoi attributi.
Se l’entità è un prodotto, gli attributi possono essere nome, marca, prezzo, disponibilità. Se l’entità è un articolo, gli attributi diventano autore, data, titolo, immagine.
Ecco un esempio essenziale in JSON-LD per una pagina prodotto:
“`html
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Trapano a batteria X200”,
“brand”: {
“@type”: “Brand”,
“name”: “Ferral”
},
“offers”: {
“@type”: “Offer”,
“price”: “129.00”,
“priceCurrency”: “EUR”,
“availability”: “https://schema.org/InStock”
}
}
</script>
“`
Non serve impararlo a memoria. Serve cogliere il meccanismo: prima definisci cos’è l’oggetto, poi ne descrivi gli attributi in modo standard.
Come verificare se il markup è corretto e utile
Test dei risultati avanzati e validazione con gli strumenti Google
Dopo l’implementazione arriva il controllo. E qui entrano in gioco due strumenti pratici: il test dei risultati avanzati e Google Search Console.
Il primo ti dice se una pagina è leggibile da Google e se il markup può essere idoneo a certi rich results. Search Console, invece, ti aiuta a monitorare errori, avvisi e stato dei dati strutturati su scala più ampia, quando il sito è già scansionato.
La sequenza più utile è semplice:
- testi una singola URL nel tool di Google
- correggi errori ed eventuali campi mancanti
- controlli in Search Console come Google vede il markup nel tempo
Non basta una validazione una tantum. Se cambi template, plugin o campi del CMS, va rifatto il controllo.
Audit rapido: validità tecnica, coerenza del contenuto, idoneità al risultato
Un mini-audit efficace si basa su tre livelli.
Primo livello: validità tecnica. Il codice è leggibile? Le proprietà richieste ci sono? Il tipo Schema.org scelto è corretto?
Secondo livello: coerenza. Il markup riflette davvero ciò che appare in pagina? Prezzo, disponibilità, autore, FAQ e breadcrumb coincidono con il contenuto visibile?
Terzo livello: idoneità. Quella pagina ha davvero senso per quel risultato avanzato? Una pagina categoria non è una scheda prodotto. Una FAQ improvvisata in fondo alla pagina non sempre giustifica `FAQPage`.
Qui si vede la differenza tra “markup presente” e “markup utile”. Sono due piani distinti.
Errori comuni che limitano i risultati
Markup non coerente con ciò che l’utente vede in pagina
È l’errore che pesa di più. E spesso nasce da automatismi.
Se il markup dichiara un prezzo scontato che in pagina non compare, o recensioni che l’utente non vede, stai creando una discrepanza. Google chiede coerenza tra dati strutturati e contenuto visibile. Se manca, il risultato avanzato può non apparire o perdere affidabilità.
Vale anche per dettagli meno evidenti. Un breadcrumb marcato in un modo e mostrato in un altro, un autore nel codice ma non nella pagina, FAQ segnate come strutturate ma assenti nel testo.
Qui non si bara.
Uso di tipi sbagliati, proprietà mancanti o markup su pagine inadatte
L’altro blocco di errori riguarda la scelta del tipo semantico. Succede quando si applica un markup solo perché “esiste”, non perché la pagina lo giustifica.
I casi più frequenti sono questi:
- `Product` su pagine che non vendono un prodotto specifico
- `FAQPage` su contenuti senza vere domande e risposte
- proprietà obbligatorie assenti o compilate in modo generico
- dati vecchi che non vengono aggiornati insieme alla pagina
C’è anche un errore strategico meno visibile: partire dalle pagine sbagliate. Se il sito non ha ancora basi solide, il markup non risolve problemi di architettura, contenuto debole o schede povere. Aiuta. Non sostituisce il resto.
Checklist pratica: da dove partire se il sito non li usa ancora
Le prime 5 verifiche da fare prima di pubblicare il markup
Per iniziare senza disperdere tempo, conviene seguire questa sequenza:
- individua le pagine con maggiore valore: prodotti, articoli chiave, contatti, FAQ reali
- scegli il tipo Schema.org più adatto alla singola pagina, non al sito in generale
- usa JSON-LD se vuoi una gestione più lineare
- verifica con test dei risultati avanzati e poi in Google Search Console
- controlla sempre coerenza tra markup, contenuto visibile e obiettivo della pagina
Pochi passaggi. Ma ben fatti.
FAQ
I dati strutturati migliorano il posizionamento su Google?
Non in modo diretto e automatico. Possono aiutare Google a comprendere meglio una pagina e, in alcuni casi, attivare rich results che migliorano visibilità e CTR. Il beneficio SEO esiste, ma passa soprattutto da chiarezza, interpretazione e presentazione del risultato.
Qual è la differenza tra Schema.org e dati strutturati?
Schema.org è il vocabolario. I dati strutturati sono l’applicazione pratica di quel vocabolario nel codice della pagina. In breve: Schema.org definisce etichette e proprietà; il markup le usa per descrivere contenuti specifici.
Meglio usare JSON-LD o Microdata?
Nella maggior parte dei casi, JSON-LD è più semplice da implementare e mantenere. Microdata può andare bene, ma richiede interventi direttamente nell’HTML e tende a essere meno comodo da gestire su siti estesi o aggiornati spesso.
Come faccio a sapere se i dati strutturati funzionano?
Puoi testare una singola pagina con il test dei risultati avanzati e monitorare lo stato del markup in Google Search Console. Ricorda però una distinzione: il fatto che il codice sia valido non significa che il rich result verrà mostrato in SERP.
Tutte le pagine del sito devono avere dati strutturati?
No. Ha senso intervenire sulle pagine dove il markup aggiunge chiarezza reale: prodotti, articoli, breadcrumb, contatti, eventi, FAQ presenti davvero. Metterli ovunque, senza criterio, crea più confusione che vantaggi.
Perché il markup è valido ma non vedo rich results in SERP?
Perché validità tecnica e visualizzazione sono due cose diverse. Il markup può essere corretto, ma la pagina potrebbe non essere idonea, non abbastanza pertinente per quella query o, semplicemente, Google può scegliere di non mostrare il risultato avanzato.