Schema eventi in SEO: la guida ai dati strutturati

Lo schema Event (schema.org/Event) è il markup che permette a un motore di ricerca di capire, senza dover interpretare il testo della pagina, che cosa succede, quando, dove e a quali condizioni si può partecipare. Non aggiunge testo visibile alla pagina: aggiunge struttura a informazioni che di solito esistono già — nome dell'evento, data di inizio e fine, luogo fisico o online, disponibilità dei biglietti e prezzo — così che possano essere riconosciute in modo affidabile invece di essere dedotte da una frase scritta in linguaggio naturale.

Chi organizza eventi tende a trattarlo come un dettaglio tecnico da spuntare una volta e dimenticare. È un errore di prospettiva: a differenza di una pagina prodotto, una pagina evento porta incorporata una data di scadenza, e il modo in cui gestisci quella scadenza — non il markup in sé — è ciò che distingue un'implementazione che funziona nel tempo da una che accumula pagine morte, indicizzate, con eventi già passati dichiarati ancora attivi.

Cosa comunica il markup Event ai motori di ricerca

Lo schema Event descrive un insieme ristretto di fatti: il nome dell'evento, l'orario di inizio e, quando applicabile, di fine; se si tiene in un luogo fisico, online o in entrambe le forme per un evento ibrido; chi lo organizza; se restano posti o biglietti disponibili e a quale prezzo; e lo stato dell'evento — programmato, rinviato, riprogrammato o annullato.

Nessuna di queste informazioni è nuova: è già scritta, in qualche forma, nella pagina che il visitatore legge. Il markup non la inventa, la rende esplicita in un formato che una macchina può leggere senza ambiguità. Una frase come «il seminario si terrà il 14 marzo alle 18, ingresso libero fino a esaurimento posti» è chiara per una persona, ma lascia a un parser troppo lavoro di interpretazione: qual è la data in formato standard, qual è il fuso orario, cosa significa esattamente «fino a esaurimento posti» in termini di disponibilità dichiarata. Lo schema toglie l'ambiguità, non aggiunge informazione che non ci fosse già.

A chi serve davvero questo markup

Non ogni sito con una pagina «eventi» ne ha davvero bisogno, e vale la pena essere onesti su questo prima di implementarlo per abitudine.

Un sito che si limita a dichiarare che «i nostri servizi sono disponibili tutto l'anno» non ha un evento nel senso che lo schema intende: ha un servizio continuativo, e forzarlo nel vocabolario Event produce un markup che descrive qualcosa che non esiste — una data di inizio inventata per un'attività che in realtà non ne ha una.

• Locali, sale e spazi che ospitano eventi con una data e un luogo fisico verificabile: concerti, mostre, fiere, spettacoli.
• Organizzatori di conferenze e meetup, dove i dettagli di data, sede e biglietteria cambiano da un'edizione all'altra.
• Enti di formazione e provider di corsi, che pubblicano sessioni con orari fissi e posti limitati.
• Chi gestisce webinar e sessioni ricorrenti online, dove la distinzione tra luogo fisico e virtuale è spesso proprio il punto debole dell'implementazione.

Data e ora: il dettaglio che quasi tutti sbagliano

startDate ed endDate sono le proprietà più importanti dello schema, e anche le più spesso implementate a metà. Il problema di solito non è dimenticarle — quasi nessuno lo fa — ma omettere il fuso orario. Una data senza offset (ad esempio 2026-11-14T18:00) è tecnicamente leggibile ma ambigua ovunque il pubblico non condivida lo stesso fuso orario di chi ha scritto il markup: un webinar pubblicizzato come «ore 18:00» senza specificare se è ora di Roma, di Londra o UTC costringe ogni lettore internazionale a indovinare, e nessun parser automatico può correggere l'ambiguità al posto tuo.

La forma corretta include sempre l'offset esplicito, ad esempio 2026-11-14T18:00:00+01:00. Per un evento con più giorni o più sessioni, endDate non è opzionale quanto sembra: senza di essa un motore di ricerca non può distinguere un evento che dura un'ora da uno che dura una settimana, e non può escludere dai risultati «di oggi» un evento già terminato da ore.

Location fisica e location virtuale

Qui si concentra l'errore più diffuso in assoluto. Un evento fisico usa una Place, con un indirizzo reale e verificabile — non l'indirizzo generico della sede legale dell'organizzatore, se l'evento si tiene altrove. Un evento interamente online non ha invece un indirizzo fisico da dichiarare: va descritto con la forma di location virtuale e l'URL a cui si accede per partecipare.

Il punto debole tipico è marcare un webinar con l'indirizzo della sede legale dell'azienda solo perché il campo location sembra richiederne uno. Il risultato è un markup internamente coerente ma falso: dichiara un luogo fisico per un evento che non ne ha uno, e un motore di ricerca che prende quel dato alla lettera lo tratta come informazione affidabile, non come approssimazione accettabile. Per un evento ibrido — parte fisico, parte trasmesso online — è legittimo dichiarare entrambe le forme di location, purché corrispondano davvero a come si può effettivamente partecipare.

Biglietti, disponibilità e prezzo

La proprietà offers collega l'evento a un'offerta con almeno prezzo, valuta e disponibilità. È qui che il markup smette di essere solo descrittivo e comincia a fare una promessa verificabile: se dichiari che i posti sono disponibili e in realtà sono esauriti, o se il prezzo indicato non corrisponde a quello mostrato nella pagina di acquisto, hai un disallineamento che un utente scopre in pochi secondi — e che un motore di ricerca può imparare a non fidarsi più di una fonte.

Per gli eventi gratuiti, il prezzo va dichiarato esplicitamente come zero, non omesso: un'offerta senza prezzo è un'offerta incompleta, non un'offerta gratuita per definizione. Per eventi con più fasce di prezzo — early bird, intero, ridotto — è preferibile dichiarare un'offerta distinta per ciascuna fascia piuttosto che forzare tutto in un unico intervallo generico che non corrisponde a nessun prezzo reale.

Stato dell'evento: rinvii, riprogrammazioni, annullamenti

Il campo che indica lo stato dell'evento è quello che quasi nessuno tocca finché non ne ha bisogno con urgenza, cioè quando un evento salta. Lo schema prevede valori distinti per lo stato programmato di default, per il rinvio senza ancora una nuova data, per la riprogrammazione a una data specifica — che va aggiornata anche nella data di inizio — e per la cancellazione.

L'errore comune qui non è tecnico ma organizzativo: la pagina viene aggiornata a parole («l'evento è stato annullato», scritto in cima al testo) mentre il markup continua a dichiarare l'evento come attivo, con la data originale. Un aggregatore che legge solo il dato strutturato, senza rirenderizzare la pagina, continua a trattarlo come valido. La regola pratica è semplice: ogni volta che cambia il testo visibile sullo stato dell'evento, deve cambiare nello stesso momento anche il markup — non in un secondo passaggio, non «quando si ha tempo».

Eventi ricorrenti: una pagina per ogni occorrenza

Un corso settimanale, un webinar mensile, una serie di spettacoli: la tentazione è avere un'unica pagina che si riscrive ogni volta con la data della prossima sessione. Funziona per chi arriva oggi, ma rompe silenziosamente tutto ciò che punta a quella pagina da prima — un link condiviso su un gruppo, una pagina già indicizzata, un segnalibro salvato da qualcuno che intendeva riferirsi a quella sessione specifica, non a «qualunque sessione sia attiva adesso».

La pratica più solida è dare a ogni occorrenza una propria URL e un proprio markup Event, anche quando il contenuto editoriale è quasi identico da una sessione all'altra. Una pagina serie può restare come punto di ingresso che elenca le occorrenze e rimanda a ciascuna, ma non dovrebbe sostituire il markup per singola occorrenza: è la sessione specifica, con la sua data precisa, quella a cui un motore di ricerca e un utente vogliono davvero arrivare.

Il problema del ciclo di vita, e come non farsi trovare impreparati

Questo è, in pratica, il punto che decide se un'implementazione Event invecchia bene o male. Una pagina evento è corretta per poche settimane — dalla pubblicazione fino alla data dell'evento — e sbagliata per sempre dopo. Non esiste una configurazione tecnica che eviti questo: esiste solo una decisione presa in anticipo su cosa succede quando la data passa.

Il fallimento più comune, di gran lunga, è non scegliere nessuna delle tre opzioni: la pagina resta online con la data di inizio nel passato e lo stato ancora su «programmato», silenziosamente sbagliata, indicizzata, visibile a chiunque cerchi quell'evento mesi dopo che si è già svolto. Prima di pubblicare vale comunque la pena validare il markup con uno strumento dedicato — non tanto per la sintassi, quanto per i campi obbligatori mancanti su un evento con molte proprietà annidate — ma la validazione sintattica copre solo metà del lavoro: l'altra metà è mantenere il markup e il testo visibile allineati nel tempo, perché un motore di ricerca che nota ripetute discrepanze tra dato strutturato e contenuto reale tende a perdere fiducia non solo in quella pagina, ma nell'affidabilità del markup dell'intero sito.

• Archiviare la pagina con un'inquadratura esplicita di evento passato — titolo, testo e markup coerenti nel dichiararlo già concluso — utile quando l'evento ha valore editoriale duraturo: un recap, delle foto, una registrazione.
• Reindirizzare alla prossima occorrenza, quando l'evento è ricorrente e la pagina passata non ha valore autonomo una volta conclusa la sessione.
• Mantenere una pagina serie permanente, distinta dalle singole occorrenze, come punto di riferimento stabile che non scade mai perché non dichiara mai una data specifica come propria.