Dati strutturati per una struttura ricettiva: quali servono e quali no

Su un sito ricettivo servono cinque tipi di dati strutturati: Hotel, o la sottoclasse corretta di LodgingBusiness, poi Organization, WebSite con BreadcrumbList, FAQPage dove ci sono domande vere e Article sui contenuti editoriali. Tutto il resto è quasi sempre rumore. E nessuno dei cinque fa salire una pagina: i marcatori non sono un fattore di posizionamento, sono un fattore di comprensione.

Aggiungere schema.org a un sito non produce traffico: produce una descrizione della pagina leggibile da una macchina senza doverla interpretare. Se coincide con quello che la pagina dice davvero, i sistemi che leggono il web hanno meno margine di errore su di te. Se non coincide, hai costruito un modo elegante per contraddirti.

Il resto è manutenzione, ed è la parte che nessuno preventiva. Un marcatore è un impegno: dichiara un indirizzo, un numero di camere, un orario di check-in. Quando quel dato cambia e il markup no, il sito racconta due versioni della stessa struttura. È il problema più frequente sui siti ricettivi, molto più della mancanza di marcatori.

Che cosa fa un marcatore, e che cosa non fa#

Schema.org è un vocabolario condiviso, nato nel 2011 da un accordo fra i principali motori di ricerca, che serve a dire in modo esplicito che cosa rappresenta un pezzo di pagina: questa stringa è un indirizzo, questo numero è un orario di check-in, questa persona è l’autore. Il formato consigliato è JSON-LD, un blocco separato dal layout: non si rompe quando cambi tema.

Fanno tre cose. Rendono esplicite le entità, cioè dicono chi sei, dove sei e che attività svolgi, senza che nessuno debba dedurlo dal testo. Rendono una pagina ammissibile a certi formati di risultato: ammissibile, non garantita. E riducono l’ambiguità per chi legge senza vedere, che oggi significa anche i sistemi generativi.

Quello che non fanno conta di più. Non sono un criterio di ordinamento: nessuna piattaforma ha mai dichiarato che i marcatori facciano salire una pagina, e le documentazioni li presentano come aiuto alla comprensione e requisito per certi formati. Non salvano un testo scritto male. E non servono a far comparire prezzi e disponibilità nei risultati alberghieri dei motori: quei dati arrivano da feed dedicati e dalle integrazioni pubblicitarie del settore, non dal JSON-LD del sito. È l’equivoco più costoso, perché porta a marcare prezzi che nessuno leggerà e che intanto diventano falsi.

I tipi che contano davvero#

Hotel, o la sottoclasse giusta#

La classe generica è LodgingBusiness, e sotto ci sono Hotel, BedAndBreakfast, Resort, Hostel, Campground e VacationRental. Scegliere quella esatta vale più di venti proprietà aggiuntive sulla classe sbagliata: un campeggio che si dichiara Hotel dice una cosa falsa nel campo che pesa di più.

Le proprietà che vale la pena compilare sono poche e tutte verificabili: name, address con un PostalAddress completo, geo, telephone, email, url, checkinTime e checkoutTime, numberOfRooms, priceRange come fascia e non come tariffa, amenityFeature per i servizi che esistono davvero, starRating con la classificazione ufficiale e non con la media delle recensioni. In più due proprietà che sembrano tecniche e sono le più utili: @id, che dà all’entità un identificatore stabile, e sameAs, che la collega ai profili ufficiali dove la struttura è già descritta.

La regola pratica è una: metti solo quello che sei disposto ad aggiornare. Un priceRange scritto tre anni fa vale meno di un campo assente.

Organization e WebSite#

Sono i due tipi che quasi nessuna struttura implementa e che rendono di più, perché si scrivono una volta e non cambiano. Organization descrive il soggetto giuridico, con legalName, vatID, indirizzo della sede e sameAs. WebSite descrive il sito come oggetto, con un @id proprio e il collegamento all’editore.

Servono a consolidare l’identità. Una società che gestisce tre strutture, con tre siti e un solo soggetto giuridico, senza questi due tipi appare come sette entità slegate; con questi due tipi appare come una società e tre strutture, che è la verità.

BreadcrumbList#

È il marcatore più economico che esista: quasi tutti i gestori di contenuti lo generano da soli e non richiede manutenzione. Su un sito con sezioni per tipologia di camera, offerte e territorio è l’unica cosa che spiega a una macchina che quelle pagine sono parenti fra loro e non venti pagine indipendenti.

FAQPage#

Va usato solo dove ci sono domande vere con risposte vere, visibili all’ospite. Marcare domande che nessuno pone, o risposte che sono slogan, è peggio che non marcare niente.

Una precisazione onesta: dal 2023 Google mostra le FAQ in forma arricchita solo per una cerchia limitata di siti istituzionali e sanitari, quindi per una struttura ricettiva questo tipo non produce più il risultato visivo per cui veniva installato. Continua a fare il suo lavoro di descrizione: una coppia domanda-risposta marcata è un frammento autonomo, facile da estrarre e da citare. Se la usi per questo ha senso; se la usi sperando nel riquadro espanso, no.

Article#

Serve sui contenuti editoriali, non sulle pagine commerciali. Le proprietà che pesano sono headline, datePublished, dateModified, author con una persona reale e nominata, publisher, e le due che quasi nessuno compila, about e mentions, che collegano l’articolo ai concetti di cui parla. Aggiornare dateModified senza toccare il testo è una furbizia che si nota e toglie valore all’unico segnale di freschezza che hai.

HotelRoom e Offer, con cautela#

HotelRoom permette di descrivere una tipologia: letti, occupazione massima, metratura, servizi. Finché resta descrittivo è utile. Il problema nasce con Offer e il campo price: se il tuo motore di prenotazione lavora in tariffa dinamica, un prezzo scritto nel markup è falso entro poche ore. Meglio marcare le tipologie senza prezzo, o non marcarle affatto.

Quello che non serve, e quello che ti mette nei guai#

La marcatura delle recensioni sulla propria struttura è il caso più comune e il più rischioso. Le linee guida delle piattaforme escludono dai formati arricchiti le valutazioni auto-riferite, cioè quelle che un’attività scrive su sé stessa: un aggregateRating con una media calcolata da te non produce stelline nei risultati, produce una dichiarazione di parte con la tua firma sopra.

Poi ci sono i marcatori inventati per far comparire qualcosa: Event su iniziative che non esistono, Product su una camera, Offer con prezzi più bassi di quelli reali, sconti calcolati su un listino che nessuno ha mai pagato. In tutti questi casi il markup descrive una pagina diversa da quella che l’ospite vede, che è la definizione di contenuto ingannevole.

Infine il problema tecnico più diffuso: il markup duplicato. Il tema ne genera uno, l’estensione di ottimizzazione un altro, quella di prenotazione un terzo, e i tre dichiarano indirizzi leggermente diversi e due numeri di telefono. Non è un problema di quantità: sei tu a fornire la prova che i tuoi dati non sono affidabili.

Le OTA hanno già i tuoi dati: che cosa cambia#

Sui portali e sui metamotori la tua struttura è già descritta in forma strutturata, con più campi di quanti ne avrai mai sul sito, aggiornati dal channel manager e verificati da chi ci ha dormito. Il markup del sito non serve quindi a informare il mondo che la struttura esiste: il mondo lo sa già da altre fonti.

Serve a due cose. La prima è essere la versione autorevole: quando le descrizioni divergono, la fonte che porta il dominio ufficiale vale come riferimento, ma solo se è coerente e completa. La seconda è l’identità: nome, indirizzo e telefono identici ovunque, un @id stabile e un sameAs verso i profili ufficiali producono una entità sola. Una struttura che si chiama in tre modi diversi in tre posti diversi produce tre entità deboli.

C’è poi la parte che le OTA non hanno: le pagine che spiegano. Politiche di cancellazione per esteso, condizioni per gruppi, informazioni sul territorio, glossari, guide. Nessun portale le replica, e sono quelle su cui il markup rende di più, perché sono anche i contenuti che un assistente generativo ha più motivo di citare. Chi lavora sulla riduzione della dipendenza dai portali parte quasi sempre dal prezzo; il contenuto che i portali non possono avere è la leva più lenta e più duratura.

Il caso del glossario: DefinedTerm e DefinedTermSet#

Un esempio di marcatura che ha senso è il glossario di questo sito: 383 schede, ognuna con un termine, una definizione e un indirizzo stabile. Ogni scheda è un DefinedTerm, con name, description, termCode, url e inDefinedTermSet che punta all’insieme. L’insieme è un DefinedTermSet, con il proprio @id e la lista hasDefinedTerm.

Funziona per un motivo solo: la pagina contiene davvero una definizione, e il markup dice che quella è una definizione, di quel termine, dentro quella raccolta. Niente di inventato e niente da mantenere a mano, perché il blocco nasce dai campi già in archivio. Un articolo può poi puntare a quei concetti con about e mentions: a quel punto il sito non è un elenco di pagine ma una rete di argomenti con identificatori stabili.

Il limite va detto: per DefinedTerm non esiste nessun formato di risultato arricchito. Nessun riquadro, nessuna riga in più. Il beneficio è tutto nella comprensione da parte delle macchine ed è invisibile nei rapporti settimanali. Se il criterio di scelta è quello che si vede in una schermata, questo tipo non lo supererà mai; se il criterio è il costo marginale, lo supera facilmente, perché è generato in automatico.

Quanto costa mantenerli, e come si verifica#

Il costo di un marcatore non è l’implementazione, è la revisione: un blocco scritto a mano va riletto ogni volta che la pagina cambia, e nessuno se ne ricorda.

Quattrocentoventidue euro l’anno non rovinano un bilancio, ma sono la spesa che non viene mai fatta: le revisioni non avvengono e il markup invecchia. Da qui il criterio di scelta, che non è quanto un tipo sia utile ma quanto sia capace di aggiornarsi da solo. Un marcatore generato dai campi che il gestore di contenuti già possiede resta vero senza che nessuno se ne occupi; uno incollato dentro una pagina è vero il giorno in cui lo scrivi.

La verifica ha due livelli. Il primo è formale: i validatori pubblici dicono se la sintassi è corretta e se mancano proprietà obbligatorie, e bastano su un campione di pagine. Il secondo non lo fa nessuno strumento: si aprono affiancate la pagina e il suo blocco JSON-LD e si controlla che indirizzo, telefono, orari, numero di camere e classificazione coincidano. Dieci minuti a trimestre, sulle pagine che contano.

Cosa fare lunedì mattina#

1. Conta i blocchi di dati strutturati nel codice sorgente della pagina principale. Se sono più di uno, individua chi li genera fra tema ed estensioni, tienine uno e disattiva gli altri.
2. Verifica che la classe dichiarata sia la sottoclasse esatta di LodgingBusiness, non la generica. È il campo che pesa di più e quello sbagliato più spesso.
3. Confronta riga per riga i dati del markup con la pagina contatti: nome, indirizzo, telefono, email, orari di check-in e check-out, numero di camere, classificazione. Correggi il markup, non la pagina.
4. Aggiungi Organization con partita IVA e denominazione sociale, e WebSite con un identificatore stabile. Sono due blocchi che si scrivono una volta e non si toccano più.
5. Togli aggregateRating e Review riferiti alla tua struttura, se ci sono. Non producono niente e ti espongono.
6. Togli ogni prezzo dal markup, salvo tariffe fisse che non cambiano. Lascia priceRange come fascia e aggiornalo a inizio stagione.
7. Elenca le pagine con markup scritto a mano e chiedi a chi gestisce il sito di generarlo dai campi già presenti. Ogni pagina che passa all’automatico smette di invecchiare.
8. Metti in calendario dieci minuti a trimestre di verifica su tre pagine: principale, contatti e una camera.