Cohérence d’entité SEO local : mon site avait 3 noms, pas 1

Mis à jour le 12 octobre 2026

La cohérence d’entité en SEO local, c’est faire en sorte que Google lise une seule entreprise là où il en voit plusieurs : même nom, même adresse, même téléphone sur la fiche Google Business Profile, sur le site, dans le balisage JSON-LD et dans les annuaires. J’ai passé une journée à le corriger chez moi, parce que mon propre site se présentait sous trois noms différents.

J’ai passé une journée entière sur un truc qui ne se voit pas. Pas une refonte, pas un nouveau contenu, pas une campagne de liens. Juste à faire en sorte que Google comprenne que ma fiche Google Business Profile, mon site et le balisage JSON-LD de ma home parlent tous de la même entreprise. Ce n’était pas le cas, et cela m’a probablement coûté de la visibilité locale sans que je m’en rende compte.

Cet article, c’est le détail de ce que j’ai fait, dans l’ordre, avec les pièges rencontrés. Si vous gérez votre propre fiche et un site WordPress sous Rank Math, vous allez sans doute reconnaître au moins trois de vos erreurs là-dedans. Je les avais toutes.

Qu’est-ce que la cohérence d’entité en SEO local, et pourquoi compte-t-elle ?

La cohérence d’entité, c’est le fait que toutes les sources qui décrivent votre entreprise (fiche Google, site visible, balisage structuré, annuaires) racontent la même histoire : même nom, même adresse, même téléphone, mêmes identifiants. Google s’en sert pour décider s’il a affaire à une entité unique et fiable, ou à plusieurs entités floues qu’il n’arrive pas à recoller.

Quand les sources divergent, Google ne sait pas qui vous êtes, et une entité mal comprise se classe mal en local. Google le dit lui-même : les résultats locaux reposent surtout sur la pertinence, la distance et la notoriété. Des informations complètes et cohérentes servent la pertinence, et la notoriété passe par les avis et les liens. Trois noms différents pour la même boîte, c’est exactement le contraire de la confiance.

Mon cas de départ était un manuel des erreurs à ne pas faire. Ma fiche s’appelait WebStrategy. Mon site se présentait sous trois noms selon l’endroit où on regardait : « Sébastien Chaffer » dans un bloc, « WordPress Freelance » dans deux autres. Et le mot « WebStrategy », ma vraie marque, celle de la fiche, n’apparaissait nulle part dans mon balisage. Google avait donc une fiche d’un côté, un site de l’autre, et aucun pont solide entre les deux.

Partie 1 : comment j’ai corrigé ma fiche Google Business Profile

L’état des lieux n’était pas glorieux

Ma fiche était techniquement valide, mais sous-exploitée au point d’être contre-productive. Le diagnostic, point par point :

• Catégorie principale réglée sur « Consultant informatique ». Générique, vague, déconnectée de mon métier réel, qui est le SEO et GEO.
• Avis : un seul, noté 5 sur 5, ce qui est joli mais statistiquement inexistant.
• Description : un bloc de mots-clés collés sans ponctuation propre, du genre « Consultant SEO & GEO à Paris Creation site Internet WordPress Symfony Hébergement & maintenance ». Du keyword stuffing pur, le truc que je déconseille à mes clients et que j’avais laissé traîner chez moi.
• Photos : le logo et une vue extérieure.
• Posts Google : un seul, daté du 27 mai.
• Profils liés : LinkedIn uniquement.

La catégorie principale, ce premier levier qu’on néglige tous

La catégorie principale est, selon Whitespark, le facteur de classement local le plus important, d’après son étude annuelle sur les facteurs de ranking local. Je l’avais laissée au pifomètre depuis l’ouverture de la fiche. Pour le reste des fondamentaux, j’ai détaillé les leviers du classement local dans un autre article.

J’ai basculé la catégorie principale de « Consultant informatique » à « Consultant en marketing ». Petit problème au passage : je n’ai pas trouvé de catégorie « Consultant SEO » dans la liste en français. Il faut donc choisir le libellé existant le plus proche de votre cœur de métier, et « Consultant en marketing » est ce qui colle le mieux quand on fait du SEO et du GEO. J’ai ajouté deux catégories secondaires : « Service de marketing sur Internet » et « Concepteur de sites Web ».

Un point que je note pour ne pas paniquer : après un changement de catégorie principale, je m’attends à voir les positions locales bouger les premiers jours. Il ne faut surtout pas revenir en arrière en voyant les positions trembler, sinon on relance le cycle pour rien.

Réécrire la description comme un humain, pas comme un robot à mots-clés

J’ai tout réécrit en prose lisible. Voici le texte que j’ai déployé :

Consultant SEO et GEO à Paris. J’aide les entreprises à rester visibles sur Google, et désormais dans les réponses des IA comme ChatGPT, Perplexity ou Gemini. Concrètement : audit et SEO technique, contenu pensé pour être cité, sites WordPress rapides qui tiennent dans le temps. Je développe aussi sur mesure en WordPress et Symfony, et je gère l’hébergement et la maintenance. 20 ans de métier, des projets menés pour de grands comptes comme pour des indépendants. Installé dans le 20e, j’interviens à Paris et à distance.

Le détail technique à retenir : la description est limitée à 750 caractères, et seuls les 250 premiers sont visibles avant le « voir plus ». Le positionnement (SEO et GEO à Paris) passe donc en tête, et tout ce qui est secondaire vient après le pli.

Vérifier le NAP avant tout le reste

NAP, c’est le trio Nom / Adresse / Téléphone, la colonne vertébrale de l’identité locale. J’ai vérifié que les trois étaient strictement identiques entre la fiche et le site :

• Nom : WebStrategy
• Adresse : 66 Rue des Couronnes, 75020 Paris
• Téléphone : 06 09 75 36 55

Strictement identiques, cela veut dire au caractère près. « Rue » et « rue », « 75020 Paris » et « Paris 75020 », ce sont des divergences pour un moteur. J’y reviens dans la partie schema, parce que c’est là que ça s’est joué.

Le lien qui soude la fiche au site

C’est l’étape la plus importante et la plus discrète. J’ai récupéré l’URL courte de ma fiche (https://share.google/GkgEfWEvVXvWEyRq3) et je l’ai ajoutée comme sameAs dans le balisage de mon site. Concrètement, je dis à Google : « cette fiche locale et ce site, c’est la même entité ». C’est ce lien qui transforme deux objets séparés en une seule entité reconnue.

Ce qu’il me reste à faire sur la fiche

Trois chantiers que je n’ai pas pu boucler dans la journée parce qu’ils s’étalent dans le temps :

• Les avis sont mon levier de classement local le plus fort en l’état, puisque je pars de un. Google rappelle que le nombre d’avis positifs aide le classement. Je vais solliciter mes clients actifs avec le lien d’avis direct, étalé sur plusieurs semaines : un afflux d’avis le même jour me paraît suspect. Et je répondrai à chacun. Pour le reste des fondamentaux, j’ai détaillé sept conseils pour travailler son SEO local dans un autre article.
• Les photos : je vais y verser régulièrement des captures de dashboards et de réalisations, plutôt que de tout poster d’un coup puis de laisser la fiche dormir.
• Les posts, en cadence hebdomadaire, en recyclant mes contenus de blog. Et je dois remplir la section Prestations et pré-rédiger trois ou quatre questions/réponses dans la partie Q&A.

Partie 2 : comment j’ai recollé le schema avec Rank Math

C’est là que c’était vraiment cassé, et c’est là que la majorité des gens passent à côté, parce que ça ne se voit pas sans aller lire le JSON-LD source.

Quel était le diagnostic de mon schema ?

Quand j’ai extrait le JSON-LD de ma home, j’ai trouvé six problèmes :

• Trois noms pour une seule entité. Un bloc hybride Organization/Person nommé « Sébastien Chaffer », un WebSite et un ProfessionalService nommés « WordPress Freelance ». Et « WebStrategy », ma marque réelle, absente partout.
• Un type hybride ["Organization", "Person"]. Un nœud qui se déclare à la fois organisation et personne, ce qui est ambigu pour Google et brouille la lecture de l’entité.
• Un ProfessionalService sans adresse ni téléphone. Le nœud censé porter le NAP local de l’entreprise était vide de NAP. Toute mon adresse vivait sur le nœud Person, c’est-à-dire sur moi en tant que personne, pas sur l’entreprise.
• Des formats de téléphone qui changeaient selon les blocs : 0609753655, +33609753655, 06.09.75.36.55. Trois écritures pour un seul numéro.
• Une casse d’adresse sale : « PARIS » et « ile de france » d’un côté, « Paris » de l’autre.
• L’adresse nulle part en clair. Elle n’existait qu’en JSON-LD, sans aucun bloc NAP visible en pied de page.

Le point clé avant de corriger, c’est d’où viennent les nœuds. Chez moi, Rank Math générait cinq nœuds : Place, Organization, WebSite, ImageObject et WebPage. Les deux autres, un Person riche et le ProfessionalService, venaient d’un schema JSON-LD personnalisé que j’avais ajouté dans l’éditeur Schema de Rank Math. Savoir qui produit quoi détermine où on corrige : les réglages SEO local de Rank Math pour les cinq premiers, le JSON-LD personnalisé de l’éditeur Schema pour les deux autres.

Quels réglages Rank Math ai-je modifiés dans le SEO local ?

Direction Rank Math, Réglages du titre, SEO local, module « Local SEO & Knowledge Graph » actif. Selon la documentation de Rank Math, ce module distingue le nom du site, le nom alternatif et le nom de la personne ou de l’organisation destiné au Knowledge Panel.

Le champ Personne ou Entreprise passe sur Organisation. Nom de l’entreprise sur WebStrategy, Nom alternatif sur WordPress Freelance (mon ancien nom, que je garde comme alias historique).

Et là, le piège. Le champ qui s’appelle Nom de la personne / organisation, je l’ai passé sur WebStrategy. Dans mon cas, c’est ce champ-là, et pas « Nom de l’entreprise », qui alimentait le name du nœud Organization du Knowledge Graph. Tant qu’il contenait « Sébastien Chaffer », mon Organization sortait sous mon nom de personne. Complètement contre-intuitif : le champ qui ressemble au bon ne l’est pas.

Deuxième point, et c’est là que mon cas diffère de la recette qu’on lit partout. Le select Type d’entreprise de Rank Math, je l’ai laissé sur Organization. La logique habituelle voudrait qu’on le bascule sur ProfessionalService, un sous-type de LocalBusiness, pour accrocher le NAP local. Sauf que mon ProfessionalService, je le gère en JSON-LD personnalisé dans l’éditeur Schema, avec un contrôle total sur ses propriétés et son @id. Si je l’activais aussi dans Rank Math, je me retrouverais avec deux ProfessionalService concurrents. Je laisse donc Rank Math produire une Organization propre, et c’est mon nœud custom qui porte le LocalBusiness.

À retenir : le bon réglage dépend de qui gère quoi. Si vous n’avez pas de schema custom, basculez le select sur ProfessionalService. Si vous en avez un qui porte déjà ce type, laissez Rank Math sur Organization pour ne pas dupliquer.

Le reste se remplit proprement : adresse en champs séparés avec une casse correcte (66 Rue des Couronnes / Paris / 75020 / FR), email de contact, et les horaires réels, qui ne sont pas un simple lundi-vendredi uniforme chez moi mais variables selon les jours (matinée seule le mercredi, fin plus tôt le vendredi). Rank Math gère ces plages au format 24:00 sans broncher. Google recommande d’ailleurs de renseigner l’adresse, le téléphone et les horaires dans le balisage d’une entreprise locale.

Quels identifiants officiels renseigner (Additional Info) ?

Dans la section Additional Info du schema Organization, j’ai rempli ce qui a du sens pour une activité de conseil française. Les champs DUNS, NAICS, LEI, ISO 6523 relèvent du registre B2B international, cela ne me concerne pas. En revanche :

• Legal Name : Sébastien Chaffer. En entrepreneur individuel, le nom légal est le nom propre, pas la marque.
• Founding Date : 2019-09-30 (Rank Math n’a gardé que l’année dans le rendu, mais on saisit la date complète).
• VAT ID : FR50853894731.
• Tax ID : 85389473100019, mon SIRET.

Ces identifiants servent l’E-E-A-T : une entité française qui expose son SIRET et sa TVA est une entité vérifiable, et Pappers reprend justement le SIREN, ce qui crée un point de recoupement externe.

C’est aussi dans cet écran que se règlent le téléphone, l’échelle de prix et les coordonnées GPS. Le téléphone est en +33609753655, format E.164, type « Service Clients ». L’échelle de prix sur $$. Et les coordonnées au format latitude,longitude séparées par une virgule : un format invalide, Rank Math le signale en rouge, donc impossible de se tromper longtemps.

Comment centraliser les profils sociaux et le sameAs ?

Direction Rank Math, Réglages du titre, Métadonnées sociales, champ Profils supplémentaires. Chez moi, c’est lui qui alimente la propriété sameAs. J’y ai centralisé :

https://share.google/GkgEfWEvVXvWEyRq3
https://www.pappers.fr/entreprise/webstrategy-853894731
https://www.linkedin.com/in/chaffer/
https://www.malt.fr/profile/sebastienchaffer0wordpress0developpeur
https://github.com/WordPress-freelance

Avant, mes sameAs étaient éparpillés sur plusieurs nœuds. Les regrouper ici les attache tous à l’entité principale Organization, ce qui donne un signal d’entité unifié au lieu de plein de petits signaux dispersés. Et la présence de la fiche Google et de Pappers dans cette liste soude l’entité locale et l’entité légale au site.

Comment corriger le schema personnalisé de l’éditeur Schema ?

Mes nœuds Person et ProfessionalService venant du JSON-LD personnalisé, c’est dans l’éditeur Schema de Rank Math que ça se corrige, pas dans les réglages SEO local.

Sur le ProfessionalService :

• j’ai renommé le name de « WordPress Freelance » en WebStrategy et basculé l’alternateName sur « WordPress Freelance » ;
• j’ai ajouté l’address complète et le contactPoint avec le téléphone E.164, ce qui comblait le NAP manquant ;
• j’ai corrigé founder et employee, qui pointaient vers un #person inexistant : ils référencent maintenant #sebastien-chaffer, l’@id réel du nœud Person ;
• j’ai complété les sameAs avec Google et Pappers ;
• j’ai résolu un conflit d’@id de logo : le ProfessionalService partageait #logo avec l’Organization, alors qu’un @id doit être unique.

Sur le Person :

• j’ai retiré « Directeur Général Associé » du jobTitle pour ne garder que « Consultant SEO/GEO et Expert WordPress » ;
• j’ai sorti de la description toute mention qui diluait l’entité de référence, qui est WebStrategy ;
• j’ai corrigé worksFor, qui créait un doublon #webstrategy : il pointe désormais vers #organization ;
• j’ai gardé les nœuds riches (hasOccupation, knowsAbout, knowsLanguage, alumniOf, estimatedSalary avec un TJM médian), parce qu’ils nourrissent l’E-E-A-T et donnent de la matière citable aux IA.

Sur l’Organization, un petit nettoyage : une virgule parasite dans la description (« WordPress , et »).

Pourquoi mon schema affichait-il douze nœuds au lieu de sept ?

Première version après injection : mon schema custom contenait les sept nœuds complets (Place, Organization, WebSite, ImageObject, WebPage, Person, ProfessionalService). Sauf que Rank Math génère déjà ses cinq. Résultat : ma home affichait douze nœuds, avec des doublons partout. Place deux fois, Organization deux fois, et ainsi de suite. Cela m’a fait perdre une demi-heure.

La règle que j’en tire : un schema custom ne doit jamais contenir un nœud déjà produit par le plugin SEO. Il ne doit ajouter que ce qui manque, et pointer vers les nœuds existants par leur @id. C’est exactement la logique que j’ai appliquée quand j’ai déployé du schema sur toute l’architecture du site. J’ai donc vidé mon custom de tout sauf Person et ProfessionalService, et fait pointer le ProfessionalService vers #organization (généré par Rank Math) pour relier les deux sources sans rien dupliquer.

Le résultat : sept nœuds, zéro doublon

Après crawl de la home, voici le graphe final. Une seule entité, racontée d’une seule voix, chaque source pointant au bon endroit :

Nœud	Source	name	NAP
Place	Rank Math	aucun	adresse + geo
Organization	Rank Math	WebStrategy	adresse + tél + 5 sameAs
WebSite	Rank Math	WebStrategy (alt. WordPress Freelance)	aucun
ImageObject	Rank Math	aucun	bannière OG
WebPage	Rank Math	Consultant SEO/GEO à Paris…	aucun
Person	JSON-LD perso (Rank Math)	Sébastien Chaffer	adresse + tél + 3 sameAs
ProfessionalService	JSON-LD perso (Rank Math)	WebStrategy (alt. WordPress Freelance)	adresse + tél + 5 sameAs

Le test des résultats enrichis de Google confirme le découpage : un bloc « Commerces et services à proximité » valide (mon ProfessionalService/LocalBusiness) et deux éléments « Organisation » valides. Les problèmes signalés sont non critiques : des recommandations, pas des erreurs bloquantes.

Pourquoi ajouter un bloc NAP visible dans le footer ?

Mon adresse n’existait qu’en JSON-LD. Or il vaut mieux que ce qui est balisé corresponde à ce qui est affiché en clair. J’ai donc ajouté un bloc NAP visible dans le footer Avada (Options globales, Footer), cohérent avec la fiche : nom, ville et code postal, téléphone, email, lien direct vers la fiche Google, et les profils (LinkedIn, Malt, GitHub).

Et un point de format que je veux marteler, parce que c’est une source d’erreur classique : E.164 en balisage, format local en affichage. +33609753655 dans le JSON-LD, 06 09 75 36 55 à l’écran. Ce ne sont pas deux numéros différents, c’est le même dans deux conventions, et chaque contexte attend la sienne.

Quels principes je retiens de cette journée ?

Quelques règles que je vais appliquer systématiquement, chez moi comme chez mes clients.

• La catégorie principale de la fiche est le réglage le plus structurant. Quand le métier exact n’existe pas dans la liste de Google, je choisis le libellé le plus proche.
• Rank Math génère cinq nœuds, le custom n’ajoute que ce qui manque. Place, Organization, WebSite, ImageObject, WebPage viennent du plugin. Tout custom doit se limiter au reste et référencer l’existant par @id, jamais le redéfinir.
• Dans mon réglage Rank Math SEO local, le champ « Nom de la personne / organisation » prime sur « Nom de l’entreprise » pour le name du Knowledge Graph. Contre-intuitif, mais c’est ce que j’ai constaté.
• Le « Type d’entreprise » conditionne le @type final, mais le bon choix dépend de votre setup. Sans schema custom, ProfessionalService. Avec un custom qui porte déjà ce type, Organization et un custom qui pointe vers #organization.
• La cohérence des @id est non négociable. Une référence vers un @id inexistant casse le lien dans le graphe, et deux nœuds qui partagent le même @id créent un conflit. Un @id, un nœud.
• Format téléphone : E.164 en balisage, local en affichage.
• Une entité française gagne à exposer ses identifiants officiels (TVA, SIRET, date de création) et des sameAs de confiance comme Pappers, qui reprend le SIREN et offre un point de recoupement externe vérifiable.

Ce que ça vaut, au fond

Aucune de ces opérations n’est spectaculaire prise isolément. Changer une catégorie, renommer un nœud, déplacer une adresse d’un bloc à un autre. Mis bout à bout, cela transforme une entité que Google lisait en trois morceaux en une entité qu’il lit d’une seule pièce. Et une entité qu’il comprend, il la classe mieux, il la cite mieux, et il la sert mieux en local.

Le plus dur dans ce genre de chantier, ce n’est pas la technique. C’est de penser à aller regarder. On ne voit pas le JSON-LD cassé en naviguant sur son propre site : il faut ouvrir le capot. Je ne l’avais pas fait depuis trop longtemps, et c’est précisément le conseil que je donne le plus souvent à mes clients. Comme quoi.

Questions fréquentes

Qu’est-ce que la cohérence d’entité en SEO local ?

C’est l’alignement du nom, de l’adresse, du téléphone et des identifiants entre la fiche Google Business Profile, le site, le balisage JSON-LD et les annuaires. Quand tout concorde, Google reconnaît une seule entreprise au lieu de plusieurs entités floues.

Quelle catégorie choisir sur Google Business Profile quand mon métier n’existe pas dans la liste ?

Je prends le libellé existant le plus proche de mon cœur de métier. Chez moi, « Consultant en marketing » en principale, avec « Service de marketing sur Internet » et « Concepteur de sites Web » en secondaires, faute de catégorie « Consultant SEO » trouvée en français.

Pourquoi mon schema affiche-t-il des nœuds en double avec Rank Math ?

Parce que le schema personnalisé redéfinit des nœuds que Rank Math produit déjà (Place, Organization, WebSite, ImageObject, WebPage). Gardez dans le custom uniquement ce qui manque et faites-le pointer vers les nœuds existants par leur @id.

Quel format de téléphone utiliser dans le JSON-LD et sur le site ?

Le format E.164 (+33609753655) dans le balisage, et le format local lisible (06 09 75 36 55) à l’écran. C’est le même numéro écrit selon la convention attendue par chaque contexte.

Faut-il afficher l’adresse en clair si elle est déjà dans le JSON-LD ?

Oui, je l’affiche. Mon adresse n’existait qu’en JSON-LD, et j’ai ajouté un bloc NAP visible dans le footer, identique à la fiche, pour que le balisage corresponde à ce que voient les visiteurs.