Google Maps : 72 signaux et l’architecture du ranking local

Un binaire récent de Google expose Geostore, Oyster Rank, 793 data providers et les différentes couches qui relient Maps au Web, au Knowledge Graph et désormais à l’IA.

Lorsqu’un établissement apparaît dans Google Maps, la liste que vous voyez n’est que le produit final d’un système beaucoup plus vaste.

En amont se trouve une entité géographique canonique, construite à partir de multiples sources de données, connectée au Knowledge Graph et au Web, évaluée par plusieurs systèmes de ranking, filtrée par des couches de retrieval géographique et sémantique, personnalisée pour l’utilisateur, puis transmise à un moteur de rendu qui décide finalement de ce qui peut réellement apparaître sur la carte.

Chez RESONEO, nous avons récemment mis la main sur un binaire exposant un scope non public de Geostore, le système utilisé par Google pour représenter les entités géographiques. Nous l’avons croisé avec les protocoles de Maps, le trafic réseau, le Web index, différents services mobiles, les tables de styles, des composants exécutés directement sur le téléphone et le Google leak de 2024.

Le corpus récupéré contient notamment :

72 signaux de ranking Geostore
793 data source providers
446 types d’intentions de recherche locale
50 998 styles Mapcore
12 936 styles de labels
10 936 déclarations Geostore consultables dans notre archive
https://think.resoneo.com/google-map-dissected/archive/

Les 72 signaux de ranking vont probablement attirer le plus l’attention des SEO.

Mais ils ne représentent qu’une couche du système.

L’architecture qui les entoure raconte quelque chose de beaucoup plus important sur la manière dont Google comprend les lieux, et sur ce que le local SEO pourrait devenir à mesure que Maps se transforme en interface conversationnelle.

Première chose à comprendre : le listing n’est pas l’entité

Le meilleur point de départ est Geostore. Google y représente les objets géographiques sous forme de Features. Une Feature peut être un établissement, un bâtiment, une route, une ville, une station, une zone ou même un objet 3D.

Dans le cas d’un établissement, l’objet peut contenir son identité, sa géométrie, ses sources, ses catégories, ses relations avec une chaîne, ses références au Knowledge Graph, différents concepts et des informations de ranking. Le listing Maps que nous connaissons tous est assemblé plus tard.

Cette distinction est importante, car l’objet qu’un propriétaire modifie dans Google Business Profile et l’entité que Google maintient en interne ne sont pas exactement la même chose.

Google cherche à construire sa propre représentation canonique du lieu. Cette représentation peut agréger plusieurs sources, conserver une identité malgré des changements de données et se connecter à d’autres identifiants utilisés dans l’écosystème Google, notamment les MID du Knowledge Graph (Machine ID).

Pour le local SEO, cela change l’objet même que nous devons chercher à optimiser.

Google construit sa propre vérité à partir de 793 providers

L’un des aspects les plus intéressants de Geostore concerne la provenance des données.

Un établissement n’a pas nécessairement une source unique. Son nom peut provenir d’un provider, son numéro de téléphone d’un autre, sa catégorie d’un troisième et sa géométrie d’une autre source encore.

Le corpus expose 793 data source providers, ainsi que des mécanismes de provenance, de priorité, de trust et de conflation. La conflation correspond au processus utilisé lorsque plusieurs sources décrivent le même objet et ne sont pas d’accord.

Geostore possède des mécanismes permettant de sélectionner une valeur, d’en fusionner plusieurs ou de déterminer quelle donnée doit survivre. Le système modélise également plusieurs niveaux de confiance, allant de sources bloquées ou non fiables jusqu’à des sources TRUSTED et SUPER_TRUSTED.

Cela donne une autre lecture d’un problème bien connu des SEO. Modifier une donnée dans Google Business Profile ne signifie pas nécessairement que Google va immédiatement adopter cette nouvelle valeur. La modification devient une nouvelle évidence dans un système qui peut déjà disposer d’informations contradictoires.

Cela aide à comprendre pourquoi certaines données incorrectes réapparaissent, pourquoi certaines modifications sont refusées et pourquoi corriger un établissement peut parfois être beaucoup plus compliqué que simplement modifier sa fiche Business Profile.

L’archive rend le leak beaucoup plus exploitable

Le binaire récent nous donne des structures, des numéros de champs et des enums complètes.La documentation Google de 2024 apporte autre chose : des descriptions textuelles expliquant parfois ce que ces structures signifient.

Nous avons donc décidé de publier les deux ensemble.

L’archive contient 10 936 déclarations Geostore. Elles peuvent être recherchées par nom de message, package, type de champ, documentation, numéro de tag, statut et plusieurs autres propriétés. C’est important, car le reverse engineering pose toujours le même problème : un nom interne peut rapidement devenir une théorie lorsqu’il commence à circuler dans la communauté SEO.

L’archive permet de revenir directement à l’évidence.

Si un signal existe, sa déclaration peut être retrouvée.
Si un champ était documenté dans les données de 2024, il est possible de consulter sa description.

Et lorsqu’un champ a disparu du scope exposé dans le binaire plus récent, son numéro protobuf peut parfois laisser un trou visible dans la séquence des tags.

Le leak de 2024 nous avait donné de nombreuses descriptions des systèmes de Google. Le binaire récent nous donne une grande partie de leur vocabulaire réel. Le croisement des deux est beaucoup plus intéressant que l’analyse de chacun séparément.

Oyster Rank contient 72 signaux de ranking

Geostore possède son propre système de ranking. Son nom interne est Oyster Rank.

Nous avons récupéré une enum complète contenant 72 signaux visibles, parmi lesquels :

les reviews Google
le volume de requêtes Web
les impressions du listing
les ouvertures du listing
les demandes d’itinéraire
les clics vers le site Web
l’appartenance à une chaîne
plusieurs signaux Wikipedia
la popularité
la prominence
les informations de landmark
l’usage des segments routiers

Parmi ces 72 valeurs, 25 sont explicitement marquées comme deprecated, dont certains mentionnant Navboost.

Il faut cependant être très précis sur ce que nous avons récupéré. Nous avons les noms des signaux mais pas leurs poids actuels.

La structure montre un pipeline dans lequel différentes observations peuvent être extraites, normalisées puis intégrées au rank de la Feature. En revanche, les coefficients qui permettraient de savoir combien chaque signal contribue au score final ne sont pas présents dans le scope que nous avons récupéré.

La présence de SIGNAL_GOOGLE_REVIEWS prouve donc que les reviews font partie du vocabulaire d’Oyster Rank. Elle ne permet pas d’affirmer qu’elles possèdent aujourd’hui un poids donné dans une recherche Maps.

Ces 72 signaux ne sont PAS « l’algorithme Google Maps »

C’est probablement le point le plus important à retenir.

Oyster Rank semble contribuer à caractériser l’importance d’une entité à l’intérieur de Geostore. Mais lorsqu’un utilisateur effectue une recherche, d’autres systèmes entrent en jeu.

Maps doit comprendre la query, déterminer son contexte géographique, générer des candidates, mesurer leur pertinence sémantique et produire un ensemble final de résultats.

Une représentation simplifiée du pipeline ressemblerait davantage à ceci :

Geostore entity -> query understanding -> semantic matching -> candidate generation -> geography / quality -> reranking -> results

Et l’architecture est encore plus complexe.

Nous avons également identifié un autre scorer fonctionnant entièrement offline sur le téléphone. Il utilise huit signaux répartis sur 13 tiers et semble distinct à la fois d’Oyster Rank et du ranking Places côté serveur.

Il n’existe donc pas une unique « formule de ranking Maps ». Plusieurs systèmes de scoring et de retrieval interviennent à différentes étapes. Transformer les 72 signaux d’Oyster Rank en une checklist de « 72 facteurs de ranking Google Maps » ferait passer à côté de l’essentiel.

La recherche locale n’a pas de rayon fixe

Nous avons également testé directement la couche géographique.

Une représentation assez courante du local search consiste à imaginer que Google sélectionne les établissements situés dans un certain rayon autour de l’utilisateur, puis les trie.

Nos mesures montrent quelque chose de plus dynamique. À partir d’un même point d’origine à Paris, la zone géographique couverte varie fortement en fonction de la query. Une recherche dense comme pharmacie génère une zone beaucoup plus réduite qu’une recherche de marque comme Carrefour.

L’environnement autour de l’utilisateur joue également un rôle. La même recherche pharmacie, lancée depuis une zone rurale peu dense, produit une zone beaucoup plus large. Google semble donc adapter son candidate space à la fois à la query et à ce qui existe autour de l’utilisateur.

Nous avons ensuite supprimé la pondération géographique du même moteur. Sur 5 083 appels et 86 584 résultats, la distance médiane est passée de 6,87 km avec la géographie à plus de 4 000 km sans celle-ci.

Mais le point le plus intéressant est ailleurs : l’ordre des résultats en mode non géographique reste extrêmement stable. Cela suggère que la géographie ne sert pas simplement à reranker la même liste de résultats en fonction de leur distance. Elle modifie ce que le moteur retrieve en premier lieu.

Pour les SEO, la distance reste évidemment fondamentale. Mais le raisonnement « je suis plus proche, donc je devrais mieux ranker » décrit mal le fonctionnement réel du système.

Maps et le Web sont reliés par les entités

La connexion entre Maps et le Web classique est probablement l’un des enseignements les plus importants du corpus.

Les Features de Geostore peuvent être reliées au Knowledge Graph à travers un MID. Du côté du Web, des documents peuvent eux aussi être associés à des MID.

Google dispose notamment d’une couche appelée Webref qui associe des documents à des entités et conserve des informations telles que la topicality, la confidence, des données géographiques et différents scores au niveau du document.

La relation existe également au niveau du ranking des documents.

Les structures récupérées décrivent notamment un signal permettant d’établir un ranking relatif entre plusieurs documents associés à la même entité, ainsi que des propriétés indiquant si un document est par exemple une page auteur, une page publisher ou une reference page.

Cela change la manière de penser une page magasin ou un store locator.

Son rôle ne consiste potentiellement pas seulement à ranker sur une query comme « magasin chaussures Paris ». Cette page peut devenir une evidence à propos de l’entité elle-même.

L’objectif devient donc en partie de permettre à Google de déterminer clairement :

quelle entité le document décrit
quelle part du document concerne réellement cette entité
avec quel niveau de confidence cette association peut être faite
si le document constitue une bonne reference pour l’entité

Le Web et le local sont beaucoup moins séparés dans l’infrastructure de Google que ne le laissent penser leurs interfaces respectives.

Google comprend des concepts, pas seulement des catégories

La couche sémantique va beaucoup plus loin que la primary category visible sur un Business Profile. Google utilise notamment des GConcepts, un vocabulaire partagé qui peut représenter des établissements, des plats, des attributs, des cuisines, des modes de service et de nombreux autres concepts.

Nous avons suivi une simple query ramen dans plusieurs parties du système. Les résultats n’appartiennent pas tous à une seule catégorie. Google peut relier la query à des ramen restaurants, des restaurants japonais, des restaurants asiatiques et d’autres concepts associés.

À l’intérieur des listings, la représentation va encore plus loin. Des review topics, des plats de menus et d’autres attributs peuvent être représentés comme des entités structurées plutôt que comme de simples chaînes de caractères. Pour un système d’IA, cette architecture est particulièrement utile.

Google n’a pas nécessairement besoin de relire des milliers de reviews à chaque fois qu’un utilisateur demande si un restaurant sert de bons ramen ou s’il faut généralement attendre longtemps.

Une partie de cette information peut déjà exister sous forme de thèmes, d’entités et de signaux structurés associés au lieu. Cette compréhension sémantique était déjà utile pour la recherche locale traditionnelle. Elle devient beaucoup plus importante lorsque l’interface doit répondre à des questions complexes.

Une partie de l’intelligence géographique de Google se trouve sur le téléphone

Tout n’est pas calculé sur les serveurs de Google. Nous avons retrouvé des structures on-device associées aux visites, aux place candidates, aux frequent places, aux trips, au domicile, au lieu de travail, aux patterns de mobilité et aux user location profiles.

Un objet particulièrement intéressant est ChainAffinity, qui suggère que le système peut modéliser l’affinité d’un utilisateur envers une chaîne retail récurrente. À cela s’ajoute le scorer offline mentionné précédemment.

Le niveau d’evidence n’est pas identique pour tous les composants. Certaines structures sont explicitement nommées dans les schemas récupérés, tandis que certaines parties de la couche persona doivent être reconstruites à partir de structures compilées.

Mais l’architecture générale est claire : le téléphone lui-même participe à la construction du contexte géographique de l’utilisateur. La personnalisation de Maps peut donc combiner une connaissance server-side du monde avec une représentation locale de la géographie propre à l’utilisateur.

Être bien classé ne signifie pas forcément être visible sur la carte

Les search results ne sont qu’un des outputs de Maps.

La carte visuelle doit résoudre un autre problème : des milliers d’entités potentiellement pertinentes ne peuvent pas toutes avoir un label affiché simultanément.

Une partie de cette logique appartient à Mapcore. Nous avons récupéré 50 998 styles Mapcore et 12 936 label styles.

La visibilité d’un label peut notamment varier selon le niveau de zoom et d’autres conditions de rendering. Un établissement peut donc être éligible, voire bien classé, sans que son nom soit réellement affiché sur la carte.

Le ranking et la visibilité cartographique sont deux problèmes différents. Cette distinction est particulièrement importante lorsqu’on mesure la « visibilité Maps » à partir de screenshots ou de map grids. La surface visuelle contient encore une décision de rendering après les étapes de retrieval et de ranking.

Et maintenant, Google place Gemini au-dessus de tout cela

Le timing de cette découverte est particulièrement intéressant.

Google développe rapidement Ask Maps et d’autres expériences basées sur l’IA, mais une grande partie de l’infrastructure nécessaire pour répondre à des questions complexes existait déjà.

Le système dispose déjà de :

canonical place entities
concepts et attributs sémantiques
reviews et topics extraits
relations avec le Knowledge Graph
Web evidence
geographic retrieval
signaux comportementaux
contexte géographique personnel
systèmes de ranking
mécanismes de composition du listing

Gemini ajoute une interface conversationnelle au-dessus de ces différentes couches. Cela change profondément ce que peut être une query locale.

« Best ramen near me » reste relativement simple. « Où est-ce que six personnes peuvent dîner près de mon hôtel ce soir, avec une personne végétarienne, peu d’attente et de bons avis récents sur le service ? » nécessite une représentation beaucoup plus riche du lieu.

Google doit comprendre ce qu’est le restaurant, ce qu’il propose, ses horaires, ce que les utilisateurs en disent, où il se trouve, comment il s’intègre au contexte ou au trajet de l’utilisateur et si les différentes evidences disponibles sont suffisamment fiables pour le recommander.

Maps construit ces briques depuis des années. L’IA donne maintenant à Google une nouvelle manière de les exploiter.

Ce que cela change pour le SEO

La conclusion la plus actionnable de cette recherche n’est pas une nouvelle liste de ranking factors.

Le SEO local s’est historiquement beaucoup concentré sur l’optimisation du Google Business Profile : catégories, reviews, photos, attributs, horaires et autres champs du listing.

Tout cela reste important, mais l’architecture de Google suggère un objectif plus large : améliorer la représentation que Google est capable de construire de l’entité elle-même.

Pour un établissement ou une enseigne retail, les bonnes questions deviennent progressivement :

Qu’est-ce exactement que ce lieu ?
Que propose-t-il ?
À quelle marque ou chaîne appartient-il ?
À quels concepts et attributs est-il associé ?
Le site Web décrit-il clairement la même entité ?
Quels documents Web apportent de l’evidence à son sujet ?
Google observe-t-il une demande réelle pour cette marque ou cet établissement ?
Que disent régulièrement les reviews sur les différentes dimensions de l’expérience ?
Pour quels utilisateurs et dans quels contextes ce lieu peut-il être pertinent ?
Dans quelles situations Google devrait-il le recommander plutôt qu’un autre ?

La qualité de la réponse que Google peut produire dépend directement de la qualité et de la complétude de cette représentation.

La semantic completeness pourrait devenir le prochain terrain de bataille du SEO local

Proximity, relevance et prominence restent des concepts utiles.

L’IA ajoute une contrainte supplémentaire : le système doit disposer d’assez d’evidence structurée pour pouvoir raisonner sur un lieu. Un restaurant peut avoir un Business Profile parfaitement optimisé et des centaines de reviews tout en étant mal représenté pour une question spécifique si Google n’est pas capable de relier avec suffisamment de confiance les bons attributs, concepts, pages Web et review topics à l’entité.

Pour les grandes enseignes, le problème est encore plus complexe. Google modélise à la fois les chaînes et leurs établissements individuels.

Nous avons observé des magasins d’une même enseigne, situés dans la même zone métropolitaine, associés à des concepts différents alors que le modèle de chaîne contient sa propre structure conceptuelle canonique.

La cohérence ne peut donc pas être considérée comme acquise simplement parce que tous les établissements appartiennent à la même marque.

Pour le multi-location SEO, le travail porte à la fois sur l’entité de marque, chaque entité locale, le site Web, les structured data, les sources tierces, l’UGC et les relations entre toutes ces couches. La surface à optimiser est beaucoup plus large qu’un simple Business Profile.

En conclusion

Les 72 signaux d’Oyster Rank sont fascinants parce qu’ils révèlent certaines catégories d’informations que Google peut utiliser pour évaluer l’importance d’un lieu.

Mais la découverte la plus forte est le système qui les entoure.

Geostore construit une entité géographique canonique à partir de sources parfois contradictoires.
Le Knowledge Graph apporte une représentation sémantique.
Webref relie les documents Web à cette entité.
Search et Places interprètent la query et génèrent des candidates à l’intérieur d’un espace géographique dynamique.
Les systèmes on-device ajoutent une partie du contexte personnel de l’utilisateur.
Mapcore contrôle ce qui atteint réellement la surface visuelle de la carte.
Ask Maps et Gemini peuvent désormais raisonner en langage naturel au-dessus de cette représentation.
Le listing Google Maps n’est que la couche visible de cette stack.

Pour les SEO, la question est désormais :

« Quelle représentation Google a-t-il construite de cette entreprise, et cette représentation est-elle suffisamment complète pour que Google puisse la recommander avec confiance ? »

L’étude complète contient l’architecture reconstruite, les expérimentations et les éléments techniques sur lesquels repose notre analyse.

L’archive associée permet également d’explorer les 10 936 déclarations Geostore récupérées et de les confronter à la documentation de 2024 afin d’inspecter directement les schemas, enums, fields, methods et ranking signals.

Toutes les informations à retrouver sur Resoneo !