Des documents internes ont levé le voile sur les secrets de Google Maps. Derrière chaque fiche se cache une architecture complexe qui assemble une entité géographique canonique, la relie au Knowledge Graph, au Web et désormais à l’IA. Au cœur du système, Geostore agrège des données issues de 793 providers, résout les conflits, calcule un score via Oyster Rank (avec 72 critères clés), puis transmet des candidates à des couches de retrieval géographique et sémantique. Les résultats sont enfin rendus sur la carte, où la visibilité des labels dépend de Mapcore et de ses 50 998 styles. Le tout s’ajuste au contexte, à la géolocalisation, et même à un scoring on-device.
Pour le SEO local, l’enjeu dépasse la simple fiche. Il faut optimiser la représentation de l’entité elle-même, tisser des preuves sur le Web (via Webref), clarifier les concepts associés (plats, services, attributs), et assurer la cohérence marque/magasins. Exemple concret : une recherche « pharmacie » en centre-ville n’active pas la même zone que « Carrefour » en banlieue. Le rayon n’est pas fixe. En 2026, Gemini et Ask Maps exploitent ces briques pour répondre à des requêtes complexes, bien au-delà d’un simple algorithme de tri par proximité. L’objectif devient clair : fournir assez d’evidence structurée et fiable pour que Google recommande une adresse avec confiance.
- Geostore modélise des entités canoniques et ingère des données de 793 sources.
- Oyster Rank expose 72 signaux nommés (25 deprecated), sans révéler leurs poids.
- La recherche locale utilise un rayon variable selon la requête et l’environnement.
- Webref relie les pages du site aux entités via des MID du Knowledge Graph.
- Un scorer on-device et des profils de mobilité personnalisent silencieusement les résultats.
- Mapcore décide quels labels s’affichent, indépendamment du ranking pur.
- Gemini ajoute une interface conversationnelle par-dessus toute la stack.
Dans les coulisses de Google Maps : 72 critères clés et une architecture complexe
Le listing n’est pas l’entité. Geostore représente d’abord un lieu comme une Feature (identité, géométrie, sources, catégories, relations de chaîne, MID, concepts, signaux). Le listing Google Maps est assemblé plus tard, après des étapes de ranking et de rendu.
Conséquence directe pour le référencement local : modifier une valeur dans Business Profile ajoute une « évidence » parmi d’autres. Si d’autres providers contredisent cette donnée, le système peut l’ignorer, la fusionner ou la supplanter, selon des niveaux de trust jusqu’à SUPER_TRUSTED.
Geostore et les 793 providers : la vérité canonique d’un lieu
Nom, téléphone, catégorie, polygone… chaque champ peut venir d’une source différente. Geostore applique la conflation pour trancher. Des erreurs « qui reviennent » s’expliquent souvent par une source TRUSTED qui réécrit la fiche en arrière-plan.
Cas pratique. Une pizzeria de quartier portée par « Lucie » change de numéro sur Business Profile. Un agrégateur local conserve l’ancien. Geostore compare, pondère la confiance, garde l’ancien si la preuve est plus solide. D’où la nécessité d’orchestrer toutes les évidences, pas seulement la fiche.
Pour structurer cette preuve côté Web, un bon point de départ reste le socle du référencement naturel et une vision « evidence-first » reliée aux entités.
Oyster Rank : 72 signaux, mais pas “l’algorithme” de Google Maps
Oyster Rank fournit un vocabulaire de 72 signaux (reviews, volume de requêtes Web, impressions, ouvertures de fiche, demandes d’itinéraire, clics site, appartenance à une chaîne, signaux Wikipedia, popularité, prominence, landmarks, usage des segments routiers). 25 sont dépréciés, certains citant Navboost.
Le pipeline extrait et normalise des observations, mais les poids ne sont pas visibles. Savoir qu’un signal existe ne dit pas combien il compte aujourd’hui. L’algorithme effectif combine en réalité plusieurs couches : compréhension de la requête, matching sémantique, génération de candidates, géographie/qualité, reranking, puis rendu.
Ce que mesurent vraiment ces signaux, et comment s’en servir
Ils évaluent l’importance d’une entité dans Geostore, pas l’ordre final affiché à l’écran. Un second scorer, offline sur le téléphone, utilise huit signaux sur 13 tiers, distinct d’Oyster Rank et du ranking Places côté serveur. Multiplier les « hacks » ne suffit pas.
Lucie l’a constaté avec sa pizzeria : hausse d’avis, trafic en hausse, mais visibilité cartographique inchangée à certains zooms. Normal. La visibilité des labels dépend de Mapcore et de conditions de rendu, pas seulement du score global.
Géolocalisation et rayon variable : le candidate space change selon la requête
Oubliez le « cercle magique » fixe. Les tests réseau montrent un espace dynamique. À Paris, « pharmacie » couvre une zone réduite. « Carrefour » ouvre un périmètre bien plus large. En zone rurale, la même query élargit la recherche.
Sans pondération géographique, sur 5 083 appels et 86 584 résultats, la distance médiane bondit de 6,87 km à plus de 4 000 km. L’ordre non géographique reste, lui, très stable. La géographie ne reranke pas seulement : elle modifie ce que le moteur retrieve au départ.
Exemple éclair : “pharmacie” vs “Carrefour” à Paris
La densité urbaine réduit le périmètre pour « pharmacie » et privilégie les candidates ultra-proches. Pour « Carrefour », marque plus rare à l’échelle micro-locale, Maps élargit le candidate space. Résultat : proximité ne rime pas toujours avec meilleur ranking.
Ce fonctionnement s’aligne avec une logique de retrieval par contraintes : requête, densité, et offre disponible guident d’abord la sélection.
Le pont Web Maps : Knowledge Graph, Webref et preuves de référencement
Les Features de Geostore sont reliées au Knowledge Graph via un MID. Côté Web, Webref associe des documents aux mêmes entités, avec topicalité, confidence, signaux géo et scores documentaires. Une page « magasin » peut donc devenir une preuve sur l’entité, pas seulement une page qui ranke.
Objectif : aider Google à déterminer quelle entité la page décrit, quelle part du contenu concerne vraiment ce lieu, et si la page constitue une référence fiable. Les schémas structurés, la cohérence NAP, et une architecture de site nette renforcent cette association.
- Clarifier l’entité sur le site (nom canonique, adresse complète, zone de chalandise, catégories et GConcepts pertinents).
- Étoffer la preuve Web avec des pages locales riches (menus, services, prix, photos originales, témoignages), reliées au MID via des signaux contextuels.
- Orchestrer les sources tierces pour aligner données et éviter les retours arrière.
- International : cohérence entre pays et langues via un hreflang maîtrisé pour les enseignes multi‑marchés.
- Coupler organique et paid pour nourrir la demande locale et les signaux d’intérêt (voir le cadre global du référencement naturel).
Concepts, topics et IA : l’entité dépasse la catégorie
La couche sémantique va au‑delà de la primary category. Google manipule des GConcepts (établissements, plats, attributs, cuisines, modes de service). Une requête « ramen » active des ramen restaurants, des restaurants japonais ou asiatiques, et des review topics déjà structurés.
Inutile de « relire » toutes les reviews à chaque question. Les thèmes et entités extraits alimentent direct l’IA. D’où l’importance d’un menu structuré, d’attributs détaillés et d’un corpus d’avis régulier, fiable et récent.
Pour décoder l’orientation IA de Maps, un éclairage utile est proposé dans cette analyse sur l’assistant intelligent de Google Maps.
On-device et Mapcore : personnalisation et visibilité carto
Des structures locales existent sur le téléphone : visites, frequent places, domicile/travail, patterns de mobilité, ChainAffinity. Un scorer offline (8 signaux/13 tiers) influe sur la pertinence perçue côté utilisateur.
Côté rendu, Mapcore orchestre la carte. Avec 50 998 styles et 12 936 styles de labels, l’affichage varie selon le zoom et des règles visuelles. On peut être « bien classé » sans voir son nom s’afficher à l’écran. Ranking et visibilité graphique sont deux problèmes distincts.
Traduction opérationnelle : mesurer la « visibilité Maps » via des captures de grille sans intégrer le rendu carto reste trompeur.
Gemini et Ask Maps : l’algorithme local passe au conversationnel
Le calendrier est parlant. Gemini se pose désormais au‑dessus de toute la pile : entités canoniques, concepts sémantiques, topics d’avis, relations Knowledge Graph, Webref, retrieval géographique, signaux comportementaux, contextes on‑device, et mécanismes de composition du listing.
Une demande simple « best ramen near me » devient triviale. Une requête complexe « dîner à 6 près de l’hôtel, un végétarien, peu d’attente, bons avis récents sur le service » exige une représentation riche, cohérente et actuelle du lieu. Le SEO local bascule vers la semantic completeness.
Fil rouge. Lucie transforme sa page « Pizzeria via Roma — Paris 11 » en preuve d’entité : menu structuré, attributs, photos datées, sections « attente moyenne » et « végétarien », liens cohérents et signaux locaux. Résultat : plus de requêtes conversationnelles remportées, et une recommandation plus confiante par Maps.
