Google Maps Ranking Signals: 72 Recovered From Geostore

Google models a place as a canonical entity, not the listing you edit in your Business Profile. The distinction matters. All 72 of the Google Maps ranking signals pulled from the Geostore data recovered in 2026 attach to that underlying entity, not to the interface you fill in. Build for discoverability and you optimize the entity Google stores, not the window you happen to look through. The listing is that window. Change it and a searcher sees something new, while the thing being ranked sits untouched underneath.

That sounds academic. It isn’t. Where you point your effort depends entirely on which layer you think you are editing, and the recovered data settles the question.

What the recovered Google Maps ranking signals document

In September 2026, a research team recovered a Google binary that exposed a non-public scope of Geostore, the database Google uses to represent real-world places. From it they pulled 72 named signals belonging to an internal Maps ranking system called Oyster Rank, as reported by Search Engine Land. Twenty-five are marked deprecated, and Navboost, the user-interaction system Google is known for on the web side, appears among those retired names (Abondance, 2026). That leaves 47 the enum still treats as live.

The names are concrete. Reporters who read the enum surfaced roughly a dozen of them by name, and grouping those by what they actually measure is more useful than a flat dump. Four families cover the ones that have been published:

Demand and behavior. Counts of what people do, which no field edit can fabricate.

• Entity query volume. How often people search for the place by name.
• Listing impressions and opens. How often the entity surfaces, and how often someone taps in.
• Direction requests. Navigation intent, logged as a behavior.
• Website clicks. Outbound taps from the entity to its site.

Reputation.

• Google reviews. The review corpus tied to the entity, not any one rating field you can edit.

Entity and relationships. How the place sits inside Google’s wider graph.

• Chain membership. Whether the place belongs to a business chain, and which one.
• Wikipedia signals. The entity’s link into encyclopedic coverage.
• Popularity and prominence. Aggregate interest, plus standing within the local set.

Geography.

• Landmarks. Nearby anchors that fix the place in real space.
• Road usage. Traffic and access around the location (Relevant Audience, 2026).

Roughly sixty names stay unpublished. Read the families as coverage, not as a weighted ranking. The point they make is that Oyster Rank’s vocabulary spans behavior, reputation, relationships and raw geography, far past the handful of profile fields most local guides still fixate on.

Around those signals sits a much larger vocabulary. There are 793 data source providers. There are 446 local search intent types. Geostore itself exposes 10,936 searchable declarations. A place in Google is not a form you filled in. It is a reconciled record pulled from hundreds of competing feeds.

Documented versus inferred

Be precise about what the recovery proves. What is documented is the names and the structure they sit inside, never their weights (Search Engine Land). Finding SIGNAL_GOOGLE_REVIEWS proves reviews belong to the Oyster Rank vocabulary. It does not prove reviews move a single ranking today. So anyone ordering these 72 signals by importance is guessing, and you should read the list as a map of what Google can measure rather than a scorecard.

The entity is the unit, the listing is the interface

Under the visible listing, Geostore keeps a canonical geographic entity with its own identity, location, source provenance, websites, business-chain relationships, Knowledge Graph references, and ranking information. When feeds disagree, Google resolves the conflict through provenance and trust rules. Your edit is not the last word (Search Engine Land).

The bridge from that place-entity to the rest of Google’s knowledge runs through one identifier. The Knowledge Graph MID, the Machine ID, is a stable, language-independent handle for an entity (Cloud Natural Language, Entity reference). It is how Maps connects a restaurant to its Wikipedia page and its parent chain. It is the same join key entity-based SEO leans on everywhere else. I walked through using the MID to diff declared schema against the entities Google’s NLP surfaces in the entity gap audit pipeline, and the logic there is the logic here. The listing you edit is one input feed among many.

That entity is only the start. Abondance, reporting the recovery independently, traces the pipeline that follows: the canonical record is scored by several ranking systems, filtered through geographic and semantic retrieval, personalized for the user, then handed to a rendering engine that decides what can appear on the map at all (Abondance, 2026). A separate layer called Webref binds ordinary web documents back to that entity. Your listing edit enters at the very first stage. Several stages sit between it and the pin a searcher finally taps.

So the working criteria for local search architecture shift with it:

• Consistency across feeds. Google reconciles 793 providers, and disagreement between them reads as low trust.
• Resolvable identity. A sameAs to Wikipedia or Wikidata binds your entity to a MID instead of leaving an unlinked name to float.
• Signal breadth over listing polish. Reviews, direction requests, opens, and query volume are entity-level behaviors no field edit can fake.

Why the model transfers to AI retrieval

Here is the part that reaches past Maps. The entity-not-listing pattern is the shape every modern retrieval system already uses. An AI assistant does not answer from your page as you wrote it. It answers from an internal representation of what your page is about, resolved against entities it already trusts. Polish the surface text without a resolvable entity behind it and you have rebuilt the listing mistake in a new place.

A page can rank and still go uncited, a split we traced in AI search visibility versus organic rankings. The system retrieves the entity first. Then it weighs whether your content is the best expression of that entity. Maps just makes the architecture legible enough to see.

The verdict

Optimize the entity, not the listing. The recovered Oyster Rank data hands you no weighted checklist, and treating it as one would be the real mistake. What it confirms is architectural: Google stores places as canonical, MID-keyed entities reconciled from hundreds of sources, and all 72 signals attach there. For a developer building for discoverability, identity hygiene and resolvable references beat another pass at the Business Profile form. The deprecated quarter of the list is its own warning. A signal Google once named is not a signal Google still counts.

If you ship sites, audit one place-entity this month the way you would audit schema. Check whether it resolves to a MID. Check whether your feeds agree with the web you point them at. The listing was always the easy part.