# Il vocabolario su cui le macchine si sono messe d'accordo Tema: [Sito leggibile dalle macchine](https://btlabs.dev/it/sito-web-ia) > Schema.org è un dizionario, non un formato. Perché non puoi inventare una proprietà — e perché l'annotazione può dire solo ciò che la pagina mostra. Vent'anni fa, nello sviluppo web, si discuteva se una pagina andasse costruita con le tabelle o con i fogli di stile. All'epoca sembrava una discussione importante. In fondo riguardava l'aspetto delle cose. La questione di oggi è un'altra, ed è più vecchia del web: come chiamiamo le cose, perché un altro capisca che cosa intendiamo? ## Un dizionario, non un formato Quasi tutte le spiegazioni di Schema.org partono dal formato — il blocco di codice, dove va, quale sintassi. È la parte meno interessante, ed è il motivo per cui tante implementazioni risultano tecnicamente corrette e praticamente inutili. Schema.org è un **dizionario**. Un elenco pubblico e limitato di cose che possono esistere — una persona, un luogo, un orario di apertura, un annuncio di lavoro, una ricetta — e delle proprietà che quelle cose possono avere. I motori di ricerca si sono messi d'accordo per non doversi costruire ognuno il proprio lessico. Tutta qui, l'idea. Il lavoro vero non è quindi scrivere il blocco. È scegliere la parola giusta da un elenco scritto da qualcun altro. ## L'elenco è finito, ed è proprio questo il punto La frase più difficile da accettare è questa: **non puoi inventare una proprietà.** Se un'azienda ha qualcosa di davvero particolare — una certificazione che non ha nessun altro, un servizio che non rientra in nessuna categoria esistente — la tentazione è inventarsi un nome e annotarlo lo stesso. Sembra innocuo. Il blocco resta valido. Nessuno segnala un errore. Ma una proprietà inventata è una parola in una lingua che nessuno parla. Nessun lettore dall'altra parte la legge, perché nessuno è stato costruito per cercarla. Hai scritto qualcosa di vero in un punto in cui non può essere sentito. L'alternativa onesta: lasciarla fuori e metterla nel testo visibile — lì la trova una persona, e lì la trova anche un modello linguistico che legge il testo corrente. ## La regola che applichiamo a noi stessi Abbiamo una regola di lavoro, più severa di quanto lo standard richieda: **su ogni campo deve essere stata presa una decisione.** O ottiene una proprietà vera, o esiste un motivo scritto per cui non l'ha. «Nessuno spazio nel vocabolario» è un motivo valido. Inventare non lo è. Questa regola esiste perché l'alternativa è peggio dell'incompletezza. Un vocabolario rispettato a metà produce annotazioni che sembrano accurate e sono silenziosamente sbagliate — e un'annotazione sbagliata è più difficile da trovare di una mancante, perché nulla protesta. ## Annotato non vuol dire vero La seconda regola viene direttamente da Google, ed è quella infranta più spesso: si può annotare solo ciò che è **visibile** sulla pagina. Nella [documentazione sui dati strutturati](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=it) Google lo scrive senza margini: «Don't add structured data about information that is not visible to the user, even if the information is accurate.» Rileggi l'ultima parte. **Anche se l'informazione è corretta.** Non puoi annotare un dato vero che la pagina visibile non riporta. Non perché ingannerebbe un lettore, ma perché un'annotazione è un'affermazione sulla pagina — non sul mondo. È qui che sbagliano le implementazioni meglio intenzionate. Qualcuno sa che l'azienda chiude alle 18, sulla pagina c'è scritto 17, e nell'annotazione finisce il valore «giusto». Ora i due si contraddicono, e la macchina crede a quello dichiarato. ## Che cosa ne consegue in pratica Tre conseguenze, nessuna tecnica: **Prima il tipo, poi le proprietà.** Che genere di cosa è la tua attività decide quali proprietà hai a disposizione. Ne ho scritto separatamente — [Che cosa sei, per una macchina?](https://btlabs.dev/it/posts/che-cosa-sei-per-una-macchina) — perché è la decisione che viene per prima e si prende per ultima. **Generare, non curare.** Se l'annotazione è scritta a mano, è una copia della pagina, e le copie divergono. Se nasce dagli stessi dati da cui si costruisce la pagina visibile, le due non possono contraddirsi: non c'è un secondo posto in cui farlo. **Pochi dati che sono corretti battono molti scritti una volta sola.** Non è modestia. Un'annotazione superata è attivamente peggiore di una mancante: fa un'affermazione sicura di sé che per caso è falsa. ## Un errore tipico, spiegato fino in fondo Prendiamo un albergo con ristorante che non compare mai quando si cerca un posto dove mangiare lì vicino. L'annotazione c'è. L'ha scritta una persona competente. E dice, nei termini del vocabolario: albergo. Non c'è nulla di falso. L'attività è davvero un albergo. Solo che una macchina a cui arriva la domanda «dove posso mangiare stasera» cerca cose che sono ristoranti, e questa si è dichiarata un'altra cosa. In modo corretto, e inutile. La correzione richiede un minuto: dichiarare entrambi, e mettere il ristorante per primo nelle pagine che parlano del ristorante. Nessun contenuto nuovo, nessuna ristrutturazione. Cambia solo una decisione su quale parola sta davanti. Qui si vede uno schema. Non annotazione mancante, non sintassi rotta — un'affermazione vera che risponde a una domanda diversa da quella posta. ## Come capire se la tua vale qualcosa Tre domande, per nessuna delle quali serve leggere codice: 1. **Il tipo dichiarato corrisponde alla domanda per cui vuoi essere trovato?** Non alla domanda che faresti tu: a quella che fa il tuo cliente. 2. **Ogni valore dichiarato compare anche nel testo visibile?** Se no, uno dei due è sbagliato, e da fuori non si capisce quale. 3. **Quand'è cambiata l'ultima volta?** Se la risposta è «quando il sito è stato costruito», descrive un'azienda che esisteva allora. La terza domanda è quella che coglie in fallo quasi tutti. Un'annotazione non si guasta in modo visibile. Semplicemente smette di essere vera, in silenzio, un dettaglio alla volta. ## Che cosa non sto affermando Non credo che l'annotazione da sola migliori i posizionamenti. Non esiste una prova solida, e chi ne promette una mi insospettisce. Quello che fa è più ristretto e più utile: toglie di mezzo l'indovinare. Una macchina che trova un orario dichiarato non deve analizzare una frase e sperare. Non è un fattore di ranking — rende più probabile essere citati correttamente che all'incirca. E per le domande in cui «all'incirca giusto» equivale a «sbagliato» — quando sei aperto, quanto chiedi, se copri una certa valle — quella differenza è tutto. Che cosa siano i dati strutturati in generale sta in [Dati strutturati](https://btlabs.dev/it/glossary/dati-strutturati); quali informazioni contino per prime, in [Quali informazioni deve poter leggere una macchina sulla tua azienda](https://btlabs.dev/it/posts/quali-dati-strutturati-inserire). --- Source: https://btlabs.dev/it/posts/vocabolario-schema-org Last-Modified: 2026-10-05T07:00:01.938Z Languages: [de](https://btlabs.dev/llms/de/posts/schema-org-vokabular) · [en](https://btlabs.dev/llms/en/posts/schema-org-vocabulary-explained) See also: [llms.txt](https://btlabs.dev/llms.txt) · [ai.txt (Policy)](https://btlabs.dev/ai.txt) · [identity.json](https://btlabs.dev/identity.json)