From the 2024 leak to Geostore, we rebuilt how Google consolidates a place, measures its importance, understands a query, selects results, draws them on the map and now starts personalising them with AI.
In 2024, a leak of internal documentation opened a window onto Google's systems. For two years it was the best available source for understanding what sat behind Google Maps.
Since then we have got hold of a recent binary carrying a non-public Geostore scope, then cross-checked that material against Google Maps protocols, its network traffic, its Web index, its adjacent services, its style tables and several locally executed components.
The result noticeably changes the picture one could have of Maps. We now hold message names, field numbers, complete enumerations, hundreds of API methods, ranking signals, indexing structures and measurements taken directly against the engine.
And the timing is interesting. On 6 August 2026, Google announced a wave of AI features in Maps. We had the code from the day before and the day after.
Google Maps is no longer just a map and a local engine. It is becoming an answer engine too. To understand what that shift means, you first have to understand the machine underneath.
1. Google Maps does not sit on a listings database.
At the centre sits Geostore, a far more general repository modelling canonical geographic entities called Feature.
2. A Feature mixes information from different sources. Provenance can be kept at field level. Name, phone, a category or a geometry can each have a different origin.
3. When sources disagree, they get arbitrated. Geostore exposes conflation, priority, trust, rights, and even the criteria a future edit must meet to replace an existing value.
4. Geostore has its own rank system, and it has a name. Oyster Rank. We recovered the complete visible enumeration of 72 signals, 25 of them explicitly deprecated. The signals present include reviews, Web query volume, listing impressions, listing opens, direction requests, clicks to the site, chain membership, popularity, prominence and road usage.
5. We have the signal names, not their coefficients.
The schema states they are combined with weights, but the fifteen most interesting fields of RankDetailsProto are stripped from the scope we could recover.
6. That rank is not the final ranking of a Maps query. Search/Places then adds semantic understanding, geographic context, candidate generation, relevance and serving.
7. The Web and Maps are far more tied than they look. Web documents are attached to entities through their MID, with topicality, confidence and geographic metadata stored in the index. One layer, Webref, decides document by document which entity a page is about.
8. The engine is not a distance sort.
In dense areas we observe a target of 20 results and a radius that adapts to the query. In Paris, 0.98 km is enough for pharmacie, against 12.44 km for Carrefour. The same pharmacie query is 32.96 km in rural Lozère.
9. Part of the geographic intelligence is computed on the phone.
An embedded layer infers frequent places, home, work, trips and a ChainAffinity, an affinity towards a retail brand. Mind the evidence level: the segmenter stage is named, the persona stage is not.
10. The AI announcement of 6 August 2026 is mostly a server-side switch-on. Of the six announced strands, five have no new code counterpart. The only genuinely new code is the consent service, because it is the one brick you cannot switch on remotely.
Three levels of evidence, held from start to finish. This is the reading grid for the whole study.
A field name, a number, an enumeration or a comment establishes that the system provides for that information.
If SIGNAL_GOOGLE_REVIEWS exists in the rank enumeration, we can state that reviews belong to Geostore's rank vocabulary. We cannot infer their current weight in a search.
We queried the services, captured responses, compared rankings, varied location and zoom, decoded tiles and measured the results.
At this level we can state that the engine returns 20 results under some conditions, or that the priority carried in the tile exactly mirrors the result order.
When data is missing, we say so. That matters most for the ranking weights.
The point of this study is not to turn internal names into SEO mythology. It is to separate what the data demonstrates from what it cannot tell us.
Messages, fields, complete enumerations, tags removed from the client scope, and the March 2024 prose alongside. A search engine to dig into types, attributes and signals, and a full dump for those who would rather use their own tools.
The documentation recovered in 2024 had a rare quality: it explained the role of thousands of models and attributes, in prose.
But it had a weakness.
Its enumerations were largely abstract. We could grasp the concepts, far less easily rebuild their actual values.
The recent binary changes that.
1 623 protobuf descriptors 4 013 messages 1 359 enumerations 17 757 enumeration values 433 Geostore types (300 messages + 133 enums)
Among the large enumerations recovered:
RankSignalProto.Signal 72 RankDetailsProto.SignalMixerType 35 FeatureProto.TypeCategory 371 EstablishmentProto.TypeCategory 374 DataSourceProvider.Provider 793 SuggestSubtype 852 in the version we measured localsearch.lite.IntentType 446
The comparison with 2024 is more instructive still.
Out of 3,585 enumeration values compared, 3,471 could not be found in the 2024 archive, including 70 of the 72 rank signals. Conversely, no Geostore model documented in 2024 has vanished from the recent corpus.
So this is not a new architecture replacing the 2024 one.
It is more as if we had obtained the wiring diagrams of a building whose rooms we already knew.
A useful mental model of Google Maps starts with a distinction.
Geostore is not Google Maps.
Geostore is the layer that maintains the identity and canonical state of a geographic entity. Search and Places come afterwards.
A Geostore Feature can be:
an establishment a city a country a road an intersection a building an area a station a transit element a 3D object … and many other kinds of spatial entity
So the POI we see in Google Maps is only a projection of a much richer object.
message geostore.FeatureProto {
id = 1;
bound = 2;
rank = 3;
name[] = 4;
address[] = 5;
point[] = 6;
polyline[] = 7;
polygon[] = 8;
child[] = 9;
center = 10;
source_info[] = 12;
related_feature[] = 13;
parent[] = 14;
type = 15;
synthetic_geometry = 16;
access_point[] = 17;
geometry_precision_meters = 20;
rank_details = 24;
covering = 26;
data_source = 33;
establishment = 51;
status = 67;
website[] = 69;
raw_gconcept_instance_container = 70;
internal = 71;
social_reference = 74;
knowledge_graph_reference = 75;
kg_property[] = 79;
business_chain = 91;
operations = 103;
experimental_data[] = 118;
feature_originators[] = 123;
existence_confirmations[] = 126;
metadata = 300;
}
Field 70 deserves its full name: raw_gconcept_instance_container. It is not a list of categories, it is a container of concept instances. That nuance carries everything that follows about categories.
Geostore's fundamental identifier is made of two 64-bit values:
FeatureId ├── cell_id 64 bits └── fprint 64 bits
The cell_id roughly corresponds to the Feature's position when it was created.
That detail matters.
It must not be read as the current position of the business. The real geometry lives elsewhere in the Feature.
And it is not a two-branch alternative. The schema describes three states:
1. exact cell position at creation time
2. randomised cell entities with no place of their own
3. field absent "As of Mar 2017, the cell ID
field of the feature ID
might not be set"
This separation lets an entity move, be corrected or change geometry without losing its identity.
It also explains the various identifiers one meets around Maps.
| Identifier | What it stands for |
|---|---|
Feature ID / ftid | the Geostore identity |
Place ID | a serialisation of that identity |
CID | the Feature's fprint |
MID | the entity identity in the Knowledge Graph |
gcid | a semantic classification |
| merchant listing identifier | the listing administered by the business owner |
That 64-bit pair is exactly what public tooling handles without naming it. An ftid such as 0x47e66e2964e34e2d:0x8ddca9ee380ef7e0 shows the cell_id then the fprint in hexadecimal; the CID is that same fprint in decimal; and a Place ID starting with ChIJ is its serialised, encoded form. Three spellings, one Geostore identity.
The distinction is fundamental for local SEO. The business, the owner-managed listing, its semantic type and the Knowledge Graph entity are not the same object.
Geostore is Google's own name for it: it is the prefix on every type in the schema, geostore.FeatureProto. In the documentation that repository carries a second name: Oyster.
It shows up on the identifier, on the entity type on the index side, and above all on the rank system itself.
// on the identifier the oyster feature id // on the entity type, index side RepositoryWebrefOysterType.featureType "a value of the enum geostore.FeatureProto.TypeCategory" // on the rank system RankSignalProto.rank "A value in the range [0, 1] estimating Oyster Rank according to this signal."
So the system whose 72 signals we detail further on, Oyster Rank, has a name, and it is not PlaceRank.
A common intuition is that a listing belongs to one source.
source = Google Business Profile
That is not the model Geostore describes.
Provenance can be attached at field level.
Name --------------------- Source A Phone -------------------- Source B Hours -------------------- Source C Category ----------------- Source D Geometry ----------------- Source E
For a field path, Geostore can keep:
field_path provider dataset
The catalogue we recovered holds 793 providers. It includes mapping sources, automated Google pipelines and internal human editing.
So a human correction sits inside the same general philosophy: an observation from a source that carries a priority and a trust level, rather than a magical truth standing outside the system.
This is one of the most useful findings for understanding Maps.
The schema exposes three generic methods:
CONFLATION_PICK_FIRST_VALUE CONFLATION_UNION_CSV CONFLATION_SUM
And the default value is:
CONFLATION_PICK_FIRST_VALUEIn other words, inside this generic mechanism, when competing values exist the system does not necessarily make the sources vote.
It can simply take the first admissible value in priority order.
That makes source priority an essential piece of data.
This mechanism does not prove every Google Maps attribute is consolidated this way. It proves Geostore explicitly holds this merge machinery.
Changing a value in Google Business Profile does not necessarily mean:
old value
↓
new definitive valueThe model looks more like:
new observation
+
observations already known
+
provenance
+
priority
+
trust
↓
canonical valueThat is a difference in kind, not in degree.
The trust level visible in the schema has six steps:
UNKNOWN 0 BLOCKED 16 NOT_TRUSTED 32 YP_FEEDS 40 TRUSTED 48 SUPER_TRUSTED 64
YP_FEEDS means yellow-pages feeds: data bought from or ingested from business directories. It ranks above an unknown source, below a source deemed reliable.But the list is not the interesting part.
For an outgoing Feature, the trust structure can also define the criteria a new edit must meet to be accepted.
So an attribute can conceptually carry three different properties:
Where does it come from? PROVENANCE How reliable is that source? TRUST What level must a future edit reach to replace it? EDIT BARRIER
That third dimension explains why some map errors are hard to correct, even when you go about it properly.
We did not recover the formula. TrustSignalsProto holds four slots stripped from the scope.
Google separates several levels.
The Feature belongs to one of 371 structural categories.
A second taxonomy holds 374 values. But its own documentation states it is deprecated in favour of GConcepts.
This is the ontological layer.
The schema's gconcept_id is the gcid: carried by engine responses. And it is not hidden data: it is the category you read under the business name inside Google Maps. When the Louvre listing shows “Art museum”, that is gcid:art_museum. When a restaurant shows “Ramen restaurant”, that is gcid:ramen_restaurant.
Attributes follow the same convention: AttributeIdProto.id is described as “a stripped format of the gcid”, while an enumerated attribute value is itself a gcid, such as gcid:attval_yes.
Categories, attributes and their values live in one namespace.
A concept can carry a prominence:
NON_PRIMARY = 0 PRIMARY = 1000
The documentation gives the example:
"a gas station with a convenience store and an ATM. All three GConcepts are highly relevant, but gas_station is the most prominent."
Traffic confirms the reading. The served gcid list puts the primary category first, then the 8 to 16 secondary ones in strict alphabetical order, on 6 entities out of 6.
The alphabetical sort is the proof that no semantic order travels with the list. The Louvre listing carries 16 values: the first is the one displayed, the fifteen that follow run from art to vacances.
gcid:art_museum ← displayed gcid:art gcid:attraction gcid:culture gcid:education_and_culture gcid:entertainment_and_recreation gcid:establishment gcid:establishment_poi gcid:feature gcid:museum gcid:places_of_interest gcid:public_api_establishment gcid:tourism gcid:tourist_attraction gcid:travel gcid:vacances
museum does not sit behind feature because it describes the place less well: it sits behind because m follows f.The limit follows immediately: there is no gradation between secondary categories. Only the PRIMARY switch is a fact the schema carries.
One last, often counter-intuitive point: the gcid is a property of the search response, not of the listing. It is absent from five GetPlace responses out of seven, which carry the /geo/type/… ontology instead.
This is the most actionable fact in the section. The PRIMARY switch is not uniform inside a chain.
Across 21 stores of the same retail brand in one metro area, matched one to one:
11 gcid:pharmacy 10 gcid:drugstore
Put that next to BusinessChainProto.canonical_gconcepts, which declares “the ideal state of the GConcepts of the members of this chain”, with the isRequired rule: “must be true for a primary gconcept”.
The ideal state is declared. The real state diverges inside the same brand, in the same city.
We will follow one example, the string ramen, from one end of this study to the other. First stop, classification.
The query returns 20 results, and each carries exactly one gcid:
ramen_restaurant 6 asian_restaurant 5 restaurant 4 japanese_restaurant 4 japanese_authentic_restaurant 1
Twenty places surfaced by the same word, spread across five different concepts.
This is one of the most structuring findings for SEO.
The bridge between Geostore and Google Search's entity ecosystem is not the Place ID.
It is the Knowledge Graph MID.
A Feature holds:
knowledge_graph_reference
↓
MIDOn the Web index side, documents themselves carry encodedMid[].
The geographic Oyster ID travels around that entity, but the conceptual pivot is the MID. Its status needs care, and the corpus states the nuance itself: on CountryLocationInfo, oyster_id is a payload “cleared during index creation”; on WebrefMustangAttachment, it is stored. Depending on the message, the same identifier is either carried or kept. A single sentence about its fate would be wrong half the time.
MID
│
┌─────────┴─────────┐
│ │
KNOWLEDGE GRAPH WEB INDEX
│ │
│ documents tied to the entity
│ topicality
│ confidence
│ document scores
│
└──────── GEOSTORE
│
FeatureThe other way round, Geostore does not store each Web page identifier. It gets aggregated signals:
SIGNAL_WEBSCORE SIGNAL_GOOGLE_WEB_QUERYVOL
The architecture is asymmetric.
The Web knows how to talk about entities. Geostore knows how much the Web seems to talk about them, without becoming a page index itself.
A business listing does not carry one MID, it carries a family of them: one per menu dish, one per review topic, one per attribute, plus the brand, the class and the meal types.
Across a capture corpus covering five queries and one full listing, we count 221 distinct MIDs.
The same kind of identifier recurs in several places on the listing, in different roles.
It is those roles that make the listing machine-readable: a menu dish is not a line of text, it is an entity; nor is a review topic.
On a restaurant listing, ramen does not exist as a string. It exists as an entity, and it turns up in three places in three different roles.
A review saying “the ramen was too salty” is not stored as a sentence. It is stored with the identified topic and the character positions where it is discussed.
That is what lets a system count mentions, attach sentiment to them, and quote the exact excerpt. Without identification, the text would have to be re-read on every question.
The boundary between the document world and the geographic world is not a metaphor. It has a name, and it can be counted.
In the 2024 leak, across 14,025 documentation attributes, 25 comments cite a geostore type or path, of which 8 are bridges from outside. Five of those eight sit in RepositoryWebref*.
And what crosses most is not the identifier, it is the entity type: FeatureProto.TypeCategory crosses the boundary three times, through three independent models.
RepositoryWebrefDomainSpecificRepresentation.entityData declares it can hold:
freebase.Topic repository_wikipedia.WikiJoin ocean.WorkMetadata* geostore.Feature
ocean is Google's corpus of publications: digitised books, academic and scientific papers. So one entity can be described at once by a Freebase topic, a Wikipedia page, a publication and a place.Webref is the layer where representations of one entity, coming from different sources, meet.
encodedMid[] "sorted by topicality score" topicalityE2 fixed point /100 confidenceE2 fixed point /100 oysterId featureType latE7 / lngE7 "same format as geostore.PointProto"
This is the point SEO should keep. Webref does not merely say which entity a document is about. It also ranks documents against one another, for a given entity.
RepositoryWebrefDetailedEntityScores.docScore "relative ranking signal between different documents for an entity" normalizedTopicality share of the document about the entity, sums to 1 across all entities connectedness relevanceScore isAuthor isPublisher isReferencePage
RepositoryWebrefMention.confidenceScore publishes its own calibration. It is worth reading closely, because it lights up every confidence in the corpus.
0,3 → 75 % 0,5 → 87 % 0,7 → 89 % 0,9 → 94 % 1,0 → 98 %
The Knowledge Graph is not fed by the listings.
Webref is the layer that decides, document by document, which entity a page is about, how much, and with what confidence, then ranks those documents against one another for that entity.
A store page does not only compete for a keyword. It competes to be a reference document for the entity.
The system has a name, a complete enumeration, and a sharp boundary where our knowledge stops.
A Feature can carry rank details.
The documented pipeline looks like this:
RAW OBSERVATION
│
▼
SignalExtractor
│
├── raw_scalar
└── raw_string
│
▼
NORMALISATION [0,1]
│
▼
RankSignalProto.rank
│
▼
SignalMixer
│
▼
FeatureProto.rankSo each signal can carry:
type rank "A value in the range [0, 1] estimating Oyster Rank according to this signal." raw_scalar raw_string metadata
The documentation then states the rank is produced by a weighted sum of several signals.
We recovered 72 values in RankSignalProto.Signal. The enumeration has no reserved_range: it is complete for the scope we hold.
Twenty-five of those 72 values are explicitly deprecated. A deprecated value is not a current ranking factor: it is the trace of one that existed.
The most telling block sits in the 3100 to 3504 family.
SIGNAL_WIKIPEDIA_ARTICLES SIGNAL_KML_PLACEMARKS SIGNAL_KML_SOURCES SIGNAL_GOOGLE_MAPSHOP_USERS SIGNAL_GOOGLE_RBL_CLICKS SIGNAL_GOOGLE_RBL_CLICK_FRACTION SIGNAL_GOOGLE_AUTHORITYPAGE_PAGERANK_CONFIDENCE SIGNAL_GOOGLE_REVIEWS SIGNAL_GOOGLE_WEB_QUERYVOL SIGNAL_GOOGLE_LISTING_IMPRESSIONS SIGNAL_GOOGLE_INFOWINDOW_VIEWS SIGNAL_GOOGLE_DIRECTION_REQUESTS SIGNAL_GOOGLE_HOMEPAGE_CLICKS SIGNAL_GOOGLE_CHAIN_STORES SIGNAL_GOOGLE_LEANBACK_TOURS SIGNAL_GOOGLE_LOCALSEARCH_PLACERANK SIGNAL_WIKIPEDIA_WIKI_SCORE SIGNAL_PLACE_INSIGHTS_LANDMARK SIGNAL_PLACE_INSIGHTS_POPULARITY SIGNAL_PLACE_INSIGHTS_PROMINENCE SIGNAL_PLACE_INSIGHTS_APPROACHABILITY SIGNAL_PLACE_INSIGHTS_TOTAL_ROAD_SEGMENT_USAGE
And a few historical survivors are explicitly deprecated:
SIGNAL_GOOGLE_MAPS_NAVBOOST_CLICKS [DEPRECATED] SIGNAL_GOOGLE_MAPS_NAVBOOST_CLICKTHROUGH_RATE [DEPRECATED] SIGNAL_GOOGLE_AUTHORITYPAGE_PAGERANK [DEPRECATED] SIGNAL_GOOGLE_WEBPAGE_REFERENCE_DOMAINS [DEPRECATED]
It surfaces several families of importance:
PRESENCE AND AUTHORITY ON THE WEB
WebScore, Wikipedia, external references,
authority page confidence
+
DEMAND
Web query volume on the entity
+
ENGAGEMENT WITH THE LISTING
impressions, listing opens, reviews
+
ACTIONS
direction requests, clicks to the site
+
COMMERCIAL STRUCTURE
chain membership
+
PHYSICAL ENVIRONMENT
roads, approachability, road segment usage
+
IMPORTANCE OF THE PLACE
popularity, prominence, landmark characterA place's importance at Google is a hybrid object: Web, cartographic, behavioural and physical at once.
But a caveat follows immediately. We know these items belong to Geostore's rank vocabulary. We do not know their current weight in the final ranking of a Maps query.
Google represents them with two different signals:
3501 PLACE_INSIGHTS_POPULARITY 3502 PLACE_INSIGHTS_PROMINENCE
A place can be busy without being an important landmark. Conversely, a monument can carry strong prominence without that notion being the same as its footfall.
Three more signals complete the family:
LANDMARK APPROACHABILITY TOTAL_ROAD_SEGMENT_USAGE
APPROACHABILITY — how easily a place can be reached and approached — raises an open question. The name is explicit, we do not have its formula.
TOTAL_ROAD_SEGMENT_USAGE shows something concrete: the road environment around a place can enter its rank vocabulary.
So an entity's rank does not only look at what happens on its listing or on the Web. It can also look at the physical world around it.
We found another piece of the puzzle, this time inside an embedded system layer.
Several pipelines carry explicit names:
deidentified-store-visits deidentified-historical-busyness deidentified-wifi-place-visits deidentified-cycling-activity
They correspond to aggregations of store visits, historical busyness, Wi-Fi-detected visits and cycling activity. The default upload cadence visible in the configuration is 6 hours.
A pulptraining folder also shows this layer takes part in model retraining.
We should be precise about what that proves. We observe:
on-device detection
↓
aggregation
↓
de-identified uploadAnd, elsewhere:
SIGNAL_PLACE_INSIGHTS_POPULARITY
We do not have the formula linking the two. The measurement chain exists. The exact causal link to the rank signal is not demonstrated.
Another vocabulary trap.
MIXER_PLACERANK appears in an enumeration of 35 mixers. A mixer is the regime used to combine signals depending on the nature of the entity.
For places:
MIXER_PLACERANK = 18Two details in this list are worth noting, because they say something about how the enumeration lived. It holds a MIXER_MANAGER at 10000 and five MIXER_TEST_1..5 right after. And values 25 and 26 are absent without being reserved: two mixers existed, disappeared, and left no declared hole.
Conceptually:
Reviews ───────────────────┐
Web query volume ──────────┤
Directions ────────────────┤
Homepage clicks ───────────┤
Popularity ────────────────┤
Prominence ────────────────┤
Approachability ───────────┤
Road usage ────────────────┤
WebScore ──────────────────┤
… │
▼
MIXER_PLACERANK
│
▼
importance of the placeSo PlaceRank is not “the PlaceRank factor”. It is a mode of combining factors.
This is the most important boundary in the study.
RankDetailsProto exposes:
signal[] signal_mixer_type
But 15 further tags were stripped from the scope. The parent field documentation states precisely that this structure holds the signals and their weights.
RankDetailsProto 15 fields stripped FeatureProto 25 fields stripped TrustSignalsProto 4 fields stripped
We do not know:
the coefficients the normalisation functions the thresholds the transformations the per-market calibrations the interactions between signals the model versions
Google develops in a single repository, google3, holding the code of almost every product except Chrome and Android. Search, YouTube, Maps, Assistant and Lens live side by side there, and nearly every engineer has access. That is an unusual choice at this scale, and it has its reasons: cross-team collaboration, uniform tooling, feasible large-scale refactors.
A small fraction of the code, around 0.1%, escapes that general access. It is isolated for confidentiality reasons, mainly around anti-spam, and goes by the name HIP, for High-value Intellectual Property. That is where, in 2024, one expected to find components like NSR or PageRankNS.
What we observe here belongs to the same family, one notch lower: descriptors compiled for a client only hold the fields in its scope, and the ones that leave it leave a trace, a reserved tag number.
The hypothesis, which we cannot demonstrate: the most sensitive behavioural signals, the ones whose very existence was debated after 2024, are probably on the closed side of that boundary. The schema does leave an indirect clue, since the two Navboost signals of the geographic vocabulary are present but deprecated: whatever is still active in that area no longer goes by that name, and has been shielded.
We put this forward as a hypothesis, not as a result. What is measured is the location of the hole and its size.
Our analysis of the 2024 leak is here.
Geostore computes or carries a notion of entity importance. But a Google Maps search asks a different question:
“Out of all these entities, which best answer this query, from this place, right now?”
A more realistic model is:
GEOSTORE
│
entity + attributes + importance
│
▼
QUERY UNDERSTANDING
│
▼
SEMANTIC MATCHING
│
▼
CANDIDATE GENERATION
│
┌───────┴────────┐
│ │
importance proximity
quality geography
│ │
└───────┬────────┘
▼
RERANKING
│
▼
TOP 20This is one of the essential separations in the whole study.
Geostore explains very well what a place is and which signals can characterise its importance. On its own it does not explain why that place is number 3 for a given query.
Engine responses expose a semantic classification of the query.
Example observed for a food brand:
fast_food_restaurant 0.913505 restaurant 0.676 hamburger 0.568 breakfast 0.509 coffee_shop 0.367 sandwich 0.348 american 0.287 + a scored Knowledge Graph entity
A scored geographic hierarchy also travels with the query:
neighbourhood city county state country
Our multilingual tests show that synonymous terms in different languages retrieve overlapping entity sets. What happens on the other side is sharper still.
Terms with different meanings do not retrieve “almost no” shared entity. They retrieve exactly zero:
mean Jaccard 0.0000 pairs compared 5,193 pairs with non-zero overlap 0%
So retrieval is not purely lexical. The term is first resolved into a conceptual representation, and that representation then steers access to the candidates.
For local SEO the consequence is direct. Having the searched word somewhere is not enough. Google has to be able to link the business to the concepts matching the intent.
Take again the distribution of concepts seen earlier. Twenty results for ramen, one gcid per business.
| Concept carried by the result | Results | |
|---|---|---|
ramen_restaurant |
6 | |
asian_restaurant |
5 | |
restaurant |
4 | |
japanese_restaurant |
4 | |
japanese_authentic_restaurant |
1 | |
| Total | 20 |
None of these businesses carries all five concepts. The engine did not widen each one’s category: it gathered five different categories around one intent.
And the most frequent one accounts for only six results out of twenty. The concept carrying the typed word exactly is a minority in its own response.
That is why “put the word ramen on the listing” and “be understood as a ramen_restaurant” are two different problems.
In sufficiently populated areas we observe 20 results. The engine then adapts the footprint needed to get them.
In Paris:
pharmacie0.98 kmboulangerie1.15 kmsupermarché5.66 kmTotal7.24 kmCarrefour12.44 kmSame query point, same city. A factor of 12.7 between two queries.
For pharmacie, distance dominates. For a brand or a more ambiguous category, relevance can push the engine much further out while hundreds of businesses sit closer.
The most telling figure is not in the table. It shows up when you leave Paris with the same query.
pharmacie Paris 0,98 km pharmacie Lozère 32,96 km
The ratio of the radii is close to the square root of the ratio of the densities. That is the signature of a constant-neighbour-count search: the engine does not search inside a circle, it searches until its twenty slots are full.
Which is why the question:
“What is the Google Maps radius?”
has no single good answer. The radius is partly an outcome of the process, not a fixed parameter set before the search.
An open search surface we instrumented has an interesting property. By omitting the geographic weighting, it exposes a state you cannot obtain with the standard Places API.
We ran:
5 083 calls 86 584 results
When two lists share the same entities, their order barely moves:
Median Spearman +1,000 Mean Spearman +0,984
Moving the origin point by thousands of kilometres barely changes that order.
It matches neither:
the cell_id the CID the lexical order of the identifier a distance to some hidden geographic point
This reveals a very stable non-geographic order behind retrieval.
observed order = FeatureProto.rank observed order = MIXER_PLACERANK
We do not have that link. It could be a quality prior, an internal document order, or something adjacent.
The phenomenon is measured. Its exact nature remains opaque.
The same call as the previous section, with and without geographic weighting.
The surface used here is experimental and undocumented. It should not be confused with the commercial Google Places API.
The geographic parameter we use does not merely define a maximum radius. When weighting is on, geography influences the ranking. Without it, you see the non-geographic order obtained earlier, once geography is removed. The 20-result ceiling holds in both cases.
The radius this form shows will often differ from the median radii measured earlier, and that is not a contradiction: the table gives a median across dozens of origin points, while here you query a single point. For pharmacie in central Paris the median sits at 0.98 km and this particular point climbs to 5.68 km, because three distant pharmacies enter the top 20 ahead of dozens of closer ones. That is exactly the phenomenon of a local search without a fixed radius, and it is more convincing to see it than to read it.
Before the user even submits a search, Maps calls its Suggest service on every keystroke.
This section does not present a catalogue. It demonstrates one thing.
On every keystroke, the system qualifies what you are typing, and it already knows whether the answer will be local or not.
Across 199 measured suggestions on the map side:
establishment 125 category 29 chain 21 locality 11 local query, web answer 9
The catalogue distinguishes very fine cases. Among the values:
SUBTYPE_MAPS_ESTABLISHMENT_POI SUBTYPE_MAPS_CATEGORY SUBTYPE_MAPS_CHAIN SUBTYPE_MAPS_LOCALITY SUBTYPE_MAPS_LOCAL_WEB SUBTYPE_MAPS_POLITICAL SUBTYPE_MAPS_ROUTE SUBTYPE_MAPS_STREET_NUMBER SUBTYPE_MAPS_TRANSIT_STATION SUBTYPE_MAPS_TRANSIT_LINE SUBTYPE_MAPS_DISH SUBTYPE_MAPS_AD SUBTYPE_MAPS_PLUS_CODE SUBTYPE_MAPS_LAT_LNG SUBTYPE_MAPS_SYNTHETIC_PLACEID SUBTYPE_MAPS_CRISIS
For street numbers, the catalogue goes as far as:
STREET_NUMBER
OUTSIDE_SEARCH_RANGE
OUTSIDE_MINMAX
IN_RANGE
IN_GAPSo Google can represent a number falling into a gap in the known address range. Not a valid address, not an out-of-area address: a third state.
SUBTYPE_MAPS_ASK_MAPS SUBTYPE_MAPS_ASK_MAPS_PROMPT SUBTYPE_MAPS_ASK_MAPS_PROMPT_FALLBACK SUBTYPE_MAPS_ASK_MAPS_QUERY_MIRROR SUBTYPE_MAPS_ASK_MAPS_QUERY_MIRROR_FALLBACK
A single autocomplete response on ramen. Every suggestion starts with the same five letters, and no two get the same qualification.
So the “See locations” label is not an interface decision. It is the consequence of a qualification made upstream, at typing time.
The mobile client talks to a gRPC-over-HTTP/3 service architecture. The catalogue we rebuilt holds 115 services and 395 methods.
This catalogue shows how misleading it becomes to speak of “the Google Maps engine” in the singular.
Search, listings, the map, UGC, advertising, personal data and AI are distinct layers communicating around shared identities.
When Google returns a result, it does not hand over the Geostore FeatureProto. It builds a much richer serving view.
In PlaceProto we found:
Geostore identity rating name review count address website coordinates opening hours phone main photo gcid MID ontological attributes related searches
The full listing then adds:
individual reviews menus
contributed photos prices
KG topics inside reviews questions and answers
busyness by hour owner responses
and by day guided taxonomies
editorial contentSearch and GetPlace use the same place structure, at different fill levels. The client explicitly requests the subfields it needs through a FieldMask.
GEOSTORE FEATURE
identity, geometry, provenance,
categories, existence, ranking
│
┌────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Knowledge Graph UGC product data
brands reviews menus
concepts photos prices
dishes Q&A hours
attributes
│ │ │
└────────────┼─────────────┘
│
personalisation
│
▼
PlaceProto
│
▼
LISTINGA Google Maps listing is a document composed on the fly around an entity, not a copy of the geographic database.
The content Maps serves goes far beyond the old POI information. We find:
generative summaries themes extracted from reviews per-theme sentiment a relevance score per review justifications offsets linking sentences to concepts confirmed and unconfirmed attributes
That is exactly the material a conversational interface needs.
So Ask Maps does not sit on top of a table holding only:
Name Address Stars Hours
It sits on top of an already heavily enriched and semanticised representation of places.
Here is what the response actually carries around one query and one business, laid out flat.
serves, cuisine, is-a.This is not a listing with fields. It is a neighbourhood of entities linked by named relations, and that is what a natural-language question can be asked against.
The restaurant listing we have followed since the start of this ramen thread carries, with no generative model involved at read time: menu dishes identified by MID, reviews anchored on identified topics with their character offsets, photos tagged per dish, and attributes split into confirmed and unconfirmed.
On another listing in our corpus, a restaurant chain this time, the thematic layer is present and reads directly:
theme "wait time" mentions 87 positive 2 negative 85
Eighty-five negative mentions out of eighty-seven, and the tally is already done before any question is asked. On top of that, a relevance score per review and justifications with their offsets.
Ask Maps does not invent this material. It reads it.
The example closes here. The string ramen never denoted a keyword. It denoted an entry point into an ontology, and a business wins or loses depending on the concepts the system knows how to attach to it.
We had the code from the day before and the day after an announcement. What the diff shows weighs more than the date.
Google presented Ask Maps on 12 March 2026, in an official post: complex real-world questions, personalised recommendations, conversational interaction with the map, initial rollout in the United States and India on Android and iOS, desktop announced for later (source).
Five months later, on 6 August 2026, a second announcement widened the set (source). Six strands:
1 rollout to 160 new countries 2 secure connection to Gmail, Calendar “soon” 3 food ordering partners 4 hotel price comparison 5 opening-hours detection from a storefront photo 6 busyness and transit alerts
Food ordering, meanwhile, was already there in mid-July:
ASK_MAPS_FOOD_ORDERING_AGENT END_TO_END_ACTION_FOOD_ORDERING
The announcement is almost entirely a server-side switch-on of infrastructure shipped earlier.
FetchLlmResult GetKnowBeforeYouGoSummaries CallKnowBeforeYouGoAgent PrototypeCallAskMapsAgent PrototypeCallAskMapsAgentStreamed CreateSharedAskMapsHistoryThread GetSharedAskMapsHistoryThread
This lets several functions be told apart:
GENERATION → LLM results AGENT → Ask Maps MEMORY → conversation history PLACE CONTEXT → Know Before You Go
So Ask Maps is less a chatbot placed in front of Maps than a new interface onto the semantic, geographic and transactional layers already present.
One telling value appears in the code:
PERSONAL_INTELLIGENCE = 45 out of 138 listing content types
We also find a service:
personalitem ListPersonalPlaces UpdatePersonalIntelligence UpdatePersonalNotes
And several sources carry unambiguous names:
KBYG_GMAIL_FLIGHT_RESERVATION KBYG_GMAIL_HOTEL_RESERVATION KBYG_GMAIL_RESTAURANT_RESERVATION TIME_TO_LEAVE_FOR_GMAIL_*
Another configuration, PLACESHEET_PERSONAL_INTELLIGENCE_MODULES, shows this layer can feed modules of the listing itself, not just a conversational answer.
Google's public framing goes the same way: Search services, Maps among them, can, with user consent, access applications like Gmail, Calendar and Google Photos in order to produce more personalised experiences.
Two people can now look at the same geographic entity without receiving exactly the same informational composition around it.
The received idea is that everything happens between the phone and the server, the first sending a query and the second returning an answer:
phone │ ▼ Google server │ ▼ response
An embedded system layer reveals another storey. Part of the geographic intelligence is computed locally on the device.
We found two large layers.
This stage is tagged: 102 named messages, numbered fields. We read the names directly.
SemanticSegment Visit PlaceCandidate PlaceInfo MobilePlacePopularity CslStateSnapshot DeviceGenericPersona
This stage is compiled to WebAssembly. Its 85 parsing tables are located and their exact tags known, but none is nameable: we know type names from RTTI, not the type-to-table mapping.
PulpCalculationInputs FeatureWeights Persona ChainAffinity UserLocationProfile FrequentPlace FrequentTrip PlaceAggregates AliasedLocationLite
The distinction matters. On CSL we can cite a message name and say it exists. On Pulp we can say an 85-entry table exists and give its tags, without being able to claim that a given table corresponds to a given type.
The visible pipeline looks like this:
LOCATION SIGNAL
│
▼
POINT-BY-POINT INFERENCES
│
▼
SEGMENTATION
│
▼
BEAM SEARCH
│
▼
SEMANTIC SEGMENTS
│
▼
VISITS / CANDIDATE PLACES
│
▼
PULP / HULK
│
├── home
├── work
├── frequent places
├── frequent trips
├── travel modes
└── personaThe profile holds:
Persona ├── ChainAffinity ├── LocationAffinity └── TravelModeAffinity FrequentPlace FrequentTrip Visit Activity PlaceCandidate SemanticSegment
The most striking field for brands is this one.
Persona.ChainAffinityA user's affinity for a retail brand can be computed and kept as a piece of their local geographic profile.
This must be told apart from a universal ranking factor. It is an on-device personalisation value.
But for understanding where Google Maps is heading, it is an architectural signal.
The home/work labelling component hard-codes a series of category identifiers.
housing indoor_lodging
residential_area guest_house
apartment motel
apartments luxury_hotel
apartment_complex budget_hotel
condominium resort_hotel
student_housing_... boarding_school
building_society college
cottage_village university
kindergarten
library
station
transitAnd right next to them appear states such as:
tp-poi-suitable-for-home tp-poi-not-suitable-for-home tp-poi-suitable-for-work tp-poi-not-suitable-for-work tp-no-prominent-category
So the semantic nature of the place takes part in deciding whether it is plausible as a home or as a workplace.
The last value is worth reading twice: tp-no-prominent-category. A place with no prominent category is an explicitly handled case, not a forgotten one.
This scorer must not be confused with the 72 Geostore signals. It belongs to the embedded search engine and is not used when the ranking comes from the server.
Its structure:
8 signals
× 13 tiers
+ 8 bases
─────────────
112 functionsFour dimensions of its main family could be characterised experimentally:
| Code | Observed behaviour |
|---|---|
c-L | baseline local prominence |
c-R | textual match between query and name |
c-C | category match |
c-A | address and position component |
The tier depends on the viewport scale. When we vary zoom only, every signal changes tier together.
That gives one more separation:
GEOSTORE RANKING
72 signals, entity importance
≠
PLACES SERVER RANKING
query + geography + relevance
≠
CLIENT OFFLINE SCORER
8 signals × 13 tiersSo speaking of “the Google Maps ranking” as one formula hides several different mechanisms.
One last step remains. Even if an entity exists and is a candidate, Google must decide what will actually be written on the map.
The mapcore rendering engine is shared across several environments. We recovered a table of:
50 998 styles 12 936 label styles
A style can change with zoom. The mechanism for text appearing is simple:
font.size = 0
↓
label invisible
font.size > 0
↓
label displayableAcross 1,386 styles starting at zero size, the appearance levels vary widely. And 593 styles never become text, at any zoom we studied. They stay as representations with no written name.
On global style 7557, “Restaurant & Bar”, the two zoom entries are identical field for field, with one exception:
style 7557 “Restaurant & Bar” zoom 0 font.size = 0 px zoom 11 font.size = 11 px every other field: identical
So the visibility of a business name is not simply:
business score > threshold
The server first assigns a style. That style determines from which zoom its text becomes eligible.
Each LabelRenderOp holds:
text geometry style priority rank CID / Feature ID alternative representations
On the layer where the 20 search results are injected into the map, we find exactly:
result #1 → 16383 result #2 → 16382 result #3 → 16381 … result #20 → 16364
So the server ranking order becomes directly a display priority order for the injected results.
The client receives far more labels than it can display. Its job is then to:
resolve collisions
↓
try an alternative representation
↓
text
↓
icon only
↓
drop if necessaryIt does not recompute the business relevance. Most of the decision was taken upstream.
So the right way to think about Maps is no longer:
PLACES DATABASE
↓
ALGORITHM
↓
RESULTSbut:
TRUTH SYSTEM
+
ENTITY GRAPH
+
DOCUMENT INDEX
+
SEARCH ENGINE
+
MAP ENGINE
+
EMBEDDED MODELS
+
PERSONALISATION
+
GENERATIVE AIIt would be tempting to turn the 72 signals into a new ranking-factor checklist. That would misread the study.
The most important lesson is architectural.
Google tries to build a coherent identity of the place across:
Maps · Knowledge Graph · Web · Merchant data UGC · geography · chain · history
The first job is to reduce ambiguity around the entity. Name, address, phone, category, URL, brand, establishment and relations must tell the same story.
The document-to-MID link is present in the index. The page topicality towards the entity is itself represented, and Webref ranks documents against one another for that entity. Aggregated Web scores then come back into the Geostore vocabulary.
A good local page must unambiguously answer:
Which place? Which brand? Which address? Which category? Which services? Which products? Which service area? Which relation to the other locations?
Google reasons with concepts, one primary category and ontological relations. A brand must properly cover its real semantic territory, by supplying enough coherent information for Google to link the place to the right concepts.
One clarification that heads off a bad inference: the schema knows no gradation between secondary categories. Only the switch to primary category is a fact the data carries, and we saw it diverge from store to store inside one brand. Stacking secondary categories to “reinforce relevance” has no support here.
SIGNAL_GOOGLE_WEB_QUERYVOL explicitly belongs to the Geostore rank vocabulary. In parallel, the query engine can recognise a brand as an entity and attach categories to it.
That reinforces an idea hard to measure in local SEO: awareness and demand around the entity can matter as much as the textual optimisation of its listing.
This is not an invitation to manufacture brand searches. It means local does not live in a silo separate from overall demand.
SIGNAL_GOOGLE_REVIEWS exists in the rank vocabulary. But reviews also produce themes, extract sentiment, identify concepts, supply justifications, feed generative summaries and answer conversational questions.
With Ask Maps, a review becomes a corpus of evidence about:
service · product · wait · noise atmosphere · accessibility · quality price · dishes · use cases
For brands, review strategy also becomes a strategy of informational coverage.
LISTING_IMPRESSIONS INFOWINDOW_VIEWS DIRECTION_REQUESTS HOMEPAGE_CLICKS
At minimum this shows Google can keep and normalise these interaction families within entity rank. The right goal is not to game them: it is to build a place that naturally generates demand and real actions.
BusinessChainProto exists. SIGNAL_GOOGLE_CHAIN_STORES exists. Persona.ChainAffinity exists on the user side. Maps tells a chain from a specific business as early as Suggest.
And measurement makes the point concrete: across 21 stores of one brand in one metro area, 11 carry gcid:pharmacy and 10 carry gcid:drugstore as primary category, while canonical_gconcepts declares an ideal state for the chain members.
BRAND ENTITY
│
├── store A
├── store B
├── store C
└── store DFor a multi-site brand, both levels need work, rather than treating each listing as an island.
Our measurements show a brand query can make the engine search much further than a dense local category. And that the same query, outside a metro area, widens by a factor of 34.
You have to stop reasoning purely as:
"I am 800 metres away, so I should be ahead"
Google balances what the user wants, what exists around them, and the importance and quality of the candidates. Distance is central. It is not sovereign.
That does not mean proximity demand is ignored: it is measured. The 2024 leak documented a clickRadius50Percent attribute, the radius within which half the clicks on a query happen. In other words Google knows, per query, how far its users are willing to go — and that radius is learned, not set.
APPROACHABILITY TOTAL_ROAD_SEGMENT_USAGE ROAD_PRIORITY
A physical address has real properties: access, roads, flows, position, environment, transport. Not everything is optimisable from a CMS.
The best retail location and the best local-SEO location are probably not two entirely independent problems.
Geostore has states for:
closed · removed · moved · rebranded duplicate · replaced · spam
It also keeps existence confirmations with their origin and timestamp. So a company must watch duplicates, relocations, former locations, rebrandings, temporary closures and address inconsistencies.
An identity error is worse than a poorly optimised field.
Ask Maps changes the system output. Before:
query ↓ list of places
Now:
complex question
↓
understanding the need
↓
selecting places
↓
reading the attributes
↓
reading the reviews
↓
Knowledge Graph
↓
optional personal context
↓
synthesis
↓
reasoned recommendationSo a business must supply enough to answer questions like:
Which restaurant would suit six people with children and one vegetarian?
Which shop is convenient on my route and still open after my appointment?
Where can I eat quickly near my hotel with good recent reviews about service?
Which shop best matches the brands I already like?
These are no longer category queries. They are problems to solve out of attributes, relations and evidence.
For a long time local SEO organised itself around three big ideas:
proximity relevance prominence
These notions remain useful. But the mechanisms we observed suggest a richer reading.
To recommend a business, the AI has to be able to determine:
what it is what it offers where it is how you get there who likes it for which reasons in which situations under which constraints at which time and with what level of confidence
So the competition is no longer only about the best listing. It is progressively about the best representation of the entity.
The most important finding in this study is not any single signal.
It is not GOOGLE_REVIEWS. It is not POPULARITY. It is not PROMINENCE. It is not even MIXER_PLACERANK.
It is the whole architecture.
The 2024 leak showed us part of the blueprints. The recent binary and the measurements taken around Maps now let us follow a large part of the wiring.
And it is probably at the moment Google puts Gemini on top of this infrastructure that such an understanding becomes most useful.
Google Maps is not a local search engine with AI bolted on.
It is becoming a system able to build a representation of the physical world, link it to the Web and to entities, observe it through behaviour, contextualise it for a user, then answer in natural language.
For SEOs and retail brands, that changes the question. It is no longer only:
"How do I rank my listing better?"
The question becomes:
"What representation does Google actually hold of my business, my brand, and what they can bring to this particular user?"
That is probably where the next generation of local SEO begins.
Everything this study quotes can be checked line by line in the archive: 10,936 declarations, the March 2024 documentation alongside, and the full dump to take away.
Explore the archive