Google Maps Inside: How 72 Ranking Signals and the Local Search System Work

When a business appears on Google Maps, what a user sees in the results is just the tip of the iceberg of a complex, multi-layered system.

Beneath the surface lies a canonical geographic entity, formed from multiple data sources, integrated with the Knowledge Graph and web index, evaluated by multiple ranking engines, filtered through geographic and semantic algorithms, personalized to the user, and passed to a rendering engine that decides what to display on the map.

Our team recently gained access to a binary file from Geostore, Google’s internal system for representing geographic features. We compared this data with Maps protocols, network traffic, web index, mobile services, style sheets, client-side components, and the 2024 Google data leak.

The results of the reconstruction:

• 72 Geostore ranking signals
• 793 data providers
• 446 local search types
• 50,998 Mapcore styles
• 12,936 label styles
• 10,936 Geostore searchable ads

Ranking signals are certainly the most eye-catching. But they’re just one layer of the system. It’s the architecture around them that reveals the most interesting picture of how Google perceives places and what local SEO could become when Maps becomes a fully-fledged conversational product.

List ≠ Entity: The Fundamental Difference

To understand the system, you need to start with Geostore. Google represents geographic features as Features. A feature can be a business, a building, a road, a city, a transit station, a neighborhood, or even a 3D structure.

For a business, a feature contains identifiers, geometry, data source information, websites, business network connections, Knowledge Graph links, conceptual tags, and rating information.

The traditional list in Maps is created later. What a business owner edits in their Google Business Profile is not always the same as what Google stores as a canonical entity.

Google creates its own representation of a place that can include data from multiple sources, experience geometry changes, and link to other Google identifiers, including the Knowledge Graph Machine ID (MID).

For local SEO, an entity is a much more useful unit of analysis than a list. A list is just an interface. The essence lies deeper.

793 Data Sources: How Google Merges Information

One of the most impressive features of Geostore is its data provenance system.

A business rarely has a single source of information. A name might come from one provider, a phone number from another, a category from a third, and a geometry from somewhere else entirely.

The analysis revealed 793 data source providers, along with mechanisms for determining provenance, priority, trust, and merging.

Merging is a process that occurs when multiple sources describe the same object in different ways. Geostore has built-in mechanisms that can:

• Select a single value
• Merge multiple values
• Combine them in a specific way

The system also models trust levels, from blocked or untrusted sources to trusted and super trusted.

This explains a common local SEO problem: changing a field in a Google Business Profile doesn’t guarantee an immediate update to the canonical representation. Your edit becomes yet another piece of evidence in a system where competing data may already exist.

For businesses that are constantly dealing with incorrect attributes, duplicate information, or changes that are routinely reversed, this architecture helps to understand why the problem is more complex than simply editing a listing.

Data Archive: Why the Leak Has Become Much More Valuable

The binary itself provides the structures, field numbers, and full listings. Google’s March 2024 documentation often includes explanatory text that reveals the meaning of these structures.

Both sources are published together. The resulting archive contains 10,936 Geostore declarations, which can be searched by message name, package, field type, documentation text, tag number, status, and other parameters.

In reverse engineering, internal names easily turn into theories when spread through the SEO community. The archive allows you to check the original sources.

If the signal exists, you will find its declaration. If the field was in the 2024 documentation, you will read the corresponding description. If the field is removed from the new client area, its protobuf tag still leaves a numbered trail.

The 2024 leak provided descriptions of Google’s systems. A newer binary file provided their actual dictionary. Together they create a much more complete picture than either source alone.

Oyster Rank: 72 Geostore Ranking Signals

Geostore has its own ranking system called Oyster Rank. We got the full list of 72 signals, including:

• Google Reviews
• Web Query Volume
• Ad Views
• Ad Opens
• Directions Requests
• Website Clicks
• Network Memberships
• Wikipedia Signals
• Popularity
• Notability
• Landmark Information
• Road Usage

Of the 72 signals, 25 are marked as obsolete.

An important limitation: we have restored the signal names, but not their current weights. The diagram shows the pipeline where the raw observations are extracted, normalized, and mixed with the feature rank. However, the weights that would indicate the contribution of each signal are left out of the restored scope.

So, SIGNAL_GOOGLE_REVIEWS proves that reviews are included in the Oyster Rank dictionary. But it does not prove that reviews are currently weighted in Maps search.

72 signals ≠ Google Maps algorithm

This is a critical clarification for SEOs. Oyster Rank seems to assess the importance of an entity within the Geostore. But the user query still goes through additional systems.

Maps has to understand the human intent, determine the geographic context, generate candidates, evaluate semantic relevance, and return a final set of results.

A simplified pipeline looks like this:

Geostore entity → Understanding query → Semantic mapping → Candidate generation → Geography and quality → Re-ranking → Results

There are additional complications. We discovered a separate estimator that works completely offline on the device. It has 8 signals at 13 levels and is different from both Oyster Rank and the server-side Places ranking.

There is no single formula for ranking Maps. Different ranking and search engines work at different stages. Turning the 72 Oyster Rank signals into a checklist of 72 Google Maps ranking factors would mean ignoring much of the architecture.

Local Search: No Fixed Radius

We tested the geographic layer. The general model for local SEO is that Google searches within a predefined radius around a user and ranks businesses within that radius.

Our measurements showed something different. Using a single location in Paris, the geographic footprint varied significantly depending on the query.

A dense query like “pharmacie” produced a much smaller search area than a branded query like “Carrefour.”

The environment also matters. The same query “pharmacy” expanded dramatically when it was run in a sparsely populated rural area.

It seems that Google adapts the candidate space to both the query and what exists around the user.

When we removed the geographic weighting from the same search engine, across 5,083 calls and 86,584 results, the median distance changed from 6.87 km with geography to over 4,000 km without it.

Even more interesting, the non-geographic order remained remarkably stable.

This suggests that geography does more than simply reorder the same list of candidates by distance. It changes what the search engine considers.

Distance remains fundamental to local SEO. But the “If I’m closer, I must be higher” model is incomplete.

Maps and the Internet: Connecting via Entities

The connection between Maps and classic web SEO is one of the most important discoveries in the corpus.

Geostore features can connect to the Knowledge Graph via MIDs. On the web index side, documents can also contain MIDs.

Google has a webref layer that associates documents with entities and stores information including relevance, authority, geographic metadata, and ratings at the document level.

This connection also works at the document ranking level. The recovered structures describe the relative ranking signal between different documents for the same entity, as well as properties such as whether a page is an author page, publisher page, or link page.

This creates a completely different way of thinking about a store locator or location page. Its role can go beyond ranking for queries like “shoe store Paris.” The document can become evidence of the underlying entity.

The goal of SEO is partly to make it easier for Google to determine:

• What entity does the document describe
• What part of the document relates to that entity
• How strong the link should be
• Whether the document is a useful link to it

Web SEO and local SEO are much less separated in Google's infrastructure than their interfaces suggest.

Concepts instead of categories: the semantic layer

The semantic layer goes far beyond the basic category visible in a list. Google uses GConcepts, a shared conceptual dictionary that can describe businesses, dishes, attributes, cuisines, service methods, and other concepts.

We followed a simple query about ramen through several parts of the system. The search results themselves did not all fall into the same category. Google associated the query with ramen restaurants, Japanese restaurants, Asian restaurants, and other related concepts.

Inside the lists, the semantic representation goes deeper. Review topics, menu items, and other attributes can be represented as entities rather than as simple strings.

For an AI system, this is incredibly useful. Instead of having to reread thousands of reviews every time someone asks if a restaurant has a long wait or good ramen, Google can work with structured topics, entities, and pre-computed signals that are already tied to a place.

Semantic understanding becomes much more important when the interface starts answering complex questions.

Geographic intelligence on a user’s phone

Not everything is calculated on Google’s servers. We found structures on the device related to visits, place candidates, frequent places, trips, home and work, mobility patterns, and user location profiles.

One particularly interesting object is ChainAffinity, which suggests that the system can model affinity for a recurring retail network.

There is also a separate offline estimator, mentioned earlier.

The exact level of evidence differs between components. Some structures are explicitly named in the recovered schema, while parts of the personalization layer can only be reconstructed from compiled structures.

But the broader architecture is clear: the phone itself is involved in constructing geographic context.

This means that personalization in Maps can combine server-side knowledge of the world with a local model of the user’s own geography.

Ranking ≠ map visibility

Search results are just one of the results of Maps.

The visual map has another problem: thousands of potentially relevant features cannot be labeled at the same time. This task belongs in part to Mapcore.

We have restored 50,998 Mapcore styles and 12,936 label styles. Label visibility can vary depending on zoom and other rendering conditions.

A business can be eligible or highly ranked, but still not appear as a visible name on the map. Search ranking and map visibility are separate optimization issues.

This distinction becomes especially important when people measure “Maps visibility” using screenshots or map grids. The visual surface includes rendering decisions after search and ranking have already occurred.

Gemini is in first place

Recovery time is useful. Google is rapidly expanding Ask Maps and other AI-powered capabilities, but much of the infrastructure needed to answer complex questions was already in place.

• The system already has:
• Canonical place entities
• Semantic concepts and attributes
• Reviews and extracted topics
• Knowledge Graph links
• Web evidence
• Geographic search
• Behavioral signals
• Personal geographic context
• List composition
• Ranking systems

Gemini adds a conversational interface on top of these layers. This changes what a local query can be.

A query like “Best ramen near me” is relatively simple. A query like “Where can six people eat tonight near my hotel, one vegetarian, with a short wait and good recent service reviews?” requires a different kind of place representation.

Google needs to know what the restaurant is, what it serves, when it’s open, what people are saying about it, where it’s located, how it relates to the user’s route or context, and whether the data it has is reliable enough to recommend it.

Maps has been building many of these ingredients for years. The AI ​​layer gives Google a new way to use them.

What to Optimize Outside of Your Google Business Profile

The most actionable takeaway from this study isn’t a new list of ranking factors.

Local SEO has traditionally focused on optimizing your Google Business Profile: categories, reviews, photos, attributes, hours, and other listing fields.

They remain important. But Google’s architecture has a broader goal: to improve the representation Google can create of the entity itself.

For a business or retail brand, it’s worth asking more often:

• What exactly is this place?
• What does it offer?
• What brand or network is it part of?
• What concepts and attributes describe it?
• Does the website clearly describe that same entity?
• What web documents provide evidence of this?
• Is Google seeing real demand for the brand?
• What do reviews consistently say about specific aspects of the experience?
• What audiences and contexts might make this place relevant?
• When should Google recommend him over another candidate?

The quality of the response that Google can provide depends on the completeness of this representation.

Semantic Completeness: The New Battleground of Local SEO

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, but still be poorly represented for a particular question if Google can’t confidently associate relevant attributes, concepts, web pages, and review topics with the property.

A large retail brand has an additional problem. Google models both networks and individual locations. We’ve seen stores of the same brand in the same metropolitan area that have different core concepts, even though the network model contains a canonical concept structure.

You can’t assume consistency just because each location is owned by the same brand.

For multi-location SEO, the challenge extends to the brand entity, each local entity, the website, structured data, third-party sources, user-generated content, and the connections between them all.

This is a much larger surface area than a business profile.

The list is just the surface

The 72 Oyster Rank signals are fascinating because they reveal categories of information that Google can use to assess the importance of a place.

The deeper discovery is the system around them:

• Geostore creates a canonical geographic entity from competing sources
• A knowledge graph gives that entity semantic meaning
• Webref connects web documents to it
• Search and Places interpret the query and retrieve candidates in a dynamic geographic space
• Device systems inject personal geographic context
• Mapcore controls what goes on the visual map
• Ask Maps and Gemini can finally reason about the resulting representation in natural language

Google Business Profile still matters. But Google’s architecture suggests looking beyond the listing itself and considering the representation Google has created about the business.

The key question is: is this representation complete enough for Google to confidently recommend the business?

The full study includes reconstructed architecture, experiments, and technical evidence. The accompanying archive contains 10,936 restored Geostore listings along with documentation from 2024, allowing for direct verification of the underlying schemas, enumerations, fields, and signals.