Référentiel 2026 pour construire le SEO depuis les entités, leurs attributs, leurs relations et la connaissance réelle
Pendant longtemps, une grande partie du travail SEO a été représentée par une chaîne relativement simple :
KEYWORD
↓
SEARCH VOLUME
↓
PAGE
↓
CONTENT
↓
RANKING
Cette approche reste utile.
Les utilisateurs continuent d'utiliser des mots et des expressions pour rechercher de l'information.
Mais un site Web représente également une réalité composée de :
- personnes ;
- organisations ;
- établissements ;
- marques ;
- produits ;
- services ;
- lieux ;
- événements ;
- concepts ;
- attributs ;
- relations.
L'approche Entity-First SEO commence donc par une autre question :
Quelles sont les choses réelles que ce site doit représenter, et quelles informations permettent de les comprendre ?
Puis seulement :
Comment les utilisateurs recherchent-ils ces choses ?
Un modèle simplifié :
REALITY
↓
ENTITIES
↓
IDENTITY
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
FIRST-PARTY KNOWLEDGE
↓
INFORMATION NEEDS
↓
CONTENT ARCHITECTURE
↓
PAGES
↓
ANSWER UNITS
↓
STRUCTURED DATA
↓
CORROBORATION
↓
SEARCH
↓
AEO / GEO / AI SEARCH
Ce référentiel présente un modèle méthodologique proposé par VisiaLocal.
Entity-First SEO n'est pas présenté ici comme une méthode officielle de Google.
Une entité peut être comprise comme une chose identifiable et distincte.
Exemples :
- une entreprise ;
- une personne ;
- un restaurant ;
- une ville ;
- une marque ;
- un produit ;
- un service ;
- un événement.
Une entité possède une identité.
Un mot-clé est une expression utilisée dans une recherche.
Une entité est la chose à laquelle cette expression peut faire référence.
Exemple :
keyword
agence SEO Aix
peut faire référence à :
- plusieurs entreprises ;
- une catégorie d'entreprises ;
- une intention locale.
Une entreprise spécifique constitue une entité.
Dans ce référentiel, Entity-First SEO désigne une approche où la modélisation des entités précède la création ou l'optimisation des pages.
La logique devient :
WHAT EXISTS?
↓
WHAT DO WE KNOW ABOUT IT?
↓
HOW IS IT CONNECTED?
↓
WHAT DO USERS NEED TO KNOW?
↓
HOW SHOULD IT BE REPRESENTED?
↓
HOW IS IT SEARCHED?
Une approche Keyword-First peut être :
KEYWORD RESEARCH
↓
CLUSTER
↓
PAGE
↓
CONTENT
Cette méthode peut être efficace.
Mais elle risque parfois de créer une architecture basée davantage sur les formulations des requêtes que sur la réalité de l'organisation.
Les deux approches ne sont pas nécessairement opposées.
Un modèle plus complet peut être :
ENTITIES
BUSINESS KNOWLEDGE
SEARCH DEMAND
↓
CONTENT ARCHITECTURE
Les mots-clés deviennent alors une source d'information sur la demande.
Ils ne constituent plus l'unique fondation.
Avant même les entités numériques existe une réalité.
Exemple :
une entreprise possède réellement :
- un nom ;
- une activité ;
- des employés ;
- des clients ;
- des services ;
- une localisation.
Le Web doit représenter cette réalité.
Une entité réelle peut être représentée par :
- site officiel ;
- page About ;
- profil professionnel ;
- fiche locale ;
- documentation ;
- réseaux sociaux ;
- sources tierces.
Ces représentations ne sont pas l'entité elle-même.
L'Entity Identity répond à :
De quelle entité parlons-nous exactement ?
L'identité peut être établie par plusieurs informations compatibles.
Le nom constitue un attribut important.
Mais le nom seul peut être ambigu.
Deux entreprises peuvent partager un nom similaire.
Le type aide à comprendre la nature de l'entité.
Exemples :
- Organization ;
- Person ;
- LocalBusiness ;
- Product ;
- Service ;
- Place.
Une description peut préciser :
- activité ;
- spécialité ;
- localisation ;
- positionnement.
Elle doit rester factuelle.
Une URL officielle peut servir de représentation principale d'une entité.
Exemple :
ORGANIZATION
↓
official website
↓
https://example.com
Dans ce framework, une Entity Home désigne une ressource principale permettant d'identifier clairement une entité.
Exemples :
Organization → homepage.
Person → profile page.
Product → product page.
Location → location page.
Il s'agit d'un concept méthodologique.
Entity Resolution consiste à déterminer si plusieurs représentations correspondent à la même entité.
Exemple :
VisiaLocal
sur un site
et
VisiaLocal
sur GitHub.
Le système doit pouvoir comprendre qu'il s'agit potentiellement de la même organisation.
La désambiguïsation permet de distinguer des entités similaires.
Exemple :
Paris
peut désigner :
- ville ;
- personne ;
- marque ;
- lieu.
Le contexte est essentiel.
Une entité possède des attributs.
Exemple :
RESTAURANT
- name ;
- address ;
- cuisine ;
- opening hours ;
- price range ;
- telephone.
Un attribut décrit généralement une entité.
Exemple :
parking available
est généralement un attribut d'un établissement.
Il n'a pas nécessairement besoin de devenir une entité ou une page.
Les entités sont reliées.
Exemple :
PERSON
↓
worksFor
↓
ORGANIZATION
Autres relations :
ORGANIZATION
→ provides →
SERVICE
PRODUCT
→ manufacturedBy →
ORGANIZATION
LOCAL BUSINESS
→ locatedIn →
PLACE
Une relation peut être représentée sous forme de triple :
SUBJECT
↓
PREDICATE
↓
OBJECT
Exemple :
VisiaLocal
↓
provides
↓
Semantic SEO.
Plusieurs relations créent un graphe.
ORGANIZATION
↓
provides
↓
SERVICE
↓
availableIn
↓
PLACE
↓
partOf
↓
COUNTRY
Un Entity Graph peut simplement représenter un ensemble d'entités et de relations.
Un Knowledge Graph peut intégrer des modèles et infrastructures plus complexes.
Les termes ne doivent pas être utilisés comme synonymes automatiques.
Un Knowledge Graph organise des connaissances autour d'entités et de relations.
Il peut être :
- interne ;
- public ;
- propriétaire ;
- spécialisé.
Les moteurs de recherche peuvent utiliser leurs propres systèmes de connaissances.
Une entreprise ne contrôle pas directement leur contenu.
Une entreprise peut également construire son propre graphe pour organiser :
- produits ;
- personnes ;
- établissements ;
- services ;
- documents.
Les données directement détenues par l'organisation peuvent fournir des informations sur ses entités.
Exemples :
- catalogue ;
- CRM ;
- PIM ;
- horaires ;
- tarifs ;
- processus.
Dans le framework VisiaLocal, Business First-Party Knowledge représente la connaissance factuelle qu'une organisation possède sur sa propre activité.
Exemples :
- délai réel ;
- service réellement disponible ;
- zones couvertes ;
- personnalisation ;
- caractéristiques.
Les connaissances peuvent être rattachées à une entité.
Exemple :
SERVICE
- provider ;
- price ;
- duration ;
- location ;
- audience.
Une approche Entity-First commence généralement par un inventaire.
Exemple :
| Entity | Type |
|---|---|
| Company | Organization |
| Founder | Person |
| Service A | Service |
| Location A | LocalBusiness |
| Product A | Product |
Certaines entités sont centrales.
Pour une agence :
- organisation ;
- dirigeants ;
- services ;
- clients ;
- études de cas.
Certaines entités fournissent du contexte.
Exemples :
- technologies ;
- villes ;
- plateformes ;
- partenaires.
Toutes les entités ne nécessitent pas le même niveau de représentation.
Une entité centrale peut nécessiter :
- page dédiée ;
- données structurées ;
- liens internes ;
- sources.
Une entité secondaire peut simplement être mentionnée.
Une matrice peut relier les entités aux pages.
| Entity | Primary Page |
|---|---|
| Organization | Homepage |
| Founder | About |
| Service A | Service page |
| Location A | Location page |
Chaque entité ne nécessite pas automatiquement une URL.
Une page peut représenter plusieurs entités liées.
Une page peut également parler de plusieurs entités.
Il faut simplement distinguer :
- entité principale ;
- entités secondaires.
Une page peut posséder une entité principale.
Exemple :
/aix-en-provence/
→ établissement d'Aix.
La même page peut mentionner :
- organisation ;
- ville ;
- services ;
- équipe.
Un sujet n'est pas nécessairement une entité.
Exemple :
SEO
peut être considéré comme un domaine ou concept.
VisiaLocal
est une organisation identifiable.
Certains systèmes peuvent néanmoins représenter des concepts comme des entités dans leurs modèles de connaissances.
La frontière dépend du système utilisé.
L'architecture peut commencer par :
ENTITY INVENTORY
↓
RELATIONSHIPS
↓
INFORMATION NEEDS
↓
CONTENT OBJECTS
↓
PAGES
Exemple :
ORGANIZATION
↓
SERVICES
↓
CLIENTS
↓
CASE STUDIES
↓
PEOPLE
↓
LOCATIONS
ORGANIZATION
↓
LOCATION
↓
SERVICES
↓
ATTRIBUTES
↓
LOCAL ANSWERS
BRAND
↓
CATEGORY
↓
PRODUCT
↓
VARIANT
↓
ATTRIBUTES
BRAND
↓
LOCATIONS
↓
LOCAL SERVICES
↓
LOCAL ATTRIBUTES
Chaque établissement constitue potentiellement une entité distincte.
Un groupe peut posséder plusieurs marques.
GROUP
↓
owns
↓
BRAND A
BRAND B
Ces relations doivent être correctement représentées.
PERSON
↓
worksFor / founderOf
↓
ORGANIZATION
↓
provides
↓
SERVICE
Cela permet de relier expertise et organisation.
Un service peut être une entité métier importante.
SERVICE
↓
providedBy
↓
ORGANIZATION
↓
availableIn
↓
AREA
Un produit peut être relié à :
- marque ;
- fabricant ;
- catégorie ;
- variantes ;
- offres.
Une marque peut être reliée à :
- organisation ;
- produits ;
- fondateurs ;
- histoire ;
- boutiques.
Les lieux peuvent représenter :
- pays ;
- région ;
- ville ;
- quartier ;
- établissement.
Les relations géographiques doivent être cohérentes.
Certaines entités possèdent des relations hiérarchiques.
Exemple :
France
↓
Provence-Alpes-Côte d'Azur
↓
Aix-en-Provence
Mais une hiérarchie n'est qu'un type de relation.
Le Local SEO peut être vu comme l'optimisation de l'entité établissement dans son environnement géographique.
Il ne se réduit pas à répéter :
service + ville.
Name, Address, Phone constituent des attributs importants pour les entreprises locales.
La cohérence de ces informations facilite l'identification.
Les horaires sont également des attributs.
Ils doivent rester cohérents entre les surfaces importantes.
Les catégories peuvent aider les plateformes à comprendre le type d'établissement.
Elles doivent correspondre à l'activité réelle.
Une entité doit idéalement conserver des informations fondamentales compatibles sur ses différentes représentations.
Dans ce framework, Entity Fragmentation désigne une situation où les représentations d'une même entité semblent incompatibles ou déconnectées.
Exemple :
trois noms différents, deux adresses obsolètes et plusieurs sites non reliés.
Le problème inverse peut apparaître lorsque deux entités distinctes sont confondues.
Lors d'un changement de marque :
OLD BRAND
↓
becomes / redirects to
↓
NEW BRAND
La continuité doit être gérée sur :
- site ;
- URLs ;
- profils ;
- structured data ;
- sources externes.
Une acquisition peut créer des relations :
COMPANY A
↓
acquiredBy
↓
COMPANY B
Ces relations peuvent évoluer dans le temps.
Certains attributs sont temporels.
Exemples :
- CEO ;
- prix ;
- horaires ;
- propriétaire ;
- adresse.
Une information peut être correcte à une date et incorrecte plus tard.
La maintenance des informations d'entité est donc essentielle.
Une organisation peut définir une source interne de référence pour chaque type d'information.
Exemple :
PRODUCT DATA
→ PIM.
EMPLOYEES
→ HR system.
PRICING
→ commercial database.
Une ressource publique peut ensuite exposer certaines de ces informations.
Les données structurées permettent de représenter certaines entités et relations dans un format machine-readable.
Schema.org fournit un vocabulaire permettant de décrire :
- entités ;
- propriétés ;
- relations.
JSON-LD permet de représenter des données liées sous forme JSON.
Exemple conceptuel :
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Company",
"url": "https://example.com/"
}
@id peut fournir un identifiant stable à une entité dans un graphe JSON-LD.
Un identifiant stable permet de réutiliser la même identité dans plusieurs blocs.
Exemple :
https://example.com/#organization
Une page peut référencer :
{
"@type": "Service",
"provider": {
"@id": "https://example.com/#organization"
}
}
Le service est ainsi relié à l'organisation.
sameAs peut être utilisé lorsque deux URLs représentent réellement la même entité.
Il ne faut pas utiliser sameAs pour chaque site parlant de l'entreprise.
Une page de presse n'est pas nécessairement la même entité que l'organisation.
Une page ou un article peut être à propos d'une entité.
Une ressource peut mentionner une entité sans en faire son sujet principal.
Dans certains contextes Schema.org, mainEntity peut identifier l'entité principale décrite.
Le choix doit correspondre au type de ressource.
Exemple conceptuel :
ORGANIZATION
↓
owns
↓
WEBSITE
↓
contains
↓
WEBPAGE
↓
about
↓
SERVICE
Ajouter :
"@type": "Organization"
ne crée pas magiquement une entité reconnue par tous les moteurs.
Le balisage représente une réalité existante.
Entity SEO ne se limite pas au JSON-LD.
Il concerne également :
- contenu ;
- identité ;
- relations ;
- sources ;
- architecture ;
- cohérence.
Obtenir un Knowledge Panel peut être un résultat observable dans certains cas.
Mais Entity-First SEO ne doit pas être réduit à cet objectif.
Un Knowledge Panel est une présentation spécifique de certaines informations dans Google Search.
Une organisation ne peut pas garantir son apparition.
Wikidata est une base de connaissances collaborative.
Elle possède ses propres règles de contribution et de notoriété.
Wikipedia est une encyclopédie.
Elle ne doit pas être utilisée comme un annuaire SEO.
Les critères éditoriaux et de notoriété doivent être respectés.
D'autres bases publiques peuvent fournir des informations sur certaines entités.
La pertinence dépend du secteur et du pays.
Les registres officiels peuvent constituer des sources particulièrement importantes pour certaines informations juridiques ou administratives.
Une entreprise peut posséder des profils sur :
- plateformes professionnelles ;
- réseaux ;
- marketplaces ;
- annuaires spécialisés.
Ils peuvent contribuer à sa représentation numérique.
Dans ce framework, Entity Corroboration désigne la confirmation compatible d'informations concernant une entité par plusieurs sources.
OFFICIAL WEBSITE
VisiaLocal → Aix-en-Provence.
PROFESSIONAL PROFILE
VisiaLocal → Aix-en-Provence.
PARTNER PAGE
VisiaLocal → Aix-en-Provence.
Ces informations convergent.
Une source indépendante possède une valeur différente d'une page contrôlée directement par l'organisation.
Créer dix profils contrôlés par la même entreprise ne constitue pas nécessairement dix validations indépendantes.
Créer artificiellement des sources ou des sites destinés uniquement à confirmer une entité est une pratique trompeuse.
Deux entités peuvent apparaître dans les mêmes documents ou contextes.
Exemple :
VisiaLocal
et
Semantic SEO
La co-occurrence peut signaler une relation contextuelle.
Deux entités apparaissant ensemble ne signifie pas nécessairement qu'une relation précise existe.
Le contexte reste nécessaire.
Exemple :
VisiaLocal fournit des prestations de Semantic SEO.
exprime une relation plus précise que :
VisiaLocal, Semantic SEO, GEO, AEO.
Les verbes sont importants.
worksFor
n'est pas :
founded
et :
provides
n'est pas :
certifiedBy
La précision des relations améliore la qualité du graphe.
Une affirmation sur une entité peut être représentée conceptuellement :
ENTITY
↓
PROPERTY
↓
VALUE
Exemple :
VisiaLocal
↓
location
↓
Aix-en-Provence.
Un fait doit être :
- exact ;
- contextualisé ;
- maintenu.
Certaines affirmations sont davantage subjectives.
Exemple :
meilleure agence SEO.
Ce n'est pas un attribut factuel simple.
Une architecture Entity-First doit distinguer :
FACT
et :
CLAIM
Cela facilite la vérifiabilité.
Une affirmation peut être reliée à une preuve.
ENTITY
↓
claims
↓
CERTIFICATION
↓
verifiedBy
↓
CERTIFICATION BODY
Une personne peut être reliée à un domaine d'expertise par :
- expérience ;
- certification ;
- publications ;
- projets.
Mentionner un sujet plusieurs centaines de fois ne prouve pas automatiquement l'expertise.
Dans ce framework, Entity Authority décrit conceptuellement le niveau de reconnaissance observable d'une entité dans un domaine.
Ce n'est pas une métrique officielle de Google.
La réputation peut être reflétée par :
- avis ;
- presse ;
- références ;
- partenaires ;
- clients.
Elle doit être distinguée de l'identité.
Une marque peut avoir une identité distincte de la société juridique qui la possède.
Exemple :
LEGAL ORGANIZATION
↓
owns
↓
BRAND
Les deux ne doivent pas toujours être fusionnées.
Une entreprise et chacun de ses établissements peuvent également constituer des entités distinctes.
Un produit est différent d'une offre commerciale.
PRODUCT
= objet.
OFFER
= conditions commerciales.
De même :
SERVICE
= prestation.
OFFER
= prix / conditions permettant de l'acheter.
Plus les distinctions sont précises, plus le modèle représente fidèlement la réalité.
Mais la complexité doit rester utile.
Créer des centaines d'entités inutiles peut rendre l'architecture complexe sans apporter de valeur.
À l'inverse, représenter toute une entreprise comme une seule entité peut masquer des relations importantes.
La granularité doit être adaptée à :
- importance ;
- autonomie ;
- besoins utilisateurs ;
- maintenance.
Dans ce framework, Entity Boundary désigne la limite permettant de décider si quelque chose doit être traité comme une entité distincte.
Ce n'est pas une notion officielle de moteur de recherche.
Entity Coverage peut être utilisé conceptuellement pour mesurer si les entités importantes sont représentées.
Attribute Coverage peut mesurer si les attributs nécessaires sont publiés.
Relationship Coverage peut examiner si les relations importantes sont exprimées.
Une entité importante n'est pas représentée.
Une entité existe mais manque d'informations essentielles.
Les entités existent mais leurs relations ne sont pas claires.
Les informations disponibles ne suffisent pas à identifier clairement l'entité.
Une information importante existe uniquement sur une source contrôlée par l'organisation lorsqu'une validation externe serait pertinente.
Les informations publiques ne correspondent plus à la réalité actuelle.
Deux sources présentent des informations incompatibles.
Exemple :
Source A
CEO = Person A.
Source B
CEO = Person B.
Dans ce framework, Entity Drift désigne l'écart progressif entre la réalité actuelle et ses représentations numériques.
Une organisation doit savoir :
- qui crée les entités ;
- qui valide les attributs ;
- qui maintient les relations ;
- qui corrige les sources.
Chaque type d'information peut avoir un responsable.
Exemple :
Products → Product Team.
Locations → Operations.
People → HR.
Une entité peut suivre :
CREATE
↓
PUBLISH
↓
UPDATE
↓
MERGE
↓
ARCHIVE
Lorsqu'une nouvelle entité apparaît :
- nouveau produit ;
- nouveau magasin ;
- nouvelle marque ;
elle doit être intégrée au modèle.
Une ancienne offre peut disparaître.
La page et les relations doivent alors être mises à jour.
Lorsqu'une ressource représentant une entité change d'URL, une redirection appropriée peut préserver la continuité de navigation.
Certaines informations historiques peuvent rester pertinentes.
Exemple :
ancien fondateur.
ancienne marque.
ancienne localisation.
Elles doivent être clairement datées.
Les liens internes peuvent matérialiser des relations.
PERSON
→ organization →
COMPANY
COMPANY
→ service →
SERVICE
L'ancre peut décrire la relation ou la destination.
Exemple :
notre méthodologie de SEO sémantique
plutôt qu'un lien générique :
cliquez ici.
Une page peut servir de hub autour d'une entité centrale.
Exemple :
BRAND
↓
products
↓
locations
↓
history
↓
people.
Un cluster peut être construit autour d'une entité plutôt qu'autour d'un mot-clé.
Topic Cluster
organise plusieurs contenus autour d'un sujet.
Entity Cluster
organise les informations relatives à une entité.
Les deux peuvent coexister.
Une page métier peut partir des entités spécifiques du secteur.
Exemple restaurant :
- Restaurant ;
- Menu ;
- Dish ;
- Chef ;
- Location ;
- Reservation.
Une pharmacie peut être reliée à :
- Organization ;
- Pharmacist ;
- Location ;
- Services ;
- Opening Hours.
Les contraintes réglementaires doivent être respectées.
Un hôtel peut inclure :
- Hotel ;
- Rooms ;
- Restaurant ;
- Spa ;
- Location ;
- Amenities.
Un e-commerce peut représenter :
- Brand ;
- Product ;
- Category ;
- Offer ;
- Organization.
Un fournisseur B2B peut représenter :
- Organization ;
- Services ;
- Products ;
- Industries ;
- Locations ;
- Experts.
Une grande entreprise peut posséder des milliers ou millions d'entités.
Le problème devient alors également :
- data engineering ;
- governance ;
- knowledge management.
Une organisation peut maintenir un registre interne des entités.
Exemple :
| ID | Entity | Type | Owner |
|---|---|---|---|
| ORG-001 | Company | Organization | Corporate |
| LOC-001 | Paris Store | Store | Retail |
| PROD-001 | Product A | Product | Product |
Les identifiants internes persistants peuvent aider à maintenir les relations lorsque :
- noms changent ;
- URLs changent ;
- langues changent.
Une architecture Enterprise peut être :
ERP
CRM
PIM
CMS
↓
ENTITY LAYER
↓
PUBLICATION
↓
SEARCH / AI
Une API peut exposer certaines informations d'entité à plusieurs systèmes.
Elle ne garantit pas que les moteurs externes l'utiliseront.
Les données peuvent être synchronisées vers :
- site ;
- apps ;
- marketplaces ;
- profils ;
- feeds.
Une source interne de référence peut réduire les contradictions.
Dans les grandes organisations, plusieurs systèmes peuvent être responsables de différents attributs.
Il faut alors définir les responsabilités.
La qualité peut être évaluée selon :
- exactitude ;
- complétude ;
- cohérence ;
- fraîcheur.
Une entité suffisamment documentée contient les attributs nécessaires pour son usage.
Cela ne signifie pas publier toutes les informations possibles.
Dans ce framework, Entity Density décrit la quantité d'entités pertinentes présentes dans un contenu.
Une densité élevée n'est pas automatiquement meilleure.
Ajouter artificiellement des noms d'entités uniquement pour tenter d'améliorer la pertinence peut produire un contenu médiocre.
Les entités doivent apparaître lorsque leur relation avec le sujet est utile.
Certaines entités sont plus centrales que d'autres dans un document.
La structure éditoriale doit refléter cette importance.
Le contexte aide à comprendre le rôle d'une entité.
Exemple :
VisiaLocal utilise Schema.org pour structurer certaines informations.
est plus précis que :
VisiaLocal Schema.org.
Une bonne description répond rapidement :
- qui ?
- quoi ?
- où ?
- pourquoi pertinent ?
Une page peut contenir du marketing.
Mais les faits concernant l'entité doivent rester distinguables.
Une Answer Unit peut répondre à une question concernant une entité.
Exemple :
Où se trouve l'entreprise ?
Quels services propose-t-elle ?
Qui l'a fondée ?
Une entité peut générer plusieurs questions :
ORGANIZATION
↓
Who?
↓
What?
↓
Where?
↓
Services?
↓
People?
↓
Evidence?
Une requête peut chercher :
- identification ;
- navigation ;
- information ;
- comparaison ;
- transaction.
Une recherche de marque est souvent une recherche d'entité.
Exemple :
VisiaLocal
Le moteur doit comprendre quelle entité est recherchée.
Une recherche non brandée peut rechercher un type d'entité.
Exemple :
agence SEO Aix-en-Provence
Un système de recherche peut récupérer des informations relatives à une entité depuis plusieurs documents.
Une réponse générative peut nécessiter de récupérer :
- identité ;
- attributs ;
- relations ;
- preuves.
Un système RAG peut organiser ou récupérer des connaissances autour d'entités.
Les implémentations varient.
Lorsque plusieurs passages sont récupérés, une identité claire aide à éviter de mélanger des informations concernant des entités différentes.
Les systèmes génératifs peuvent également rencontrer des ambiguïtés d'entités.
Une représentation publique cohérente peut réduire certaines ambiguïtés sans garantir leur élimination.
Une réponse peut citer une source contenant une information sur une entité.
Une entité peut être mentionnée sans citation.
Les deux phénomènes doivent être distingués.
Une entité peut être recommandée lorsqu'elle correspond aux critères de l'utilisateur.
Exemple :
TYPE
restaurant
LOCATION
Aix
ATTRIBUTE
gluten-free
Les recherches conversationnelles peuvent contenir de nombreux attributs.
Cela renforce l'intérêt de publier des informations précises.
Une requête peut également dépendre d'une relation.
Exemple :
agences partenaires de X.
La relation devient le critère de recherche.
Pour comparer deux entités, le système a besoin d'attributs comparables.
Dans ce framework, Entity Comparison Readiness désigne la capacité d'une entité à fournir suffisamment de faits publics pour permettre une comparaison pertinente.
Ce n'est pas une métrique officielle.
Une entité bien documentée peut être plus facile à évaluer par rapport à des critères explicites.
Cela ne garantit pas sa recommandation.
Dans ce framework, Entity Search Visibility représente la présence observable d'une entité dans différents environnements de recherche.
Une entité peut être visible :
- dans une SERP ;
- un Knowledge Panel ;
- Maps ;
- une réponse IA ;
- une citation ;
- une recommandation.
La visibilité possède plusieurs surfaces.
Exemples :
WEB SEARCH
LOCAL SEARCH
IMAGE SEARCH
SHOPPING
AI SEARCH
KNOWLEDGE PANELS
Une organisation peut donc chercher à maintenir une représentation cohérente sur plusieurs surfaces.
AEO peut utiliser les entités comme points d'ancrage des réponses.
QUESTION
↓
ENTITY
↓
ATTRIBUTE / RELATIONSHIP
↓
ANSWER
GEO peut bénéficier d'une représentation claire des entités et des faits pouvant être récupérés par les systèmes génératifs.
AI Search peut être représenté :
QUERY
↓
ENTITY / INTENT DETECTION
↓
RETRIEVAL
↓
ENTITY INFORMATION
↓
GENERATED ANSWER
Les architectures réelles varient selon les systèmes.
Semantic SEO peut utiliser les entités comme structure principale du contenu.
Le contenu répond alors :
Que devons-nous expliquer sur cette entité ?
plutôt que :
Combien de fois devons-nous utiliser ce mot-clé ?
La recherche de mots-clés reste utile.
Mais elle intervient après l'identification de l'entité.
Exemple :
ENTITY
Semantic SEO.
↓
QUESTIONS
what is semantic SEO?
semantic SEO agency?
semantic SEO strategy?
Les différentes formulations d'une même intention peuvent être regroupées autour d'une entité ou d'un besoin.
Deux pages peuvent cibler des requêtes similaires.
Le problème peut parfois être résolu en clarifiant quelle entité ou intention chaque page représente.
Dans ce framework, Entity Cannibalization désigne une situation où plusieurs pages prétendent être la représentation principale de la même entité sans fonction distincte.
Plusieurs ressources redondantes peuvent parfois être consolidées autour d'une représentation principale.
Une entité insuffisamment documentée peut nécessiter davantage d'attributs ou de relations.
Cela ne signifie pas nécessairement davantage de pages.
Le gap peut être :
- identité ;
- attribut ;
- relation ;
- preuve ;
- réponse.
Cette classification est plus précise qu'un simple « keyword gap ».
KEYWORD GAP
concurrent ranks for keyword X.
ENTITY GAP
important entity or attribute is missing from our representation.
Les deux analyses répondent à des problèmes différents.
Une opportunité peut exister lorsqu'une entreprise possède des informations uniques sur une entité mais ne les publie pas.
Une organisation possède naturellement davantage d'informations sur certaines de ses propres entités que des sources externes.
Exemple :
un fabricant connaît :
- dimensions ;
- processus ;
- matériaux ;
- variantes ;
- compatibilités.
Publier ces informations peut augmenter le gain informationnel du corpus.
Une entité importante peut être documentée à travers :
- page principale ;
- FAQ ;
- documentation ;
- études de cas ;
- données structurées.
Exemple :
ORGANIZATION
↓
claims
↓
CERTIFICATION
↓
verifiedBy
↓
CERTIFICATION BODY
ORGANIZATION A
↓
workedFor
↓
ORGANIZATION B
↓
documentedBy
↓
CASE STUDY
Les relations publiées doivent respecter les accords de confidentialité.
ORGANIZATION A
↓
partnerOf
↓
ORGANIZATION B
Une relation de partenariat doit être réelle et correctement définie.
PERSON / ORGANIZATION
↓
hasCredential
↓
CERTIFICATION
↓
issuedBy
↓
ORGANIZATION
ORGANIZATION
↓
hasLocation
↓
LOCAL BUSINESS
↓
addressLocality
↓
PLACE
BRAND
↓
offers
↓
PRODUCT
↓
hasOffer
↓
OFFER
ORGANIZATION
↓
provides
↓
SERVICE
↓
availableIn
↓
PLACE
PERSON
↓
authorOf
↓
ARTICLE
↓
about
↓
TOPIC
Les différentes relations doivent être compatibles.
Un graphe contradictoire réduit la qualité de la représentation.
Le graphe doit évoluer lorsque la réalité change.
Un audit Entity-First peut examiner :
L'entité est-elle identifiable ?
Sa nature est-elle claire ?
Les informations essentielles sont-elles disponibles ?
Les relations importantes sont-elles représentées ?
Existe-t-il des sources appropriées ?
Les représentations machine-readable sont-elles cohérentes ?
Les informations sont-elles actuelles ?
Exemple :
| Entity | Type | Primary URL | Status |
|---|---|---|---|
| Company | Organization | / | Complete |
| Founder | Person | /about | Partial |
| Service A | Service | /service-a | Complete |
| Location A | LocalBusiness | /location-a | Partial |
Exemple :
| Entity | Attribute | Available |
|---|---|---|
| Location | Address | Yes |
| Location | Hours | Yes |
| Service | Price | No |
| Service | Area | Yes |
Exemple :
| Subject | Relationship | Object | Published |
|---|---|---|---|
| Company | provides | Service A | Yes |
| Founder | founderOf | Company | Yes |
| Service A | availableIn | France | Partial |
Pour chaque information :
- source officielle ;
- source secondaire ;
- source indépendante ;
- date.
Les attributs volatils doivent être contrôlés plus fréquemment.
Identifier la réalité métier.
Lister les entités.
Déterminer leurs types.
Définir leur identité.
Documenter leurs propriétés.
Cartographier leurs relations.
Vérifier les faits.
Définir leur représentation Web.
Créer les réponses nécessaires.
Ajouter les données structurées appropriées.
Construire les liens internes.
Développer les confirmations externes légitimes.
Observer leur visibilité.
Maintenir les informations.
REALITY
↓
ENTITY DISCOVERY
↓
ENTITY INVENTORY
↓
ENTITY IDENTITY
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
FIRST-PARTY KNOWLEDGE
↓
INFORMATION NEEDS
↓
CONTENT ARCHITECTURE
↓
ENTITY PAGES
↓
ANSWER UNITS
↓
INTERNAL GRAPH
↓
STRUCTURED DATA GRAPH
↓
EXTERNAL CORROBORATION
↓
CRAWL / INDEX
↓
RETRIEVAL
↓
SEO / AEO / GEO
↓
AI SEARCH
↓
MEASUREMENT
↓
MAINTENANCE
Le principe central peut être résumé ainsi :
Before asking what keywords a business should rank for, identify what the business actually is, what it contains, what it does, and how its entities are related.
Keywords describe demand. Entities describe reality.
Une stratégie moderne peut utiliser les deux.
A website should not merely contain keywords about a business. It should represent the business.
Relationships are information.
Savoir qu'une entreprise, une personne, un service et une ville existent séparément est moins informatif que comprendre leurs relations.
Structured data should describe a semantic model, not replace one.
Le JSON-LD doit représenter une réalité déjà présente.
Entity consistency is more important than textual uniformity.
Les formulations peuvent varier.
Les faits fondamentaux doivent rester compatibles.
More entities ≠ better Entity SEO.
Seules les entités pertinentes doivent être modélisées.
Semantic SEO constitue un domaine plus large.
Entity-First SEO est une manière de commencer cette architecture depuis les entités.
Entity SEO traite généralement de l'optimisation et de la représentation des entités.
Entity-First SEO ajoute un principe méthodologique :
commencer par les entités avant de construire l'architecture de recherche.
Un Knowledge Graph est une structure de connaissances.
Entity-First SEO est une méthodologie de conception et d'optimisation.
Structured Data constitue une couche d'implémentation.
Entity-First SEO commence avant cette couche.
AEO demande :
Quelles réponses faut-il fournir ?
Entity-First SEO demande :
À quelles entités et relations ces réponses se rapportent-elles ?
GEO étudie la visibilité dans les environnements génératifs.
Entity-First SEO fournit une architecture de connaissances pouvant soutenir cette visibilité.
AI Search Optimization constitue un périmètre plus large incluant :
- retrieval ;
- sources ;
- citations ;
- réponses génératives.
Entity-First SEO constitue l'une de ses couches fondamentales.
Une petite entreprise peut commencer simplement :
BUSINESS
↓
OWNER / TEAM
↓
SERVICES
↓
LOCATION
↓
CUSTOMER QUESTIONS
Cela suffit souvent pour identifier les principales entités.
Un e-commerce peut commencer par :
ORGANIZATION
↓
BRANDS
↓
CATEGORIES
↓
PRODUCTS
↓
OFFERS
↓
ATTRIBUTES
Un réseau peut modéliser :
BRAND
↓
LOCATIONS
↓
LOCAL ATTRIBUTES
↓
LOCAL SERVICES
Une entreprise internationale peut modéliser :
GROUP
↓
BRANDS
↓
SUBSIDIARIES
↓
COUNTRIES
↓
LOCATIONS
↓
PRODUCTS
↓
PEOPLE
↓
CONTENT
Les agents peuvent avoir besoin de comprendre :
- quelle entité fournit un service ;
- quelles conditions s'appliquent ;
- où ;
- à quel prix ;
- avec quelle disponibilité.
Une représentation précise peut faciliter certaines interactions futures.
Une entité peut également être représentée par :
- texte ;
- image ;
- vidéo ;
- audio.
Les différents formats doivent rester associés à la bonne entité.
Une image produit doit être reliée au bon produit.
Une photo d'établissement doit être reliée au bon lieu.
Une vidéo de démonstration peut être reliée :
- au produit ;
- au service ;
- à l'expert.
Une entité peut posséder plusieurs représentations linguistiques sans devenir plusieurs entités.
Exemple :
SAME ORGANIZATION
↓
French page
↓
English page
↓
German page.
Changer de langue ne change pas nécessairement l'identité de l'entité.
En revanche, une filiale locale peut constituer une entité différente.
Exemple :
GLOBAL GROUP
↓
FRANCE SUBSIDIARY
↓
GERMANY SUBSIDIARY
Les attributs peuvent varier selon le marché :
- prix ;
- catalogue ;
- services ;
- contacts.
À grande échelle, l'objectif est d'éviter :
MILLIONS OF PAGES
↓
without
↓
COHERENT ENTITY MODEL
L'architecture doit partir du modèle de données.
Dans le framework VisiaLocal :
ENTITY-FIRST SEARCH ENGINEERING
combine :
- entity modeling ;
- data architecture ;
- content architecture ;
- structured data ;
- technical SEO ;
- retrieval thinking ;
- measurement.
Ce terme est utilisé comme modèle méthodologique.
Le Keyword Map classique :
| Keyword | Volume | URL |
|---|---|---|
| Keyword A | 1000 | /page-a |
| Keyword B | 500 | /page-b |
peut être complété par :
| Entity | Attributes | Relationships | Primary URL |
|---|---|---|---|
| Organization | name, location | provides Service | / |
| Service | price, area | providedBy Organization | /service |
| Location | hours, address | partOf Organization | /location |
Le Keyword Map reste utile pour comprendre :
- vocabulaire ;
- demande ;
- volumes ;
- concurrence.
Entity-First ne cherche pas à le supprimer.
Une architecture plus riche peut connecter :
ENTITY
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
QUESTIONS
↓
SEARCH QUERIES
↓
PAGE
↓
ANSWER UNITS
Les recherches conversationnelles permettent aux utilisateurs de combiner de nombreux critères.
Exemple :
Trouve une agence à Aix qui travaille sur le SEO sémantique, les données structurées et la visibilité dans les IA.
Pour répondre, le système doit potentiellement relier :
ORGANIZATION
PLACE
SERVICE
CAPABILITY
Une représentation Entity-First fournit précisément ce type de structure informationnelle.
Entity-First SEO ne garantit pas :
- classement ;
- Knowledge Panel ;
- AI Overview ;
- citation ;
- recommandation ;
- trafic ;
- conversion.
Il fournit une architecture permettant de mieux représenter une organisation et ses connaissances.
Entity-First SEO n'est pas :
- du keyword stuffing d'entités ;
- une liste de
sameAs; - uniquement du JSON-LD ;
- uniquement un Knowledge Graph ;
- une technique de backlink ;
- une garantie de Knowledge Panel ;
- une méthode pour manipuler les LLM.
Les utilisateurs doivent également bénéficier du modèle.
Une bonne représentation d'entité facilite :
- compréhension ;
- navigation ;
- comparaison ;
- vérification.
L'objectif n'est pas de choisir entre humains et machines.
Une architecture efficace peut servir :
HUMANS
SEARCH ENGINES
AI SYSTEMS
Un modèle conceptuel peut être :
Les principales entités sont connues.
Leurs attributs sont disponibles.
Leurs relations sont cartographiées.
Les informations pertinentes sont accessibles publiquement.
Certaines informations sont représentées en structured data.
Des sources externes légitimes confirment certaines informations.
Les informations sont régulièrement vérifiées.
La visibilité des entités est observée.
Ce modèle n'est pas une échelle officielle de moteur de recherche.
Quelles entités existent réellement ?
Comment sont-elles identifiées ?
Que savons-nous sur elles ?
Comment sont-elles connectées ?
Quelles informations propriétaires possédons-nous ?
Où doivent-elles être représentées ?
Quelles questions concernent ces entités ?
Quelles relations peuvent être représentées ?
Quelles sources externes sont légitimes ?
Les informations sont-elles actuelles ?
Comment observons-nous leur visibilité ?
Ce référentiel distingue :
- Entity ;
- Entity Resolution ;
- Entity Disambiguation ;
- Knowledge Graph ;
- Structured Data ;
- Schema.org ;
- JSON-LD.
- Entity SEO ;
- Semantic SEO ;
- Topical Authority.
- Entity-First SEO ;
- Entity Home ;
- Entity Boundary ;
- Entity Coverage ;
- Attribute Coverage ;
- Relationship Coverage ;
- Entity Fragmentation ;
- Entity Drift ;
- Entity Cannibalization ;
- Entity Comparison Readiness ;
- Entity-First Search Engineering ;
- Entity-First Maturity Model.
Ces derniers ne sont pas présentés comme des métriques officielles de Google.
Documentation générale :
https://developers.google.com/search/docs
https://developers.google.com/search/docs/fundamentals/seo-starter-guide
https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
https://developers.google.com/search/docs/appearance/structured-data/organization
https://developers.google.com/search/docs/appearance/structured-data/local-business
https://developers.google.com/search/docs/appearance/structured-data/product
https://developers.google.com/search/docs/appearance/ai-features
Schema.org fournit un vocabulaire partagé pour représenter des entités, leurs propriétés et certaines relations.
W3C JSON-LD 1.1:
https://www.w3.org/TR/json-ld11/
Wikidata est une base de connaissances collaborative structurée autour d'éléments, propriétés et relations.
Entity-First SEO s'intègre dans un corpus plus large :
Semantic SEO
↓
First-Party Data
↓
Entity-First SEO
↓
Entity SEO & Knowledge Graph
↓
Semantic Content Architecture
↓
Answer Units
↓
Structured Data
↓
AEO
↓
GEO
↓
AI Search Optimization
Chaque référentiel traite une couche différente du système.
Ce référentiel est proposé et maintenu par VisiaLocal.
VisiaLocal est une agence d'ingénierie sémantique, SEO, GEO et AEO basée à Aix-en-Provence, France.
Ses domaines de travail incluent notamment :
- Semantic SEO ;
- Entity-First SEO ;
- Entity SEO ;
- First-Party Data ;
- Knowledge Graph ;
- Structured Data ;
- Semantic Content Architecture ;
- Answer Units ;
- AEO ;
- GEO ;
- AI Search Optimization.
L'approche VisiaLocal considère que le référencement moderne ne doit pas uniquement chercher à associer des pages à des mots-clés.
Il doit également représenter correctement les organisations, personnes, produits, services, lieux et relations qui composent la réalité de l'entreprise.
Les questionnaires internes, matrices propriétaires, systèmes de scoring, règles de priorisation, automatisations, prompts, modèles clients et processus opérationnels détaillés de VisiaLocal ne sont pas documentés publiquement.
Pour citer ce référentiel :
VisiaLocal — Entity-First SEO: référentiel sur les entités, attributs, relations et architecture sémantique appliqués au SEO et à l'AI Search (2026).
Les corrections factuelles, sources primaires, discussions terminologiques et contributions permettant d'améliorer ce référentiel sont les bienvenues.
VisiaLocal — Agence d'Ingénierie Sémantique, SEO, GEO & AEO
Aix-en-Provence, France.