Il codice di una pagina web dice al browser come mostrare i contenuti, non cosa significano. Il titolo di un articolo, il prezzo di un prodotto, l’orario di apertura di un ristorante sono tutti testi indistinguibili per una macchina che legge solo HTML. I dati strutturati servono a questo: aggiungere uno strato di significato leggibile da Google, Bing e dai modelli AI che oggi generano risposte al posto dei classici dieci link blu.
Fino a qualche anno fa erano una leva utile ma opzionale, servivano soprattutto per ottenere i rich snippet (stelline, prezzi, ricette con foto). Con AI Overview di Google, ChatGPT Search e Perplexity che leggono e citano le pagine in modo semantico, i dati strutturati sono diventati uno dei segnali più efficaci per farsi capire, e citare, dai motori generativi. Vediamo come si implementano davvero.
Cosa sono i dati strutturati e perché non sono un vezzo tecnico
I dati strutturati sono un vocabolario standardizzato (Schema.org) che descrive gli oggetti di una pagina in modo esplicito: “questo è un articolo”, “questo è il nome dell’autore”, “questa è la data di pubblicazione”, “questo è il prezzo del prodotto”. Il vocabolario è mantenuto da un consorzio che include Google, Microsoft, Yahoo e Yandex, quindi è uno standard cross-motore, non una feature Google.
Il formato consigliato oggi è JSON-LD: uno script JSON inserito nel <head> o nel body della pagina, separato dal contenuto visibile. È preferito rispetto ai vecchi Microdata e RDFa perché non contamina l’HTML e si gestisce meglio via template CMS.
La differenza pratica è semplice: senza dati strutturati, un motore di ricerca deduce il significato del contenuto dall’analisi del testo e dei tag semantici (h1, h2, meta, ecc.), con i dati strutturati glielo dichiari esplicitamente. Nel primo caso l’interpretazione è probabilistica, nel secondo è certa.
Perché contano per l’AI, non solo per i rich snippet
Storicamente i dati strutturati erano il biglietto d’ingresso per i rich result nella SERP: le stelline delle recensioni, il prezzo in evidenza, il breadcrumb, l’orario dell’evento. Continuano a servire per questo. Ma il cambio di paradigma è recente.
I modelli generativi che rispondono alle query (AI Overview, ChatGPT Search, Perplexity, Gemini) leggono le pagine web per estrarne informazioni citabili. Quando trovano dati strutturati, hanno meno lavoro da fare: sanno esattamente chi ha scritto un articolo, quando, di cosa parla, quale prodotto è recensito, quanto costa. Meno lavoro di interpretazione significa maggiore probabilità che la pagina venga usata come fonte.
Su questo tema ho scritto una guida più ampia su come ottimizzare i contenuti per le ricerche AI nel 2026: i dati strutturati sono uno dei pilastri di quel lavoro, insieme alla struttura semantica del testo e alle FAQ ben formulate.
Quali tipi di Schema implementare (e in quale ordine)
Schema.org contiene centinaia di tipi. Per un sito PMI italiano, i tipi che coprono il 90% dei casi sono meno di dieci. Li elenco in ordine di priorità operativa:
- Organization o LocalBusiness: identifica l’azienda, il logo, i contatti, la sede. Va nella home. LocalBusiness è la scelta giusta se hai una sede fisica con orari di apertura.
- WebSite con SearchAction: dichiara il sito e abilita il box di ricerca sitelinks nella SERP.
- BreadcrumbList: le briciole di navigazione. Google le mostra al posto dell’URL nella SERP mobile.
- Article o BlogPosting: per ogni articolo del blog. Include autore, data pubblicazione, data modifica, immagine in evidenza.
- Product con Offer e AggregateRating: per ogni scheda prodotto e-commerce. Prezzo, disponibilità, recensioni.
- FAQPage: per le sezioni FAQ. Attenzione: Google ha ridotto la visibilità dei rich result FAQ nel 2023, ma il markup resta utile per l’AI.
- HowTo: per tutorial passo-passo. Anche qui i rich result sono stati ridotti, ma il segnale semantico resta.
- Event: per eventi, corsi, webinar con data e luogo.
Non serve implementarli tutti. Serve implementare bene quelli pertinenti al tuo tipo di sito.
Esempio pratico: JSON-LD per un articolo di blog
Questo è il markup minimo funzionante per un articolo. Va inserito nel <head> della pagina articolo, non della home.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Dati strutturati SEO: guida pratica al markup Schema",
"image": "https://www.esempio.it/wp-content/uploads/2026/07/copertina.jpg",
"datePublished": "2026-07-06T09:00:00+02:00",
"dateModified": "2026-07-06T09:00:00+02:00",
"author": {
"@type": "Person",
"name": "Simone Coglitore",
"url": "https://www.esempio.it/autore/simone-coglitore/"
},
"publisher": {
"@type": "Organization",
"name": "Mocart Studio",
"logo": {
"@type": "ImageObject",
"url": "https://www.esempio.it/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.esempio.it/dati-strutturati-seo/"
}
}
</script>Due dettagli da controllare: datePublished e dateModified devono essere in formato ISO 8601 con fuso orario, e mainEntityOfPage deve corrispondere all’URL canonico della pagina. Se il logo non è quadrato o supera 600x60px, Google può scartare il markup Organization.
Come si implementa su WordPress (senza plugin inutili)
Su WordPress hai tre strade. La scelta dipende dal livello di controllo che vuoi avere.
Opzione 1: plugin SEO che include lo Schema
Rank Math (versione free) e Yoast SEO Premium gestiscono nativamente i tipi principali: Article, Product (con WooCommerce), BreadcrumbList, Organization, WebSite. Configurabili da un pannello, senza toccare codice. Per il 70% dei siti PMI è la soluzione più sensata.
In Rank Math: Dashboard → Titles & Meta → Posts, sezione “Schema Type”, seleziona “Article”. Poi Dashboard → Titles & Meta → Local SEO per configurare Organization/LocalBusiness. In Yoast Premium: SEO → Search Appearance, tab “Content Types” e “Organizzazione”.
Opzione 2: plugin dedicato Schema
Se hai bisogno di tipi non coperti dal plugin SEO (Event, Course, JobPosting, Recipe), aggiungi Schema Pro o WP SEO Structured Data Schema. Non consiglio di stackare più plugin Schema: generano markup duplicato, che Google segnala come errore.
Opzione 3: JSON-LD custom via functions.php
Se hai un tema custom o un CPT (custom post type) specifico non gestito dai plugin, scrivi il markup a mano. Esempio di hook per aggiungere BlogPosting solo sui post:
add_action('wp_head', 'mocart_blogposting_schema');
function mocart_blogposting_schema() {
if (!is_single() || get_post_type() !== 'post') return;
global $post;
$author_id = $post->post_author;
$image = get_the_post_thumbnail_url($post->ID, 'full');
$schema = array(
'@context' => 'https://schema.org',
'@type' => 'BlogPosting',
'headline' => get_the_title(),
'image' => $image,
'datePublished' => get_the_date('c'),
'dateModified' => get_the_modified_date('c'),
'author' => array(
'@type' => 'Person',
'name' => get_the_author_meta('display_name', $author_id),
'url' => get_author_posts_url($author_id)
),
'publisher' => array(
'@type' => 'Organization',
'name' => get_bloginfo('name'),
'logo' => array(
'@type' => 'ImageObject',
'url' => 'https://www.esempio.it/logo.png'
)
),
'mainEntityOfPage' => get_permalink()
);
echo '<script type="application/ld+json">' . wp_json_encode($schema) . '</script>';
}Se usi questa via, ricordati di disattivare lo Schema Article del plugin SEO per lo stesso tipo di post, altrimenti generi duplicati.
WooCommerce: Product Schema fatto bene
WooCommerce genera nativamente un markup Product base. È spesso incompleto: manca brand, la sku può essere vuota, aggregateRating compare solo se ci sono recensioni. Se vendi online, è la prima cosa da sistemare, e si intreccia con altri fondamentali della SEO e-commerce che spesso vengono sbagliati.
Struttura minima corretta per un prodotto:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Nome prodotto",
"image": ["url-immagine-1.jpg", "url-immagine-2.jpg"],
"description": "Descrizione del prodotto",
"sku": "SKU-12345",
"brand": {
"@type": "Brand",
"name": "Nome brand"
},
"offers": {
"@type": "Offer",
"url": "https://www.esempio.it/prodotto/",
"priceCurrency": "EUR",
"price": "49.90",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "23"
}
}priceValidUntil è obbligatorio per evitare warning nel Search Console. Se non hai recensioni reali, non inserire aggregateRating: inventare valutazioni è una violazione delle linee guida Google che può portare a manual action.
Come testare i dati strutturati (i tre strumenti da usare)
Dopo aver implementato, devi verificare. Ci sono tre strumenti gratuiti, ciascuno con uno scopo diverso.
- Rich Results Test (search.google.com/test/rich-results): incolli l’URL o il codice, ti dice se la pagina è eleggibile per rich result su Google e ti segnala errori bloccanti e warning. È il primo test da fare.
- Schema Markup Validator (validator.schema.org): valida rispetto allo standard Schema.org, indipendentemente da cosa Google supporta. Utile per tipi che non generano rich result ma servono all’AI.
- Google Search Console, sezione “Miglioramenti”: mostra lo stato di tutti i dati strutturati rilevati sul sito, errori e warning aggregati. È l’unico strumento che ti dice come sta andando nel tempo. Ho scritto una guida a parte su come usare Search Console per analizzare la salute del sito.
Ordine operativo consigliato: dopo l’implementazione, Rich Results Test sulla singola pagina, se passa Schema Markup Validator per verificare la correttezza formale, dopo 7-14 giorni controllo su Search Console per vedere se Google ha effettivamente indicizzato il markup su tutte le pagine.
Errori comuni
Alcuni errori si ripetono con una frequenza fastidiosa:
- Markup duplicato: due plugin che generano lo stesso tipo di Schema. Il Rich Results Test lo segnala come warning ma va risolto disattivando uno dei due.
- Dati non visibili in pagina: dichiarare nel JSON-LD un prezzo o una recensione che l’utente non vede nel contenuto della pagina è una violazione delle linee guida Google. Il markup deve rispecchiare il contenuto visibile.
- Immagini troppo piccole: Article richiede immagini di almeno 1200px di larghezza. Sotto quella soglia, il rich result non compare.
- aggregateRating inventato: come già detto, valutazioni finte sono manual action garantita se scoperte.
- Tipi sbagliati per il contenuto: mettere Product su una pagina informativa che non vende nulla, o Article su una pagina categoria. Il tipo deve corrispondere alla natura reale della pagina, un problema che si intreccia con la gestione corretta di tag e tassonomie in ottica SEO.
- Date modificate a caso: aggiornare
dateModifiedsenza modifiche reali al contenuto è considerato manipolazione. Google se ne accorge confrontando il diff.
Checklist di verifica finale
Prima di considerare chiuso il lavoro sui dati strutturati, verifica punto per punto:
- Home page: markup Organization (o LocalBusiness se hai sede fisica) più WebSite con SearchAction.
- Ogni articolo di blog: BlogPosting completo di autore, date, immagine ≥1200px, publisher con logo.
- Ogni scheda prodotto: Product con offer (prezzo, valuta, disponibilità, priceValidUntil), brand, sku. AggregateRating solo se hai recensioni reali.
- Ogni pagina profonda: BreadcrumbList che rispecchia la struttura di navigazione.
- Pagine FAQ o sezioni FAQ nei post: FAQPage con almeno 4 coppie domanda/risposta.
- Rich Results Test: nessun errore bloccante, warning valutati e risolti dove possibile.
- Schema Markup Validator: markup formalmente corretto rispetto allo standard.
- Search Console → Miglioramenti: dopo 14 giorni, verifica che il numero di elementi validi corrisponda alle pagine attese, e nessun errore critico.
- Nessun markup duplicato (un solo plugin o sistema che genera ciascun tipo).
- Il contenuto dichiarato nel JSON-LD è visibile nel corpo della pagina.
Domande frequenti
I dati strutturati migliorano il posizionamento nella SERP?
Non direttamente. Google ha dichiarato più volte che i dati strutturati non sono un fattore di ranking. Migliorano però la comprensione della pagina, abilitano rich result che aumentano il CTR (click-through rate) e rendono la pagina più citabile dalle AI generative. L’effetto sul traffico è indiretto ma misurabile.
Serve implementare Schema se ho già un plugin SEO come Yoast o Rank Math?
In molti casi no: i plugin SEO gestiscono i tipi principali (Article, Organization, WebSite, BreadcrumbList) in automatico. Servono interventi aggiuntivi solo se hai tipi specifici (Event, Course, Recipe, JobPosting) o custom post type non riconosciuti dal plugin. Verifica sempre con Rich Results Test cosa il plugin sta effettivamente generando.
Il markup FAQPage funziona ancora dopo la riduzione dei rich result di Google?
Sì, ma con obiettivo diverso. Google mostra i rich result FAQ solo per siti autorevoli in settori specifici, quindi non contarci per il CTR. Il markup resta però un segnale semantico forte per AI Overview, ChatGPT Search e Perplexity, che usano le FAQ strutturate come blocchi citabili. Implementalo per l’AI, non per la SERP.
Posso usare Microdata invece di JSON-LD?
Tecnicamente sì, Google supporta ancora Microdata e RDFa. Ma JSON-LD è il formato raccomandato da Google, più facile da manutenere (è separato dall’HTML), meno soggetto a errori quando si modifica il template. Se stai partendo oggi, usa JSON-LD. Se hai un sito legacy con Microdata funzionanti, non serve migrare a tutti i costi.
Quanto tempo passa prima che Google riconosca il nuovo markup?
Sulle pagine già indicizzate, di solito da 3 a 14 giorni dopo il ricrawl. Puoi accelerare richiedendo l’indicizzazione manuale via Search Console (Ispezione URL → Richiedi indicizzazione) per le pagine principali. Il pannello “Miglioramenti” di Search Console mostra l’aggregato di tutti gli elementi validi ed errori su base sitewide, e si aggiorna con qualche giorno di ritardo.
Se il mio CMS non è WordPress, i concetti valgono lo stesso?
Sì. Schema.org e JSON-LD sono standard indipendenti dalla piattaforma. Su Shopify, PrestaShop, Magento o soluzioni custom cambia solo il modo di iniettare lo script nel <head> (app dedicate, moduli, template engine). La logica dei tipi da implementare e degli strumenti di test è identica.
Un lavoro invisibile che fa la differenza
I dati strutturati non si vedono. Non cambiano il layout, non aggiungono contenuto, non fanno rumore. Sono uno strato tecnico che parla direttamente a motori e AI, e che decide se la tua pagina viene interpretata correttamente o lasciata all’interpretazione probabilistica.
Nel 2026, con la ricerca che si sposta verso risposte generate anziché liste di link, questo strato è passato da opzionale a infrastruttura di base. Non serve implementarli tutti insieme: parti dai tipi principali (Organization, Article, Product se hai un e-commerce), testali con Rich Results Test, monitora Search Console. Il resto si aggiunge quando serve. Se ti serve un confronto operativo su un caso specifico, sai dove trovarmi.
