sameAs dans Schema.org : comment les machines comprennent de qui ou de quoi il s’agit

Lorsque j’ai découvert sameAs dans les données structurées, cette propriété m’a d’abord semblé assez secondaire. On ajoute LinkedIn, éventuellement Instagram ou un profil d’auteur, puis on revient aux éléments du balisage qui paraissent plus importants.

Pourtant, sameAs est loin d’être anodin.

Chaque URL ajoutée constitue une déclaration précise : l’entité décrite par le nœud Schema est la même que celle représentée à cette autre adresse.

Il ne s’agit donc pas d’un simple lien externe ni d’une référence vers des informations complémentaires. sameAs sert à aider les machines à relier différentes représentations d’une même personne, organisation, marque, publication ou chose.

Cela peut concerner Google et Bing, mais aussi les graphes de connaissances, les bases de données, les robots d’exploration et les moteurs de recherche basés sur l’intelligence artificielle. La propriété n’est cependant ni un facteur de classement garanti ni un bouton magique permettant à une personne d’apparaître soudainement plus souvent dans ChatGPT ou Perplexity.

Malheureusement, la propriété ne s’appelle pas pleaseUnderstandWhoIAm. Pourtant, son rôle s’en rapproche beaucoup.

Ce que signifie réellement sameAs

Schema.org définit sameAs comme l’URL d’une page de référence permettant d’identifier sans ambiguïté l’élément décrit. Schema.org cite notamment une page Wikipédia, une entrée Wikidata ou un site officiel. La propriété appartient à Thing et peut donc théoriquement être utilisée par tous les types Schema.org qui en dérivent.

On retrouve notamment :

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

La disponibilité technique d’une propriété ne signifie pas qu’elle soit pertinente dans tous les cas. Le mot le plus important de la définition est souvent négligé : la page indiquée doit permettre une identification sans ambiguïté.

Un article de presse peut parler en détail d’une personne, préciser sa profession et reprendre plusieurs de ses citations. Malgré cela, l’article n’est généralement pas une page représentant son identité. Il s’agit d’un document à son sujet.

Un profil d’auteur officiel, un site personnel ou un profil LinkedIn clairement attribuable représente plus directement la personne.

sameAs ne sert donc pas à déclarer :

Cette page me mentionne.

La déclaration correspond plutôt à :

Cette URL représente la même entité que celle décrite dans ce nœud Schema.

Cette distinction n’est pas une simple subtilité sémantique. Lorsqu’une mention ordinaire est indiquée comme sameAs, le balisage affirme une relation plus forte que celle qui existe réellement entre les pages.

Pourquoi les machines ont besoin d’aide pour résoudre les identités

Les humains reconnaissent souvent une identité grâce au contexte. Un nom, une photographie, un employeur et une fonction nous suffisent généralement pour comprendre de quelle personne il s’agit.

Une machine reçoit d’abord plusieurs signaux séparés :

• un nom,
• une URL,
• du texte visible,
• des données structurées,
• des connexions internes,
• des profils externes,
• des mentions sur d’autres domaines.

Ces signaux peuvent être clairs, mais ce n’est pas toujours le cas.

Plusieurs personnes peuvent porter le même nom. Une entreprise peut apparaître sous sa marque, sa raison sociale complète et différentes abréviations. Après un changement de nom, les anciennes et nouvelles dénominations peuvent continuer à circuler en parallèle.

Ce problème est souvent appelé résolution d’entités ou entity resolution. Un système tente de déterminer si plusieurs données, pages ou références décrivent la même personne, organisation ou chose réelle.

sameAs fournit une connexion explicite pouvant faciliter ce processus. La propriété ne remplace toutefois pas les autres informations. Le nom, l’image, le site officiel, la description et la cohérence des profils restent nécessaires pour rendre la relation crédible.

Une connexion erronée ne devient pas correcte simplement parce qu’elle est inscrite en JSON-LD. Les données structurées ne font qu’exprimer l’affirmation dans un format plus facilement exploitable par les machines.

Le rôle de sameAs pour Google, Bing et les systèmes d’IA

Schema.org n’est pas un format exclusivement destiné à Google. Ce vocabulaire a été conçu pour intégrer des informations structurées aux sites web afin que les moteurs de recherche et d’autres applications puissent mieux traiter les contenus et leurs relations.

Google documente plusieurs utilisations concrètes. Dans le balisage Organization, sameAs peut pointer vers des profils externes, notamment sur les réseaux sociaux ou les plateformes d’avis. Il est possible d’indiquer plusieurs URL. Google présente également les données structurées relatives aux organisations comme un moyen de mieux comprendre une entreprise et de la distinguer d’autres entités.

Pour les articles, Google peut utiliser author.url et author.sameAs afin d’identifier plus précisément un auteur. Google recommande également le balisage ProfilePage pour les pages internes consacrées aux auteurs.

Bing traite lui aussi les données structurées et prend en charge Schema.org en JSON-LD. Microsoft explique que ces données peuvent aider Bing à comprendre le contenu et les relations présentes sur une page. Microsoft déconseille également d’insérer dans le balisage des informations fausses ou trompeuses que les utilisateurs ne peuvent pas voir.

Les informations publiques sont moins nombreuses concernant les systèmes de recherche et de réponse fondés sur l’intelligence artificielle.

OpenAI explique que OAI-SearchBot explore les sites afin qu’ils puissent apparaître dans les fonctions de recherche de ChatGPT. Selon OpenAI, les pages qui bloquent ce robot ne sont pas affichées dans ChatGPT Search.

Perplexity décrit PerplexityBot comme un robot utilisé pour découvrir et référencer des sites dans les résultats de recherche de Perplexity. L’entreprise recommande de l’autoriser lorsqu’un site souhaite pouvoir apparaître dans ces résultats.

Anthropic donne à Claude accès à une recherche web, ce qui permet au système de consulter des pages récentes et de les utiliser comme sources. Sa documentation publique ne décrit toutefois aucun traitement particulier de sameAs.

Aucun de ces fournisseurs d’IA ne confirme publiquement que l’ajout de sameAs entraîne directement davantage de mentions, une meilleure position ou des citations plus fréquentes.

Son intérêt potentiel se situe ailleurs. Les systèmes d’IA connectés au web doivent eux aussi déterminer à quelle personne correspond un nom, quel domaine est officiel et si deux profils appartiennent à la même organisation. Un graphe Schema cohérent peut fournir des indices supplémentaires lisibles par les machines, à condition que le système concerné les analyse et les utilise.

sameAs n’est donc pas un raccourci de Generative Engine Optimization. C’est un élément de données d’entité correctement structurées.

La différence entre sameAs, url, @id et les propriétés similaires

Plusieurs propriétés de données structurées peuvent sembler remplir le même rôle parce qu’elles contiennent des URL ou des identifiants. En réalité, leurs fonctions sont différentes.

@id comme identifiant interne d’entité

@id ne doit pas être confondu avec une URL de profil ordinaire et cliquable. Cette propriété donne au nœud JSON-LD un identifiant précis vers lequel d’autres parties du graphe peuvent pointer.

Une personne pourrait par exemple recevoir l’@id suivant :

"@id": "https://example.com/a-propos/#person"

Le fragment #person n’a pas besoin d’ouvrir une page visible séparée. Il sert à identifier la personne dans le modèle de données.

Lorsque cette personne est ensuite indiquée comme auteur d’un article, celui-ci peut utiliser le même @id. Chaque page ne crée ainsi pas un nouveau nœud Person isolé.

url comme page principale

url pointe généralement vers la page centrale associée à l’entité.

Pour une personne, il peut s’agir de sa page À propos. Pour une organisation, il s’agit habituellement du site officiel. Google décrit explicitement url dans le balisage Organization comme le site de l’organisation et comme une information pouvant aider à l’identifier sans ambiguïté.

sameAs comme connexion d’identité

sameAs ajoute d’autres pages représentant clairement la même entité. Pour une personne, il peut s’agir de LinkedIn, de Wikidata ou d’un profil d’auteur officiel chez un éditeur.

Cette propriété ne remplace ni @id ni url. Un nœud d’entité bien construit peut contenir les trois.

mainEntityOfPage comme relation thématique

Une page peut principalement parler d’une personne ou d’une entreprise sans constituer sa représentation officielle.

Un portrait d’entreprise publié par un magazine peut avoir cette entreprise comme entité principale. L’article ne devient pas pour autant une page sameAs de l’entreprise.

identifier comme identifiant formel

Schema.org prévoit identifier pour les ISBN, GTIN, UUID et autres systèmes d’identification formels. Un profil LinkedIn n’est pas un identifiant de ce type et ne devrait donc généralement pas être placé dans ce champ.

Canonical et hreflang comme relations entre documents

Une balise canonical aide les moteurs de recherche à choisir une URL préférée parmi plusieurs documents identiques ou très proches. Elle ne relie pas des personnes ou des organisations.

hreflang sert en revanche à indiquer les variantes linguistiques ou régionales d’une page. Les versions française et anglaise d’une page À propos ne devraient donc pas être reliées avec sameAs simplement pour indiquer qu’il s’agit de traductions. Elles peuvent cependant référencer le même nœud Person et le même @id.

La règle la plus simple à retenir est la suivante :

Canonical et hreflang organisent les documents.
@id, url et sameAs organisent les entités.

Quelles URL utiliser dans sameAs – et lesquelles éviter

Une URL convient lorsqu’elle représente la même entité de manière si claire qu’elle laisse peu de place à l’interprétation.

Pour une personne, les candidats pertinents peuvent inclure :

• un site personnel officiel,
• un profil de réseau social clairement attribuable,
• un profil d’auteur auprès d’un journal ou d’un éditeur,
• une entrée Wikidata ou Wikipédia,
• un profil officiel dans une base professionnelle pertinente.

Pour une organisation, les pages adaptées peuvent inclure des profils d’entreprise officiels, des annuaires professionnels, des plateformes d’avis ou des bases de connaissances. Google cite explicitement les profils externes de réseaux sociaux et de plateformes d’avis comme valeurs possibles de Organization.sameAs.

La plateforme ne suffit toutefois pas à rendre une URL pertinente. Le profil doit permettre d’identifier clairement son propriétaire. La concordance du nom, de l’image, de la fonction, des informations d’entreprise et des liens vers le site officiel peut renforcer cette identification.

Les pages suivantes ne devraient généralement pas apparaître dans sameAs :

• les articles de presse consacrés à l’entité,
• les tribunes ou contributions rédigées par la personne,
• les sites généraux d’employeurs ou de clients,
• les pages de résultats de recherche internes,
• les pages de catégorie contenant plusieurs personnes,
• les pages où le nom est seulement mentionné,
• les profils de personnes ou d’entreprises au nom similaire.

Un profil d’auteur peut représenter l’identité d’une personne. Un article individuel écrit par cet auteur représente avant tout un Article ou un BlogPosting.

De la même manière, la page d’accueil d’un employeur représente principalement cet employeur. Une page dédiée à un membre de l’équipe peut toutefois représenter clairement la personne.

Une attention particulière est nécessaire pour les maisons mères, les marques et les filiales. Une filiale n’est pas automatiquement la même entité que le groupe auquel elle appartient. Une marque de produit n’est pas nécessairement identique à l’entreprise qui la possède.

Une question pratique permet de résoudre de nombreux cas limites :

Une personne indépendante ouvrirait-elle cette URL et conclurait-elle immédiatement qu’elle représente exactement la même entité ?

Lorsque la réponse est seulement « plus ou moins », sameAs n’est probablement pas la bonne propriété.ur „irgendwie schon“, ist sameAs wahrscheinlich nicht die richtige Property.

Comment implémenter proprement sameAs

Avant de rassembler des profils externes, il faut déterminer l’entité centrale décrite. S’agit-il d’une personne, d’une organisation, d’une marque ou d’une œuvre ?

L’entité doit ensuite recevoir un @id stable et une url principale.

Un nœud Person simple pourrait ressembler à ceci :

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/a-propos/#person",
  "name": "Jean Dupont",
  "url": "https://example.com/a-propos/",
  "image": {
    "@type": "ImageObject",
    "url": "https://example.com/images/jean-dupont.jpg"
  },
  "jobTitle": "Consultant SEO",
  "sameAs": [
    "https://www.linkedin.com/in/jean-dupont/",
    "https://example-editeur.com/auteurs/jean-dupont/",
    "https://www.wikidata.org/wiki/Q123456"
  ]
}

Dans cet exemple, la page À propos est l’url principale. Les autres profils apparaissent sous sameAs parce qu’ils représentent la même personne sur d’autres plateformes.

Lorsque cette personne est indiquée comme auteur d’un article de blog, il n’est pas nécessaire de créer un second nœud Person indépendant :

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/sameas-schema-org-entites/#article",
  "headline": "sameAs dans Schema.org : comment les machines comprennent de qui ou de quoi il s’agit",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/sameas-schema-org-entites/"
  },
  "author": {
    "@type": "Person",
    "@id": "https://example.com/a-propos/#person"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  }
}

L’article référence désormais la même personne que celle déjà décrite sur la page À propos. Cette structure est plus propre que la création, pour chaque publication, d’un nouveau nœud auteur comportant des informations légèrement différentes.

Pour une mise en œuvre pratique, je suivrais cet ordre :

1. Identifier l’entité centrale.
2. Définir un @id permanent.
3. Choisir la page officielle comme url.
4. Ne sélectionner pour sameAs que des profils d’identité sans ambiguïté.
5. Examiner le balisage déjà généré par le thème ou l’extension SEO.
6. Regrouper les nœuds Person ou Organization en double.
7. Valider le JSON-LD réellement affiché.
8. Vérifier que les robots pertinents des moteurs de recherche et des systèmes d’IA peuvent accéder à la page.

De nombreux sites WordPress génèrent déjà un graphe Schema par l’intermédiaire du thème, de Rank Math, de Yoast ou d’une autre extension. Ajouter un bloc JSON-LD complet et indépendant peut créer involontairement une deuxième version de la même personne ou organisation.

Avant d’ajouter du code personnalisé, il faut donc vérifier si le nœud existant peut simplement être complété.

La syntaxe peut être contrôlée avec le Schema Markup Validator. Le test des résultats enrichis de Google se concentre principalement sur les balisages pris en charge pour des fonctionnalités précises de la recherche Google. Un sameAs valide peut donc ne pas y apparaître comme une amélioration distincte.

Erreurs fréquentes et limites réalistes

L’erreur la plus courante consiste à traiter sameAs comme une collection de liens sociaux. Un thème propose quinze champs de profil, donc quinze profils sont ajoutés.

La quantité n’est pourtant pas un signal de qualité.

Chaque URL supplémentaire constitue une nouvelle déclaration d’identité qui doit rester correcte, actuelle et cohérente. Trois profils clairs sont souvent plus utiles que douze connexions faibles ou obsolètes.

Une autre erreur consiste à sélectionner les pages en fonction de l’autorité du domaine. Un article publié sur un grand site d’actualité ne devient pas une page d’identité simplement parce que son domaine est réputé.

Les nœuds Schema contradictoires peuvent également créer une ambiguïté inutile. Une extension peut créer la personne sous /#person, un extrait de code personnalisé peut utiliser /a-propos/#author, tandis qu’un troisième outil affiche uniquement le nom sans identifiant. Plusieurs nœuds séparés sont alors produits. Les moteurs peuvent tenter de les fusionner, mais le balisage ne leur fournit pas de référence commune propre.

Les informations du JSON-LD doivent également correspondre au contenu visible de la page. Bing déconseille explicitement d’insérer dans le balisage des informations fausses ou trompeuses que les utilisateurs ne peuvent pas consulter.

Si les données structurées indiquent dix fonctions, plusieurs entreprises et de nombreux profils, tandis que la page À propos visible ne contient qu’un nom, le site présente deux versions différentes de lui-même : une aux humains et une aux analyseurs.

sameAs peut aider les machines à relier des signaux d’identité déjà existants. Cette propriété ne peut pas compenser une autorité inexistante, des contenus faibles, des informations d’entreprise contradictoires ou une absence de présence externe.

C’est une infrastructure, pas un amplificateur.

Conclusion : la précision compte davantage que la longueur du tableau

Dans le JSON-LD, sameAs ressemble à une courte liste d’URL. Sur le plan sémantique, la propriété formule pourtant une déclaration forte concernant l’identité d’une personne, d’une organisation ou d’une chose.

Elle ne devrait donc pas être complétée en fonction du nombre de profils disponibles. Ce qui compte, c’est de choisir les pages qui représentent réellement et sans ambiguïté l’entité décrite.

Google documente des utilisations concrètes pour l’identification des auteurs et des organisations. Bing utilise également les données structurées comme aide à la compréhension. ChatGPT, Perplexity et Claude peuvent accéder à des contenus web, mais aucun ne confirme publiquement que sameAs fonctionne comme un levier indépendant de visibilité ou de classement.

Cela ne rend pas cette propriété inutile. Cela impose simplement de l’interpréter avec réalisme.

Un graphe d’entités propre fournit aux machines une réponse précise à une question fondamentale, sans promettre davantage que ce que les informations disponibles permettent d’affirmer :

De qui ou de quoi s’agit-il réellement ?