sameAs in Schema.org: come le macchine riconoscono chi o cosa intendi

Quando ho incontrato per la prima volta sameAs nei dati strutturati, la proprietà mi è sembrata piuttosto secondaria. Si inserisce LinkedIn, magari si aggiunge Instagram o un profilo autore, per poi tornare agli elementi del markup apparentemente più importanti.

In realtà, sameAs è meno marginale di quanto sembri.

Ogni URL inserito costituisce un’affermazione precisa: l’entità descritta dal nodo Schema è la stessa entità rappresentata a quell’altro indirizzo.

Non si tratta quindi di un semplice collegamento esterno né di un rimando a ulteriori informazioni. sameAs serve ad aiutare le macchine a collegare diverse rappresentazioni della stessa persona, organizzazione, marca, pubblicazione o cosa.

Questo può essere rilevante per Google e Bing, ma anche per knowledge graph, database, crawler e sistemi di ricerca basati sull’intelligenza artificiale. La proprietà non è però né un fattore di ranking garantito né un interruttore magico capace di far apparire improvvisamente una persona più spesso in ChatGPT o Perplexity.

Purtroppo la proprietà non si chiama pleaseUnderstandWhoIAm. Concettualmente, però, il suo compito è piuttosto simile.

Cosa significa davvero sameAs

Schema.org definisce sameAs come l’URL di una pagina di riferimento che consente di riconoscere senza ambiguità l’identità dell’elemento descritto. Tra gli esempi indicati compaiono una pagina Wikipedia, una voce Wikidata o un sito ufficiale. La proprietà appartiene a Thing e può quindi essere utilizzata, almeno in teoria, da tutti i tipi Schema.org derivati da esso.

Tra questi rientrano, ad esempio:

• Person
• Organization
• Brand
• Product
• Place
• Event
• CreativeWork

La disponibilità tecnica di una proprietà non significa che sia utile in ogni possibile situazione. La parte decisiva della definizione è facile da trascurare: la pagina indicata deve identificare l’entità senza ambiguità.

Un articolo di giornale può parlare dettagliatamente di una persona, indicarne la professione e includere diverse citazioni. Nonostante ciò, l’articolo normalmente non rappresenta l’identità della persona. È un documento su quella persona.

Un profilo autore ufficiale, un sito personale o un profilo LinkedIn chiaramente attribuibile rappresentano invece la persona in modo più diretto.

sameAs non dovrebbe quindi essere utilizzato per dire:

Questa pagina mi menziona.

L’affermazione corretta è piuttosto:

Questo URL rappresenta la stessa entità descritta nel nodo Schema.

Questa distinzione non è una semplice sottigliezza semantica. Quando una normale menzione viene indicata come sameAs, il markup afferma una relazione più forte di quella realmente esistente tra le pagine.

Perché le macchine hanno bisogno di aiuto per risolvere le identità

Le persone riconoscono spesso un’identità attraverso il contesto. Vediamo un nome, una fotografia, un datore di lavoro e una posizione professionale e riusciamo solitamente a capire di quale persona si stia parlando.

Una macchina riceve inizialmente diversi segnali separati:

• un nome,
• un URL,
• testo visibile,
• dati strutturati,
• collegamenti interni,
• profili esterni,
• citazioni su altri domini.

Questi segnali possono essere chiari, ma non è sempre così.

Più persone possono avere lo stesso nome. Un’azienda può essere indicata con il nome del marchio, la denominazione legale completa e varie abbreviazioni. Dopo un rebranding, le denominazioni vecchie e nuove possono continuare a circolare contemporaneamente sul web.

Il problema di fondo viene spesso chiamato entity resolution, ovvero risoluzione delle entità. Un sistema cerca di determinare se più dati, pagine o riferimenti descrivono la stessa persona, organizzazione o cosa reale.

sameAs offre un collegamento esplicito che può supportare questo processo. La proprietà non sostituisce tuttavia le altre informazioni. Nome, immagine, sito ufficiale, descrizione e dati coerenti nei diversi profili restano necessari per rendere plausibile l’associazione.

Un collegamento errato non diventa corretto soltanto perché è scritto in JSON-LD. I dati strutturati esprimono semplicemente l’affermazione in un formato più facile da elaborare per le macchine.

Il ruolo di sameAs per Google, Bing e i sistemi di intelligenza artificiale

Schema.org non è un formato esclusivamente destinato a Google. Il vocabolario è stato sviluppato per integrare informazioni strutturate nei siti web, in modo che motori di ricerca e altre applicazioni possano elaborare meglio contenuti e relazioni.

Google documenta diversi utilizzi concreti. Nel markup Organization, sameAs può puntare a profili esterni, compresi social network e piattaforme di recensioni. È possibile indicare più URL. Google descrive inoltre i dati strutturati relativi alle organizzazioni come un modo per comprendere meglio un’azienda e distinguerla da altre entità.

Per gli articoli, Google può utilizzare sia author.url sia author.sameAs per identificare con maggiore precisione un autore. Google consiglia inoltre il markup ProfilePage per le pagine autore interne.

Anche Bing elabora i dati strutturati e supporta Schema.org in JSON-LD. Microsoft descrive questi dati come informazioni che possono aiutare Bing a comprendere il contenuto e le relazioni presenti in una pagina. Microsoft mette inoltre in guardia dall’inserimento nel markup di informazioni false o ingannevoli che gli utenti non possono vedere.

Per i sistemi di ricerca e risposta basati sull’intelligenza artificiale esiste meno documentazione pubblica.

OpenAI spiega che OAI-SearchBot esegue la scansione dei siti affinché possano apparire nelle funzioni di ricerca di ChatGPT. Secondo OpenAI, le pagine che bloccano questo bot non vengono mostrate in ChatGPT Search.

Perplexity descrive PerplexityBot come un crawler utilizzato per scoprire e collegare siti nei risultati di ricerca di Perplexity. L’azienda consiglia di consentirne l’accesso se un sito desidera poter comparire in tali risultati.

Anthropic fornisce a Claude l’accesso alla ricerca web, permettendo al sistema di consultare pagine aggiornate e utilizzarle come fonti. La documentazione pubblica non descrive però alcun trattamento particolare di sameAs.

Nessuno di questi fornitori di intelligenza artificiale conferma pubblicamente che la semplice aggiunta di sameAs produca direttamente più menzioni, un posizionamento migliore o citazioni più frequenti.

Il suo possibile valore si trova altrove. Anche i sistemi di intelligenza artificiale con accesso al web devono decidere quale persona corrisponde a un nome, quale dominio è ufficiale e se due profili appartengono alla stessa organizzazione. Un grafo Schema coerente può offrire ulteriori indizi leggibili dalle macchine, a condizione che il sistema li analizzi e li utilizzi.

sameAs non è quindi una scorciatoia per la Generative Engine Optimization. È una parte di dati di entità ben strutturati.

La differenza tra sameAs, url, @id e proprietà simili

Diverse proprietà dei dati strutturati possono sembrare equivalenti perché contengono URL o identificatori. In realtà, svolgono funzioni differenti.

@id come identificatore interno dell’entità

@id non deve essere confuso con un normale URL di profilo cliccabile. Attribuisce al nodo JSON-LD un identificatore preciso a cui le altre parti del grafo possono fare riferimento.

Una persona potrebbe, ad esempio, ricevere il seguente @id:

"@id": "https://example.com/chi-sono/#person"

Il frammento #person non deve necessariamente aprire una pagina visibile separata. Serve a identificare la persona all’interno del modello di dati.

Quando la stessa persona viene successivamente indicata come autore di un articolo, quest’ultimo può utilizzare lo stesso @id. In questo modo ogni pagina non genera un nuovo nodo Person isolato.

url come pagina principale

url punta normalmente alla pagina centrale associata all’entità.

Per una persona potrebbe essere la pagina Chi sono. Per un’organizzazione è generalmente il sito ufficiale. Google descrive esplicitamente url nel markup Organization come il sito dell’organizzazione e come un’informazione che può contribuire a identificarla senza ambiguità. (Google Search Central)

sameAs come collegamento di identità

sameAs aggiunge altre pagine che rappresentano chiaramente la stessa entità. Per una persona potrebbero essere LinkedIn, Wikidata o un profilo autore ufficiale presso un editore.

La proprietà non sostituisce né @id né url. Un nodo di entità ben costruito può contenere tutti e tre.

mainEntityOfPage come relazione tematica

Una pagina può parlare principalmente di una persona o di un’azienda senza essere la sua rappresentazione ufficiale.

Un profilo aziendale pubblicato da una rivista potrebbe avere l’azienda come entità principale. L’articolo non diventa per questo una pagina sameAs dell’impresa.

identifier come identificatore formale

Schema.org prevede identifier per ISBN, GTIN, UUID e altri sistemi formali di identificazione. Un profilo LinkedIn non è un identificatore di questo tipo e quindi, normalmente, non dovrebbe essere inserito in quel campo. (Schema.org)

Canonical e hreflang come relazioni tra documenti

Un tag canonical aiuta i motori di ricerca a scegliere l’URL preferito tra documenti identici o molto simili. Non collega persone o organizzazioni. (Google Search Central)

hreflang, invece, indica le versioni linguistiche o regionali di una pagina. Le versioni italiana e inglese di una pagina Chi sono non dovrebbero quindi essere collegate con sameAs soltanto per segnalare che sono traduzioni. Possono però fare riferimento allo stesso nodo Person e allo stesso @id.

La regola più semplice da ricordare è:

Canonical e hreflang organizzano i documenti.
@id, url e sameAs organizzano le entità.

Quali URL inserire in sameAs – e quali evitare

Un URL è adatto quando rappresenta la stessa entità in modo tanto chiaro da lasciare poco spazio all’interpretazione.

Per una persona, possono essere pertinenti:

• un sito personale ufficiale,
• un profilo social chiaramente attribuibile,
• un profilo autore presso un giornale o un editore,
• una voce Wikidata o Wikipedia,
• un profilo ufficiale in una banca dati professionale rilevante.

Per un’organizzazione, possono essere adatti profili aziendali ufficiali, directory professionali, piattaforme di recensioni o basi di conoscenza. Google cita esplicitamente i profili esterni sui social network e sulle piattaforme di recensioni come possibili valori di Organization.sameAs.

La piattaforma da sola non rende però un URL adatto. Il profilo deve mostrare chiaramente a chi appartiene. La corrispondenza di nome, immagine, posizione professionale, informazioni aziendali e collegamenti al sito ufficiale può rafforzare l’identificazione.

Le seguenti pagine normalmente non dovrebbero essere inserite in sameAs:

• singoli articoli di stampa sull’entità,
• articoli ospiti scritti dalla persona,
• siti generali di datori di lavoro o clienti,
• pagine interne di risultati di ricerca,
• pagine di categoria contenenti più persone,
• pagine in cui il nome viene soltanto menzionato,
• profili appartenenti a persone o aziende con nomi simili.

Un profilo autore può rappresentare l’identità di una persona. Un singolo articolo scritto da quell’autore rappresenta principalmente un Article o un BlogPosting.

Allo stesso modo, la homepage di un datore di lavoro rappresenta innanzitutto il datore di lavoro. Una pagina dedicata a un dipendente può però rappresentare chiaramente la persona.

È necessaria particolare attenzione con società controllanti, marchi e filiali. Una filiale non è automaticamente la stessa entità del gruppo societario. Un marchio di prodotto non coincide necessariamente con l’azienda che lo possiede.

Una domanda pratica risolve molti casi limite:

Una persona indipendente aprirebbe questo URL e concluderebbe immediatamente che rappresenta esattamente la stessa entità?

Quando la risposta è soltanto “più o meno”, sameAs probabilmente non è la proprietà adatta.

Come implementare correttamente sameAs

Prima di raccogliere profili esterni, bisogna determinare quale sia l’entità centrale descritta. Si tratta di una persona, di un’organizzazione, di un marchio o di un’opera?

L’entità necessita quindi di un @id stabile e di un’url principale.

Un semplice nodo Person potrebbe apparire così:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/chi-sono/#person",
  "name": "Mario Rossi",
  "url": "https://example.com/chi-sono/",
  "image": {
    "@type": "ImageObject",
    "url": "https://example.com/images/mario-rossi.jpg"
  },
  "jobTitle": "Consulente SEO",
  "sameAs": [
    "https://www.linkedin.com/in/mario-rossi/",
    "https://example-editore.com/autori/mario-rossi/",
    "https://www.wikidata.org/wiki/Q123456"
  ]
}

In questo esempio, la pagina Chi sono è l’url principale. Gli altri profili sono inseriti sotto sameAs perché rappresentano la stessa persona su altre piattaforme.

Quando la persona viene utilizzata come autore di un articolo del blog, non è necessario creare un secondo nodo Person indipendente:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/sameas-schema-org-entita/#article",
  "headline": "sameAs in Schema.org: come le macchine riconoscono chi o cosa intendi",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/sameas-schema-org-entita/"
  },
  "author": {
    "@type": "Person",
    "@id": "https://example.com/chi-sono/#person"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  }
}

L’articolo fa ora riferimento alla stessa persona già descritta nella pagina Chi sono. Questa struttura è più pulita rispetto alla creazione di un nuovo nodo autore, con dati leggermente diversi, per ogni pubblicazione.

Per un’implementazione pratica, seguirei questo ordine:

1. Identificare l’entità centrale.
2. Definire un @id permanente.
3. Scegliere la pagina ufficiale come url.
4. Selezionare per sameAs soltanto profili di identità inequivocabili.
5. Esaminare il markup già generato dal tema o dal plugin SEO.
6. Unificare i nodi Person o Organization duplicati.
7. Convalidare il JSON-LD effettivamente renderizzato.
8. Verificare che i crawler rilevanti dei motori di ricerca e dei sistemi di intelligenza artificiale possano accedere alla pagina.

Molti siti WordPress generano già un grafo Schema tramite il tema, Rank Math, Yoast o un altro plugin. Aggiungere un blocco JSON-LD completo e indipendente può creare involontariamente una seconda versione della stessa persona o organizzazione.

Prima di aggiungere codice personalizzato, è quindi opportuno verificare se il nodo esistente possa essere semplicemente esteso.

La sintassi può essere controllata con lo Schema Markup Validator. Il test dei risultati multimediali di Google si concentra soprattutto sul markup supportato per specifiche funzionalità della ricerca Google. Un sameAs valido potrebbe quindi non essere mostrato come miglioramento separato.

Errori comuni e limiti realistici

L’errore più frequente consiste nel trattare sameAs come una raccolta di link social. Un tema offre quindici campi per i profili, quindi vengono aggiunti quindici profili.

La quantità, però, non è un segnale di qualità.

Ogni URL aggiuntivo rappresenta un’ulteriore dichiarazione di identità che deve restare corretta, aggiornata e coerente. Tre profili chiari sono spesso più utili di dodici collegamenti deboli o obsoleti.

Un altro errore consiste nel selezionare le pagine in base all’autorità del dominio. Un articolo pubblicato su un noto sito di notizie non diventa una pagina di identità soltanto perché il dominio è autorevole.

Anche nodi Schema contraddittori possono creare ambiguità inutili. Un plugin potrebbe creare la stessa persona sotto /#person, uno snippet personalizzato potrebbe utilizzare /chi-sono/#author, mentre un terzo strumento potrebbe mostrare soltanto il nome senza identificatore. Si producono così diversi nodi separati. I sistemi di ricerca possono tentare di unirli, ma il markup non fornisce loro un riferimento comune pulito.

Le informazioni nel JSON-LD dovrebbero inoltre corrispondere ai contenuti visibili della pagina. Bing mette esplicitamente in guardia dall’inserire nel markup informazioni false o ingannevoli che gli utenti non possono vedere.

Se lo Schema elenca dieci ruoli professionali, diverse aziende e numerosi profili, mentre la pagina Chi sono visibile contiene soltanto un nome, il sito presenta due versioni differenti di se stesso: una alle persone e un’altra ai parser.

sameAs può aiutare le macchine a collegare segnali di identità già esistenti. Non può compensare una scarsa autorevolezza, contenuti deboli, informazioni aziendali contraddittorie o l’assenza di una presenza esterna.

È un’infrastruttura, non un amplificatore.

Conclusione: la precisione conta più della lunghezza dell’array

Nel JSON-LD, sameAs appare come un piccolo elenco di URL. Dal punto di vista semantico, però, formula una dichiarazione forte sull’identità di una persona, un’organizzazione o una cosa.

La proprietà non dovrebbe quindi essere compilata in base al numero di profili disponibili. Ciò che conta è scegliere le pagine che rappresentano davvero e senza ambiguità l’entità descritta.

Google documenta utilizzi concreti per identificare autori e organizzazioni. Anche Bing utilizza i dati strutturati come supporto alla comprensione. ChatGPT, Perplexity e Claude possono accedere ai contenuti web, ma nessuno di questi sistemi conferma pubblicamente che sameAs funzioni come un interruttore indipendente di visibilità o ranking.

Questo non rende la proprietà irrilevante. Richiede semplicemente un’interpretazione realistica.

Un grafo di entità pulito fornisce alle macchine una risposta precisa a una domanda fondamentale, senza promettere più di quanto le informazioni disponibili permettano di affermare:

Chi o cosa viene realmente descritto?