Schema Markup: Guida Completa ai Dati Strutturati dopo gli ultimi aggiornamenti (esempi JSONLD)

Schema Markup: La Guida Definitiva ai Dati Strutturati per SEO e AI Search

C’è un problema nel modo in cui il settore SEO parla di Schema markup. Da anni l’industria trascina una singola parola — schema — attraverso tre lavori diversi, su tre scale temporali diverse, per tre sistemi consumatori diversi. La confusione che ne risulta è strutturale, non accidentale. L’equazione che costa di più è quella familiare: Schema = JSON-LD = rich results. Collassa queste tre cose in una sola, e otterrai la patologia ricorrente che Gianluca Fiorelli ha definito “Schema Sacrifice”: professionisti che sovra-ingegnerizzano il markup per inseguire rich results volatili, poi concludono che “Schema è morto” nel momento in cui Google ritira una feature di visualizzazione.

Schema non è morto. Quello che muore, con cadenza biennale circa, sono le feature di visualizzazione.

L’11 maggio 2026, Ahrefs ha pubblicato uno studio causale su 1.885 pagine, monitorando cosa succede alle citazioni AI dopo l’aggiunta di markup JSON-LD. Il risultato è stato nullo: citazioni ChatGPT +2.2%, Google AI Mode +2.4% (entrambi indistinguibili dallo zero statistico), e Google AI Overviews addirittura -4.6%. Entro 48 ore, metà di SEO Twitter ha dichiarato Schema morto. L’altra metà citava blog di vendor che promettevano un boost del 2.5x sulle citazioni.

Entrambi i campi sbagliano, e sbagliano nello stesso modo. Stanno rispondendo a una domanda che Schema non è mai stato costruito per rispondere, misurata al layer dove Schema fa meno, su una scala temporale che non può rilevare il layer dove Schema fa di più.

Con oltre 15 anni di esperienza nell’implementazione di dati strutturati per siti enterprise e PMI, ho visto questo pattern ripetersi decine di volte. Implementazioni frettolose inseguendo l’ultimo rich result del momento, poi frustrazione quando Google cambia le regole. La verità è che Schema markup, implementato correttamente, è una delle infrastrutture più stabili e a lungo termine che puoi costruire per il tuo sito — ma solo se capisci cosa sta realmente facendo.

In questa guida ti mostrerò cos’è realmente Schema markup (e cosa non è), come funziona ai diversi livelli architetturali e temporali, come implementarlo correttamente con esempi di codice JSON-LD, e perché la mentalità giusta è pensarlo come “registrazione aziendale” piuttosto che “pubblicità”. Non teoria astratta: comprensione profonda che ti permetterà di fare scelte strategiche informate.

Lo Schema Sacrifice — costruire markup contro obiettivi volatili di rich results — è una strategia che ti lascia esposto ogni volta che Google decide di ritirare una feature. L’episodio FAQ/HowTo del 2023-2026 lo ha dimostrato in termini di policy. La deprecazione completa dei rich results FAQ nel maggio 2026, con la documentazione ufficiale che esplicitamente dice che Google continuerà a usare i dati strutturati FAQ per comprendere le pagine anche senza mostrare il rich result, è l’architettura tradotta in policy.

Questa guida ti insegnerà a costruire su fondamenta stabili, non su sabbie mobili.

❓ Domande Frequenti su Schema Markup

Prima di entrare nei dettagli tecnici, rispondiamo alle domande più comuni che ricevo da sviluppatori, SEO e imprenditori che si avvicinano al mondo dei dati strutturati.

Cos’è esattamente Schema markup?

Schema markup è un vocabolario standardizzato di tipi e proprietà che permette di descrivere entità (persone, organizzazioni, prodotti, articoli, eventi, etc.) in modo che le macchine possano comprenderle. È mantenuto da Schema.org, un consorzio fondato nel 2011 da Google, Microsoft, Yahoo e Yandex.

Il vocabolario include migliaia di tipi (Person, Organization, Product, Recipe, Article, MedicalCondition, Event…) e proprietà (name, author, sameAs, priceCurrency, knowsAbout…). Quando aggiungi Schema markup a una pagina, stai dichiarando in termini machine-readable: “Questa pagina parla di questa specifica entità, che ha queste proprietà, e si collega a queste altre entità”.

È importante distinguere tre cose che l’industria spesso confonde:

• Schema.org: il vocabolario (i tipi e le proprietà)
• JSON-LD, Microdata, RDFa: le serializzazioni (i formati sintattici per esprimere il vocabolario)
• Rich results: gli output (una delle possibili manifestazioni visibili, non l’unica)

Qual è la differenza tra JSON-LD, Microdata e RDFa?

Sono tre modi diversi di scrivere la stessa cosa — tre alfabeti per lo stesso linguaggio. JSON-LD usa blocchi JavaScript separati, Microdata usa attributi HTML inline, RDFa usa attributi XML-like. Un parser che converte qualsiasi dei tre in triple RDF produrrà output semanticamente equivalente.

JSON-LD è diventato il formato preferito da Google non perché sia semanticamente più ricco, ma perché è operativamente più pulito:

• Vive in un blocco <script type="application/ld+json"> separato
• Non si intreccia con il DOM renderizzato
• Può essere iniettato via tag manager o template server-side senza toccare il codice frontend
• È più facile da generare dinamicamente e debuggare

Microdata e RDFa rimangono validi e parsati da Google, ma per nuove implementazioni JSON-LD è la scelta raccomandata.

Schema markup migliora il ranking?

No, non direttamente. John Mueller e Danny Sullivan di Google hanno dichiarato ripetutamente e pubblicamente che Schema non ha nulla a che fare con il ranking e non fornisce un boost di posizionamento. Ryan Levering, ingegnere dei dati strutturati di Google, ha chiarito che Schema è trattato come un segnale, non come verità assoluta, e viene sovrascritto quando il markup contraddice il contenuto visibile o segnali di autorità consolidati.

Il percorso indiretto — rich result → CTR più alto → segnale comportamentale → ranking — è reale, ma comprimerlo in “Schema è un fattore di ranking” significa rappresentare erroneamente una catena a quattro step come un effetto diretto.

Quello che Schema fa realmente è renderti leggibile ai sistemi che decidono se presentarti. Essere leggibile non causa direttamente ranking o citazioni; rende possibile che i sistemi ti considerino quando arriva il momento di presentare qualcuno.

Schema markup aiuta con l’AI Search?

Sì, ma non nel modo in cui molti credono, e non al layer dove è facile misurare. Lo studio Ahrefs di maggio 2026 ha prodotto un risultato nullo sulle citazioni AI — ma ha misurato il layer sbagliato (Life 3: runtime retrieval) su una finestra temporale troppo breve (30 giorni) per rilevare gli effetti che Schema produce ai layer dove fa di più (Life 1: index pipeline, Life 2: pretraining).

Google ha confermato esplicitamente (Ryan Levering, Search Central Live Toronto, aprile 2026) che il lavoro di dati strutturati a Life 1 alimenta AI Overviews e AI Mode. Per gli altri provider (OpenAI, Anthropic, Perplexity), non c’è conferma first-party verificata che i loro motori di retrieval runtime parsino JSON-LD nativamente — l’evidenza empirica indica che al Life 3 Schema viene letto come testo plain, non come struttura parsata.

La claim difendibile è più ristretta e più forte: i sistemi AI search sono entity-and-attribute-aware; Schema è il modo più economico e pulito per comunicare informazioni su entità e attributi; costruire per i layer che compongono nel tempo è l’unica strategia sostenibile.

Cosa sono i rich results e sono garantiti?

I rich results sono una delle possibili manifestazioni consumer-facing del markup, limitata a un sottoinsieme del vocabolario, disponibile in giurisdizioni limitate, e soggetta a revoca in qualsiasi momento.

Google supporta circa 800 tipi Schema.org per la comprensione del contenuto; la sua Rich Results Gallery ne copre poche decine. L’implicazione è diretta: la maggior parte del vocabolario fa lavoro che non produce mai un cambiamento visibile nella SERP. L’episodio FAQ/HowTo lo dimostra: Google ha ritirato il rich result ma continua a usare i dati strutturati per comprendere le pagine.

Costruire una strategia Schema interamente intorno ai rich results è costruire su una feature di prodotto che la piattaforma può revocare a piacimento.

Cosa è successo con FAQ e HowTo Schema?

Agosto/Settembre 2023: Google restringe i FAQ rich results ai siti autorevoli e depreca i HowTo rich results. 7 Maggio 2026: deprecazione completa dei FAQ rich results. Ma — e questo è il punto cruciale — la documentazione ufficiale dice esplicitamente che Google continuerà a usare i dati strutturati FAQ per comprendere le pagine, anche se il rich result è stato eliminato.

Questa è l’architettura tradotta in policy: la feature di display (output) è stata ritirata, ma il vocabolario (Schema.org FAQPage) rimane valido, il markup continua a essere parsato a Life 1 per la comprensione, influenza indirettamente il territorio Life 2 negli aggiornamenti a lungo termine.

I professionisti che hanno costruito strategie FAQ come fini a se stesse sono bloccati. Quelli che hanno trattato FAQPage come una delle tante asserzioni semantiche sulla pagina hanno perso un enhancement CTR e mantenuto tutto il resto.

Quanto tempo ci vuole per vedere effetti dallo Schema?

Dipende da quale layer stai cercando di influenzare. I rich results possono apparire entro giorni/settimane dal crawl. Gli effetti sul Knowledge Graph operano su cicli di indicizzazione più lunghi (settimane/mesi). Gli effetti indiretti su LLM pretraining (Life 2) compongono su snapshot e release di modelli — una scala temporale misurata in anni, non settimane.

Non puoi fare un test di 30 giorni contro Life 2. Ogni nuova versione del modello trainata su uno snapshot fresco porta avanti, o non porta avanti, la rappresentazione dell’entità che il tuo sito ha emesso per anni.

Cosa significa “Entity Home”?

Entity Home è un concetto sviluppato da Jason Barnard: la pagina web che Google considera la fonte autorevole di verità per una specifica entità. È la pagina che “possiede” l’entità nel Knowledge Graph di Google.

L’Entity Home tipicamente è la pagina “Chi siamo” o “About” per un’organizzazione, la pagina profilo o sito personale per una persona. È la pagina dove dichiari @type, name, sameAs verso risorse esterne autorevoli (Wikidata, Wikipedia, LinkedIn, registri ufficiali), e tutte le proprietà rilevanti dell’entità.

Nel giugno 2025, Google ha eseguito quello che Barnard ha documentato come “Great Clarity Cleanup”: circa 3 miliardi di entità rimosse dal Knowledge Graph, una contrazione del 6.26% della comprensione mondiale di Google, con la quota maggiore di rimozioni che colpiva classificazioni “multityped” e ambigue “Thing”. Sopravvivere al cleanup richiede link non ambigui a una categoria specifica (Organization, Person, Product) supportati da validazione esterna consistente.

Devo implementare Schema su tutte le pagine?

No, non necessariamente su tutte, ma su tutte le pagine che rappresentano o descrivono entità importanti per il tuo business. Homepage, pagina about/chi siamo, pagine prodotto, pagine servizio, pagine autore, articoli di blog — queste sono candidate primarie.

La priorità dovrebbe andare a:

1. Entity Home (Organization o Person principale)
2. Pagine prodotto/servizio (Product, Service, Offer)
3. Contenuti (Article, BlogPosting con author linkato)
4. Contatti e locazioni (LocalBusiness, ContactPoint)

Markup che non identifica entità reali, non dichiara proprietà significative, e non include sameAs links, è markup che valida ma non contribuisce nulla al layer entità.

🏗️ I Tre Layer Architetturali: Vocabolario, Serializzazione, Output

Per capire cosa Schema sta realmente facendo, devi separare tre layer che l’industria insiste nel fondere. Questa separazione è fondamentale perché i tre layer falliscono e evolvono indipendentemente.

Layer 1: Il Vocabolario (Schema.org)

Schema.org è un vocabolario: un insieme di tipi (Person, Organization, Product, Recipe, Article, e migliaia di altri) e proprietà (name, author, sameAs, priceCurrency, knowsAbout) mantenuto dal 2011 da un consorzio fondato da Google, Microsoft, Yahoo e Yandex, con R.V. Guha come lead architetturale e Dan Brickley come curatore storico.

Il vocabolario siede formalmente sopra RDF Schema (RDFS) ed è quindi esprimibile in qualsiasi sintassi RDF-compatibile. Questo significa che Schema.org non è legato a un formato specifico — è un linguaggio concettuale che può essere scritto in diversi “alfabeti”.

Caratteristiche chiave del vocabolario:

• Gerarchia di tipi: Thing è il tipo radice, da cui discendono Organization, Person, CreativeWork, Product, Place, Event, Action, etc.
• Ereditarietà proprietà: un tipo figlio eredita le proprietà del tipo padre
• Estensibilità: esistono estensioni verticali (health-lifesci, auto, bib) per domini specifici
• Governance comunitaria: opera attraverso un W3C Community Group con Steering Group che approva le proposte via GitHub

La governance è un punto cruciale. Schema.org è governato comunitariamente ed è stabile attraverso i cicli di prodotto. È un contratto semantico su cui puoi costruire con confidenza a lungo termine.

Layer 2: La Serializzazione (JSON-LD, Microdata, RDFa)

JSON-LD, Microdata e RDFa sono serializzazioni: vasi sintattici alternativi per lo stesso contenuto semantico. L’analogia è più precisa di quanto sembri: il vocabolario è una lingua, la sintassi è una grammatica, la serializzazione è un alfabeto — Romano, Cirillico, Greco — script diversi che scrivono le stesse parole.

JSON-LD (JavaScript Object Notation for Linked Data):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Gianni Puglisi Digital",
  "url": "https://giannipuglisi.it",
  "sameAs": [
    "https://www.linkedin.com/in/giannipuglisi/",
    "https://www.wikidata.org/wiki/Q..."
  ]
}
</script>

Microdata (attributi HTML inline):

<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">Gianni Puglisi Digital</span>
  <a itemprop="url" href="https://giannipuglisi.it">Sito</a>
</div>

RDFa (attributi XML-like):

<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">Gianni Puglisi Digital</span>
  <a property="url" href="https://giannipuglisi.it">Sito</a>
</div>

Un parser che converte Microdata, RDFa o JSON-LD in triple RDF produrrà output semanticamente equivalente in tutti e tre i casi. La preferenza per JSON-LD è una raccomandazione di deployment, non un ruling semantico.

Layer 3: Gli Output (Rich Results e oltre)

I rich results sono output: una possibile manifestazione consumer-facing, limitata a:

• Un piccolo sottoinsieme del vocabolario
• Giurisdizioni geografiche limitate
• Requisiti di eligibilità specifici
• Soggetta a revoca in qualsiasi momento

Google supporta circa 800 tipi Schema.org per la comprensione del contenuto. La sua Rich Results Gallery copre poche decine. L’implicazione è diretta: la maggior parte del vocabolario fa lavoro che non produce mai un cambiamento visibile nella SERP.

Altri output oltre ai rich results:

• Knowledge Panel
• Author attribution
• Entity disambiguation nelle query branded
• Feedstock per i sistemi generativi di Google
• Sitelinks strutturati

La documentazione Organization di Google è esplicita su questo punto: non elenca proprietà richieste, ma dice “raccomandiamo di aggiungere quante più proprietà rilevanti possibile per la tua organizzazione” — 28 proprietà suggerite per Organization, contro le 40+ proprietà dirette di Schema.org sul tipo.

Indipendenza dei tre layer

Questo è il punto cruciale: i tre layer falliscono e evolvono indipendentemente.

• Una serializzazione può essere deprecata senza ritirare il vocabolario
• Un’eligibilità rich result può essere revocata senza invalidare il markup sottostante
• Il vocabolario può espandersi senza che nuovi tipi generino rich results

L’episodio FAQ/HowTo del 2023-2026 ha dimostrato questa indipendenza in termini di policy. Il display feature (output) è stato ritirato. Il vocabolario (Schema.org FAQPage) rimane valido. Il markup continua a essere parsato a Life 1 per la comprensione.

⏱️ Le Tre Vite dello Schema: Index Time, Pretraining Time, Query Time

L’architettura ti dice cosa Schema è. Per spiegare quando fa cosa per chi, serve un secondo asse: quello che Suganthan Mohanadasan ha utilmente etichettato “le tre vite” del markup Schema, ognuna che corre su un clock diverso per un sistema consumatore diverso.

Life 1: Google Index Pipeline (il lavoro originale)

Questa è la vita originale, il caso d’uso per cui Schema.org è stato progettato nel 2011, e quello che paga ancora il dividendo più alto.

Come funziona:

1. Googlebot estrae sia l’HTML visibile che il blocco JSON-LD al primo fetch
2. Il markup iniettato via JavaScript viene accodato per un secondo render pass attraverso il Web Rendering Service
3. Il contenuto visibile alimenta la pipeline di ranking
4. I dati strutturati alimentano una pipeline entità separata

Cosa fa la pipeline entità:

• Identifica quale entità la pagina descrive
• Verifica se quell’entità esiste nel Knowledge Graph
• Segue i link sameAs per ancorare l’entità attraverso il web
• Crea o aggiorna il record dell’entità

Tutto questo processo avviene offline, in batch, prima che qualsiasi utente abbia cercato qualcosa.

Gli output di Life 1:

• Rich results (dove i tipi sono eligibili)
• Knowledge Panel per organizzazioni e persone
• Author attribution
• Entity disambiguation nelle query branded
• Feedstock per AI Overviews e AI Mode

A Search Central Live Toronto nell’aprile 2026, l’ingegnere dei dati strutturati di Google Ryan Levering ha riaffermato che questa pipeline alimenta anche AI Overviews e AI Mode, elencando quattro ragioni per cui i dati strutturati contano ancora:

1. Sono più precisi dell’estrazione LLM su contenuti complessi come i prezzi dei prodotti
2. Possono esprimere informazioni non visibili sulla pagina
3. Parsare dati strutturati è più economico che inferire ripetutamente il significato dalla prosa
4. Il markup giusto focalizza l’attenzione della macchina escludendo contesto irrilevante

Life 2: LLM Pretraining (l’influenza indiretta)

I modelli fondazionali — GPT, Claude, Gemini e gli altri — si addestrano su enormi corpora di testo. Mentre l’input pubblico più grande è Common Crawl, che cattura pagine HTML complete, le moderne pipeline di pulizia ed estrazione testo strippano ampiamente i blocchi JSON-LD.

Cosa succede durante la pulizia dei dati:

• Le euristiche di data curation per dataset come C4 strippano le righe contenenti parentesi graffe, rimuovendo la maggior parte del JSON-LD
• Pipeline di scraping altamente ottimizzate come FineWeb isolano esplicitamente il testo prosa principale e scartano completamente i tag script

Ma ecco il punto cruciale: il codice JSON-LD stesso non sopravvive direttamente alla pulizia nei corpora di testo. L’intervento di Schema a Life 2 è strutturale e indiretto.

Per oltre un decennio, dati strutturati puliti hanno alimentato store entità canonici e il Knowledge Graph di Google. Poiché questi profili entità ottimizzati, panel di ricerca e superfici autorevoli sono pesantemente rappresentati nel testo pubblico e profondamente ingeriti nei training set, i dati strutturati storici di un sito si compongono nella memoria parametrica dell’LLM attraverso gli entity store che ha originariamente popolato.

Cosa significa per te:

• Questo layer è invisibile alla misurazione a breve termine
• Non puoi fare un test di 30 giorni contro Life 2
• Ogni nuova versione del modello trainata su uno snapshot fresco porta avanti (o non porta avanti) la rappresentazione dell’entità che il tuo sito ha emesso per anni
• La disciplina Schema che costruisci oggi potrebbe influenzare come un LLM ti rappresenta tra 2 anni

Life 3: LLM Runtime Retrieval (dove lo studio Ahrefs ha misurato)

Questo è il layer che lo studio Ahrefs ha misurato — e quello dove Schema fa meno.

Quando chiedi a ChatGPT, Claude, Perplexity o Google AI Mode una domanda che triggera una web search, il sistema:

1. Effettua una ricerca web
2. Fetcha pagine live
3. Le parsa
4. Usa il contenuto estratto per grounding della risposta

L’esperimento searchVIU di ottobre 2025, documentato su Search Engine Land, ha testato questo comportamento su tutti e cinque i principali sistemi e ha trovato un pattern consistente: quando un assistente fetchava una pagina live attraverso la sua pipeline di retrieval standard, strippava i blocchi JSON-LD e si affidava interamente all’HTML visibile. Schema era ignorato come dati strutturati a questo layer.

Il test Williams-Cook di febbraio 2026 ha chiarito la ragione meccanica esatta: gli LLM tokenizzano l’intera risposta HTML, inclusi i blocchi script, quindi possono leggere i caratteri dentro schema come testo plain, ma non li parsano come dati strutturati.

A Life 3, Schema è funzionalmente trattato come caratteri di testo raw, non struttura interpretata.

Riepilogo delle Tre Vite

🎯 Cosa Schema Fa Realmente: I 5 Scopi Fondamentali

La formulazione canonica di Aaron Bradley — che i dati strutturati hanno spostato la SEO “from strings to things” (dalle stringhe alle cose) — è corretta, ma solo se i professionisti sono disposti a identificare le cose. Ecco i cinque scopi fondamentali di Schema, in ordine decrescente di supporto evidenziale.

1. Entity Disambiguation (il core architetturale)

Quando una pagina dichiara @type: Organization, name: "Tratos", e sameAs: ["https://www.wikidata.org/wiki/Q...", "https://www.linkedin.com/company/tratos", "https://www.tratosgroup.com"], sta facendo quello che la prosa non può fare: asserire, in termini machine-resolvable, quale Tratos questa pagina riguarda, e puntare a nodi esterni autorevoli contro cui qualsiasi consumatore può fare join.

Questo è il core architetturale di quello che Jason Barnard chiama Entity Home. La disciplina è diventata materialmente più consequenziale nel giugno 2025, quando Google ha eseguito il “Great Clarity Cleanup”: circa 3 miliardi di entità rimosse dal Knowledge Graph, una contrazione del 6.26% della comprensione mondiale di Google, con la quota maggiore di rimozioni che colpiva classificazioni “multityped” e ambigue “Thing”.

Sopravvivere al cleanup richiede:

• Link non ambigui a una categoria specifica (Organization, Person, Product)
• Validazione esterna consistente
• sameAs discipline verso target di alta autorità

I target della proprietà sameAs si sono spostati verso l’alto in autorità: Wikipedia, Wikidata, registri governativi (Companies House UK, LEI, INPI Francia, Camera di Commercio Italia), numeri DUNS, e profili social primary-source.

2. Knowledge Graph Contribution

Il Knowledge Graph di Google, Satori di Microsoft, e i vari grafi verticali consumano markup Schema.org come uno dei tanti input, insieme a Wikidata, dataset licenziati, feed strutturati, web extraction, e curazione umana.

Il lavoro pubblicato da Google sul Knowledge Vault descrive una knowledge base probabilistica che accresce fatti sulle entità combinando text extraction con structured-data extraction e conoscenza pregressa da grafi esistenti, assegnando confidence score piuttosto che trattare qualsiasi singola fonte come ground truth.

Bill Slawski ha consistentemente enfatizzato che il layer entità è dove Google ha investito la sua ingegneria più costosa per oltre un decennio, e Schema è uno degli input più economici e puliti a quella pipeline.

3. Machine-Readable Semantic Explication

Il framing originale di Brickley e Guha nel loro paper ACM del 2016:

1. Una pagina ha un significato sottostante che gli umani estraggono dalla prosa
2. Il markup Schema rende un sottoinsieme di quel significato esplicito, così che motori di ricerca, assistenti vocali (e agenti basati su LLM, ipotizzerei) non devono ricostruirlo in modo lossy

Il punto è cooperazione, non gaming. Stai aiutando le macchine a capire quello che gli umani già capiscono dalla lettura.

4. Type and Property Constraints on Interpretation

Dichiarare @type: MedicalCondition piuttosto che @type: Article è un impegno forte su come un consumatore dovrebbe modellare la pagina:

• Quale set di proprietà aspettarsi
• Quali tipi di autorità richiedere
• Quali claim fattuali estrarre

La disciplina si propaga a cascata:

• Un Product vincola per brand, manufacturer, offers
• Una Person vincola per worksFor, knowsAbout, sameAs
• Un Article vincola per author, datePublished, publisher

5. Multilingual Disambiguation

Un link sameAs a un Q-identifier Wikidata è language-neutral. Una pagina italiana su Roma e una pagina inglese su Rome, entrambe sameAs-linkate allo stesso Q-id, vengono unite in un singolo nodo entità.

Questo è particolarmente potente per business internazionali o contenuti multilingua.

Le Proprietà Sottoutilizzate: about e mentions

Due proprietà meritano menzione specifica perché sono drammaticamente sottoutilizzate:

• about: nomina l’entità principale di cui la pagina tratta
• mentions: nomina entità che sono referenziate senza essere centrali

Insieme permettono a una pagina di dichiarare la sua topologia semantica — di cosa argomenta, cosa cita, cosa sfiora soltanto — in termini su cui un Knowledge Graph può agire.

La maggior parte delle pagine che portano markup Schema non porta nulla di questo. Dichiarano un tipo e un nome e si fermano — markup che soddisfa un validatore ma non contribuisce nulla al layer entità.

💻 Implementazione JSON-LD: Sintassi e Struttura

Passiamo alla pratica. Ecco come scrivere markup JSON-LD corretto, con esempi di codice per i casi d’uso più comuni.

Anatomia di un blocco JSON-LD

Un blocco JSON-LD ha questa struttura base:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TipoEntità",
  "@id": "https://tuosito.it/#identificatore-unico",
  "proprietà1": "valore1",
  "proprietà2": "valore2",
  "proprietàAnnidata": {
    "@type": "AltroTipo",
    "nome": "valore"
  }
}
</script>

Elementi chiave:

• @context: sempre “https://schema.org” (definisce il vocabolario)
• @type: il tipo di entità (Organization, Person, Product, etc.)
• @id: identificatore URI univoco per l’entità (fondamentale per grafi annidati)
• Proprietà: coppie chiave-valore che descrivono l’entità

Schema Organization (Entity Home)

L’Organization è tipicamente l’Entity Home del tuo business — la dichiarazione centrale di chi sei:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://giannipuglisi.it/#organization",
  "name": "Gianni Puglisi Digital",
  "alternateName": "Gianni Puglisi Consulente SEO",
  "url": "https://giannipuglisi.it",
  "logo": {
    "@type": "ImageObject",
    "url": "https://giannipuglisi.it/logo.png",
    "width": 600,
    "height": 60
  },
  "description": "Consulenza SEO e Digital Marketing in Sicilia. Oltre 15 anni di esperienza in ottimizzazione siti web, WordPress e strategie digitali.",
  "foundingDate": "2010",
  "founder": {
    "@id": "https://giannipuglisi.it/#person-gianni"
  },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Palermo",
    "addressRegion": "Sicilia",
    "addressCountry": "IT"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+39-XXX-XXXXXXX",
    "contactType": "customer service",
    "availableLanguage": ["Italian", "English"]
  },
  "sameAs": [
    "https://www.linkedin.com/in/giannipuglisi/",
    "https://twitter.com/giannipuglisi",
    "https://www.facebook.com/giannipuglisidigital",
    "https://www.wikidata.org/wiki/QXXXXXXX"
  ],
  "knowsAbout": [
    "SEO",
    "Search Engine Optimization",
    "WordPress",
    "Digital Marketing",
    "Schema Markup",
    "Dati Strutturati"
  ]
}
</script>

Note importanti:

• @id usa un frammento URI (#organization) che rimane stabile nel tempo
• sameAs punta a profili esterni autorevoli che corroborano l’identità
• founder referenzia un altro @id nello stesso grafo (Person)
• knowsAbout dichiara le aree di competenza

Schema Person (per fondatori, autori, professionisti)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://giannipuglisi.it/#person-gianni",
  "name": "Gianni Puglisi",
  "givenName": "Gianni",
  "familyName": "Puglisi",
  "jobTitle": "SEO Consultant & Digital Marketing Strategist",
  "description": "Consulente SEO con oltre 15 anni di esperienza in Sicilia. Specializzato in ottimizzazione WordPress, dati strutturati e strategie di visibilità digitale.",
  "image": "https://giannipuglisi.it/gianni-puglisi.jpg",
  "url": "https://giannipuglisi.it/chi-sono/",
  "worksFor": {
    "@id": "https://giannipuglisi.it/#organization"
  },
  "alumniOf": {
    "@type": "EducationalOrganization",
    "name": "Università degli Studi di Palermo"
  },
  "knowsAbout": [
    "Search Engine Optimization",
    "Schema Markup",
    "WordPress Development",
    "E-commerce SEO",
    "Technical SEO",
    "Digital Marketing Strategy"
  ],
  "sameAs": [
    "https://www.linkedin.com/in/giannipuglisi/",
    "https://twitter.com/giannipuglisi",
    "https://github.com/giannipuglisi",
    "https://www.wikidata.org/wiki/QXXXXXXX"
  ]
}
</script>

L’esempio Games Workshop/Darren Latham dalla Branded SEO Guide 2026 di Fiorelli mostra il pattern concreto: un nodo Person con additionalName, jobTitle, worksFor che linka a un @id Organization stabile, knowsAbout che elenca competenze specifiche, e sameAs che punta a profili esterni autorevoli.

Schema Article con Author linkato

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://giannipuglisi.it/blog/schema-markup-guida/#article",
  "headline": "Schema Markup: La Guida Definitiva ai Dati Strutturati",
  "description": "Guida completa allo Schema markup per SEO e AI Search nel 2026.",
  "image": "https://giannipuglisi.it/images/schema-markup-hero.jpg",
  "datePublished": "2026-05-19",
  "dateModified": "2026-05-19",
  "author": {
    "@id": "https://giannipuglisi.it/#person-gianni"
  },
  "publisher": {
    "@id": "https://giannipuglisi.it/#organization"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://giannipuglisi.it/blog/schema-markup-guida/"
  },
  "about": [
    {
      "@type": "Thing",
      "name": "Schema.org",
      "sameAs": "https://www.wikidata.org/wiki/Q3475322"
    },
    {
      "@type": "Thing",
      "name": "Structured data",
      "sameAs": "https://www.wikidata.org/wiki/Q26813700"
    }
  ],
  "mentions": [
    {
      "@type": "Person",
      "name": "Gianluca Fiorelli",
      "sameAs": "https://www.linkedin.com/in/gianlucafiorelli/"
    },
    {
      "@type": "Organization",
      "name": "Google",
      "sameAs": "https://www.wikidata.org/wiki/Q95"
    }
  ]
}
</script>

Nota l’uso di about e mentions: dichiarano esplicitamente la topologia semantica dell’articolo — di cosa parla principalmente (Schema.org, Structured data) e cosa menziona (Gianluca Fiorelli, Google). Questo è il markup che contribuisce al layer entità, non solo decorazione.

Schema LocalBusiness (per attività locali)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://esempio.it/#localbusiness",
  "name": "Ristorante Da Mario",
  "image": "https://esempio.it/ristorante.jpg",
  "url": "https://esempio.it",
  "telephone": "+39-091-XXXXXXX",
  "priceRange": "€€",
  "servesCuisine": "Italian",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via Roma 123",
    "addressLocality": "Palermo",
    "postalCode": "90100",
    "addressRegion": "PA",
    "addressCountry": "IT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 38.1157,
    "longitude": 13.3615
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "12:00",
      "closes": "15:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "19:00",
      "closes": "23:00"
    }
  ],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "127"
  },
  "sameAs": [
    "https://www.facebook.com/ristorantedamario",
    "https://www.instagram.com/ristorantedamario",
    "https://goo.gl/maps/XXXXX"
  ]
}
</script>

Schema Product con Offer

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://shop.esempio.it/prodotto-xyz/#product",
  "name": "Plugin SEO Premium WordPress",
  "image": "https://shop.esempio.it/images/plugin-seo.jpg",
  "description": "Plugin WordPress per ottimizzazione SEO avanzata con supporto Schema markup automatico.",
  "sku": "PLG-SEO-001",
  "mpn": "SEO2026PRO",
  "brand": {
    "@type": "Brand",
    "name": "Gianni Puglisi Digital"
  },
  "manufacturer": {
    "@id": "https://giannipuglisi.it/#organization"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.esempio.it/prodotto-xyz/",
    "priceCurrency": "EUR",
    "price": "99.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@id": "https://giannipuglisi.it/#organization"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "45"
  }
}
</script>

🔗 sameAs Discipline: Il Collegamento alle Fonti Autorevoli

Se dovessi identificare la singola proprietà più sottovalutata e mal implementata in Schema markup, sarebbe sameAs. Questa proprietà è il meccanismo principale attraverso cui dichiari l’identità della tua entità in termini che i Knowledge Graph possono verificare e ancorare.

Cos’è sameAs e perché è cruciale

sameAs è una proprietà che punta a URL di pagine che descrivono la stessa entità. Non pagine correlate, non pagine che parlano dell’entità — pagine che sono la rappresentazione dell’entità su altre piattaforme.

Cosa fa sameAs per il Knowledge Graph:

• Permette ai sistemi di disambiguare quale specifica entità stai descrivendo
• Fornisce corroborazione esterna dell’esistenza e identità dell’entità
• Crea link cross-platform che i grafi possono seguire per unificare informazioni
• Stabilisce autorità attraverso il collegamento a fonti verificabili

Dopo il Great Clarity Cleanup di giugno 2025, la sameAs discipline è diventata ancora più critica. Google ha rimosso 3 miliardi di entità ambigue dal Knowledge Graph. Le entità sopravvissute sono quelle con link non ambigui a categorie specifiche, supportati da validazione esterna consistente.

Gerarchia delle fonti sameAs per autorità

Non tutti i link sameAs hanno lo stesso peso. Ecco la gerarchia per autorità, dal più forte al meno forte:

Tier 1 — Massima autorità (Knowledge Graphs primari):

• Wikidata (Q-identifier): il gold standard. Language-neutral, collaboratively-edited, usato da tutti i principali Knowledge Graph
• Wikipedia: se hai una pagina Wikipedia, linkala. È pesantemente ingerita nei training set LLM
• Registri governativi ufficiali: Companies House (UK), LEI (Legal Entity Identifier), Camera di Commercio (Italia), INPI (Francia), SEC EDGAR (USA)

Tier 2 — Alta autorità (Piattaforme verificate):

• LinkedIn (profilo aziendale o personale verificato)
• Google Business Profile (per LocalBusiness)
• Crunchbase (per aziende tech/startup)
• DUNS Number (Dun & Bradstreet)
• ISNI (International Standard Name Identifier, per autori)

Tier 3 — Media autorità (Social primari):

• Twitter/X (profilo ufficiale)
• Facebook (pagina aziendale)
• Instagram (profilo business)
• YouTube (canale ufficiale)
• GitHub (per sviluppatori/tech)

Tier 4 — Bassa autorità (Directories settoriali):

• Profili su directories di settore
• Pagine su siti di recensioni (TripAdvisor, Yelp)
• Profili su marketplace

Implementazione sameAs corretta

Per Organization:

"sameAs": [
  "https://www.wikidata.org/wiki/Q12345678",
  "https://it.wikipedia.org/wiki/Nome_Azienda",
  "https://www.linkedin.com/company/nome-azienda/",
  "https://twitter.com/nomeazienda",
  "https://www.facebook.com/nomeazienda",
  "https://www.instagram.com/nomeazienda/",
  "https://www.youtube.com/c/nomeazienda",
  "https://www.crunchbase.com/organization/nome-azienda"
]

Per Person:

"sameAs": [
  "https://www.wikidata.org/wiki/Q87654321",
  "https://en.wikipedia.org/wiki/Nome_Persona",
  "https://www.linkedin.com/in/nomepersona/",
  "https://twitter.com/nomepersona",
  "https://github.com/nomepersona",
  "https://orcid.org/0000-0000-0000-0000",
  "https://isni.org/isni/0000000000000000"
]

Per LocalBusiness:

"sameAs": [
  "https://www.google.com/maps/place/....",
  "https://www.facebook.com/nomeattivita",
  "https://www.instagram.com/nomeattivita/",
  "https://www.tripadvisor.it/...",
  "https://www.yelp.it/biz/..."
]

Errori comuni con sameAs

Consistenza cross-platform

Un aspetto spesso trascurato: le informazioni sui profili linkati via sameAs devono essere consistenti con quello che dichiari nel markup. Se il tuo markup dice “Gianni Puglisi Digital” ma il profilo LinkedIn dice “GP Consulting”, crei ambiguità invece di risolverla.

Checklist consistenza:

• Nome identico o riconoscibilmente equivalente su tutte le piattaforme
• Logo/immagine consistente
• Descrizione allineata
• Link reciproci dove possibile (il profilo LinkedIn linka al sito, il sito linka al profilo)

🤖 Schema e AI Search: Cosa Dicono le Evidenze Reali

Il rapporto tra Schema markup e AI Search è il tema più dibattuto e frainteso del momento. Vendor che promettono boost del 2.5x sulle citazioni AI. Studi che mostrano effetto nullo. Chi ha ragione? La risposta richiede di guardare alle tre vite separatamente.

Lo studio Ahrefs: metodologia corretta, layer sbagliato

L’11 maggio 2026, Ahrefs ha pubblicato uno studio causale su 1.885 pagine:

• Metodologia: aggiunta di markup JSON-LD, monitoraggio citazioni AI per 30 giorni
• Risultati: ChatGPT +2.2%, Google AI Mode +2.4% (indistinguibili da zero), AI Overviews -4.6%
• Conclusione apparente: Schema non influenza le citazioni AI

Perché lo studio è metodologicamente corretto ma testa il layer sbagliato:

Lo studio ha misurato Life 3 (runtime retrieval) su una finestra di 30 giorni. Ma:

• A Life 3, i blocchi JSON-LD vengono strippati o letti come testo plain
• L’esperimento searchVIU ha mostrato questo comportamento su tutti e 5 i sistemi principali
• Il test Williams-Cook ha confermato il meccanismo: tokenizzazione HTML include script blocks, ma non c’è parsing strutturale

Gli effetti di Schema operano principalmente a Life 1 (cicli di indicizzazione, settimane/mesi) e Life 2 (pretraining, anni). Non puoi misurare questi effetti in 30 giorni.

Cosa Google ha effettivamente confermato

A Search Central Live Toronto (aprile 2026), Ryan Levering ha esplicitamente confermato che il lavoro di dati strutturati a Life 1 alimenta AI Overviews e AI Mode. Ha elencato quattro ragioni:

1. Precisione: dati strutturati sono più precisi dell’estrazione LLM su contenuti complessi (prezzi, specifiche tecniche)
2. Informazioni non visibili: possono esprimere metadati non presenti nella prosa visibile
3. Efficienza computazionale: parsare struttura è più economico che inferire ripetutamente dalla prosa
4. Focus dell’attenzione: il markup giusto aiuta i sistemi a escludere contesto irrilevante

Questo è importante: Google ha confermato il meccanismo a Life 1. Il lavoro di entity disambiguation e Knowledge Graph contribution che Schema fa al momento dell’indicizzazione fluisce poi nei sistemi AI.

Cosa gli altri provider NON hanno confermato

Per OpenAI, Anthropic, Perplexity e Microsoft: non esiste conferma first-party verificata che i loro motori di retrieval runtime parsino JSON-LD nativamente.

L’evidenza empirica (searchVIU, Williams-Cook) indica che a Life 3 Schema viene:

• Strippato dalla pipeline di pulizia, oppure
• Letto come caratteri di testo raw, non come struttura interpretata

Questo non significa che Schema sia irrilevante per questi sistemi. Significa che l’influenza è indiretta, attraverso:

• Life 2: entity stores che popolano i training set
• Life 1 di altri sistemi (Google) i cui risultati vengono citati

Il concetto di “Ghost Citations”

Andrea Volpini ha introdotto il concetto di “ghost citations”: il fenomeno che emerge quando l’infrastruttura entità di Life 1 alimenta il retrieval attraverso forti connessioni entità, anche quando la storia di ranking tradizionale di un documento non lo prevederebbe.

In altre parole: se hai costruito una forte presenza entità nel Knowledge Graph attraverso anni di markup pulito e sameAs discipline, potresti essere citato da sistemi AI in contesti dove il tuo ranking organico tradizionale non ti porterebbe.

Il lavoro di Dan Petrovic sul query fan-out mostra che le sub-query interne usate dai sistemi AI per recuperare fonti candidate sono entity-and-attribute-driven. Più pulitamente una pagina candidata dichiara le sue claim entità e attributi a Life 1, più alta la probabilità che sopravviva ai filtri strutturali di fan-out nel set finale di citazioni.

La claim difendibile su Schema e AI

Le claim dei vendor “Schema aumenta le citazioni AI del X%” dovrebbero essere lette con forte scetticismo.

La claim difendibile è più ristretta e più forte:

1. I sistemi AI search sono entity-and-attribute-aware
2. Schema è il modo più economico e pulito per comunicare informazioni su entità e attributi
3. Costruire per i layer che compongono nel tempo (Life 1 e Life 2) è l’unica strategia sostenibile
4. Non aspettarti win overnight dal layer dove win overnight non sono possibili (Life 3)

🔍 Validazione e Debug: Verificare il Tuo Markup

Prima di pubblicare markup Schema, devi validarlo. Ecco gli strumenti e i processi per assicurarti che il tuo markup sia corretto, completo e funzionante.

Strumenti di validazione

1. Google Rich Results Test

URL: search.google.com/test/rich-results

• Testa l’eligibilità per rich results specifici
• Mostra errori e warning
• Anteprima dei rich results potenziali
• Supporta URL live o code snippet

2. Schema.org Validator

URL: validator.schema.org

• Validazione generica Schema.org
• Più permissivo del Rich Results Test
• Utile per markup che non target rich results specifici

3. Google Search Console – Enhancements

• Report su tutti i tipi di rich results rilevati
• Errori a livello di sito
• Trend nel tempo
• Esempi di pagine con problemi

4. Structured Data Testing Tool (deprecato ma utile)

• Ancora accessibile, mostra parsing raw del markup
• Utile per debug tecnico approfondito

Processo di validazione raccomandato

Step 1: Validazione sintattica

Prima di tutto, verifica che il JSON sia sintatticamente corretto:

• Usa un JSON validator (jsonlint.com o editor con highlighting)
• Controlla parentesi, virgole, quote
• Verifica encoding caratteri speciali

Step 2: Validazione Schema.org

Usa validator.schema.org per verificare:

• Tipi riconosciuti
• Proprietà valide per ogni tipo
• Valori nel formato corretto

Step 3: Test Rich Results

Se stai targetizzando rich results specifici:

• Usa Google Rich Results Test
• Verifica che tutte le proprietà richieste siano presenti
• Risolvi errori (bloccanti) prima dei warning

Step 4: Verifica rendering JavaScript

Se il markup è iniettato via JavaScript:

• Testa con “Fetch as Google” in Search Console
• Verifica che il markup sia presente dopo il render
• Considera server-side rendering per markup critico

Errori comuni da debuggare

Errore: “Missing field ‘name'”

Soluzione: name è richiesto per quasi tutti i tipi. Verifica che sia presente e non vuoto.

Errore: “Invalid URL format”

Soluzione: URL devono essere completi (https://…), non relativi. Verifica encoding di caratteri speciali.

Errore: “Value not in required set”

Soluzione: alcune proprietà accettano solo valori specifici (es: availability deve essere un URL Schema.org come “https://schema.org/InStock”).

Warning: “Missing recommended field”

Soluzione: non bloccante ma riduce qualità. Aggiungi le proprietà raccomandate per il tipo.

Errore: “Duplicate @id”

Soluzione: ogni @id deve essere unico nel documento. Usa fragment identifiers diversi (#organization, #person, #article).

📈 Casi Studio: Schema Markup in Azione

Vediamo tre esempi reali di implementazione Schema markup, con i risultati ottenuti e le lezioni apprese.

Caso Studio #1: E-commerce Nicchia – Da Invisibile a Knowledge Panel

Caso Studio #2: Studio Professionale – Entity Disambiguation in Mercato Affollato

Caso Studio #3: Blog Tecnico – Author Authority Building

🛠️ Trucchi Pratici: Schema Markup Operativo

Dopo la teoria e i casi studio, ecco sei trucchi pratici che puoi applicare immediatamente per migliorare la tua implementazione Schema.

Trucco #1: Il Grafo Annidato con @id Persistenti

Problema: Blocchi JSON-LD isolati sulla stessa pagina raccontano storie separate e frammentate.

Soluzione: Usa @id per creare riferimenti cross-block. Un grafo annidato con @id persistenti racconta una storia unificata.

// Definisci Organization una volta
{
  "@type": "Organization",
  "@id": "https://tuosito.it/#org",
  "name": "..."
}

// Referenziala ovunque serva
{
  "@type": "Article",
  "publisher": { "@id": "https://tuosito.it/#org" },
  "author": { "@id": "https://tuosito.it/#person-mario" }
}

Perché funziona: I Knowledge Graph seguono i riferimenti @id per costruire grafi di relazioni. Entità isolate non si collegano.

Pro Tip: Gli @id devono essere URI stabili che non cambiano mai. Usa fragment identifiers (#org, #person-name) che sopravvivono a ristrutturazioni URL.

Trucco #2: knowsAbout per Topical Authority

Problema: Il markup Person/Organization non comunica aree di competenza.

Soluzione: Usa knowsAbout con una lista dettagliata di topic, idealmente linkati a Wikidata.

"knowsAbout": [
  {
    "@type": "Thing",
    "name": "Search Engine Optimization",
    "sameAs": "https://www.wikidata.org/wiki/Q180711"
  },
  {
    "@type": "Thing",
    "name": "Schema.org",
    "sameAs": "https://www.wikidata.org/wiki/Q3475322"
  },
  "WordPress",
  "Technical SEO",
  "E-commerce SEO"
]

Perché funziona: knowsAbout alimenta i sistemi di topical relevance. Linkare a Wikidata Q-id rende la competenza machine-verifiable.

Trucco #3: about e mentions per Topologia Semantica

Problema: I tuoi articoli hanno markup Article base ma non comunicano la struttura semantica del contenuto.

Soluzione: Aggiungi about (entità principale) e mentions (entità citate) con sameAs verso identificatori stabili.

{
  "@type": "Article",
  "headline": "Guida allo Schema Markup",
  "about": [
    {
      "@type": "Thing",
      "name": "Schema.org",
      "sameAs": "https://www.wikidata.org/wiki/Q3475322"
    }
  ],
  "mentions": [
    {
      "@type": "Person",
      "name": "Dan Brickley",
      "sameAs": "https://www.wikidata.org/wiki/Q5214801"
    },
    {
      "@type": "Organization",
      "name": "Google",
      "sameAs": "https://www.wikidata.org/wiki/Q95"
    }
  ]
}

Perché funziona: Dichiari esplicitamente la topologia semantica. I Knowledge Graph possono agire su queste dichiarazioni per collegare il tuo contenuto alle entità rilevanti.

Trucco #4: BreadcrumbList per Struttura Sito

Problema: Google non capisce la gerarchia del tuo sito.

Soluzione: Implementa BreadcrumbList su ogni pagina interna.

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://tuosito.it/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://tuosito.it/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema Markup Guida",
      "item": "https://tuosito.it/blog/schema-markup-guida/"
    }
  ]
}

Perché funziona: BreadcrumbList è uno dei rich results più stabili e produce sitelinks strutturati. Inoltre comunica la tassonomia del sito ai sistemi di comprensione.

Trucco #5: WebSite con SearchAction per Sitelinks Search Box

Problema: Non hai il search box nei sitelinks per query branded.

Soluzione: Implementa WebSite con potentialAction SearchAction sulla homepage.

{
  "@type": "WebSite",
  "@id": "https://tuosito.it/#website",
  "url": "https://tuosito.it",
  "name": "Nome Sito",
  "publisher": { "@id": "https://tuosito.it/#org" },
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://tuosito.it/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

Perché funziona: Se eligibile, produce il search box direttamente nei sitelinks. È un segnale di autorità brand e migliora UX per query branded.

Trucco #6: Speakable per Voice Search e AI Reading

Problema: Vuoi che specifiche sezioni del contenuto siano candidate per lettura vocale o estrazione AI.

Soluzione: Usa speakable per indicare sezioni ottimizzate per text-to-speech.

{
  "@type": "Article",
  "headline": "...",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-summary", ".key-takeaways"]
  }
}

Perché funziona: Anche se speakable non ha rich result diffuso, è un segnale ai sistemi AI/voice di quali porzioni del contenuto sono più adatte per estrazione e lettura. È un investimento nel futuro dell’interazione vocale.

🔥 BONUS: 10 Metodi Avanzati per Schema Markup Enterprise

Questi sono i metodi che uso per implementazioni Schema avanzate su siti enterprise e progetti complessi. Richiedono competenze tecniche più profonde, ma possono fare la differenza tra markup “che valida” e markup che effettivamente costruisce infrastruttura entità duratura.

🔧 Metodo #1: Il Context Graph Unificato

Quando usarlo: Siti multi-pagina dove le stesse entità appaiono su più pagine e vuoi un grafo coerente.

La tecnica:

1. Definisci un “grafo base” con tutte le entità core (Organization, Person principali) su una pagina centrale (es: /about/)
2. Su ogni altra pagina, referenzia queste entità via @id invece di ri-dichiararle
3. Mantieni un documento di riferimento con tutti gli @id e le loro definizioni canoniche
4. Usa @graph array per dichiarare multiple entità connesse in un singolo blocco

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tuosito.it/#org",
      "name": "Nome Azienda",
      ...
    },
    {
      "@type": "Person",
      "@id": "https://tuosito.it/#person-ceo",
      "name": "Mario Rossi",
      "worksFor": { "@id": "https://tuosito.it/#org" }
    },
    {
      "@type": "WebSite",
      "@id": "https://tuosito.it/#website",
      "publisher": { "@id": "https://tuosito.it/#org" }
    }
  ]
}

Perché funziona: I Knowledge Graph costruiscono grafi di relazioni. Un grafo unificato con @id consistenti permette ai sistemi di vedere le connessioni tra entità attraverso tutto il sito, non frammenti isolati.

🔧 Metodo #2: Il Wikidata Bootstrapping

Quando usarlo: Vuoi massimizzare entity disambiguation ma non hai ancora presenza Wikidata.

La tecnica:

1. Crea una voce Wikidata per la tua organizzazione o persona chiave
2. Popola con informazioni verificabili: nome ufficiale, data fondazione, sede, sito ufficiale, identificatori (P.IVA, LEI, etc.)
3. Aggiungi claims per relazioni (founder, parent organization, etc.)
4. Linka la voce Wikidata nel tuo sameAs
5. Mantieni la voce aggiornata quando cambiano informazioni

Requisiti Wikidata per notabilità:

• Fonti secondarie indipendenti che documentano l’esistenza dell’entità
• Informazioni verificabili (non auto-dichiarate)
• Rispetto delle policy Wikidata sulla notabilità

Perché funziona: Un Q-identifier Wikidata è il gold standard per entity disambiguation. È language-neutral, collaboratively-verified, e usato come reference da tutti i principali Knowledge Graph incluso quello di Google.

🔧 Metodo #3: Il Credential e Certification Markup

Quando usarlo: Professionisti con certificazioni, titoli, iscrizioni ad albi che vogliono comunicare autorità verificabile.

La tecnica:

{
  "@type": "Person",
  "name": "Dr. Mario Rossi",
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "degree",
      "name": "Laurea in Ingegneria Informatica",
      "recognizedBy": {
        "@type": "EducationalOrganization",
        "name": "Politecnico di Milano",
        "sameAs": "https://www.wikidata.org/wiki/Q850829"
      }
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "Google Cloud Professional Architect",
      "recognizedBy": {
        "@type": "Organization",
        "name": "Google",
        "sameAs": "https://www.wikidata.org/wiki/Q95"
      },
      "validFor": "P2Y",
      "dateCreated": "2024-06"
    }
  ],
  "hasOccupation": {
    "@type": "Occupation",
    "name": "SEO Consultant",
    "occupationalCategory": "15-1252.00"
  }
}

Perché funziona: hasCredential comunica autorità verificabile in termini machine-readable. È particolarmente importante per settori YMYL (Your Money Your Life) dove l’autorità dell’autore è un fattore critico.

🔧 Metodo #4: Il Multi-Language Entity Linking

Quando usarlo: Siti multilingua dove le stesse entità esistono in versioni localizzate.

La tecnica:

1. Usa lo stesso @id per la stessa entità su tutte le versioni linguistiche
2. sameAs verso Wikidata Q-id (language-neutral per definizione)
3. Dichiara inLanguage per contenuti localizzati
4. Usa translationOfWork/workTranslation per contenuti tradotti

// Pagina italiana
{
  "@type": "Organization",
  "@id": "https://tuosito.it/#org",
  "name": "Nome Azienda S.r.l.",
  "sameAs": ["https://www.wikidata.org/wiki/Q12345"]
}

// Pagina inglese
{
  "@type": "Organization",
  "@id": "https://tuosito.it/#org",  // STESSO @id
  "name": "Company Name Ltd",
  "sameAs": ["https://www.wikidata.org/wiki/Q12345"]  // STESSO Q-id
}

Perché funziona: Lo stesso @id e lo stesso Q-id Wikidata comunicano che è la stessa entità in lingue diverse. I Knowledge Graph unificano automaticamente.

🔧 Metodo #5: Il Product Variant Clustering

Quando usarlo: E-commerce con prodotti che hanno varianti (taglia, colore, configurazione).

La tecnica:

{
  "@type": "ProductGroup",
  "@id": "https://shop.it/prodotto-base/#product-group",
  "name": "T-Shirt Premium",
  "description": "T-shirt in cotone organico",
  "brand": { "@id": "https://shop.it/#brand" },
  "variesBy": ["https://schema.org/size", "https://schema.org/color"],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "T-Shirt Premium - Bianca M",
      "size": "M",
      "color": "Bianco",
      "sku": "TSH-WHT-M",
      "offers": { "@type": "Offer", "price": "29.90", ... }
    },
    {
      "@type": "Product",
      "name": "T-Shirt Premium - Bianca L",
      "size": "L",
      "color": "Bianco",
      "sku": "TSH-WHT-L",
      "offers": { "@type": "Offer", "price": "29.90", ... }
    }
  ]
}

Perché funziona: ProductGroup comunica la relazione tra varianti, evitando che Google tratti ogni variante come prodotto completamente separato. Migliora aggregazione recensioni e presentazione in SERP.

🔧 Metodo #6: Il Service Area Specification

Quando usarlo: Business con area di servizio definita (idraulici, elettricisti, consulenti che servono zone specifiche).

La tecnica:

{
  "@type": "LocalBusiness",
  "name": "Idraulico Express Milano",
  "areaServed": [
    {
      "@type": "City",
      "name": "Milano",
      "sameAs": "https://www.wikidata.org/wiki/Q490"
    },
    {
      "@type": "AdministrativeArea",
      "name": "Provincia di Milano",
      "sameAs": "https://www.wikidata.org/wiki/Q16163"
    }
  ],
  "serviceArea": {
    "@type": "GeoCircle",
    "geoMidpoint": {
      "@type": "GeoCoordinates",
      "latitude": 45.4642,
      "longitude": 9.1900
    },
    "geoRadius": "30000"
  }
}

Perché funziona: areaServed e serviceArea comunicano esattamente dove operi. Particolarmente importante per query “near me” e per evitare di apparire per zone non servite.

🔧 Metodo #7: L’Event Series e Recurring Events

Quando usarlo: Eventi ricorrenti (webinar settimanali, corsi periodici, eventi seriali).

La tecnica:

{
  "@type": "EventSeries",
  "@id": "https://tuosito.it/webinar-seo/#event-series",
  "name": "Webinar SEO Mensile",
  "description": "Serie di webinar mensili su SEO e digital marketing",
  "organizer": { "@id": "https://tuosito.it/#org" },
  "subEvent": [
    {
      "@type": "Event",
      "name": "Webinar SEO - Giugno 2026",
      "startDate": "2026-06-15T18:00:00+02:00",
      "endDate": "2026-06-15T19:30:00+02:00",
      "eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
      "eventStatus": "https://schema.org/EventScheduled",
      "location": {
        "@type": "VirtualLocation",
        "url": "https://tuosito.it/webinar-giugno/"
      },
      "superEvent": { "@id": "https://tuosito.it/webinar-seo/#event-series" }
    }
  ]
}

Perché funziona: EventSeries raggruppa eventi correlati, comunicando che sono parte di una serie. superEvent/subEvent creano la gerarchia navigabile.

🔧 Metodo #8: Il Citation e Reference Markup

Quando usarlo: Contenuti accademici, tecnici o giornalistici che citano fonti.

La tecnica:

{
  "@type": "Article",
  "headline": "Guida allo Schema Markup",
  "citation": [
    {
      "@type": "ScholarlyArticle",
      "name": "Schema.org: Evolution of Structured Data on the Web",
      "author": [
        { "@type": "Person", "name": "R.V. Guha" },
        { "@type": "Person", "name": "Dan Brickley" }
      ],
      "datePublished": "2016",
      "publisher": { "@type": "Organization", "name": "ACM" },
      "url": "https://dl.acm.org/doi/pdf/10.1145/2844544"
    },
    {
      "@type": "WebPage",
      "name": "Google Structured Data Documentation",
      "url": "https://developers.google.com/search/docs/appearance/structured-data",
      "publisher": {
        "@type": "Organization",
        "name": "Google",
        "sameAs": "https://www.wikidata.org/wiki/Q95"
      }
    }
  ]
}

Perché funziona: citation dichiara esplicitamente le fonti, segnalando rigore e verificabilità. È un segnale E-E-A-T machine-readable.

🔧 Metodo #9: Il Review e Claim Markup per Fact-Checking

Quando usarlo: Siti che fanno fact-checking o review di claim.

La tecnica:

{
  "@type": "ClaimReview",
  "url": "https://tuosito.it/fact-check/claim-xyz/",
  "claimReviewed": "La Terra è piatta",
  "itemReviewed": {
    "@type": "Claim",
    "author": {
      "@type": "Person",
      "name": "Fonte della claim"
    },
    "datePublished": "2026-01-15"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 1,
    "bestRating": 5,
    "worstRating": 1,
    "alternateName": "Falso"
  },
  "author": { "@id": "https://tuosito.it/#org" }
}

Perché funziona: ClaimReview è usato da Google per il rich result fact-check. È uno dei pochi rich results con impatto diretto sulla lotta alla disinformazione.

🔧 Metodo #10: Il Dynamic Schema Generation

Quando usarlo: Siti con migliaia di pagine dove il markup manuale è impossibile.

La tecnica:

1. Crea template Schema per ogni tipo di pagina (prodotto, articolo, categoria, autore)
2. Mappa i campi del CMS/database alle proprietà Schema
3. Genera JSON-LD server-side al momento del render
4. Implementa validazione automatica pre-pubblicazione
5. Monitora errori via Search Console API

Esempio architettura (pseudocodice):

function generateProductSchema($product) {
  return [
    "@context" => "https://schema.org",
    "@type" => "Product",
    "@id" => $product->url . "#product",
    "name" => $product->title,
    "description" => $product->description,
    "image" => $product->images,
    "sku" => $product->sku,
    "brand" => ["@id" => SITE_ORG_ID],
    "offers" => [
      "@type" => "Offer",
      "price" => $product->price,
      "priceCurrency" => "EUR",
      "availability" => $product->inStock 
        ? "https://schema.org/InStock" 
        : "https://schema.org/OutOfStock"
    ],
    "aggregateRating" => $product->hasReviews ? [
      "@type" => "AggregateRating",
      "ratingValue" => $product->avgRating,
      "reviewCount" => $product->reviewCount
    ] : null
  ];
}

Perché funziona: La generazione dinamica scala a qualsiasi numero di pagine mantenendo consistenza. L’@id fisso per Organization (SITE_ORG_ID) crea il grafo unificato automaticamente.

⚠️ Errori Comuni che Compromettono il Markup

In anni di audit Schema, ho identificato pattern di errori ricorrenti. Evitarli ti mette avanti rispetto alla maggioranza delle implementazioni.

🚀 Conclusione: Registrazione, Non Pubblicità

Il modello mentale più pulito per capire cosa Schema sta facendo è l’analogia che Gianluca Fiorelli ha presentato: pensalo come registrazione aziendale, non come pubblicità.

Non registri la tua azienda alla Camera di Commercio perché ti aspetti un boost immediato sulle vendite. Registri perché essere un’entità legale formalmente riconoscibile è la fondazione su cui altre cose si appoggiano: firmare contratti, aprire conti bancari, essere referenziato in documenti legali, partecipare a gare d’appalto.

Schema funziona allo stesso modo. Essere un’entità strutturata formalmente riconoscibile è la fondazione contro cui il Knowledge Graph di Google indicizza, i sistemi di retrieval usano per disambiguare quando la prosa è ambigua, e le superfici consumer-facing attingono quando arriva il momento di presentarti.

Aggiungere Schema non causa direttamente citazioni o ranking. Ti rende leggibile ai sistemi che decidono se presentarti. Queste sono cose molto diverse.

La formulazione di Andrea Volpini — “la struttura è il fossato” — è il punto finale contemporaneo del “from strings to things” di Aaron Bradley. La disciplina è costruzione paziente:

• Un Entity Home stabile
• URI @id persistenti che non cambiano
• sameAs discipline verso registri autorevoli
• Grafi annidati che esprimono relazioni reali
• Una valutazione onesta che nessuna singola eligibilità rich result è permanente

Guardando al 2027 e oltre, possiamo aspettarci:

• AI Search sempre più entity-aware: i sistemi diventeranno migliori nel ragionare su entità, non solo su keyword
• Knowledge Graph più selettivi: dopo il Great Clarity Cleanup, aspettati standard più alti per l’inclusione
• Rich results più volatili: Google continuerà a sperimentare, lanciare e ritirare feature di display
• sameAs verso registri ufficiali sempre più importante: la verifica di identità diventerà più rigorosa
• Author authority amplificata: per contenuti YMYL, l’identità verificabile dell’autore conterà sempre di più

Una pagina è una narrativa; una narrativa ha personaggi, ambientazioni e relazioni. Il markup Schema è la pagina che dichiara il proprio dramatis personae direttamente — questo è il protagonista, questa è l’ambientazione, questa è la relazione con quell’altra entità. Quando il markup è onesto e allineato con la prosa, sia i lettori umani che quelli macchina se ne vanno con la stessa ricostruzione.

Schema non è morto. Non è nemmeno una leva magica per citazioni AI. È l’infrastruttura entità che ti rende formalmente riconoscibile a qualsiasi sistema ti stia leggendo, su qualsiasi scala temporale.

Aggiungi Schema in modo pulito. Mantienilo consistente. Non aspettarti win overnight dal layer dove win overnight non sono possibili. E lascia che tutte e tre le vite lavorino insieme.

Se vuoi implementare Schema markup in modo strategico per il tuo sito — costruendo infrastruttura entità duratura invece di inseguire rich results volatili — su giannipuglisi.it offro consulenza specializzata. Audit della tua implementazione attuale, strategia per entity presence nel Knowledge Graph, e implementazione tecnica che dura nel tempo.