Dati strutturati per tour operator e noleggi: a cosa servono e come farli bene

I dati strutturati sono un blocco di codice invisibile ai visitatori che descrive ai motori di ricerca cosa c’è in una pagina: questo è un tour, costa tanto, parte da qui, ha queste recensioni, appartiene a questa azienda. Per un tour operator o un’attività di noleggio servono a far capire a Google e agli assistenti AI di cosa si tratta senza doverlo indovinare dal testo. Si scrivono di solito in formato JSON-LD con il vocabolario schema.org, e funzionano solo se sono coerenti: un’azienda descritta due volte in modo diverso, o un voto medio che non corrisponde alle recensioni, fa più danni che non averli.

Cosa sono, in pratica

Una pagina di un tour, per una persona, è chiara: c’è il titolo, una galleria, il prezzo, il pulsante «prenota». Per un motore di ricerca è testo e immagini da interpretare. I dati strutturati aggiungono una descrizione esplicita, in un formato standard, che dice: questo è un TouristTrip, questa è la sua offerta con prezzo e valuta, questa è l’organizzazione che lo vende.

Non sono una scorciatoia per salire in classifica. Servono a tre cose concrete:

• rendere la pagina idonea ai risultati arricchiti, come prezzi, voti o percorso di navigazione mostrati direttamente in Google (che poi decide se mostrarli);
• evitare ambiguità su chi sei, cosa vendi e dove operi;
• dare informazioni pulite anche ai sistemi di intelligenza artificiale che leggono il web per rispondere alle domande.

I tipi schema.org utili per tour ed escursioni

Non serve usarli tutti. Serve usare quelli giusti per ogni tipo di pagina.

Due note di realismo. Google oggi mostra i risultati arricchiti delle FAQ solo per pochi siti autorevoli, quindi FAQPage aiuta soprattutto a descrivere bene il contenuto, non a ottenere un riquadro in più. E le stelle delle recensioni che un’azienda pubblica su sé stessa non vengono più mostrate nei risultati: il voto resta utile come informazione, ma va riportato in modo onesto e coerente.

Un grafo unico, non tanti pezzi sparsi

Il modo più solido di scrivere i dati strutturati è un unico grafo per pagina: un solo blocco JSON-LD in cui i vari nodi (organizzazione, sito, pagina, tour, offerta) si richiamano tra loro con un identificativo, il campo @id. L’organizzazione si descrive una volta sola, e il tour dice semplicemente «sono venduto da quell’organizzazione».

Il problema nasce quando più strumenti scrivono ciascuno il proprio pezzo: il tema del sito, un plugin SEO, il widget delle recensioni, uno script aggiunto anni fa. Ognuno ha la sua idea di chi sei, e il risultato è un’azienda descritta tre volte con dati diversi.

Gli errori più comuni

Sono quasi sempre gli stessi:

• due nodi organizzazione con lo stesso identificativo ma contenuti diversi: indirizzo in uno, telefono nell’altro, nomi leggermente diversi;
• voti incoerenti: un voto medio in un blocco e un altro voto, o un numero di recensioni diverso, in un secondo blocco della stessa pagina;
• breadcrumb che non corrispondono al sito: percorsi verso pagine che non esistono più, o categorie diverse da quelle del menu;
• prezzi non aggiornati: l’offerta nei dati strutturati dice un prezzo, la pagina un altro;
• dati generati in automatico e mai controllati: il plugin produce qualcosa, nessuno l’ha mai letto.

Nessuno di questi errori si vede guardando il sito. Si vedono solo leggendo il codice o passando la pagina negli strumenti di verifica.

Se il tuo sito è su WordPress

Su WordPress il primo passo è capire chi sta già scrivendo dati strutturati. Spesso il plugin SEO li genera in automatico, e altri plugin aggiungono i propri. Si sceglie una sola fonte: o si configura bene il plugin, o si disattiva la sua parte di JSON-LD e si genera il grafo con un componente unico, che sa quali tipi usare per ogni tipo di pagina.

La seconda strada richiede più lavoro all’inizio, ma rende il risultato prevedibile: i dati strutturati di un tour escono dagli stessi dati che compongono la pagina, e non possono contraddirla.

Se il tuo sito è su un CMS chiuso

Molti operatori turistici usano piattaforme proprietarie in cui non si può modificare il codice dei modelli di pagina. Non è un vicolo cieco. Quasi sempre è possibile aggiungere uno script alle pagine, e da lì si può:

• disattivare o neutralizzare il blocco di dati strutturati sbagliato prodotto dalla piattaforma;
• inserire al suo posto quello corretto, costruito per tipo di pagina;
• lasciare intatto ciò che funziona, per esempio il widget delle recensioni.

Google legge anche i dati strutturati aggiunti tramite JavaScript. È un intervento da fare con attenzione, con test che verificano il risultato pagina per pagina, ma permette di sistemare i dati senza cambiare piattaforma.

Validare con gli strumenti di Google

Ogni modifica va verificata. Gli strumenti sono gratuiti:

1. Test dei risultati multimediali (Rich Results Test): dice se la pagina è idonea ai risultati arricchiti e segnala errori e avvisi.
2. Validatore di schema.org: controlla la correttezza rispetto al vocabolario, anche per i tipi che Google non usa per i risultati arricchiti.
3. Google Search Console: dopo la pubblicazione mostra, nei report sui miglioramenti, gli errori rilevati su tutto il sito nel tempo.

Conviene affiancare a questi controlli manuali dei test automatici che, a ogni modifica, verificano che ogni tipo di pagina produca il grafo atteso.

Due esempi reali

Ho lavorato sui dati strutturati di due siti turistici, da solo, partendo da situazioni diverse.

Il primo è un sito WordPress multilingua con tema a blocchi. Il plugin SEO generava il proprio JSON-LD, e la diagnosi ha trovato due nodi organizzazione con lo stesso identificativo e voti incoerenti tra loro, oltre a breadcrumb da correggere. Ho disattivato i dati automatici del plugin e scritto un unico generatore di grafi per tipo di pagina, con TouristTrip, Product, Offer, Review, AggregateRating, BreadcrumbList, ItemList, BlogPosting e WebSite con ricerca interna.

Il secondo è su un CMS proprietario, senza accesso ai modelli di pagina. Qui uno script disattiva il blocco organizzazione errato prodotto dalla piattaforma e inserisce quello corretto, lasciando intatto il widget delle recensioni. I dati strutturati di ogni pagina escono da un unico pacchetto generato a partire da dodici modelli (tour, servizi, schede prodotto, FAQ, blog, pagine legali). Per costruirlo ho estratto l’inventario delle pagine escludendo qualsiasi dato personale; il risultato è coperto da test automatici e verificato con il Test dei risultati multimediali.

Su uno dei due, il sito di un’agenzia di escursioni, il lavoro non si è fermato al JSON-LD. Ho curato anche la messa in produzione, con HTTPS forzato e redirect 301 verso il dominio principale, cache e compressione per la velocità, Google Tag Manager per il tracciamento e un file llms.txt con gli articoli nelle due lingue, pensato per i motori di ricerca basati su AI.

Domande frequenti

I dati strutturati migliorano il posizionamento?

Non direttamente. Rendono la pagina idonea ai risultati arricchiti e più chiara per i motori di ricerca, e questo può migliorare la visibilità e i clic. Non sostituiscono contenuti utili e un sito veloce.

Basta il plugin SEO?

A volte sì, se configurato bene e se nessun altro strumento aggiunge dati in conflitto. Conviene comunque controllare cosa produce: spesso genera tipi generici e non sa che una pagina descrive un tour.

Si possono correggere senza rifare il sito?

Sì. Su WordPress si interviene sul tema o con un componente dedicato; su un CMS chiuso, quasi sempre, con uno script inserito nelle pagine.

Da dove partire

Se il tuo sito vende tour, escursioni o noleggi e non sai cosa racconta di te ai motori di ricerca, possiamo fare insieme una verifica. Puoi vedere come lavoro sui booking engine e sull’evoluzione di siti e software esistenti, oppure scrivermi direttamente: la prima analisi è gratuita.