Chiedi a un assistente IA di consigliarti una società di consulenza, spiegare un prodotto o confrontare due aziende. La risposta può sembrare fluire senza sforzo. Compaiono i nomi, seguono le descrizioni e qualche fonte dà all’insieme un’aria rassicurante di certezza.

Ma sotto tutta quella scrittura scorrevole c’è una domanda: di quale azienda, persona o prodotto sta effettivamente parlando la risposta?

Un nome familiare non basta sempre. Due aziende possono avere lo stesso nome. Un autore può comparire con diverse versioni del proprio nome. Un servizio può sembrare un prodotto software. E un sito web può descrivere tutti e tre senza spiegare come siano collegati.

È qui che le entità diventano utili per la GEO, o Generative Engine Optimisation: il lavoro volto a migliorare il modo in cui i tuoi contenuti e la tua attività compaiono nelle risposte generate dall’IA.

L’aspetto interessante non è aggiungere un altro strato di gergo alla SEO. È rendere la tua identità più facile da distinguere, le tue affermazioni più facili da verificare e le tue relazioni più facili da seguire.

Ecco cosa voglio approfondire:

  1. Che cos’è davvero un’entità.
  2. Perché i sistemi di IA traggono vantaggio da identità chiare.
  3. Quale contributo danno Schema.org e JSON-LD.
  4. Qual è il ruolo di Wikidata e quali sono i suoi limiti.
  5. Come tradurre tutto questo in interventi utili su un sito web reale.
Cinque tipi di entità collegati attorno a un’organizzazione immaginaria
Un’entità diventa riconoscibile attraverso i suoi attributi e le sue relazioni, non soltanto grazie al nome.

1. Un’entità è una cosa specifica, non soltanto un’espressione

Pensa a un’entità come a qualcosa che puoi identificare in modo univoco e descrivere attraverso attributi e relazioni.

Un’organizzazione ha un nome, un sito web e forse una sede. Una persona ha un ruolo professionale e affiliazioni. Un prodotto ha un produttore e specifiche. Un luogo ha una posizione geografica. Un concetto ha un significato e collegamenti con altri concetti.

Sono le cinque famiglie illustrate nella slide della conferenza che ha ispirato questo articolo: organizzazioni, persone, prodotti, concetti e luoghi. Anche i servizi fanno parte del quadro, sebbene la loro descrizione debba rispecchiare ciò che sono realmente.

Prendiamo una società di consulenza immaginaria chiamata Northstar Analytics. Il suo fondatore, Alex Morgan, è un’entità. La società di consulenza è un’altra. Il suo servizio di audit GEO è una terza. Barcellona, dove ha sede, è un’altra ancora.

Puoi inserire questi nomi in una pagina. Oppure puoi spiegare le relazioni: Alex lavora per Northstar; Northstar fornisce l’audit; l’azienda ha sede a Barcellona.

La seconda versione dice molto di più a chi legge. Fornisce anche materiale più chiaro a un sistema che cerca di collegare i fatti.

Questa distinzione conta quando si passa dalla corrispondenza tra parole all’identificazione di ciò a cui quelle parole si riferiscono.

2. Perché questo conta quando la risposta viene generata

Una risposta dell’IA su un’azienda deve mantenere chiaro il soggetto. Se mescola due aziende con lo stesso nome, anche una spiegazione elegante diventa inaffidabile.

La complicazione è che «l’IA» raramente consiste in un unico meccanismo semplice. A seconda del prodotto e della domanda, una risposta può attingere alle conoscenze del modello, a pagine recuperate, a risultati di ricerca o ad altre informazioni collegate. Questi percorsi non elaborano tutti i siti web nello stesso modo.

Gli LLM possono riconoscere le entità nominate nel testo ordinario, come dimostra la ricerca sul riconoscimento delle entità nominate. Riconoscere un nome e determinare a quale entità del mondo reale si riferisca sono compiti diversi. Un modello non ha sempre bisogno di una voce Wikidata o di un blocco JSON-LD per riconoscere un’azienda. Affermare il contrario significherebbe attribuire alla tecnologia più di quanto sia giustificato.

La mia deduzione pratica è più circoscritta: rendere esplicite l’identità e le relazioni riduce l’ambiguità del materiale disponibile per questi sistemi. Resta da verificare se un determinato prodotto usi quel materiale e se la risposta risultante migliori.

Sul sito di Northstar, «aiutiamo i brand ambiziosi a vincere» lascia senza risposta gran parte delle domande utili. «Northstar Analytics è una società di consulenza con sede a Barcellona che offre servizi di analisi dei dati e audit GEO» dà sia ai lettori sia alle macchine qualcosa di più concreto.

Lo stesso principio si applica alla pagina di un autore. Dai ad Alex una biografia reale, un ruolo definito e collegamenti ai suoi lavori. Un nome sotto un articolo è un punto di partenza; un’identità professionale collegata al resto delle informazioni è più informativa.

C’è anche un vantaggio editoriale. Descrivere chiaramente l’entità spesso mette in luce il posizionamento vago che si nascondeva dietro il linguaggio del marketing.

Immagina una domanda di confronto: «Quali società di consulenza a Barcellona offrono audit GEO e chi ne dirige il lavoro?». Una pagina che collega chiaramente l’organizzazione, il servizio, la sede e l’esperto contiene gli elementi per una risposta pertinente. Una pagina che contiene queste quattro parole in qualche punto del testo può comunque lasciare poco chiaro il rapporto tra loro. Questo non garantisce che venga selezionata, ma spiega perché il lavoro sulle entità sia utile prima di iniziare a misurarne gli effetti.

3. Schema.org fornisce il vocabolario. JSON-LD lo veicola

Questi due nomi vengono spesso citati insieme, ma svolgono funzioni diverse.

Schema.org fornisce termini condivisi per descrivere cose e relazioni: Organization, Person, Service, Article, author, publisher e molti altri. JSON-LD è un formato per esprimere dati collegati, comunemente inserito in una pagina web all’interno di un blocco script. L’introduzione di Schema.org e lo standard JSON-LD del W3C spiegano la distinzione.

Stai rendendo il significato più esplicito. Questa è un’organizzazione. Questa persona lavora per essa. Questo servizio ha quell’organizzazione come fornitore.

Esiste un utilizzo documentato nella ricerca: Google afferma che i dati strutturati lo aiutano a comprendere il contenuto delle pagine e la sua documentazione sulle organizzazioni descrive specificamente la disambiguazione delle aziende. Questo sostiene l’utilità di un’identità più chiara; non dimostra un aumento universale delle citazioni nelle risposte dell’IA. L’introduzione di Google ai dati strutturati e le indicazioni sulle organizzazioni.

Un grafo illustrativo di un sito web che collega un’organizzazione, una persona, un servizio, un articolo e un luogo
Il valore sta nell’accuratezza dei collegamenti. Le frecce descrivono relazioni, non una sequenza che garantisce visibilità.

Per Northstar, un piccolo grafo JSON-LD potrebbe essere così:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://northstar.example/#organisation",
      "name": "Northstar Analytics",
      "url": "https://northstar.example/"
    },
    {
      "@type": "Person",
      "@id": "https://northstar.example/team/alex/#person",
      "name": "Alex Morgan",
      "worksFor": {
        "@id": "https://northstar.example/#organisation"
      }
    }
  ]
}

Esempio immaginario che usa un dominio riservato agli esempi; adattalo ai fatti descritti in modo visibile nella pagina pertinente.

L’organizzazione riceve un @id stabile. La persona fa riferimento a quell’identificatore tramite worksFor. Le due descrizioni sono collegate invece di restare separate. Un @graph può raggruppare i nodi, mentre gli identificatori permettono loro di fare riferimento gli uni agli altri. Il W3C sugli identificatori dei nodi.

Usa lo stesso identificatore dell’organizzazione in modo coerente quando altre pagine fanno riferimento a quell’azienda. Un servizio può collegarsi tramite provider; un articolo può collegarsi tramite author e publisher. Scegli il tipo che descrive il soggetto, invece di quello che sembra più di moda.

4. Wikidata offre ad alcune entità un’identità pubblica condivisa

Il tuo sito web può descrivere la tua attività. Wikidata offre qualcosa di diverso: una base di conoscenza pubblica e collaborativa in cui un’entità può avere un identificatore condiviso tra lingue e descrizioni.

Gli elementi usano identificatori che iniziano con Q. Per esempio, Q312 identifica Apple Inc., anziché il frutto o un’altra azienda chiamata Apple.

Etichette, alias, descrizioni e dichiarazioni sono associati a quell’identificatore. Etichette in lingue diverse possono riferirsi allo stesso elemento, cosa utile quando un nome varia da un mercato all’altro. Wikidata registra anche riferimenti e collegamenti ad altre banche dati. L’introduzione di Wikidata.

Questo lo rende un utile riferimento per l’identità quando l’elemento è accurato e descrive davvero l’entità in questione. Non significa che ogni assistente IA consulti Wikidata per ogni risposta, né che un elemento faccia automaticamente consigliare il suo soggetto.

Per un sito web multilingue, questa distinzione è particolarmente pratica. Una pagina in inglese e una in spagnolo possono descrivere la stessa organizzazione con formulazioni diverse mantenendo lo stesso riferimento per l’identità. Servono comunque traduzioni accurate e fatti coerenti. L’identificatore aiuta a dire «si tratta dello stesso soggetto»; non traduce il testo né dimostra che le affermazioni circostanti siano vere.

C’è un altro limite che merita più attenzione: Wikidata è un progetto di conoscenza della comunità, non un elenco commerciale promozionale.

Un’entità non deve necessariamente avere una voce Wikipedia per essere ammissibile. La politica sulla rilevanza prevede anche criteri basati su fonti pubbliche autorevoli o su un’esigenza strutturale. Ma l’ammissibilità va valutata alla luce di quelle regole; desiderare più visibilità nella GEO non dà diritto a un elemento. La politica di Wikidata sulla rilevanza.

Per una piccola società di consulenza, il punto di partenza sensato può essere semplicemente un sito chiaro, profili professionali accurati e una copertura esterna credibile. Se esiste già un elemento Wikidata adatto, verificalo. Se non esiste, stabilisci se crearlo sia utile alla base di conoscenza prima di pensare ai benefici di marketing. Le indicazioni di Wikidata mettono espressamente in guardia dal creare elementi a scopo promozionale. Aiuto sugli elementi.

5. Un identificatore locale e sameAs non sono intercambiabili

È una piccola distinzione tecnica con una grande conseguenza pratica.

Il tuo @id identifica un nodo nei dati del tuo sito web. Un collegamento sameAs rimanda a un’altra pagina che identifica senza ambiguità la stessa cosa. Schema.org include esplicitamente le voci Wikidata tra i suoi esempi. La definizione di sameAs.

Se stessi descrivendo Apple Inc., l’URL Wikidata verificato per Q312 potrebbe essere un riferimento per l’identità. Non sarebbe appropriato per Northstar Analytics soltanto perché la società di consulenza lavora con prodotti Apple.

Allo stesso modo, un articolo sulla GEO non è la stessa entità del concetto di GEO. Un fondatore non è la stessa entità della sua azienda. Un’associazione non rende identiche due cose.

Confronto tra identificatori locali stabili e riferimenti esterni che corrispondono esattamente all’identità
L’identificatore di Northstar e l’elemento Wikidata di Apple sono esempi separati. Illustrano due funzioni, non una corrispondenza di identità tra le aziende.

Usa una relazione adatta all’affermazione: author per la paternità di un contenuto, worksFor per il rapporto di lavoro o about per il soggetto di un’opera. Riserva sameAs all’identità.

La stessa attenzione vale per i nomi. Ragione sociale, nome commerciale e nome del brand tradotto possono legittimamente differire. Spiega come si collegano invece di costringere ogni etichetta a coincidere carattere per carattere.

Un blocco tecnicamente valido può comunque descrivere l’azienda sbagliata. Superare un validatore ti dice qualcosa sul codice; non certifica la verità di ogni dichiarazione che contiene.

6. Cosa cambierei davvero su un sito web

Inizierei dalle pagine visibili.

Un visitatore può capire chi possiede il sito, cosa offre l’azienda, chi scrive i suoi contenuti e dove opera? I servizi importanti sono descritti singolarmente? Le biografie degli autori spiegano l’esperienza pertinente senza gonfiarla?

Poi traccerei una piccola mappa di entità e relazioni. Per Northstar, significa l’organizzazione, le persone pertinenti, i servizi, gli articoli e la sede. Non richiede di aggiungere markup a ogni sostantivo in ogni pagina.

Segue l’implementazione: identificatori stabili, tipi e proprietà appropriati e riferimenti che collegano i nodi giusti. Controlla i plugin esistenti prima di aggiungere un altro blocco; due strumenti possono facilmente pubblicare descrizioni contrastanti della stessa azienda.

Il markup deve restare fedele al contenuto visibile. Non usarlo per inserire competenze, premi, recensioni o affiliazioni che la pagina non può documentare. Le norme di Google richiedono che i dati strutturati rappresentino accuratamente la pagina. Le linee guida sui dati strutturati.

Poi guarda oltre il sito web. Correggi i profili obsoleti, chiarisci le descrizioni ambigue e cerca riscontri credibili per le affermazioni che vuoi vengano riprese da altri. Ripetere una tua affermazione in dieci profili non equivale a una conferma indipendente.

Infine, controlla l’accesso e misura il risultato. I crawler pertinenti possono raggiungere le pagine? Il contenuto può essere recuperato? Quando provi delle domande, la risposta identifica l’azienda giusta e le attribuisce i servizi e le persone corretti?

Un ciclo in quattro fasi per identificare, collegare, verificare e misurare le entità
Mantieni collegati i controlli sull’implementazione e quelli sulle risposte. Nessuno dei due sostituisce l’altro.

Monitora separatamente le menzioni, le citazioni con link e l’accuratezza dei fatti. Un brand può essere nominato senza essere citato oppure citato con una descrizione errata. Registra i prompt, la lingua, la piattaforma, la data e le richieste non riuscite, così che il confronto abbia una base significativa.

Un cambiamento in un piccolo campione di test è un’osservazione, non una prova della visibilità complessiva sul mercato o di un effetto causale del JSON-LD. Altri cambiamenti nei contenuti, nel recupero delle informazioni e nella piattaforma stessa possono influire sul risultato.

7. Il mio punto di vista sulla promessa della GEO

Penso che il lavoro sulle entità meriti il suo posto quando rende un’azienda più facile da comprendere e le sue informazioni più facili da mantenere.

È una ragione solida per investirci. L’argomento più debole è che aggiungere schema e un identificatore Wikidata dia accesso a un sistema di raccomandazioni dell’IA.

Google è particolarmente chiaro su questo punto per le proprie funzionalità di ricerca basate sull’IA: non è richiesto alcun markup Schema.org speciale per comparirvi. Le sue indicazioni continuano a concentrarsi sulle basi consolidate della SEO e su contenuti utili e accessibili. Questa è un’affermazione sulle funzionalità di Google, non su ogni prodotto di IA. Le indicazioni di Google sulle funzionalità di IA.

Wikidata può fornire un prezioso riferimento pubblico. JSON-LD con il vocabolario Schema.org può esprimere una descrizione coerente sul tuo sito. Nessuno dei due crea competenza, riscontri indipendenti o una risposta utile quando questi elementi mancano.

Quindi formulerei l’obiettivo così: rendere facile identificare l’entità giusta, capire cosa fa e verificare perché merita di essere inclusa nella risposta. Poi verificare se i sistemi che ti interessano usano effettivamente quelle informazioni.

È meno spettacolare di una scorciatoia GEO garantita. È anche una base molto più difendibile per questo lavoro.

TL;DR: i punti chiave

  • La risposta potrebbe confonderti con qualcun altro? Chiarisci l’entità attraverso nomi, attributi e relazioni.
  • I tuoi dati strutturati descrivono i fatti visibili? Collega i nodi giusti con identificatori stabili e proprietà appropriate.
  • Wikidata è il riferimento giusto? Usa un elemento esatto e verificato quando pertinente; valuta l’ammissibilità prima di creare qualsiasi cosa.
  • La visibilità è migliorata? Verifica menzioni, citazioni e accuratezza, invece di considerare il markup valido come il risultato finale.