Dati strutturati che portano rich result veri

Introduzione

La maggior parte dei progetti schema che ereditiamo passa il Rich Results Test e non produce nulla. Il motivo raramente è un errore di sintassi. Di solito il lavoro è finito in tipi che Google non mostra più, mentre manca l'unico markup che rende negli anni: una descrizione coerente dell'azienda stessa.

Qui sotto le due cose separate. Cosa dice davvero la documentazione, quali tipi producono ancora qualcosa nel 2026, JSON-LD da adattare, e la sequenza che seguiamo in ogni progetto.

Cosa fanno e cosa non fanno i dati strutturati

Google descrive i dati strutturati come un formato standardizzato per fornire informazioni su una pagina e classificarne il contenuto. Tolgono al motore di ricerca il lavoro di dedurre dal testo corrente chi ha scritto, di quale azienda si parla, quale indirizzo vale, quando si è aperti.

Quello che ne consegue è più ristretto di quanto sostenga il mercato. I dati strutturati rendono una pagina idonea ai rich result. Non ne garantiscono nessuno. Le linee guida generali sono esplicite: anche con markup che supera il Rich Results Test non esiste alcuna promessa che una funzione compaia, perché l'algoritmo sceglie la presentazione che ritiene migliore per quell'utente.

Alla domanda sul ranking Google risponde in un punto che quasi nessuno cita. Le stesse linee guida dicono che un'azione manuale sui dati strutturati fa perdere alla pagina l'idoneità ai rich result e che questo non incide sul suo posizionamento nella ricerca web. Se nemmeno la sanzione tocca il ranking, di norma non lo tocca neanche il markup.

Resta la presentazione, dove l'effetto è reale. Nella sua introduzione Google cita quattro casi di studio, fra cui Nestlé con un tasso di clic superiore dell'82 per cento per le pagine mostrate come rich result e Rotten Tomatoes con un tasso di clic superiore del 25 per cento dopo aver marcato 100.000 pagine. Due precisazioni: sono dati dichiarati dai siti stessi e pubblicati da Google, e confrontano pagine con markup contro pagine senza, non la stessa pagina prima e dopo un cambiamento altrimenti identico.

Una regola sta sopra le altre: non marchi nulla che non sia visibile nella pagina. L'esempio di Google è un JSON-LD che descrive un artista che nel corpo HTML non compare. La conseguenza non è un declassamento, ma qualcosa di più preciso. Con un'azione manuale il markup della pagina viene ignorato del tutto. La pagina continua a posizionarsi, i suoi dati strutturati per Google non esistono più.

Quali tipi producono ancora qualcosa nel 2026

L'elenco si accorcia da anni e negli ultimi mesi il ritmo è aumentato:

• FAQPage. L'8 maggio 2026 Google ha inserito un avviso di deprecazione: la funzione non compare più nella ricerca dal 7 maggio 2026. Il 15 giugno 2026 la documentazione è stata rimossa.
• HowTo. Ritirato già ad agosto 2023, annunciato sul blog di Search Central.
• Practice problem. Documentazione rimossa il 6 gennaio 2026 perché la funzione non viene più mostrata.

Da qui una regola di pianificazione: non costruisca un business case su un singolo tipo di rich result. Google rimuove le funzioni con poche settimane di preavviso. È rimasto stabile solo il gruppo che descrive chi è Lei e come sono collegate le Sue pagine.

Per i profili di cliente con cui lavoriamo, quattro tipi rendono quasi sempre: Organization o un sottotipo LocalBusiness adatto, BreadcrumbList, Article o BlogPosting, e nel commercio Product con Offer. Event quando un hotel organizza eventi veri, JobPosting quando pubblica davvero posizioni aperte. Il resto lo valutiamo caso per caso e di solito lo lasciamo fuori.

Organization: il markup che rende univoca l'azienda

Qui sta la parte che vale anche fuori da Google. Nella documentazione di Organization, Google scrive che alcune proprietà servono dietro le quinte a disambiguare la Sua organizzazione da altre organizzazioni, e cita iso6523Code e naics come esempi. Di url dice che aiuta Google a identificare l'organizzazione in modo univoco. Di vatID: un importante segnale di fiducia, perché gli utenti possono cercare l'azienda nei registri IVA pubblici.

Non ci sono proprietà obbligatorie. Google consiglia di indicarne il maggior numero possibile fra quelle pertinenti, con peso sulla presenza reale (indirizzo, telefono) e su quella digitale (URL, logo).

Un esempio per un'azienda altoatesina, con ragione sociale in tedesco e in italiano:

{

"@context": "https://schema.org",

"@type": "Organization",

"@id": "https://www.esempio-falegnameria.it/#organization",

"name": "Falegnameria Gruber",

"alternateName": "Tischlerei Gruber",

"legalName": "Falegnameria Gruber Srl",

"url": "https://www.esempio-falegnameria.it/",

"logo": "https://www.esempio-falegnameria.it/immagini/logo-512.png",

"description": "Falegnameria per arredi su misura e finiture d'interni a Bressanone.",

"email": "info@esempio-falegnameria.it",

"telephone": "+39-0472-123456",

"vatID": "IT01234567890",

"foundingDate": "1987",

"address": {

"@type": "PostalAddress",

"streetAddress": "Via Stazione 12",

"addressLocality": "Bressanone",

"addressRegion": "BZ",

"postalCode": "39042",

"addressCountry": "IT"

},

"sameAs": [

"https://www.linkedin.com/company/esempio-falegnameria",

"https://www.instagram.com/esempio\_falegnameria"

]

}

Quattro dettagli su cui i progetti si fermano:

Un nodo, non venti. Google consiglia di mettere questi dati sulla home page o su una singola pagina dedicata all'azienda, e dice esplicitamente che non servono su ogni pagina. Assegni un @id stabile e lo richiami dagli altri blocchi. Il reperto più frequente nei nostri audit sono due blocchi Organization per pagina, uno dal tema e uno dal plugin SEO, con numeri di telefono diversi.

La vatID coerente con il Paese. Google richiede che il codice fiscale corrisponda al Paese indicato in address. Per l'Italia la partita IVA con prefisso IT, per la Germania la USt-IdNr con DE, per l'Austria ATU, per la Svizzera la UID in formato CHE.

Bilinguismo trattato bene. In Alto Adige molte aziende operano con due denominazioni. La più usata va in name, la seconda in alternateName. Non inventi una traduzione che nel registro imprese non esiste.

sameAs solo con profili reali. Colleghi profili che controlla e che sono attivi. Un rimando a una pagina Facebook cancellata non è un segnale, è una contraddizione.

Il logo deve essere di almeno 112 per 112 pixel e scansionabile.

LocalBusiness, Article e BreadcrumbList

LocalBusiness ha due proprietà obbligatorie: name e address. Google consiglia il sottotipo più specifico invece del termine generico, quindi Dentist e non LocalBusiness. Per più attività si indica un array; additionalType non è supportato.

{

"@context": "https://schema.org",

"@type": "Dentist",

"@id": "https://www.esempio-studio.it/#studio",

"name": "Studio dentistico Dr. Berger",

"url": "https://www.esempio-studio.it/",

"telephone": "+39-0471-123456",

"priceRange": "$$",

"address": {

"@type": "PostalAddress",

"streetAddress": "Via Portici 42",

"addressLocality": "Bolzano",

"addressRegion": "BZ",

"postalCode": "39100",

"addressCountry": "IT"

},

"geo": {

"@type": "GeoCoordinates",

"latitude": 46.49790,

"longitude": 11.35472

},

"openingHoursSpecification": [

{

"@type": "OpeningHoursSpecification",

"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],

"opens": "08:00",

"closes": "18:00"

},

{

"@type": "OpeningHoursSpecification",

"dayOfWeek": "Friday",

"opens": "08:00",

"closes": "13:00"

}

]

}

Google chiede almeno cinque decimali sulle coordinate. priceRange deve restare sotto i 100 caratteri, altrimenti Google non mostra alcuna fascia di prezzo.

E ora la trappola che incontriamo più spesso. Per LocalBusiness, Google consiglia aggregateRating e review solo ai siti che raccolgono recensioni su altre aziende. Marcare le quattro stelle delle proprie testimonianze come AggregateRating è la via più breve verso un'azione manuale. Non lo facciamo per nessun cliente, nemmeno quando le recensioni sono autentiche.

Per gli articoli di blog bastano due oggetti affiancati. Anche Article non ha proprietà obbligatorie:

[

{

"@context": "https://schema.org",

"@type": "BlogPosting",

"@id": "https://www.esempio.it/blog/dati-strutturati#article",

"headline": "Dati strutturati che portano rich result veri",

"image": ["https://www.esempio.it/immagini/schema-16x9.jpg"],

"datePublished": "2026-07-29T09:00:00+02:00",

"dateModified": "2026-07-29T09:00:00+02:00",

"author": {

"@type": "Person",

"name": "Jonas Tribus",

"jobTitle": "CTO",

"url": "https://www.esempio.it/author/jonas-tribus"

},

"publisher": { "@id": "https://www.esempio.it/#organization" }

},

{

"@context": "https://schema.org",

"@type": "BreadcrumbList",

"itemListElement": [

{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.esempio.it/blog" },

{ "@type": "ListItem", "position": 2, "name": "SEO", "item": "https://www.esempio.it/blog/seo" },

{ "@type": "ListItem", "position": 3, "name": "Dati strutturati" }

]

}

]

Due note. In author.name va solo il nome. Google elenca esplicitamente fra gli errori i titoli professionali, gli appellativi e le formule introduttive tipo "pubblicato da", e rimanda a jobTitle per il ruolo. E l'ultimo elemento del breadcrumb non porta item, perché è la pagina corrente.

Dati strutturati e risposte IA

Da maggio 2026 esiste una risposta ufficiale, ed è più asciutta di quanto il mercato vorrebbe. Nella guida all'ottimizzazione per le funzioni di IA generativa, Google mette "Overfocusing on structured data" fra i miti da sfatare: i dati strutturati non sono necessari per la ricerca con IA generativa e non esiste alcun markup schema.org speciale da aggiungere. Restano utili nel lavoro SEO complessivo perché creano l'idoneità ai rich result. Nella stessa sezione si legge che Google Search ignora llms.txt.

Chi Le vende un "pacchetto schema per le AI Overview" sta contraddicendo la documentazione del fornitore di cui vende la funzione.

Il valore in termini di entità resta però reale, solo altrove: nella disambiguazione, che è esattamente dove Google lo colloca. Se a Bressanone un hotel, una falegnameria e uno studio legale portano lo stesso cognome, è la combinazione di indirizzo, partita IVA, URL e profili verificati a decidere quale sia quello giusto. Quei dati restano corretti anche quando nessuno mostra un rich result.

Non deduca dal markup Schema.org un vantaggio garantito in ChatGPT, Perplexity o Gemini: la documentazione dei fornitori citata qui non offre questa garanzia. Su cosa sposta davvero la visibilità nelle risposte IA, veda il nostro confronto sulla differenza fra SEO, AEO e GEO e la descrizione del servizio di visibilità nelle risposte IA. L'effetto si misura in Search Console, nel rapporto sul rendimento nelle funzioni di IA generativa.

La sequenza che seguiamo in ogni progetto

1. Inventario su cinque tipi di pagina. Home page, una pagina servizio, una pagina sede, un articolo, la pagina contatti. Rich Results Test più una lettura del sorgente. Prima i duplicati, poi gli errori.
2. Riconciliazione dei dati. Ragione sociale, indirizzo, telefono e partita IVA devono coincidere con le note legali e con il profilo dell'attività su Google. Le note legali sono la fonte più affidabile perché vengono mantenute per obbligo. Dove la grafia di vie e nomi varia, vale una sola variante ovunque.
3. Un solo nodo Organization. Sulla home page, con @id stabile. Tutto il resto lo richiama invece di ripeterlo.
4. Rendering lato server. Google elabora anche il JSON-LD inserito via JavaScript, ma ogni dipendenza in più è un modo per rompere tutto al deployment successivo.
5. Due validazioni, due domande. Il Rich Results Test risponde se una pagina è idonea a una funzione di Google. Lo Schema Markup Validator su validator.schema.org risponde se il vocabolario è valido, compresi i tipi che Google non usa. Poi il controllo URL in Search Console, perché solo quello mostra cosa vede Google dopo il rendering.
6. Aspettare e osservare. Google avverte che dopo la pubblicazione possono servire diversi giorni prima che una pagina venga trovata e scansionata. Chi si aspetta risultati la mattina dopo sta misurando rumore.

Cosa lasciamo fuori di proposito: le recensioni su noi stessi, ogni ulteriore lavoro su FAQPage, e qualsiasi dato che nella pagina non compaia. Le fondamenta tecniche sotto tutto questo, dalla consegna alla scansionabilità, sono le basi tecniche di un sito. Come si collegano tempi di caricamento e stabilità lo trova in Core Web Vitals nella pratica.