Dati strutturati e motori di ricerca: cosa cambia nel 2026
Lo schema markup JSON-LD è il linguaggio con cui dichiari ai motori di ricerca — e ai modelli AI generativi — cosa contiene una pagina, non solo come appare. Nel 2026 questa distinzione è più rilevante che mai: Google AI Overview, ChatGPT Search e Perplexity attingono ai dati strutturati per costruire risposte citate, attribuibili e verificabili. Uneven Lab lavora con questo approccio dal 2013, integrando lo schema markup nell’architettura tecnica dei siti dei propri clienti europei come componente strutturale della strategia SEO, AEO e GEO — non come aggiunta opzionale. In questa guida trovi la mappa operativa: tipi prioritari, struttura corretta, errori frequenti e impatto reale sulla visibilità organica e generativa.
JSON-LD, Microdata, RDFa: perché il formato conta
Il vantaggio strutturale di JSON-LD
Google raccomanda esplicitamente lo schema markup JSON-LD come formato preferito per i dati strutturati. Il motivo è tecnico: JSON-LD non si integra inline nel markup HTML visibile, ma si inserisce in un blocco <script type=”application/ld+json”> nell’<head> o nel <body>. Questo separa nettamente la semantica dichiarativa dal rendering visivo. Il risultato pratico è che puoi modificare i dati strutturati senza toccare il template, e il codice della pagina rimane leggibile. Per chi gestisce siti su Shopify, WooCommerce o Drupal — dove i template sono già complessi — questo isolamento riduce il rischio di regressioni durante gli aggiornamenti.
Perché Microdata e RDFa sono scelte più costose
Microdata e RDFa richiedono di inserire attributi semantici direttamente sugli elementi HTML visibili. Funzionano, ma ogni modifica al layout rischia di rompere la struttura dei dati. In ambienti con frequenti restyling o con team che lavorano separatamente su frontend e SEO, la manutenzione diventa un problema operativo concreto. La separazione garantita dallo schema markup JSON-LD evita questo accoppiamento e rende i dati strutturati gestibili anche da chi non ha accesso diretto ai template.
Schema.org: il vocabolario condiviso
Il vocabolario di riferimento per lo schema markup JSON-LD è Schema.org, mantenuto da un consorzio che include Google, Bing, Yahoo e Yandex. Quando scrivi "@type": "Article" stai usando una definizione condivisa e riconoscibile da tutti i principali motori. La specificità dei tipi ha un impatto diretto: un sito che dichiara Restaurant anziché il generico LocalBusiness, o Course anziché Product, aumenta la probabilità che Google attivi rich result mirati per quel tipo di entità. La precisione semantica non è un dettaglio: è il criterio con cui i crawler decidono quali markup elaborare per i formati speciali.
I tipi di schema markup prioritari per SEO, AEO e GEO
Article e BlogPosting: autorità editoriale dichiarata
Il tipo Article — e il suo sottotipo BlogPosting — è il punto di partenza per qualsiasi sito che pubblica contenuti editoriali. Permette di dichiarare autore, data di pubblicazione, data di modifica, immagine principale e headline. L’autore deve essere collegato a un’entità Person con proprietà name, url e sameAs che punta ai profili verificati — LinkedIn, Wikidata, sito ufficiale.
Questo collegamento è determinante per la strategia GEO: i modelli di linguaggio usano queste catene di riferimento per attribuire correttamente le citazioni nelle risposte generative. Un articolo con autore anonimo o dichiarato solo come stringa di testo ha meno probabilità di essere citato da un sistema AI rispetto a un articolo con entità autore verificabile grazie allo schema markup JSON-LD e coerente tra le fonti.
FAQPage: il tipo centrale per l’AEO
Il tipo FAQPage con proprietà Question e Answer annidate è uno degli strumenti più diretti per l’AEO (Answer Engine Optimization). Google utilizza questo schema markup JSON-LD per identificare pagine strutturate come fonti di risposte, aumentando la probabilità di comparire nei blocchi “People Also Ask” e, in misura crescente, nelle sintesi di AI Overview. Le risposte devono essere brevi, tecnicamente precise e contenere la keyword della domanda. Una risposta che supera i 400 caratteri perde efficacia come risposta diretta — può essere espansa nel corpo della pagina, ma la versione nel markup deve essere sintetica. È uno degli interventi con il rapporto effort/impatto più alto nell’ottimizzazione AEO di una pagina esistente.
Product e Offer: prerequisito per l’e-commerce nel 2026
Per gli e-commerce, il tipo Product con Offer annidato non è più un’ottimizzazione avanzata: è un prerequisito per apparire nei formati commerciali emergenti. Google Shopping Graph, i carousel AI e i blocchi prodotto in AI Overview usano i dati strutturati per estrarre prezzo, disponibilità, valutazioni e attributi tecnici. Un prodotto senza dati strutturati completi non viene escluso dall’indice, ma è invisibile ai formati che oggi generano la maggior parte del traffico commerciale qualificato. Per Shopify, WooCommerce e Magento esistono implementazioni native, ma spesso incomplete: le proprietà sku, gtin, brand e aggregateRating vengono omesse dai temi base e devono essere aggiunte esplicitamente.
Organization, LocalBusiness e BreadcrumbList
Il tipo Organization è il nodo centrale per la costruzione dell’entità nel Knowledge Graph di Google. Dichiara nome, URL, logo, sede, canali social e — attraverso sameAs — i riferimenti esterni che unificano l’identità dell’azienda tra le fonti. Per attività con sede fisica, LocalBusiness aggiunge indirizzo, orari e aree di servizio. Il tipo BreadcrumbList è spesso sottovalutato, ma ha un impatto diretto sulla leggibilità dell’architettura da parte dei crawler e mostra il percorso di navigazione nello snippet SERP — particolarmente utile per e-commerce e siti con struttura gerarchica profonda. L’implementazione di questi tre tipi in modo coerente e interconnesso è il fondamento di qualsiasi lavoro di entity optimization.
Implementazione JSON-LD: struttura @graph ed errori critici
Quando e come usare @graph
Quando una pagina richiede più tipi di schema markup JSON-LD — per esempio Organization + WebSite + BreadcrumbList + Article — la struttura corretta è quella con @graph, che raggruppa tutti i nodi in un unico blocco script. Ogni nodo può fare riferimento agli altri tramite @id, creando un grafo di entità coeso anziché una serie di dichiarazioni isolate. Questo approccio è adottato come standard da RankMath e Yoast SEO nelle versioni recenti, e riflette il modo in cui Google elabora i dati strutturati: come un insieme di relazioni tra entità, non come una lista di tag indipendenti. La struttura @graph riduce anche il rischio di conflitti tra blocchi script separati sulla stessa pagina.
Proprietà obbligatorie e avvisi in Search Console
Google Search Console distingue tra errori (che impediscono i rich result) e avvisi (proprietà raccomandate mancanti). Per Article, le proprietà obbligatorie sono headline, image e datePublished. Per Product, sono name e almeno una tra review, aggregateRating o offers. Per FAQPage, ogni Question deve avere un acceptedAnswer con testo non vuoto. Gli avvisi per proprietà raccomandate mancanti non bloccano l’elaborazione, ma riducono la ricchezza del rich result ottenibile. Un audit tecnico SEO completo include sempre la verifica sistematica di questi avvisi per tutti i tipi implementati.
La regola di corrispondenza tra markup e contenuto visibile
Il vincolo più importante nell’implementazione di schema markup JSON-LD è la corrispondenza con il contenuto visibile della pagina. Google applica penalizzazioni manuali per “markup fuorviante” quando i dati strutturati dichiarano informazioni che il visitatore non può verificare nella pagina. Un prezzo nel markup che non corrisponde al prezzo mostrato, un autore dichiarato nel JSON-LD che non appare nel testo, una valutazione aggregata senza recensioni visibili: sono tutti casi che possono portare a una penalizzazione manuale. La verifica di questa corrispondenza è parte standard del workflow di implementazione — non un controllo opzionale da fare in fase di rilascio.
Richiedi un audit tecnico dei tuoi dati strutturati
Se vuoi verificare lo stato attuale dello schema markup JSON-LD del tuo sito — lacune nei tipi implementati, proprietà mancanti, conflitti tra blocchi, copertura AEO e GEO — puoi richiedere una prima call conoscitiva con il team Uneven Lab. La call serve a capire il punto di partenza e, dove utile, a definire le priorità di intervento in base all’architettura esistente.
Domande frequenti sullo schema markup JSON-LD per SEO
Lo schema markup JSON-LD influisce direttamente sul ranking organico?
Non è un fattore di ranking diretto confermato da Google. L’impatto è indiretto: i dati strutturati abilitano rich result che migliorano il CTR, e un click-through rate più alto su una posizione invariata produce più traffico organico reale. Nel contesto AEO e GEO, i dati strutturati aumentano la probabilità di essere citati nelle risposte AI, che oggi sottraggono visibilità ai risultati organici classici.
Qual è la differenza tra schema markup per SEO e per GEO?
Per la SEO tradizionale, lo schema markup JSON-LD serve principalmente ad abilitare rich result e a migliorare la comprensione della pagina da parte dei crawler. Per la GEO (Generative Engine Optimization), il focus si sposta sulla costruzione del grafo di entità: Organization con sameAs verificabili, autori collegati a profili Wikidata, Product con attributi tecnici espliciti. I modelli AI generativi usano questi riferimenti per costruire risposte attribuibili a fonti specifiche anziché sintetizzare senza citazione.
Come si verifica che il JSON-LD sia implementato correttamente?
Google mette a disposizione il Rich Results Test (search.google.com/test/rich-results) per testare URL o codice diretto, e lo strumento di ispezione URL in Search Console per verificare i dati strutturati effettivamente rilevati in fase di scansione. Per audit su larga scala — migliaia di URL con tipi diversi — strumenti come Screaming Frog consentono di estrarre e confrontare sistematicamente tutti i blocchi JSON-LD presenti nel sito.
