---
title: "sameAs dans Schema.org : comment les machines comprennent de qui ou de quoi il s’agit"
description: "sameAs n’est pas une simple collection de liens externes. Cette propriété de Schema.org relie une personne, une organisation ou une autre entité à des pages représentant sans ambiguïté la même identité."
url: https://johannesbecht.com/fr/blog/schema-same-as
date: 2026-07-19
modified: 2026-07-19
author: "Johannes Becht"
image: https://johannesbecht.com/wp-content/uploads/2026/07/Code-de-donnees-structurees-Schema-sameAs-.png
categories: ["Blog marketing"]
tags: ["Blog SEO"]
type: post
lang: fr
---

# 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](https://schema.org/sameAs) 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.

| Élément | Fonction |
| --- | --- |
| `@id` | Attribue au nœud Schema un identifiant stable et réutilisable |
| `url` | Pointe vers la page principale ou officielle de l’entité |
| `sameAs` | Relie l’entité à d’autres pages représentant la même identité |
| `mainEntityOfPage` | Indique que l’entité est le sujet principal d’une page précise |
| `identifier` | Contient un identifiant formel comme un ISBN, un GTIN ou un UUID |
| `rel="canonical"` | Désigne l’URL préférée parmi des documents identiques ou proches |
| `hreflang` | Relie les versions linguistiques ou régionales d’une page |

`**@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 ?**
