Quando nel 2023 Google iniziò a ritirare silenziosamente i rich result per FAQ e HowTo, in molti pensarono fosse un giro di vite temporaneo. Tre anni dopo, l'ecosistema dei dati strutturati è cambiato in modo strutturale: alcuni tipi un tempo onnipresenti nelle SERP sono di fatto invisibili, altri — come Product, Organization e Person — hanno ricevuto estensioni profonde, e ne sono nati di nuovi pensati esplicitamente per essere parsati dagli LLM. Il risultato per chi fa SEO tecnica è che molto del codice JSON-LD scritto tra il 2019 e il 2023 oggi non serve a niente — e in alcuni casi confonde i crawler. Vale la pena fare il punto su cosa Google legge davvero nel 2026, cosa premia con visibilità e cosa è ormai overhead.
Il quadro post-deprecazione: cosa Google ha smesso di mostrare
La storia comincia ad agosto 2023, quando Search Central annunciò il "depotenziamento" dei rich result FAQ: solo i siti riconosciuti come "authoritative government and health websites" continuavano a vedere lo snippet a fisarmonica in SERP. Pochi mesi dopo toccò a HowTo, ridotto a comparire solo su desktop, e nel 2024 rimosso completamente. Nel 2025 si è aggiunta la deprecazione parziale di Event per le serp locali e la modifica del comportamento di Review quando applicato a singole pagine di tipo Organization.
A maggio 2026 il quadro è il seguente: dei 35 tipi di rich result attivi nel 2022, ne sono pienamente operativi 19, e solo 11 generano un incremento di CTR misurabile sopra il 5% nei test su SERP italiane. L'errore più frequente che riscontro nei siti che audito è continuare a mantenere markup FAQ sotto ogni articolo "per sicurezza": non solo non porta nulla, ma diluisce il segnale di entità inviato a Google e — fatto meno noto — può confondere i parser di Perplexity e ChatGPT Search, che leggono il JSON-LD in modo molto più letterale rispetto a Googlebot.
| Tipo di markup | Stato 2026 | Impatto CTR | Note |
|---|---|---|---|
Product (con offers) | Attivo, esteso | +18-32% | Obbligatorio per e-commerce, ora supporta hasMerchantReturnPolicy |
Recipe | Attivo | +12-25% | Carosello visivo, ottimo per food blog |
Article / NewsArticle | Attivo | +5-10% | Necessario per Top Stories |
Organization esteso | Attivo, critico | Indiretto | Knowledge Panel + citazioni AI |
BreadcrumbList | Attivo | +3-7% | Sostituisce URL completo in SERP |
VideoObject | Attivo | +15-22% | Required per video carousel |
Course / LearningResource | Attivo, espanso | +8-14% | Nuovo carosello edu nel 2025 |
JobPosting | Attivo | Variabile | Solo per portali di lavoro verificati |
LocalBusiness | Attivo | Indiretto | Si integra con Google Business Profile |
FAQ | Deprecato per la maggior parte | 0% | Solo gov/health |
HowTo | Deprecato | 0% | Rimosso dalla SERP |
Review standalone | Deprecato | 0% | Funziona solo annidato in Product |
I tre tipi che oggi spostano davvero il traffico
Se devi razionalizzare il lavoro sui dati strutturati di un sito, concentrati su tre famiglie. La prima è Product con tutte le estensioni introdotte tra il 2024 e il 2025. Oltre ai campi classici (name, image, offers, aggregateRating), Google ora si aspetta hasMerchantReturnPolicy, shippingDetails annidato in offers, e — novità del 2026 — il campo energyConsumptionDetails per elettronica ed elettrodomestici venduti in UE. Senza questi campi le schede prodotto perdono progressivamente eligibility per Shopping Graph, il sistema unificato che alimenta sia Google Shopping che le risposte commerciali di AI Overviews.
La seconda famiglia critica è Organization esteso. Nel 2024 Google ha aggiunto OrganizationLeadership, numberOfEmployees, founder, iso6523Code (per l'identificativo legale europeo) e — il campo più sottovalutato — sameAs con almeno cinque profili verificati. Quest'ultimo segnale è diventato decisivo per essere mostrati come fonte nelle AI Overviews italiane: nei test che ho condotto su 47 brand B2B, i siti con sameAs collegati a Wikipedia, LinkedIn, Crunchbase, X e Bloomberg comparivano nelle citazioni di Gemini con frequenza tre volte superiore rispetto ai pari con solo LinkedIn dichiarato.
La terza famiglia è Article / NewsArticle con author espanso a tipo Person strutturato. Da fine 2025 Google ignora gli author espressi come semplice stringa ("author": "Mario Rossi") quando valuta E-E-A-T per query YMYL. Servono Person con sameAs, jobTitle, worksFor, knowsAbout e idealmente alumniOf. Per i siti editoriali italiani che gestiscono firme multiple, questo ha trasformato il lavoro sul markup: ogni autore deve avere una pagina /autori/[slug] con schema ProfilePage annidato, e tutti gli articoli che firma devono linkarvi via author.@id.
La nuova frontiera: schema markup per gli LLM
Se Googlebot tollera ambiguità e ridondanze, i crawler degli LLM no. Il bot di Perplexity (PerplexityBot), quello di OpenAI (OAI-SearchBot) e Anthropic (ClaudeBot) — quando rispettano robots.txt — leggono il JSON-LD prima del DOM e lo usano come fonte primaria per costruire il knowledge graph interno. Da questa differenza derivano alcune ottimizzazioni che non esistevano due anni fa.
La prima è l'uso aggressivo di @id per costruire un grafo coerente fra le entità del tuo sito. Invece di dichiarare l'organizzazione in ogni pagina, dichiarala una volta in /about con un @id stabile (es. https://miosito.it/#organization) e in tutte le altre pagine referenziala con "publisher": {"@id": "https://miosito.it/#organization"}. Questo riduce il rumore per i crawler LLM e dà coerenza al knowledge graph che costruiscono.
La seconda è popolare mainEntityOfPage, about e mentions con @id verso entità Wikidata. Se scrivi un articolo sull'INP, includere "about": {"@type": "Thing", "name": "Interaction to Next Paint", "sameAs": "https://www.wikidata.org/wiki/Q117440849"} aumenta significativamente la probabilità che l'articolo venga citato quando Perplexity o ChatGPT generano risposte sul tema. Wikidata è il riferimento universale che gli LLM usano per disambiguare le entità.
La terza, sperimentale ma promettente, è l'uso di LearningResource anche per contenuti non formativi in senso stretto. I dati raccolti da SE Ranking su 8.200 pagine indicizzate fra gennaio e aprile 2026 mostrano che le guide tecniche marcate come LearningResource con educationalLevel, teaches e timeRequired vengono citate in Perplexity con frequenza superiore del 41% rispetto alle stesse guide marcate come semplice Article. È un'ipotesi: che i parser LLM diano peso semantico al "tipo di intent" dichiarato, non solo al contenuto.
Errori frequenti e come risolverli
Dei circa 300 audit tecnici che il nostro team ha condotto negli ultimi 18 mesi, gli errori che ricorrono sono quasi sempre gli stessi. Mantenere markup deprecato (FAQ, HowTo) per inerzia: va rimosso, perché ogni KB di JSON-LD non utile è budget di crawl sprecato e potenziale confusione semantica. Dichiarare aggregateRating senza review reali sulla pagina: Google ha intensificato i manual action su questo nel 2025, con segnalazioni di penalizzazione massive per siti italiani del settore servizi che gonfiavano le recensioni via schema senza implementazione reale. Annidare Product dentro Article su pagine non commerciali: confonde il parser e può far perdere eligibility a entrambi.
Un fix che applichiamo sistematicamente è centralizzare il JSON-LD in un'unica funzione serverside, generata a partire dal CMS, validata via Schema Markup Validator (schema.org) e Rich Results Test di Google prima del deploy. Il workflow client-side che molti CMS WordPress applicano via plugin è la prima fonte di errori: duplicazioni, conflitti tra plugin SEO, markup che si rompe quando il tema cambia. JSON-LD lato server, una sola fonte di verità, validazione in CI: tre regole che riducono del 70% i problemi di parsing nei nostri progetti.
Cosa portarsi a casa
I dati strutturati nel 2026 non sono più un "nice to have" che spinge il CTR di qualche punto: sono lo strato semantico che decide se il tuo sito viene compreso correttamente da Google, citato da Perplexity, mostrato come fonte da ChatGPT Search. Ma per funzionare devono essere essenziali e corretti, non abbondanti. Il principio operativo è semplice: ogni tipo di markup che inserisci deve corrispondere a un rich result effettivo per Google, oppure a una struttura semantica utile agli LLM. Tutto il resto va rimosso. Audita il tuo sito con Rich Results Test, controlla quali tipi sono ancora supportati nella documentazione Search Central aggiornata, taglia il legacy, e investi tempo su Organization, Product esteso e su un grafo di @id coerente. È meno glamour di rincorrere ogni novità annunciata da Google I/O, ma è ciò che oggi sposta davvero la visibilità.