Schema.org per AI search e GEO

Un modello linguistico non guarda la tua pagina: la legge, la spezza in frammenti e prova a capire di chi sta parlando. I dati strutturati servono a togliergli il dubbio. Sono l’unico punto del sito in cui puoi dichiarare, senza margini di interpretazione, che quel nome è un’azienda, che quell’indirizzo è la sua sede, che quella persona ha firmato quell’articolo. Per questo schema.org è diventato il pezzo più tecnico e meno negoziabile della GEO.

Per i motori di ricerca generativi conta l’entità, non la parola chiave

La SEO classica ha lavorato per vent’anni sulle stringhe: la query conteneva certe parole chiave, la pagina le conteneva a sua volta, il motore di ricerca faceva incontrare le due cose. I motori di ricerca generativi ragionano in un altro modo. ChatGPT, Gemini, Perplexity e Google AI Mode non restituiscono dieci link: costruiscono una risposta, e per costruirla devono prima decidere di chi e di cosa stanno parlando. Devono risolvere un’entità.

Qui casca quasi tutto. «Villella Solutions» è un’azienda, un cognome, un marchio o un refuso? Un LLM prova a dedurlo dal contesto, e quando il contesto è povero sbaglia oppure, peggio, non cita nessuno. Ecco perché i contenuti strutturati pesano più oggi di quanto pesassero cinque anni fa: non servono a scalare la SERP, servono a esistere come soggetto riconoscibile dentro un grafo di conoscenza. Chi lavora sulla generative engine optimization parte da lì, non dal numero di ripetizioni della keyword.

Un dettaglio che sfugge: i dati strutturati non sono un fattore di ranking magico e non lo sono mai stati. Sono una dichiarazione di identità leggibile da una macchina, e il loro effetto sul posizionamento è indiretto. La differenza rispetto alla SEO tradizionale sta tutta in questo cambio di scopo, ed è la stessa che separa la SEO dalla GEO.

I tipi schema.org che contano per la GEO di un’attività reale

Schema.org conta oltre ottocento tipi. Per un’impresa che vende qualcosa ne servono sette o otto, non ottocento. Il resto è rumore: allunga il file, complica la manutenzione e non aggiunge un solo segnale utile né alla SEO né alla GEO.

Organization — chi sei come soggetto. Nome esatto, logo, sito, canali di contatto. È il nodo radice del brand: quasi tutto il resto punta qui.

LocalBusiness — serve quando esiste un luogo fisico in cui qualcuno può presentarsi. Vuole indirizzo completo, orari, area servita. Senza una sede visitabile non forzarlo: usa Organization.

Person — l’autore, il titolare, il consulente. È il tipo più trascurato e uno dei più utili: senza una Person coerente il segnale di competenza resta appeso al nulla e nessun motore ti considera autorevole.

Article — il singolo contenuto editoriale: titolo, autore, editore, data di pubblicazione e di ultima modifica.

Product e Service — cosa vendi. Product per un oggetto con codice e disponibilità, Service per una prestazione. Confonderli è l’errore più frequente nelle schede B2B.

FAQPage — domande e risposte che stanno davvero nella pagina, visibili a chi scorre.

BreadcrumbList — dove si trova quella pagina dentro l’architettura del sito. Costa cinque righe e chiarisce la gerarchia meglio di un menu.

Nella mia esperienza il salto di qualità non arriva quando aggiungi il nono tipo. Arriva quando i sette che hai già smettono di contraddirsi.

Il @graph e gli @id: come strutturare le entità per i motori generativi

Il markup sparso è il problema più comune sui siti aziendali: una Organization nel footer, un Article nella pagina, una Person nel box autore. Tre isole che non si parlano. Il @graph risolve esattamente questo: mette i nodi in un unico blocco e li collega con identificatori stabili.

L’idea è semplice. Ogni entità riceve un @id, cioè una URI unica e permanente. Le altre entità, invece di ripetere i dati, puntano a quella URI. Un solo posto da aggiornare, zero versioni divergenti dello stesso soggetto. Strutturare così il markup costa mezz’ora una volta sola.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://esempio.it/#organizzazione",
      "name": "Nome Esatto Srl",
      "url": "https://esempio.it/",
      "logo": "https://esempio.it/logo.png",
      "sameAs": ["https://www.linkedin.com/company/nome-esatto"]
    },
    {
      "@type": "Person",
      "@id": "https://esempio.it/#autore-mario",
      "name": "Mario Rossi",
      "worksFor": { "@id": "https://esempio.it/#organizzazione" }
    },
    {
      "@type": "Article",
      "@id": "https://esempio.it/guida/#articolo",
      "headline": "Titolo identico all'H1 della pagina",
      "author": { "@id": "https://esempio.it/#autore-mario" },
      "publisher": { "@id": "https://esempio.it/#organizzazione" },
      "datePublished": "2026-08-22",
      "dateModified": "2026-08-22",
      "mainEntityOfPage": "https://esempio.it/guida/"
    }
  ]
}

Tre nodi, due riferimenti incrociati, nessun dato duplicato. Conta la forma, non la lunghezza. Nota il carattere # dentro gli @id: produce identificatori distinti anche quando più entità vivono sulla stessa URL.

Che cosa guarda un motore di ricerca generativo nel tuo markup

Un modello linguistico che assembla una risposta deve scegliere chi citare. Non sceglie il documento più lungo: sceglie quello che gli permette di dire una frase verificabile senza rischiare. Un blocco di dati strutturati ben fatto gli offre esattamente questo: nome del soggetto, ruolo, competenza dichiarata, luogo, data. Informazioni che un LLM riusa senza inventare.

Il legame con l’autorevolezza è diretto. Un brand che dichiara sempre gli stessi dati, sulle stesse entità, con gli stessi identificatori, costruisce un profilo stabile che i motori di risposta ritrovano ovunque. Un brand che cambia forma a ogni pagina resta un insieme di frammenti. Nell’ottimizzazione per l’intelligenza artificiale generativa è questa coerenza a fare la differenza, molto più della densità delle parole chiave.

Una precisazione, perché il tema si presta a promesse gonfiate: nessun markup ti fa citare da ChatGPT. Il markup toglie gli ostacoli. Se il contenuto non ha niente da dire, un JSON-LD perfetto non lo salva.

Dati strutturati, SEO e generative engine optimization: due lavori sullo stesso file

Nella SEO tradizionale i dati strutturati servivano quasi solo alle rich card: stelline, ricette, eventi. L’obiettivo era il click, e il traffico organico diceva se aveva funzionato. Nella GEO lo stesso file fa un altro lavoro: alimenta la comprensione dell’entità, e il risultato non è un click ma una menzione dentro una risposta generata.

Le due cose convivono nello stesso blocco JSON-LD, e per questo non ha senso separare strategia SEO e strategia GEO a livello di markup. Cambia la priorità, non il codice. Ottimizzare i contenuti per i motori generativi vuol dire curare gli stessi campi con un’attenzione diversa: meno ossessione per la rich card, più cura per l’identità del soggetto.

C’è una conseguenza pratica su cui insisto in ogni audit GEO. I motori di ricerca tradizionali premiano la pagina; i modelli di intelligenza artificiale premiano il soggetto. Le menzioni del brand dentro le risposte di un LLM nascono da entità coerenti, non da una keyword ripetuta negli H2. È il motivo per cui una strategia GEO parte dal markup e dalla creazione di contenuti firmati, non dalla lista delle parole chiave.

Detto in modo netto: la GEO non sostituisce la SEO. Le tecniche SEO che già conosci — SEO tecnica, architettura del sito, link interni — restano il pavimento su cui poggia tutto il resto. Cambia il piano di sopra. I nuovi motori basati su intelligenza artificiale leggono le domande degli utenti e cercano un soggetto di cui fidarsi prima di scrivere una risposta generata dall’intelligenza artificiale. Il futuro della SEO passa da qui, e una strategia SEO che ignora il markup si ferma a metà.

sameAs, brand e autorevolezza: le prove che non scrivi tu

Vedo sameAs trattato come una barra di icone. Non è quello. È la dichiarazione: questo soggetto e quel profilo là fuori sono la stessa cosa. Serve a un motore per confermare un’identità incrociando fonti che non controlli tu.

Due regole pratiche. La prima: metti solo profili che esistono, attivi, che appartengono davvero al soggetto. Un URL a un account abbandonato nel 2019 lavora contro di te. La seconda: nome, indirizzo e telefono identici ovunque, carattere per carattere. Se sul sito scrivi «Via Tevere 10» e sulla scheda locale «V. Tevere, 10», stai chiedendo a un algoritmo di indovinare. Indovinerà male.

Pesano di più le fonti che un terzo può verificare: registri pubblici, profili professionali, schede di piattaforme note. Un link al proprio blog dentro sameAs non aggiunge niente. È il sito che parla di sé.

Gli errori di markup che vedo più spesso nei progetti GEO

Markup senza testo a video. Il caso più grave e il più facile da evitare. Una FAQPage con sei domande che nella pagina non compaiono viola le linee guida di Google sui dati strutturati e può costare un’azione manuale. Se non lo legge un essere umano scorrendo la pagina, non lo dichiari.

FAQ finte. Variante educata del punto precedente. Domande scritte per riempire il markup, risposte di due righe che non rispondono. Un revisore le riconosce subito. Un motore generativo le ignora.

Identificatori duplicati o assenti. Due nodi con lo stesso @id su pagine diverse, oppure lo stesso identificatore riassegnato a un’entità di tipo diverso. Il grafo diventa incoerente: al motore di ricerca arriva un soggetto che dichiara di essere due cose insieme. Ho testato la stessa correzione su siti in cui il tema generava un identificatore nuovo a ogni post: raggruppare i nodi in un unico @graph con URI stabili ha reso il markup parsabile in un colpo solo.

Address incompleti. Un PostalAddress con la sola città non serve a niente. Servono streetAddress, postalCode, addressLocality e addressCountry. Se ne manca uno il nodo resta valido e inutilizzabile per il posizionamento locale.

Campi placeholder pubblicati. «Your Company Name», «example.com», date al 1° gennaio 1970. Capita quando si copia un template trovato online. Nessuno se ne accorge a video, perché il markup è invisibile: restano lì per mesi.

Tipi troppo generici o troppo ambiziosi. Dichiarare Product per una consulenza, oppure LocalBusiness per un’attività che opera solo da remoto. Il tipo si sceglie per quello che sei, non per la rich card che vorresti ottenere.

Un esempio dichiaratamente ipotetico. Uno studio tecnico con due sedi pubblica su ogni pagina lo stesso blocco LocalBusiness, stesso @id, indirizzo della sede principale. Le due sedi diventano un’unica entità sdoppiata. La correzione non è aggiungere markup: è dare a ciascuna sede il proprio @id e collegarle alla stessa Organization con parentOrganization.

Due controlli SEO e GEO che costano cinque minuti

Il primo apre ogni audit GEO che facciamo, e viene saltato quasi sempre: rileggere il JSON-LD servito dalla pagina live, non quello che credi di avere spedito. Plugin e cache riscrivono i contenuti più spesso di quanto si immagini, e una sola entità HTML grezza dentro una description basta a rompere il parsing. Un blocco non parsabile equivale a un blocco assente.

Il secondo è un confronto fra markup e pagina: ogni campo dichiarato deve avere un corrispettivo visibile. Autore dichiarato, autore scritto in pagina. Data dichiarata, data mostrata. Domande dichiarate, domande leggibili. Noi facciamo passare ogni contenuto da questa verifica prima della messa online, e le sorprese arrivano dai campi automatici del tema.

Fuori da qui restano due pezzi con spazio proprio: il file llms.txt, che indica a un crawler generativo cosa leggere, e l’impianto di ottimizzazione per i motori di risposta, la vecchia answer engine optimization.

Da dove parte un intervento GEO sui dati strutturati

Quando apriamo un progetto l’ordine è sempre lo stesso, e non parte dal codice. Prima l’inventario delle entità reali: chi è l’azienda, chi firma i contenuti, quali servizi esistono davvero, dove si opera. Poi la scelta del tipo schema.org per ciascuna, uno solo per soggetto. Poi il @graph, scritto una volta in un template condiviso da tutto il sito. Alla fine il controllo di quello che i motori di ricerca ricevono davvero.

L’errore che vedo più spesso è invertire l’ordine: si parte dal plugin, si attivano venti tipi e si spera. Esce un file lungo che descrive un soggetto che nessuno ha mai definito. Ottimizzare i contenuti per i motori di risposta comincia dall’identità, non dal generatore automatico.

Domande frequenti su schema.org, SEO e GEO

Tre cose da portarsi via prima di toccare il markup

Primo: i tipi utili sono pochi, e si scelgono per quello che l’attività è davvero. Secondo: le entità vanno collegate, perché un grafo di nodi isolati non dice niente ai modelli di intelligenza artificiale. Terzo: qualunque cosa dichiari nel markup deve esistere anche a video. Su queste tre cose si regge tutto il resto di una strategia GEO, e nessuna richiede un budget: richiedono ordine.

La domanda con cui vale la pena chiudere è scomoda. Se un modello dovesse descrivere la tua azienda usando soltanto i dati strutturati che il tuo sito espone oggi, cosa risponderebbe? E quanto di quella risposta ti somiglia?