Hai un’attività locale, con un sito online e un Business Profile strutturato e ottimizzato. A un certo punto però arriva qualcuno e ti chiede “hai messo i dati strutturati?”
Allora tu giustamente apri Google, ChatGPT, Perplexity o Gemini, scegli qualche articolo per capire cosa sono e ti trovi davanti a una lista di quindici markup, sigle strane che non avevi mai sentito, esempi di codice presi da settori che non c’entrano niente con il tuo.
Il risultato è ovvio: sei più confuso di prima.
Da lì in genere si va in due direzioni: implementare tutto a caso sperando che qualcosa funzioni oppure rimandare a tempo indeterminato perché sembra una cosa tecnica da lasciare agli sviluppatori.
La risposta è meno spettacolare e più utile di entrambe: per un’attività locale i markup utili sono pochi, vanno scelti in base al tipo di business e implementati in modo coerente con il resto della presenza online. Tutto il resto è ornamentale e in qualche caso può anche essere d’intralcio.
In questo articolo vediamo quali sono quei pochi, in che ordine di priorità conviene affrontarli, e dove fermarsi.
A cosa servono per chi fa local?
Saltiamo la teoria generale, perché si trova ovunque (se vuoi approfondire, anche noi le abbiamo deddicato un post ad hoc:”Cosa sono i dati strutturati per la SEO“). In questo articolo ci interessa un livello di dettaglio molto più specifico: cosa cambia quando metti i dati strutturati sul sito di un’attività locale?
Risposta breve: cambiano tre cose e tutte e tre hanno a che fare con il modo in cui Google riconosce chi sei, non cosa hai scritto.
- La prima: aiuti il motore di ricerca a capire che la tua pagina parla di un’entità precisa, la tua attività, e non di un argomento generico. È un livello di molto superiore al riconoscimento di keyword classico. Stai dicendo a Google “questa non è una pagina che parla di pizzerie a Bologna, questa è la pagina di una pizzeria a Bologna, con questo nome, in questo indirizzo, aperta in questi orari”.
- La seconda: rinforzi il legame tra il sito e il Profilo dell’attività su Google (in inglese Google Business Profile, il vecchio Google My Business). Quando le informazioni coincidono in modo pulito tra le due fonti, Google ha meno motivi per dubitare, e la scheda della tua attività tende a essere mostrata in modo più completo su Maps e nei risultati di ricerca.
- La terza, più recente: i sistemi AI che generano risposte alle ricerche degli utenti, quelli che ormai compaiono in cima a buona parte delle SERP, ragionano per entità. Non leggono le pagine come faceva il vecchio Google. Uno schema ben fatto è uno dei pochi modi che hai per fornire quei fatti in una forma che le macchine prendono al volo.
Anche se sembrano tre obiettivi diversi, ma la direzione è la stessa: essere riconoscibili e riconosciuti. Tutte le istruzioni e informazioni che ti darò a seguire ruotano attorno a questo punto cardinale.
Il livello base: LocalBusiness e il sotto-tipo giusto
Se di tutto questo articolo dovessi tenere una cosa sola, è quella che segue: il markup di base per qualsiasi attività con una sede fisica si chiama LocalBusiness.
Questo dato strutturato sostanzialmente dice a Google “sono X, un’attività locale, ecco dove si trova la mia sede, questi sono i miei orari, questi il mio telefono e la mia email”.
Fin qui siamo alla base. Tieni a mente però che LocalBusiness è un type, un po’ come fosse il “padre”. Sotto ha decine di sotto-tipi specifici: Restaurant, Dentist, HairSalon, AutoRepair, MedicalClinic, Store, LodgingBusiness e così via.
La regola, che lo stesso Google indica anche nella sua documentazione ufficiale, è di usare il sotto-tipo più specifico che descrive la tua attività, non soltanto il tipo generico.
La differenza, quando dichiari Dentist invece di LocalBusiness, è che stai dando a Google due informazioni invece di una: che sei un’attività locale e che sei uno studio dentistico.
Capirai bene che c’è una grande differenza tra apparire come un “attività locale” e apparire come un “dentista a Bologna”, no?
Proprietà più utili
Schema.org elenca decine di proprietà possibili per LocalBusiness. A mio parere, quelle che non dovrebbero mai mancare sul sito di un attività locale sono all’incirca una decina:
name, il nome dell’attività, esattamente come compare sul Profilo dell’attività su Googleaddress, l’indirizzo completo, in formato strutturato (via, città, CAP, paese)telephone, il numero di telefono nel formato internazionaleopeningHoursSpecification, gli orari di apertura giorno per giornogeo, le coordinate geografiche (latitudine e longitudine)url, l’URL del sitoimage, una o più immagini dell’attivitàpriceRange, la fascia di prezzo, espressa con i simboli € (€, €€, €€€)
Per tutte le restanti vale uno dei consigli principali della SEO: testa, verifica, valida!
Un esempio concreto
Mettiamo che hai uno studio dentistico a Bologna con una sola sede. Lo schema base, in formato JSON-LD, sarebbe qualcosa di simile a questo:
{
"@context": "https://schema.org",
"@type": "Dentist",
"name": "Studio Dentistico Bianchi",
"image": "https://www.studiodentisticobianchi.it/img/studio.jpg",
"url": "https://www.studiodentisticobianchi.it",
"telephone": "+39 051 *** ***",
"priceRange": "€€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Via dei denti sani",
"addressLocality": "Bologna",
"postalCode": "40100",
"addressCountry": "IT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 44.4949,
"longitude": 11.3426
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "19:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "09:00",
"closes": "13:00"
}
]
}Nota bene: il @type non è LocalBusiness, è Dentist.
Lo snippet va inserito nell’HTML della pagina, di solito nella home o nella pagina contatti, dentro un tag <script type="application/ld+json">. Una volta pubblicato, lo si verifica con il Rich Results Test di Google, che dice se Google legge correttamente i dati e se ci sono errori da sistemare.
Se quello che hai è una sola sede, e fai una sola cosa, questo è già il 70% del lavoro.
Quando il sotto-tipo da solo non basta
Per alcuni settori, il sotto-tipo specifico porta con sé delle proprietà aggiuntive che descrivono cose che LocalBusiness generico non sa raccontare. Sono i casi in cui scegliere il @type giusto fa una differenza visibile anche nei risultati di ricerca, perché Google sa cosa farne di quelle informazioni in più.
I settori dove questo conta sono soprattutto quattro: ristorazione, ricettività, sanità e retail. Vediamoli con un minimo di dettaglio per scongiurare l’errore più comune: trattare queste informazioni come “markup aggiuntivi” da affiancare a LocalBusiness, quando invece sono semplicemente proprietà che vivono dentro il sotto-tipo corretto.
Ristorazione
Il sotto-tipo è Restaurant (o, se serve precisare, BarOrPub, CafeOrCoffeeShop, FastFoodRestaurant). Le proprietà aggiuntive che hanno senso sono servesCuisine (i tipi di cucina offerti), menu (URL della pagina menù), acceptsReservations (true o false). Per i ristoranti, queste informazioni Google le mostra spesso nella scheda dell’attività e nelle risposte locali, quindi sono tra le proprietà più “ripagate” in assoluto.
Un esempio di snippet per una trattoria a Modena:
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "Trattoria PopCorn",
"servesCuisine": ["Italian", "Emiliana"],
"menu": "https://www.trattoriapopcorn.it/menu",
"acceptsReservations": "True",
"priceRange": "€€"
}Le altre proprietà di base (indirizzo, telefono, orari, geo) restano identiche all’esempio precedente. Non le sto a ripetere, ma vanno incluse tutte nello stesso schema.
Ricettività
Per alberghi, B&B, case vacanze, agriturismi il sotto-tipo è LodgingBusiness, con le varianti Hotel, BedAndBreakfast, Resort. Qui le proprietà rilevanti diventano checkinTime, checkoutTime, numberOfRooms, amenityFeature (con le caratteristiche tipo Wi-Fi, parcheggio, piscina), starRating.
In questo settore, dove si lavora molto con i portali di prenotazione, la coerenza dei dati strutturati conta ancora di più della media. Se sul sito dichiari check-in alle 14 e su Booking alle 15, Google se ne accorge e non è un bene!
Sanità
Qui la questione è più complicata.
Sopra a tutto c’è MedicalBusiness, sotto stanno Dentist, Physiotherapist, MedicalClinic, Optician, e così via. Le proprietà specifiche più utili sono medicalSpecialty (per cliniche multi-specialità) e availableService, che permette di esplicitare quali prestazioni vengono offerte.
Vale la pena ricordare che in ambito sanitario Google è particolarmente attento alla coerenza tra quello che dichiari nello schema e quello che mostri effettivamente sul sito. Indicare specialità che poi non vengono trattate è uno di quei casi in cui i dati strutturati invece di aiutare possono creare diffidenza.
Retail
Per i negozi fisici il sotto-tipo base è Store, con varianti come ClothingStore, BookStore, JewelryStore, HardwareStore. Le proprietà settoriali sono meno interessanti che negli altri tre casi: in pratica, il valore aggiunto di Store rispetto a LocalBusiness sta soprattutto nella categorizzazione. Per i negozi fisici la parte importante arriva al livello successivo, quando si collegano i prodotti tramite il markup Product.
Un errore frequente: non serve raddoppiare!
Capita di vedere implementazioni in cui sulla stessa pagina sono presenti due script JSON-LD: uno con @type: LocalBusiness e uno con @type: Restaurant.
Sono ridondanti: Restaurant è già un LocalBusinessed eredita tutte le sue proprietà. Mettere entrambi confonde Google, che si ritrova due descrizioni separate di quella che dovrebbe essere la stessa entità.
La regola è semplice: un’attività, uno schema, il sotto-tipo più specifico possibile.
Cosa puoi aggiungere allo schema base?
Una volta che lo schema dell’attività è pulito, hai la possibilità di integrarlo con una serie di markup aggiuntivi da combinare con il principale. Sono quelli che descrivono cose legate all’attività: servizi, prodotti, eventi, domande frequenti, recensioni.
La domanda giusta da farsi qui è “quali di queste cose fanno parte del mio business in modo riconoscibile?”. Se la risposta è “nessuna”, si lascia perdere. Aggiungere markup per ottenere visibilità su contenuti che il sito non gestisce davvero è il modo più rapido per far ignorare a Google anche quelli che hai messo bene.
Service
È il più sottovalutato della lista. Si usa quando l’attività offre prestazioni distinte, ognuna con caratteristiche proprie: un’autofficina che fa tagliando, revisione e cambio gomme, uno studio dentistico che offre igiene, ortodonzia e implantologia, un centro estetico con trattamenti diversi.
Il vantaggio è duplice. Da una parte rende ogni servizio un’entità riconoscibile, che Google può collegare a query molto specifiche tipo “ortodonzia invisibile bologna”. Dall’altra è uno dei markup che le AI generative leggono volentieri quando devono rispondere a domande del tipo “dove posso fare X in zona”.
Uno snippet di esempio per un servizio dello studio dentistico:
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "Implantologia dentale",
"provider": {
"@type": "Dentist",
"name": "Studio Dentistico Bianchi"
},
"areaServed": {
"@type": "City",
"name": "Bologna"
},
"description": "Inserimento di impianti dentali in titanio con tecnica computer-guidata."
}In pratica si crea uno schema Service per ogni prestazione importante, di solito sulla pagina dedicata a quel servizio (non tutti insieme in home).
Product
Ha senso solo se hai un catalogo fisico, anche piccolo, e se quel catalogo è raccontato sul sito. Un’ottica, una ferramenta, un’enoteca, un negozio di animali. Non ha senso per uno studio professionale, e non ha senso “in finzione” per chi non vende prodotti.
Il markup Product permette di dichiarare nome, immagine, prezzo, disponibilità, brand. Quando i dati sono coerenti con quello che il sito mostra, Google può far comparire l’attività nelle ricerche di prodotti locali, con immagine e prezzo direttamente in SERP.
Una nota importante: se decidi di metterlo, va messo bene, con availability e price aggiornati. Un Product con prezzo sbagliato o disponibilità non veritiera è uno dei casi che Google segnala come violazione delle linee guida.
Un’aggiunta: io personalmente l’ho spesso utilizzato anche per servizi immateriali, al posto del precedente Service. Per me ha comunque funzionato.
Event
È utile in un caso specifico: l’attività organizza eventi ricorrenti che sono parte dell’offerta. Una palestra con corsi a calendario, una sala eventi con serate, un ristorante che fa cene a tema, una libreria con presentazioni.
Non è utile per “eventi di vita aziendale”, tipo l’inaugurazione di una nuova sede o lo sconto del weekend. Sono casi che Google non riconosce come Event nel senso che intende lui.
Esempio per un corso ricorrente in una palestra:
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Pilates Matwork",
"startDate": "2026-06-03T18:30",
"endDate": "2026-06-03T19:30",
"eventSchedule": {
"@type": "Schedule",
"byDay": ["Monday", "Wednesday"],
"startTime": "18:30",
"endTime": "19:30"
},
"location": {
"@type": "Place",
"name": "Palestra Popcorn",
"address": "Via Garibaldi 12, Modena"
},
"organizer": {
"@type": "Organization",
"name": "Palestra Popcorn"
}
}FAQPage
Funziona, ma con un’avvertenza. Dal 7 maggio 2026, Google non supporta più i risultati avanzati (rich results) per le FAQ
Resta comunque un markup utile, ma per altri motivi: aiuta i sistemi AI a leggere le risposte alle domande tipiche dei clienti in una forma pulita. Lo si mette sulle pagine servizio o sulla pagina contatti, non sulla home, e si scrivono domande vere, quelle che i clienti fanno davvero al telefono.
Review e AggregateRating
Su questo Google ha alzato molto la soglia di attenzione e per buone ragioni: molti ne hanno abusato. Le recensioni dichiarate via schema devono essere recensioni reali, raccolte e mostrate sul sito stesso.
Il caso in cui ha senso è quando l’attività raccoglie testimonianze proprie sul sito, magari tramite un form di feedback dedicato, e le pubblica in una pagina con il contenuto visibile. In quei casi Review aggiunto allo schema è coerente con quello che il sito mostra, e Google lo legge volentieri.
BreadcrumbList
Non è un markup “local” in senso stretto, ma per attività con più sedi o con un catalogo di servizi diventa utile. Aiuta Google a capire la struttura del sito (homepage → sedi → sede di Bologna, oppure homepage → servizi → ortodonzia) e a mostrarla nelle SERP al posto dell’URL.
Si implementa una volta sola, a livello di template, e poi lavora da solo su tutte le pagine.
Più sedi: una pagina, uno schema, una sede
Se l’attività ha più di una sede, succede quasi sempre la stessa cosa: si mette uno schema LocalBusiness in homepage con tutti gli indirizzi infilati dentro e ci si ferma lì. Ecco, questo è forse il modo più rapido per distruggere il lavoro fatto!
Google associa uno schema a una pagina e a un’entità. Se in homepage dichiari quattro indirizzi diversi sotto lo stesso nome, il motore di ricerca prova a capire, in genere ignora il dato, e finisce per non collegarne bene nessuno.
La logica corretta è totalmente opposta: ogni sede merita la sua pagina, e ogni pagina merita il suo schema dedicato.
Come si struttura
Per un’attività con più sedi, l’architettura più ragionevole è questa. La homepage ospita lo schema dell’organizzazione complessiva, di tipo Organization, che descrive il gruppo o il brand nel suo insieme. Poi ogni sede ha una sua landing page, con il suo indirizzo, i suoi orari, il suo telefono, le sue foto, e il suo schema LocalBusiness (o il sotto-tipo specifico) compilato con i dati di quella sede.
Sul piano del codice, lo schema di ogni sede è identico nella struttura a quello dell’esempio iniziale dello studio dentistico, cambiano i contenuti. Se manteniamo l’esempio dello studio, immaginiamo che abbia aperto una seconda sede a Modena. La pagina studiodentisticobianchi.it/sedi/modena conterrebbe uno schema così:
json
{
"@context": "https://schema.org",
"@type": "Dentist",
"name": "Studio Dentistico PopCorn - Sede di Modena",
"image": "https://www.studiodentisticopopcorn.it/img/sede-modena.jpg",
"url": "https://www.studiodentisticopopcorn.it/sedi/modena",
"telephone": "+39 059 1234566",
"priceRange": "€€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Via Emilia Centro 88",
"addressLocality": "Modena",
"postalCode": "41121",
"addressCountry": "IT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 44.6471,
"longitude": 10.9252
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "10:00",
"closes": "20:00"
}
],
"parentOrganization": {
"@type": "Organization",
"name": "Studio Dentistico Popcorn",
"url": "https://www.studiodentisticopopcorn.it"
}
}L’unica proprietà nuova rispetto allo schema della sede singola è parentOrganization, che dice a Google “questa sede appartiene a un’organizzazione più ampia, che ha questo nome e questo sito” e lega le sedi al brand senza confondere le entità.
Le sedi vanno collegate anche al Profilo
Una sede vera, riconosciuta da Google, ha sempre un suo Business Profile, con il suo indirizzo e i suoi orari. Lo schema sul sito e il Business Profile di quella sede devono coincidere. Nome identico, indirizzo identico, telefono identico, orari identici.
È un lavoro un po’ più noioso di quello che sembra, perché significa tenere allineate informazioni che vivono in posti diversi. Ma è anche il punto in cui le attività multi-sede fanno la differenza tra una local SEO che funziona e una che galleggia.
E quando le sedi sono molte?
Per le attività con molte sedi (catene, franchising, gruppi medici), la struttura non cambia nei principi, cambia nella gestione. In quei casi si lavora con uno store locator dinamico, dove ogni pagina sede viene generata da un template e lo schema viene compilato da database. La logica resta la stessa: una pagina per sede, uno schema per pagina, dati allineati al Business Profile corrispondente.
Non cercare scorciatoie. Usare uno schema generico unico per tutte le sedi sembra economico ma rischia di azzerare il valore del tuo lavoro.
Dati strutturati e AI: cosa è cambiato negli ultimi due anni
Fino a qualche anno fa, la ragione principale per implementare i dati strutturati era una sola: ottenere rich result in SERP, cioè quei risultati arricchiti con stelline, prezzi, orari, immagini. L’obiettivo era estetico e funzionale insieme, perché un risultato più visibile prende più clic.
Quella ragione esiste ancora, e per molte ricerche locali è ancora il motivo principale. Ma negli ultimi due anni se ne è aggiunta un’altra, che per chi fa local è diventata altrettanto importante: il modo in cui i sistemi di intelligenza artificiale leggono e riutilizzano le informazioni sull’attività.
Google AI Overviews, ChatGPT con accesso al web, Perplexity, Gemini. Quando un utente chiede “dove posso fare la pulizia dei denti vicino a Bologna” o “ristorante per cena di compleanno in centro a Modena”, la risposta non arriva più solo dalla lista classica di link. Arriva da un sistema che ha letto le pagine, estratto i fatti, riconosciuto le entità, e ha costruito una risposta che cita alcune attività e ne ignora altre.
Cosa cercano questi sistemi
Cercano fatti riconoscibili, non testo da interpretare. Quando una pagina dichiara via schema che lo studio si chiama “Studio Dentistico PopCorn”, si trova a un certo indirizzo, è aperto in certi orari, offre questi servizi, sta consegnando alla macchina informazioni in una forma che la macchina prende così com’è.
Una pagina che dice le stesse cose solo via testo prosa, senza dati strutturati, costringe il sistema a estrarre quei fatti dal testo, con tutto il margine di errore del caso. Se il testo è scritto bene, probabilmente ce la farà. Se è scritto male, no. Se è scritto in modo ambiguo, magari sì ma in modo sbagliato.
I dati strutturati fanno una cosa molto semplice: tolgono ambiguità. È il motivo per cui un’attività locale con uno schema pulito ha più probabilità di comparire nelle risposte AI rispetto a una concorrente con un sito uguale ma senza markup.
Cosa devi fare?
Non c’è da implementare nulla di nuovo per essere “AI-ready”. Lo schema LocalBusiness ben fatto, con il sotto-tipo giusto, le proprietà compilate con cura, i Service sulle pagine servizio, il tutto coerente con il Profilo.
Chiudiamo quindi tornando alla alla domanda iniziale: quali dati strutturati servono davvero a un’attività locale?
Lo schema LocalBusiness con il sotto-tipo specifico, compilato con cura nelle proprietà che contano. Una pagina per ogni sede, con il suo schema dedicato. I markup di estensione (Service, Product, Event, FAQPage) solo dove esiste un contenuto reale sul sito che li giustifica. Tutto allineato al Profilo dell’attività su Google, sempre.
È meno di quello che vendono molte guide ed è molto di più di quello che la maggior parte delle attività ha implementato sul proprio sito.
Per un’attività locale, esistere agli occhi di Google significa essere riconoscibili in modo univoco. I dati strutturati sono lo strumento più diretto che hai per dire al motore di ricerca chi sei, dove sei, e cosa fai. Tutto il resto del lavoro local viene dopo, e lavora meglio quando questa parte è in ordine.
Ti interessa la SEO locale? Ecco tre articoli da non perdere:
