Wikidata e il Google Knowledge Graph: il livello delle entità dietro i Knowledge Panel e le risposte dell'IA

La maggior parte delle persone che ci chiedono di «entrare nel Google Knowledge Panel» o di «apparire correttamente in ChatGPT» pensa di stare facendo una domanda sui contenuti. Non è così. Stanno chiedendo delle entità — se le macchine che alimentano la ricerca e l'IA riconoscono la loro azienda, il loro fondatore o il loro prodotto come qualcosa di distinto nel mondo, con un'identità stabile e un insieme noto di fatti.

Questo livello di riconoscimento ha un nome. Anzi, ha diversi nomi, e la maggior parte delle persone li usa in modo intercambiabile quando invece significano cose molto diverse. Wikipedia non è Wikidata. Wikidata non è il Google Knowledge Graph. E nessuno di essi è un Knowledge Panel garantito.

Questo articolo chiarisce tutto questo. È la spiegazione che inviamo ai clienti che arrivano convinti di aver bisogno di un articolo Wikipedia quando quello di cui hanno davvero bisogno — almeno in prima battuta — è un'entità Wikidata pulita. È onesto su cosa può fare il livello delle entità ed esplicito su cosa non può fare.

Tre cose diverse, chiaramente definite

Separiamo i tre sistemi che vengono spesso confusi, perché quasi tutti gli errori successivi derivano dalla confusione tra di essi.

Wikipedia è un'enciclopedia. È prosa — articoli scritti da esseri umani, paragrafi, riferimenti, punto di vista neutrale. Per avere un articolo su Wikipedia, un soggetto deve superare la notability (Wikipedia:Notability — il criterio di ammissibilità che richiede una copertura significativa in fonti secondarie indipendenti e affidabili): la copertura significativa in fonti secondarie indipendenti e affidabili. Il livello è alto e continua ad alzarsi. La maggior parte delle aziende non si qualifica, e questo è intenzionale. Wikipedia è per i soggetti su cui il mondo ha già scritto ampiamente.

Wikidata è un database strutturato. Non è prosa; sono fatti in un formato leggibile dalle macchine. Dove Wikipedia ha un articolo sulla Torre Eiffel, Wikidata ha un item — un record con un identificatore (Q243) e un elenco di affermazioni: è un'istanza di «torre», si trova a Parigi, è stata progettata da Gustave Eiffel, la sua altezza è 330 metri, e così via. Ognuno di questi fatti è una coppia proprietà-valore, idealmente supportata da un riferimento. Wikidata è un progetto gemello di Wikipedia, gestito dalla stessa Wikimedia Foundation, ma è qualcosa di fondamentalmente diverso — e, cosa cruciale, ha un livello di inclusione più basso. Ne parliamo più avanti.

Il Google Knowledge Graph è il database privato di Google sulle entità e le relazioni tra di esse. È stato lanciato nel 2012 con la frase «things, not strings» (cose, non stringhe di testo) — Google ha smesso di trattare «Apple» come una stringa di cinque lettere e ha iniziato a trattarla come un'entità che poteva essere il frutto, l'azienda o l'etichetta discografica, ciascuna con i propri fatti e connessioni. Il Knowledge Graph alimenta il Knowledge Panel (il riquadro a destra di un risultato di ricerca) e la comprensione delle entità in tutti i prodotti Google. È alimentato da Wikipedia e Wikidata, tra molte altre fonti — ma Google lo possiede, lo controlla, e non è possibile modificarlo direttamente.

Ecco la relazione in una sola frase: Wikipedia e Wikidata sono fonti aperte, pubbliche e modificabili che Google ingloba nel proprio Knowledge Graph proprietario, che utilizza poi (a propria discrezione) per visualizzare i Knowledge Panel e informare le risposte dell'IA.

Confondere questi tre sistemi porta a errori prevedibili. Le persone cercano di «modificare il proprio Knowledge Panel» direttamente — non si può; è possibile solo rivendicarlo e suggerire modifiche. Le persone assumono che un item Wikidata produrrà un articolo Wikipedia — non è così; sono processi separati con soglie separate. E le persone assumono che tutto ciò garantisca un pannello — non è così; Google prende sempre la decisione finale.

Come i dati strutturati alimentano Google e gli LLM

Per capire perché Wikidata ha un peso specifico così elevato, bisogna capire come è costruito — perché la struttura è esattamente ciò che le macchine cercano.

Ogni item Wikidata ha un QID, un identificatore unico come Q95 (Google), Q312 (Apple Inc.) o Q42 (Douglas Adams). Il QID è l'indirizzo permanente dell'entità. Non cambia mai anche se l'etichetta cambia, ed è indipendente dalla lingua — Q42 è Douglas Adams sia che l'interfaccia sia in inglese, in giapponese o in arabo. Questa è la cosa più importante che fornisce Wikidata: un identificatore stabile e inequivocabile per una cosa.

Sul QID si trovano statements (affermazioni), costruiti da properties (proprietà) e values (valori). Le proprietà sono a loro volta identificate (P31 è «instance of» — istanza di, P159 è «headquarters location» — sede, P1448 è «official name» — nome ufficiale, P856 è «official website» — sito web ufficiale). Quindi il fatto «Apple Inc. ha sede a Cupertino» è memorizzato come Q312 → P159 → Q190080 (Cupertino). Le macchine non devono analizzare una frase; leggono una tripla.

Questo è rilevante per due categorie di utilizzatori:

• Google. Il Knowledge Graph è esso stesso un grafo di entità e triple. Il formato di Wikidata si mappa quasi direttamente su di esso, ed è per questo che Google ingloba Wikidata su larga scala e per cui un item Wikidata ben costruito è uno dei segnali più chiari che si possano inviare sull'identità, il tipo e gli attributi fondamentali di un'entità. Google si affida anche a Wikidata per la disambiguazione — per distinguere la vostra azienda dalle cinque altre aziende con un nome simile.
• I modelli linguistici di grandi dimensioni (LLM — Large Language Model). Quando un LLM risponde a «chi ha fondato [azienda]» o «dove ha sede [azienda]», sta attingendo a pattern nei suoi dati di addestramento. Wikipedia è la fonte testuale più pesantemente ponderata nella maggior parte dei corpora di addestramento, e Wikidata appare sempre più nei dataset strutturati usati per il grounding, il retrieval e le ricerche in knowledge base. Un'entità coerente e ben referenziata è molto più probabilmente rappresentata correttamente — e molto meno probabilmente confusa con un'entità dal nome simile — rispetto a una che esiste solo come menzioni sparse e non strutturate sul web aperto.

Questa è la versione onesta della «visibilità nell'IA», ed è il fondamento del lavoro SEO basato sulle entità e sul Knowledge Graph: non si iniettano contenuti in ChatGPT o Gemini. Nessuno può farlo. Quello che si può fare è costruire un'infrastruttura pulita, leggibile dalle macchine e ben referenziata che aumenti la probabilità che le macchine descrivano accuratamente la vostra entità. Abbiamo scritto di più su questa distinzione nel nostro lavoro sulla visibilità nell'IA — la leva è la qualità delle fonti e i dati strutturati, non la manipolazione dei prompt.

La soglia di notability più bassa di Wikidata

Ecco la parte che la maggior parte delle persone non conosce, e quella che amplia il numero di chi può davvero beneficiarne.

Wikipedia richiede la notability (Wikipedia:Notability) — il soggetto deve essere abbastanza noto da essere stato coperto in profondità da fonti indipendenti. Wikidata richiede qualcosa di molto più debole: grossomodo, l'esistenza verificabile e l'identificabilità, più o un sitelink a una pagina Wikimedia esistente, o un riferimento a una fonte esterna seria, o la necessità strutturale di descrivere altri item.

Rileggete, perché la differenza è il punto centrale. Wikipedia chiede «questo soggetto è abbastanza importante che il mondo ne abbia scritto?» Wikidata chiede «possiamo verificare che questa cosa esiste e indicare una fonte che lo confermi?» Sono soglie completamente diverse.

In pratica questo significa che un'azienda di medie dimensioni che verrebbe rifiutata da Wikipedia — non abbastanza copertura indipendente in profondità — può spesso avere un item Wikidata perfettamente legittimo, a condizione che la sua esistenza e i fatti fondamentali siano verificabili attraverso riferimenti credibili: un'iscrizione al registro delle imprese, un deposito regolatorio, un archivio di autorità, database esterni consolidati. L'item non renderà l'azienda famosa né creerà notability artificialmente. Ma fornisce all'entità un QID, un'identità stabile e un insieme di fatti leggibili dalle macchine che il Knowledge Graph e gli LLM possono leggere.

Alcune avvertenze oneste affinché nessuno interpreti male questo punto:

• «Soglia più bassa» non significa «nessuna soglia». Wikidata ha comunque linee guida sulla notability (WP:NCORP — la politica che si applica anche a Wikidata per le organizzazioni), e gli item per soggetti non notevoli senza riferimenti seri vengono eliminati. Non è possibile creare un item per una società di consulenza individuale con zero presenza esterna e aspettarsi che sopravviva.
• Wikidata non è uno spazio promozionale. È un database fattuale. Non c'è spazio per il linguaggio di marketing, e non dovrebbe esserci.
• Un item Wikidata da solo è un segnale più debole rispetto a un articolo Wikipedia. È una fondazione, non un traguardo.

Ma per una larga fascia di aziende e individui che sono reali e verificabili ma non ancora «Wikipedia-notevoli», Wikidata è il passo a livello delle entità che è effettivamente raggiungibile oggi. Ecco perché lo raccomandiamo così spesso come primo passo.

Anatomia di un Google Knowledge Panel

Quando appare un Knowledge Panel, i suoi campi sono assemblati da più fonti. Nessuna singola fonte «possiede» il pannello. Capire quale campo tende a provenire da dove aiuta a capire cosa vale la pena correggere — e dove Wikidata ha davvero una leva.

La tabella seguente è una guida generale, non un contratto. Google mescola le fonti, le sovrascrive e modifica il comportamento nel tempo. Trattatela come «da dove proviene solitamente questo campo», non «da dove proviene sempre».

Due conclusioni. Prima: il pannello è un composito — migliorare una fonte migliora uno spicchio. Se la vostra descrizione è sbagliata, di solito è un problema dell'introduzione di Wikipedia; se l'indirizzo è sbagliato, è un problema di Google Business Profile; se la data di fondazione o il tipo di entità è sbagliato, è spesso un problema di Wikidata. Seconda: se il pannello appare è una decisione di Google, guidata principalmente dalla fiducia di Google che l'entità sia reale, distinta e abbastanza notevole da meritare un pannello. Wikidata e Wikipedia aumentano questa fiducia. Non impongono il risultato.

Basi di SEO per entità: sameAs, schema e archivi di autorità

Wikidata non opera in isolamento. Si trova all'interno di una rete più ampia di segnali di identità, e più di essi concordano tra loro, più con confidenza un motore di ricerca può risolvere la vostra entità. L'idea centrale è la corroborazione: gli stessi fatti, gli stessi identificatori, che puntano alla stessa cosa da più luoghi indipendenti.

I mattoni pratici:

• Dati strutturati schema.org sul vostro sito. Marcando la homepage o la pagina «chi siamo» con lo schema Organization o Person (in JSON-LD) si dice direttamente a Google quale entità rappresenta il sito — il suo nome, logo, data di fondazione e persone chiave. Questa è l'unica parte del livello delle entità che controllate completamente, su un'infrastruttura di vostra proprietà.
• La proprietà sameAs. All'interno di quel markup dello schema, sameAs è un array di URL che puntano ad altre rappresentazioni autorevoli della stessa entità — il vostro articolo Wikipedia, il vostro item Wikidata, i vostri profili social verificati, la vostra voce su Crunchbase o in un database di settore. sameAs è, in effetti, il modo in cui dite a Google «tutto questo si riferisce alla stessa cosa». È il tessuto connettivo tra il vostro sito di proprietà e il grafo aperto delle entità.
• Archivi di autorità. Sono identificatori formali e istituzionali mantenuti da biblioteche, enti di standardizzazione e registri. Sono la prova esterna che un'istituzione riconosciuta ha catalogato la vostra entità. I più comuni:

Wikidata è il luogo in cui molti di questi convergono: un item ben costruito si collega a VIAF, ISNI, ORCID, LEI, GRID/ROR e altri tramite proprietà dedicate. Questo trasforma l'item Wikidata in un hub — un unico luogo in cui una macchina può confermare che «questo QID» equivale a «questo LEI» equivale a «questo ORCID» equivale a «questo articolo Wikipedia». Ogni identificatore corrispondente è un ulteriore voto che l'entità è reale e singola.

Non avete bisogno di tutti questi identificatori. Un istituto di ricerca dovrebbe avere GRID/ROR; una società quotata in borsa dovrebbe avere un LEI; un accademico individuale dovrebbe avere ORCID. Il punto non è collezionare distintivi — è che gli identificatori per cui si è legittimamente qualificati dovrebbero essere presenti e coerenti, in modo che l'intero grafo concordi con se stesso.

Modalità di fallimento comuni

La maggior parte degli item Wikidata che non fanno nulla di utile fallisce per un piccolo numero di ragioni ricorrenti. Ne vediamo sempre le stesse.

• Item orfani. L'item esiste ma niente vi punta e non punta a niente. È un record isolato senza relazioni. Il Knowledge Graph è un grafo — le entità traggono significato dalle loro connessioni. Un item senza link in entrata o in uscita verso altre entità è quasi invisibile per i sistemi che consumano Wikidata.
• Riferimenti mancanti. Le affermazioni senza fonti sono deboli e soggette a cancellazione. «Sede: Berlino» senza riferimento è un'asserzione; «Sede: Berlino» citando un registro delle imprese è un fatto. Gli item non referenziati vengono segnalati, e le affermazioni non referenziate vengono eliminate o ignorate dai consumatori downstream più cauti.
• Nessun sitelink in inglese (o nessun sitelink in assoluto). Un sitelink collega l'item Wikidata a un articolo Wikipedia in una determinata lingua. Molte integrazioni di alto valore e gran parte della fiducia di Google si basano sul collegamento in lingua inglese. Un item senza sitelink a nessuna edizione Wikipedia è più debole e più difficile da considerare attendibile per i sistemi. (Questo è anche il motivo per cui un item Wikidata non è un sostituto di un articolo Wikipedia quando questo è ottenibile.)
• Entità ambigue o duplicate. Due item per la stessa azienda. Un fondatore confuso con un atleta omonimo. Un prodotto unito all'item dell'azienda, o suddiviso quando non dovrebbe esserlo. I duplicati e l'ambiguità sono un veleno per la risoluzione delle entità — esattamente il problema che il sistema QID esiste per prevenire. Unire i duplicati e disambiguare le entità in conflitto è spesso il lavoro di pulizia di maggior valore su un item esistente.

Nessuna di queste è esotica. Sono la differenza tra un item che esiste e un item che funziona — e individuarle è la maggior parte di ciò in cui consiste il lavoro attento su Wikidata.

Tempi realistici, e cosa può e non può innescare un item pulito

Gestiamo le aspettative onestamente, perché è da qui che proviene la maggior parte delle delusioni.

Creare un item Wikidata ben costruito non è lento di per sé — l'item può essere pubblicato in un giorno. Ciò che richiede tempo è la propagazione downstream, e quella tempistica non è sotto il controllo di nessuno tranne Google.

• Creazione dell'item: da ore a un giorno per un item correttamente strutturato e referenziato.
• Indicizzazione e ingestione da parte di Google: tipicamente settimane. Google reingerisce Wikidata secondo il proprio calendario.
• Effetto visibile su un Knowledge Panel (se ne appare uno): da settimane a mesi, e solo se Google decide che l'entità merita un pannello.

Cosa può fare un item Wikidata pulito:

• Stabilire un QID stabile e un'identità leggibile dalle macchine per l'entità.
• Migliorare la disambiguazione — riducendo il rischio di essere confusi con un'entità dallo stesso nome.
• Contribuire fatti strutturati accurati (tipo di entità, fondatori, sede, sito ufficiale, identificatori) che Google e gli LLM possono leggere.
• Rafforzare il web sameAs collegando lo schema del vostro sito di proprietà a un hub esterno autorevole.
• Rendere più pulita la struttura dati di un futuro articolo Wikipedia.

Cosa non può fare un item Wikidata pulito:

• Garantire un Knowledge Panel. Google prende sempre la decisione finale, e molte entità perfettamente valide non ne ottengono mai uno.
• Creare notability. Registra fatti verificabili; non vi rende importanti, e non sostituirà la copertura indipendente richiesta da un articolo Wikipedia.
• Iniettare o controllare l'output dell'IA. Migliora le probabilità di una rappresentazione accurata. Non vi permette di dettare cosa dice un modello.
• Sovrascrivere i dati di Google Business Profile. Il vostro indirizzo, gli orari e le recensioni provengono da altrove.
• Sopravvivere se è promozionale o non referenziato. Wikidata è un database fattuale con editor e bot attivi; un item di bassa qualità viene eliminato.

Se un'agenzia vi dice che un item Wikidata garantirà un Knowledge Panel o controllerà come ChatGPT vi descrive, è lo stesso prodotto vapore di cui mettiamo in guardia ovunque. Il discorso onesto è probabilistico: un'infrastruttura di entità pulita aumenta la probabilità di una rappresentazione accurata e idonea. Non è un interruttore che si accende.

Quando Wikidata è il giusto primo passo

Wikidata è la mossa giusta per prima — prima di tentare un articolo Wikipedia completo — in un insieme riconoscibile di situazioni:

• Il soggetto è reale e verificabile ma non ancora «Wikipedia-notevole». Il caso più comune. C'è un'iscrizione al registro delle imprese, una presenza regolatoria, forse qualche copertura di settore, ma non le 3-5 coperture approfondite indipendenti di cui ha bisogno un articolo Wikipedia. Wikidata fornisce all'entità un'identità legittima leggibile dalle macchine ora, mentre si costruisce la base di fonti per Wikipedia in seguito.
• C'è un problema di confusione di entità. Google o un LLM vi sta confondendo con un'azienda, una persona o un prodotto dallo stesso nome. Un item pulito e disambiguato con gli identificatori giusti è spesso il rimedio più diretto.
• Volete la fondazione SEO per le entità in atto prima di una spinta maggiore. Il markup dello schema, sameAs e un hub Wikidata pulito sono il lavoro preparatorio su cui dovrebbe appoggiarsi un articolo Wikipedia — non un sostituto, ma il livello che rende tutto il resto più coerente.
• Non siete sicuri di qualificarvi per Wikipedia. È esattamente per questo che esiste un audit di notability Wikipedia. Se l'audit dice che le fonti supportano un articolo, ottimo — procedete con la creazione della pagina Wikipedia, con Wikidata come parte dello stesso flusso di lavoro. Se dice che le fonti sono insufficienti, Wikidata è il passo raggiungibile che fa comunque avanzare il livello delle entità mentre colmate il gap di copertura.

La logica di sequenziamento è semplice. Wikidata ha la soglia più bassa e il percorso più rapido verso un risultato legittimo, quindi è da dove dovrebbero iniziare i soggetti verificabili ma non ancora famosi. Wikipedia ha la soglia più alta e il segnale più forte, quindi è dove si va quando le fonti ci sono davvero. Tentare Wikipedia prima quando non si è qualificati spreca settimane e rischia una cancellazione che rende il tentativo successivo più difficile. Costruire prima Wikidata costa poco, aiuta comunque e non danneggia mai il caso Wikipedia.

Quello che non è è un trucco, una scorciatoia per la fama o un pannello garantito. È il livello delle entità — la fondazione inglamour, strutturata e ben referenziata che fa sì che le macchine vi descrivano accuratamente. Per molte aziende e individui, sistemare correttamente questo livello è allo stesso tempo il passo più raggiungibile e quello più trascurato nell'intera conversazione sulla visibilità nell'IA.

Non siete sicuri se la vostra entità dovrebbe iniziare con Wikidata o puntare direttamente a un articolo Wikipedia? Scriveteci a team@wikibusines.com e vi invieremo una valutazione onesta su quale passo si adatti davvero alla vostra situazione.