When a business appears in Google Maps, the listing you see is the end product of a much larger system.
Behind it sits a canonical geographic entity assembled from multiple data sources, connected to the Knowledge Graph and the web, scored by several ranking systems, filtered through geographic and semantic retrieval, personalized for the user, and finally passed to a rendering engine that decides what can actually appear on the map.
Our team recently obtained a binary exposing a non-public scope of Geostore, the system Google uses to represent geographic entities. We crossed it with Maps protocols, network traffic, the web index, mobile services, style tables, on-device components, and Google’s 2024 leak.
The recovered material includes:
- 72 Geostore ranking signals.
- 793 data source providers.
- 446 local search intent types.
- 50,998 Mapcore styles.
- 12,936 label styles.
- 10,936 searchable Geostore declarations.
The ranking signals will probably attract attention. But they’re only one layer.
The architecture around them tells a more important story about how Google understands places and what local SEO may become as Maps turns into a conversational product.
The first thing to understand: A listing isn’t the entity
A useful mental model starts with Geostore. Google represents geographic objects internally as Features. A Feature can be a business, building, road, city, station, area, transit element, or even a 3D object.
For an establishment, the object can contain identity, geometry, source information, websites, business-chain relationships, Knowledge Graph references, concepts, and ranking information.
The familiar Maps listing is assembled later. What a business owner edits in Google Business Profile isn’t necessarily what Google maintains internally as the entity.
Google builds a canonical representation of the place that can incorporate data from multiple sources, survive changes in geometry, and connect to other Google identifiers, including the Knowledge Graph machine ID (MID).
For local SEO, the entity is the more useful unit to consider. The listing is the interface. The entity sits underneath it.
Everything you need to manage your GBP, dominate Google Maps, and attract more customers.
Google combines data from 793 providers
One of the most revealing parts of Geostore is its provenance system.
A business doesn’t simply have one source. Its name might come from one provider, its phone number from another, its category from another, and its geometry from somewhere else entirely.
The corpus exposes 793 source providers, along with mechanisms for provenance, priority, trust, and conflation.
Conflation is the process used when several sources describe the same object and disagree.
Geostore contains generic mechanisms that can pick one value, merge several values, or combine them. It also models trust levels ranging from blocked or untrusted sources to trusted and super-trusted ones.
This gives a different interpretation to a common local SEO problem: changing a field in Google Business Profile doesn’t guarantee that Google’s canonical representation immediately becomes that new value.
The edit becomes another piece of evidence entering a system that may already have competing evidence.
For businesses struggling with persistent incorrect attributes, duplicate information, or changes that repeatedly revert, this architecture helps explain why the problem can be harder than editing a listing.
Dig deeper: The local SEO gatekeeper: How Google defines your entity
The archive makes the leak much more useful
The binary itself gives us structures, field numbers, and complete enumerations. Google’s March 2024 documentation often gives us something different: prose explaining what those structures mean.
We published the two together. The resulting archive contains 10,936 Geostore declarations that can be searched by message name, package, field type, documentation text, tag number, status, and other properties.
In reverse-engineering work, an internal name can easily become a theory once it circulates through the SEO community. The archive lets you inspect the underlying evidence.
If a signal exists, you can find its declaration. If a field existed in the 2024 documentation, you can read the associated description. If a field has been stripped from the newer client scope, its protobuf tag still leaves a numbered hole.
The 2024 leak gave us many descriptions of Google’s systems. The newer binary gives us much more of their actual vocabulary.
Together, they provide a more useful picture than either source does on its own.
Oyster Rank contains 72 ranking signals
Geostore has its own ranking system. Internally, it’s called Oyster Rank. We recovered a complete visible enumeration of 72 signals, including:
- Google reviews.
- Web query volume.
- Listing impressions.
- Listing opens.
- Direction requests.
- Website clicks.
- Chain membership.
- Wikipedia signals.
- Popularity.
- Prominence.
- Landmark information.
- Road usage.
Out of 72 values, 25 are explicitly marked deprecated.
The important limitation is that we recovered the signal names, not their current weights.
The schema shows a pipeline in which raw observations are extracted, normalized, and mixed into the Feature’s rank. But the coefficients that would tell us how much each signal contributes are outside the scope we recovered.
So SIGNAL_GOOGLE_REVIEWS proves that reviews belong to the Oyster Rank vocabulary. It doesn’t prove that reviews currently carry a particular weight in a Maps search.
The 72 signals aren’t the Google Maps algorithm
This is probably the most important clarification for SEOs. Oyster Rank appears to characterize the importance of the entity inside Geostore. A user query still has to go through additional systems.
Maps must understand what the person means, identify a geographic context, generate candidates, evaluate semantic relevance, and serve a final result set.
A simplified pipeline looks more like:
Geostore entity -> query understanding -> semantic matching -> candidate generation -> geography and quality -> reranking -> results
There are additional complications. We also found a separate scorer running entirely offline on the device. It has eight signals across 13 tiers and is distinct from both Oyster Rank and server-side Places ranking.
There isn’t a single Maps ranking formula. Different scoring and retrieval systems operate at different stages.
Turning the 72 Oyster Rank signals into a checklist of 72 Google Maps ranking factors would miss most of the architecture.
Local search doesn’t have a fixed radius
We also tested the geographic layer directly. A common local SEO model imagines Google looking within a predefined radius around the user and ranking the businesses found inside it.
Our measurements show something more dynamic. Using the same origin in Paris, the geographic footprint changed considerably depending on the query.
A dense query, such as pharmacie produced a far smaller search area than a brand query, such as Carrefour.
The environment matters, too. The same pharmacy query expanded dramatically when run in a sparsely populated rural area.
Google appears to adapt the candidate space to both the query and what exists around the user.
We then removed geographic weighting from the same engine. Across 5,083 calls and 86,584 results, the median distance moved from 6.87 km with geography to more than 4,000 km without it.
More interestingly, the non-geographic order remained extremely stable.
This suggests geography is doing more than reordering the same list of candidates by distance. It changes what the retrieval system considers in the first place.
Distance is still fundamental in local SEO. But “I’m closer, I should rank higher” is an incomplete model.
Dig deeper: The proximity paradox: Beating local SEO’s distance bias
Maps and the web are connected through entities
The connection between Maps and classic web SEO may be one of the most consequential findings in the corpus.
Geostore Features can connect to the Knowledge Graph through a MID. On the web index side, documents can also carry MIDs.
Google has a layer called webref that associates documents with entities and stores information, including topicality, confidence, geographic metadata, and document-level scores.
The relationship also works at the document-ranking level. The recovered structures describe a relative ranking signal between different documents for the same entity, along with properties such as whether a page is an author page, publisher page, or reference page.
This creates a very different way of thinking about a store locator or location page. Its role may extend beyond ranking for queries such as “shoe shop Paris.” The document can become evidence about the underlying entity.
The SEO objective is then partly to make it easy for Google to establish:
- Which entity the document describes.
- How much of the document is actually about that entity.
- How confident that association should be.
- Whether the document is a useful reference for it.
Web SEO and local SEO are much less separate inside Google’s infrastructure than their interfaces suggest.
Google understands concepts, not just categories
The semantic layer goes considerably beyond the primary category visible on a listing. Google uses GConcepts, a shared conceptual vocabulary that can describe businesses, dishes, attributes, cuisines, service modes, and other concepts.
We followed a simple ramen query through several parts of the system. The search results themselves didn’t all belong to one category. Google connected the query with ramen restaurants, Japanese restaurants, Asian restaurants, and other related concepts.
Inside listings, the semantic representation goes deeper. Review topics, menu dishes, and other attributes can be represented as entities rather than plain strings.
For an AI system, this is extremely useful. Instead of rereading thousands of reviews every time someone asks whether a restaurant has long waits or good ramen, Google can work from structured themes, entities, and precomputed signals already attached to the place.
Semantic understanding becomes much more important when the interface starts answering complex questions.
Part of Google’s geographic intelligence lives on the phone
Not everything is calculated on Google’s servers. We found on-device structures associated with visits, place candidates, frequent places, trips, home and work, mobility patterns, and user location profiles.
One particularly interesting object is ChainAffinity, which suggests the system can model affinity toward a recurring retail chain.
There’s also the separate offline scorer mentioned earlier.
The exact evidence level differs between components. Some structures are explicitly named in the recovered schema, while parts of the persona layer can only be reconstructed from compiled structures.
But the broader architecture is clear: The phone itself participates in building geographic context.
That means personalization in Maps can combine server-side knowledge of the world with a local model of the user’s own geography.
Ranking still doesn’t guarantee map visibility
Search results are only one of the outputs of Maps.
The visual map has another problem to solve: Thousands of potentially relevant entities cannot all receive labels simultaneously. That job belongs partly to Mapcore.
We recovered 50,998 Mapcore styles and 12,936 label styles. Label visibility can change with zoom and other rendering conditions.
A business can be eligible or highly ranked and still fail to appear as a visible name on the map. Search ranking and map visibility are separate optimization problems.
This distinction becomes especially important when people measure “Maps visibility” using screenshots or map grids. The visual surface includes a rendering decision after retrieval and ranking have already happened.
Then Google puts Gemini on top
The timing of the recovery is useful. Google is rapidly expanding Ask Maps and other AI-powered experiences, but much of the infrastructure required to answer complex questions was already present.
The system already has:
- Canonical place entities.
- Semantic concepts and attributes.
- Reviews and extracted topics.
- Knowledge Graph relationships.
- Web evidence.
- Geographic retrieval.
- Behavioral signals.
- Personal geographic context.
- Listing composition.
- Ranking systems.
Gemini adds a conversational interface over these layers. That changes what a local query can be.
“Best ramen near me” is relatively easy. “Where can six people eat near my hotel tonight, with one vegetarian, little waiting time, and good recent feedback about service?” requires a different kind of place representation.
Google needs to know what the restaurant is, what it serves, when it’s open, what people say about it, where it is, how it relates to the user’s route or context, and whether the available evidence is reliable enough to recommend it.
Maps has been building many of those ingredients for years. The AI layer gives Google a new way to use them.
Dig deeper: Google Ask Maps: How to optimize for visibility
What to optimize beyond the Business Profile
The most actionable conclusion from this research isn’t a new list of ranking factors.
Local SEO has traditionally concentrated heavily on optimizing the Google Business Profile: categories, reviews, photos, attributes, opening hours, and other listing fields.
Those remain important.
But Google’s architecture suggests a broader objective: improve the representation Google can build of the entity itself.
For a business or retail brand, I would increasingly ask:
- What exactly is this place?
- What does it offer?
- Which brand or chain does it belong to?
- Which concepts and attributes describe it?
- Does its website describe the same entity clearly?
- Which Web documents provide evidence about it?
- Does Google see real demand for the brand?
- What do reviews consistently say about specific aspects of the experience?
- Which audiences and contexts could make this place relevant?
- When should Google recommend it rather than another candidate?
The quality of the answer Google can produce depends on the completeness of that representation.
Semantic completeness may become the next local SEO battleground
Proximity, relevance, and prominence remain useful concepts.
AI adds another requirement. The system needs enough structured evidence to reason about a place.
A restaurant can have an optimized profile and hundreds of reviews, yet still be poorly represented for a specific question if Google can’t confidently connect the relevant attributes, concepts, web pages, and review themes to the entity.
A large retail brand has an additional problem.
Google models both chains and individual locations. We observed stores from the same brand in the same metropolitan area carrying different primary concepts, even though the chain model contains a canonical concept structure.
Consistency can’t be assumed simply because every location belongs to the same brand.
For multi-location SEO, the task extends across the brand entity, each local entity, the website, structured data, third-party sources, user-generated content, and the relationships between all of them.
That’s a much larger surface than a Business Profile.
Dig deeper: Multi-location SEO: How to structure geographic pages at scale
Boost your visibility, earn more reviews, climb higher on Maps, and stay ahead of local competitors.
The listing is only the surface
The 72 Oyster Rank signals are fascinating because they expose categories of information Google can use when estimating the importance of a place.
The deeper finding is the system around them:
- Geostore builds a canonical geographic entity from competing sources.
- The Knowledge Graph gives that entity semantic meaning.
- Webref connects Web documents to it.
- Search and Places interpret the query and retrieve candidates within a dynamic geographic space.
- On-device systems contribute personal geographic context.
- Mapcore controls what reaches the visual map.
- Ask Maps and Gemini can finally reason over the resulting representation in natural language.
The Google Business Profile still matters. But Google’s architecture suggests looking beyond the listing itself and considering the representation Google has built of the business.
The key question is whether that representation is complete enough for Google to confidently recommend the business.
The full study includes the reconstructed architecture, experiments, and technical evidence. The companion archive exposes the 10,936 recovered Geostore declarations alongside the 2024 documentation so the underlying schemas, enums, fields, and signals can be inspected directly.
