La settimana scorsa un cliente mi ha chiesto: «Abbiamo un file schemas.ts nel nostro codebase, ma nessuno ricorda più perché c'è né cosa faccia ogni blocco». Non è un caso isolato. In almeno metà dei progetti che mi passano sotto mano c'è un file JSON-LD sperduto, piazzato lì a suo tempo da uno sviluppatore — senza documentazione, senza uno scopo chiaro e spesso senza che nessuno sappia più se è corretto.
È un peccato, perché i dati strutturati sono esattamente il tipo di informazione che i sistemi AI come ChatGPT, Perplexity e le AI Overviews di Google cercano con voracità. Sono contesto leggibile dalle macchine che dice: «questo è chi siamo, questo è dove siamo, queste sono le risposte alle domande frequenti». Senza quel contesto un modello linguistico deve tirare a indovinare basandosi su testo non strutturato. Con quel contesto ottiene una fonte diretta e affidabile.
In questo articolo ti spiego i tre tipi di schema più usati — Organization, LocalBusiness e FAQPage — con esempi concreti che puoi implementare già oggi.
Perché i dati strutturati contano ancora nell'era dell'AI
I dati strutturati (quasi sempre in JSON-LD) esistono dal 2011 grazie a schema.org, nato dalla collaborazione tra Google, Bing, Yahoo e Yandex. L'obiettivo all'epoca era semplice: aiutare i motori di ricerca a capire i contenuti, così da poter mostrare risultati arricchiti — recensioni con le stelline, orari di apertura, FAQ espandibili direttamente in SERP.
Cosa è cambiato: il «lettore» dei tuoi dati strutturati non è più solo un crawler che indicizza per una lista di risultati. Oggi è anche un modello linguistico che analizza i tuoi contenuti per formulare una risposta a un utente che magari non arriverà mai sul tuo sito. Se qualcuno chiede a ChatGPT «quali agenzie a Milano fanno consulenza AI», la probabilità che il tuo JSON-LD venga ripreso nella risposta è molto più alta della probabilità che venga interpretato un pezzo di testo di marketing.
Il motivo è che i dati strutturati non sono ambigui. Una frase come «siamo nel cuore di Milano» richiede che il modello la interpreti e faccia supposizioni. Un oggetto PostalAddress con addressLocality: "Milano" non ha bisogno di interpretazioni: è un fatto che si può estrarre direttamente.
Per la strategia più ampia dietro questo tipo di ottimizzazione ti consiglio di leggere anche che cos'è la GEO — i dati strutturati sono solo un pezzo di un mosaico più grande.
I tre tipi di schema che ti servono quasi sempre
Organization: chi sei, davvero?
Lo schema Organization è la base. Risponde alla domanda a cui i sistemi AI spesso non sanno rispondere: cos'è questa azienda e perché dovrei fidarmi? Questo schema va sulla homepage e, idealmente, va ripetuto (o referenziato) su ogni pagina tramite il layout.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "Sviluppo web AI-native e ottimizzazione GEO/AEO per aziende che vogliono farsi trovare da ChatGPT, Perplexity e Google AI Overviews.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Quello che conta qui: sameAs non è decorativo. Questo campo collega la tua azienda a fonti esterne verificabili — il tuo LinkedIn, la tua pagina Wikipedia (se esiste), il tuo profilo Crunchbase. I modelli AI usano questi rimandi incrociati per capire se un'entità è «reale». Un Organization senza sameAs è come un profilo LinkedIn senza contatti: tecnicamente valido, ma poco convincente.
La description non va copiata dalla meta description. Scrivi una frase specifica su cosa fai e per chi — non «siamo un'agenzia leader del settore», ma concreto: cosa, per chi, perché in modo diverso.
LocalBusiness: indispensabile se devi essere trovato sul territorio
Se hai una sede fisica — un ufficio, un negozio, uno studio — LocalBusiness (o un sottotipo più specifico come ProfessionalService, Restaurant, Store) è essenziale. È il motivo diretto per cui gli assistenti AI riescono a rispondere alle domande tipo «qui vicino».
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Via Manzoni 12",
"addressLocality": "Milano",
"postalCode": "20121",
"addressCountry": "IT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 45.4642,
"longitude": 9.1900
},
"telephone": "+39-02-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "18:00"
}
],
"priceRange": "€€€"
}
Due cose che vanno spesso storte. Primo: ci si dimentica delle coordinate geo, che sono esattamente ciò che i sistemi usano per calcolare la distanza nelle query «più vicino a me». Secondo: il @type è spesso troppo generico. Non usare LocalBusiness per default se esiste un sottotipo più preciso: Google e i sistemi AI riescono a fare match molto più mirati sull'intento con un tipo specifico (come Dentist, Accountant o MarketingAgency, dove disponibile).
È proprio il tema che approfondisco in GEO per le aziende locali — lì spiego anche come gestire più sedi.
FAQPage: lo schema più sottovalutato per l'AEO
Se c'è un tipo di schema che incide direttamente sulla probabilità di essere citato in una risposta AI, è FAQPage. Perché? Perché fornisce letteralmente la struttura domanda-risposta di cui un modello linguistico ha bisogno per riutilizzare i tuoi contenuti nella propria risposta — spesso parola per parola.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Quanto costa un sito web AI-native?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Un sito AI-native viene consegnato per fasi. Il costo dipende dal numero di pagine, dal numero di lingue e dalle integrazioni con i sistemi esistenti. Chiedi un preventivo basato sul tuo perimetro, con le ore stimate per ogni fase."
}
},
{
"@type": "Question",
"name": "I dati strutturati funzionano anche senza un team tecnico?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sì. La maggior parte dei CMS e dei framework supporta JSON-LD tramite plugin o semplici snippet di codice. Non serve uno sviluppatore dedicato per implementare lo schema Organization o FAQPage."
}
}
]
}
La trappola qui è riempire lo schema FAQPage con domande di marketing («Perché scegliere noi?») invece delle domande che le persone fanno davvero a un motore di ricerca o a un assistente AI. Guarda la sezione «Le persone chiedono anche» di Google, oppure testa tu stesso su ChatGPT e Perplexity quali domande emergono intorno al tuo tema. Scrivi risposte che stanno in piedi da sole: una risposta deve essere comprensibile senza rileggere la domanda, perché è esattamente così che un modello linguistico la estrae.
Ho approfondito il tema in la guida pratica all'AEO, inclusa la parte su come capire quali domande vale la pena di presidiare.
Dal file isolato al sistema che funziona: l'implementazione pratica
Dove inserirlo nel codebase
Se hai già un lib/schemas.ts (o qualcosa di simile), la struttura logica è questa: esporta funzioni che generano oggetti JSON-LD a partire dai tuoi contenuti, non stringhe statiche. Qualcosa del genere:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Così eviti che gli schema si scolleghino dai contenuti — un problema molto comune, in cui il testo delle FAQ sulla pagina viene aggiornato ma lo schema dietro non cresce di conseguenza. L'incoerenza tra contenuto visibile e dati strutturati è esattamente ciò che non vuoi: mina la fiducia sia di Google sia dei crawler AI.
Testa e valida prima di andare online
Usa il Rich Results Test di Google e il validatore ufficiale di Schema.org prima di pubblicare. Un errore frequente è un typo nel @type (per esempio Organisation con la grafia britannica invece di Organization): lo schema fallisce in silenzio, senza messaggi di errore sul sito, e te ne accorgi solo quando ti chiedi perché nulla funziona.
Non dimenticare di controllare che il tuo robots.txt non blocchi i crawler AI che dovrebbero leggere proprio questi dati — vedi la guida a robots.txt e crawler AI se hai dubbi che la tua configurazione sia corretta.