Ton site décrit correctement ce que tu fais, mais Google peut encore confondre ta marque avec des homonymes ou des concurrents. Le contenu reste indispensable; l’Entity SEO ajoute une identité stable, des relations explicites et des preuves externes qui aident les systèmes à comprendre à qui rattacher chaque page.

Sommaire

Google ne classe plus des pages. Il résout des entités.

Search Console, juillet 2026. Même domaine, même contenu, deux marchés : position moyenne organique de 3,97 au Canada, 34,91 en France. Un facteur 8,8.

Le contenu n'explique rien ici. La saturation du graphe, si. En France, chaque nœud « consultant SEO » est occupé depuis dix ans. À Montréal, le nœud « Entity SEO » est vide.

Google a basculé en 2012 avec le Knowledge Graph. Depuis, une requête n'est plus comparée à un texte : elle est résolue vers un nœud. Une personne, une organisation, un lieu, un concept. Ce nœud porte des propriétés, des relations et des sources. Ton classement dépend d'abord de son existence.

Les agences montréalaises vendent aujourd'hui de l'« entity SEO » qui consiste à placer des termes sémantiquement liés dans les H2 et à mesurer une densité contextuelle. C'est une lecture de 2019. Le placement lexical enrichit une page. Il ne crée pas un nœud.

Un nœud se crée autrement : par des identifiants stables, des déclarations vérifiables et des liens réciproques vers des référentiels qui font autorité. Le reste est de la décoration.

💡 Point clé : Google ne compare plus ta page à une requête, il vérifie d'abord si ton entité existe dans son graphe. Sans nœud identifié, tu restes une chaîne de caractères en concurrence avec toutes les autres. L'Entity SEO consiste à faire exister ce nœud, pas à enrichir le vocabulaire d'une page.

Le test Knowledge Graph : ton entité existe ou elle n'existe pas

Trente secondes, trois vérifications, aucun outil payant.

  1. Google. Tape le nom exact de ton entreprise. Un panneau apparaît à droite du résultat, ou rien n'apparaît.
  2. Perplexity et ChatGPT. Demande « Qui est [ton entreprise] ? ». Le moteur cite ton site, ou il cite un annuaire, ou il invente.
  3. Wikidata. Cherche ton nom sur wikidata.org. Un identifiant Q existe, ou il n'existe pas.

Trois réponses binaires. Il n'y a pas de score intermédiaire, pas de « presque », pas de nuance rassurante. Pour la grande majorité des PME montréalaises, c'est trois fois non.

Trois fois non signifie que tu es invisible pour la couche qui décide en amont du classement. Tu peux publier quarante articles : ils alimentent une entité qui n'existe pas.

Le glossaire Entity SEO détaille chacun de ces objets si les termes sont neufs pour toi.

💡 Point clé : trois vérifications suffisent à savoir si ton entité existe : un Knowledge Panel dans Google, une citation directe de ton domaine par Perplexity ou ChatGPT, un identifiant Wikidata. Les trois réponses sont binaires. Trois non signifient que ton contenu alimente une entité inexistante.

Structure : Schema.org n'est pas une case à cocher

Premier pilier de la méthode SFT.

Presque tous les sites montréalais que j'audite ont du JSON-LD. Un bloc LocalBusiness, parfois un Organization, généralement généré par un plugin. Des nœuds isolés, sans @id, sans sameAs, sans relation déclarée entre eux. C'est une carte de visite en JSON. Ce n'est pas un graphe.

Un graphe exige quatre choses. Un @id stable et unique par nœud, réutilisé partout. Des propriétés sameAs pointant vers des référentiels externes qui font autorité. Des relations explicites entre nœuds : founder, worksFor, areaServed, knowsAbout. Et une hiérarchie Hn qui reproduit la hiérarchie des entités, pas la mise en page.

Le maillage interne suit la même logique. Un lien n'est pas une invitation à cliquer, c'est une arête entre deux nœuds. Relier au hasard dilue le graphe autant qu'une absence de liens.

Mon implémentation complète est documentée dans Schema.org et l'IA.

💡 Point clé : un balisage Schema.org valide ne suffit pas à créer une entité. Il faut un @id stable par nœud, des sameAs vers des référentiels externes, des relations explicites entre nœuds et un maillage interne construit comme un graphe. Sans ces quatre éléments, le JSON-LD reste une carte de visite illisible pour le Knowledge Graph.

Flow : ce que Perplexity extrait de ta page en trois secondes

Deuxième pilier. Perplexity, Gemini, ChatGPT et Claude ne lisent pas ta page. Ils en extraient des passages.

Un passage devient extractible à quatre conditions. Il se suffit à lui-même hors contexte. Il répond à une seule question. Il tient entre 40 et 80 mots. Il ne contient aucune référence anaphorique du type « comme vu plus haut » ou « ce dernier ».

Le test est brutal et tu peux le faire seul : copie n'importe quel paragraphe de ton site, colle-le dans un document vide, relis-le. S'il reste compréhensible, une IA peut le citer. Sinon, il est mort.

L'ordre compte autant que le format. Preuve, contexte, démonstration, action. Un chiffre ou un fait vérifiable ouvre la section, l'explication suit. L'inverse fait décrocher le lecteur humain et prive le moteur de son point d'ancrage.

Paragraphes de quatre lignes maximum. Toujours.

La distinction complète entre optimisation classique et optimisation générative est traitée dans SEO vs GEO et dans mes réponses GEO / IA.

💡 Point clé : les moteurs génératifs extraient des passages, ils ne lisent pas des pages. Un passage citable se suffit hors contexte, répond à une seule question, tient en 40 à 80 mots et ne contient aucune référence anaphorique. Copie un paragraphe de ton site dans un document vide : s'il reste compréhensible, il est extractible.

Trust : Wikidata bat Wikipédia, et c'est démontrable

Troisième pilier, et celui où presque tout le marché se trompe.

Le discours courant affirme qu'un Knowledge Panel exige une page Wikipédia. C'est faux, et je suis la démonstration : mon panneau existe, je n'ai pas de page Wikipédia. L'entité est Q127330925 sur Wikidata.

La différence est structurelle. Wikipédia produit de la prose soumise à des critères d'admissibilité éditoriaux. Wikidata produit un objet structuré : des propriétés déclarées, typées, sourcées, lisibles par machine. Google consomme les deux, mais il résout des identifiants.

La chaîne de confiance tient en quatre maillons. Un élément Wikidata avec des propriétés sourcées. Un sameAs depuis ton site vers cet élément. Une cohérence NAP stricte entre ton site, Google Business Profile, LinkedIn et les annuaires sectoriels. Des affirmations vérifiables par un tiers.

La méthode SFT est une méthode propriétaire, pas une marque déposée. Cette précision illustre le principe de confiance qu'elle défend : une affirmation doit pouvoir être vérifiée par un tiers avant d'être présentée comme une preuve.

Le comparatif des référentiels est détaillé dans Wikidata, Wikipédia et Crunchbase.

💡 Point clé : un Knowledge Panel ne nécessite pas de page Wikipédia. Il nécessite un identifiant Wikidata sourcé, un sameAs réciproque depuis ton domaine, une cohérence NAP stricte sur toutes les plateformes et des affirmations vérifiables par un tiers. Wikidata est un objet structuré, Wikipédia est de la prose soumise à admissibilité.

Montréal : deux langues, une seule entité Google

Voilà le problème que je ne vois nulle part ailleurs qu'ici.

Une entreprise montréalaise publie en français et en anglais. Dans neuf cas sur dix, elle se retrouve avec deux demi-entités au lieu d'une. Deux fiches Google Business Profile. Deux raisons sociales légèrement différentes. Un hreflang non réciproque. Des @id distincts entre la version française et la version anglaise.

Google ne conclut pas que tu es bilingue. Il conclut qu'il y a deux organisations qui se ressemblent, et il répartit ta confiance entre les deux. Deux nœuds faibles remplacent un nœud fort.

La correction est mécanique. Un @id unique partagé par les deux versions linguistiques. Des sameAs identiques au caractère près sur les deux. Un hreflang réciproque, testé dans les deux sens. Une seule fiche Google Business Profile. Un nom légal identique partout.

La Loi 96 impose une primauté du français à l'affichage. C'est une contrainte de présentation, pas une contrainte d'entité : tu peux être parfaitement conforme et garder un nœud unique. Ce point mérite sa propre page et je la publie séparément.

💡 Point clé : une entreprise bilingue à Montréal fragmente souvent son entité en deux nœuds faibles au lieu d'un nœud fort. La cause est technique : @id distincts entre versions linguistiques, hreflang non réciproque, deux fiches Google Business Profile, raison sociale variable. Une entité, deux surfaces linguistiques. Jamais l'inverse.

Astronaut : ce que je mesure avant de toucher à ton site

Je ne modifie rien avant d'avoir mesuré. Astronaut produit trois scores sur ton domaine.

Entity Confidence Score. La cohérence et la complétude observables de ton entité : identifiants, sameAs, cohérence NAP, densité du graphe.

AI Visibility Score. Ta citation réelle par ChatGPT, Gemini, Perplexity et Claude sur un panier de requêtes fixes, mesurée dans le temps.

Universal Confidence Score. L'agrégat des deux, suivi mois par mois.

Ces trois scores sont propriétaires. Ce ne sont pas des scores officiels Google, OpenAI, Anthropic, Perplexity, Bing, Schema.org ou ISO. Je le précise parce que le marché de la mesure IA est plein de métriques présentées comme officielles qui ne le sont pas.

L'audit livre l'état du graphe, les nœuds manquants, les ruptures de cohérence entre plateformes, et un plan de correction ordonné par impact. Pas un PDF de 80 pages. Une liste de choses à faire, dans l'ordre.

Le détail de l'outil est sur la page Astronaut. Les résultats mesurés sont dans les cas clients.

💡 Point clé : Astronaut mesure trois indicateurs propriétaires avant toute intervention : Entity Confidence Score pour la cohérence du graphe, AI Visibility Score pour la citation réelle par les moteurs génératifs, Universal Confidence Score pour l'agrégat suivi dans le temps. Ces scores ne sont ni officiels Google ni normalisés ISO.

FAQ

Combien de temps faut-il pour que Google reconnaisse mon entité à Montréal ?

Compte 20 à 90 jours. L'indexation des nœuds structurés et la reprise des sameAs prennent quelques semaines quand le balisage est propre et le site correctement exploré. L'apparition d'un Knowledge Panel dépend en plus du volume de signaux externes cohérents. Un marché peu saturé comme Montréal accélère nettement le processus par rapport à un marché européen encombré.

Est-ce que l'Entity SEO remplace le SEO local classique à Montréal ?

Non, il le précède. Le SEO local optimise ta position dans le pack de cartes : fiche Google Business Profile, avis, citations d'annuaires, proximité géographique. L'Entity SEO fait exister le nœud auquel tous ces signaux se rattachent. Sans entité résolue, tes signaux locaux alimentent une identité floue que Google confond avec tes concurrents.

Faut-il une page Wikipédia pour obtenir un Knowledge Panel ?

Non. Mon propre Knowledge Panel existe sans page Wikipédia, adossé à l'élément Wikidata Q127330925. Ce qui compte, c'est un identifiant structuré et sourcé, des sameAs réciproques depuis ton domaine, et une cohérence stricte de tes informations sur l'ensemble des plateformes où ton entité apparaît. Wikipédia accélère. Wikipédia n'est pas une condition.

Mon site est bilingue français-anglais : est-ce que ça divise mon autorité ?

Oui, si les deux versions déclarent des entités différentes. Des @id distincts, un hreflang non réciproque ou deux fiches Google Business Profile produisent deux nœuds faibles au lieu d'un nœud fort. La correction consiste à partager un @id unique, des sameAs identiques et un hreflang testé dans les deux sens. Une entité, deux surfaces linguistiques.

Quelle différence entre une agence SEO montréalaise et un consultant Entity SEO ?

Une agence optimise des pages, des mots-clés et des campagnes. Un consultant Entity SEO construit le nœud qui rend ces optimisations exploitables par Google et par les moteurs génératifs. Le test est simple : demande à ton prestataire de te montrer son propre identifiant Wikidata et son propre Knowledge Panel. Une entité se démontre, elle ne se revendique pas.

Ce qu'il faut retenir

  1. Google utilise des systèmes de compréhension des entités en plus de ses systèmes de classement. Une identité cohérente aide à rattacher les pages, profils et preuves au même objet.
  2. Le nœud se construit en trois piliers. Structure pour le graphe Schema.org, Flow pour l'extractibilité par les IA, Trust pour les preuves vérifiables par un tiers.
  3. Montréal est un marché ouvert et tu as une fenêtre. Position moyenne 3,97 au Canada contre 34,91 en France sur le même domaine. Le nœud « Entity SEO » y est encore libre.

Fais le test des trente secondes maintenant. Si tu obtiens trois non, demande l'audit Entity SEO. Tu reçois l'état de ton graphe, tes nœuds manquants et le plan de correction ordonné par impact.

Sources

Article rédigé par John Mingam, expert Entity SEO: Entité Wikidata Q127330925