A leaked Google Maps binary plus related 2024 documentation pulls back the curtain on how Google internally represents places. For local-search teams this isn’t a tweak to ranking signals — it’s a shift in the fundamental optimization unit. Google builds canonical place entities from hundreds of sources, ties them to the Knowledge Graph and on-device models, and treats listing edits as one piece of evidence among many.

What the Geostore material actually shows

Internally Google models geographic objects as Features inside a system called Geostore. A Feature can be a business, building, road, transit element or even a 3D object. For establishments the Feature may include identity, geometry, provenance metadata, Knowledge Graph links, website references and precomputed ranking fields.

The recovered binary and supporting files enumerate concrete structures: 72 named ranking signals (the internal Oyster Rank vocabulary), 793 distinct data-source providers, nearly 11,000 Geostore declarations and large numbers of map-rendering and label styles. The provenance system models trust, priority and conflation — the logic that resolves conflicting values from multiple sources.

Two practical corollaries follow. First, editing a Google Business Profile (GBP) is only one piece of evidence; that edit can enter a conflation pipeline and may not immediately replace a canonical value. Second, inconsistent data across authoritative sources is harder to fix by changing a single listing because Geostore reconciles many inputs before updating the entity.

Oyster Rank: visible signals, not an exposed formula

The files list 72 Oyster Rank signals, including Google reviews, web query volume, listing impressions, direction requests, website clicks, chain membership, Wikipedia cues, popularity and landmark information. The schema shows how observations are normalized and mixed into a Feature’s rank field.

Crucially, the recovered scope contains signal names and pipeline stages, but not the coefficients that determine the weight of each signal. Some signals are explicitly marked deprecated. In short, the presence of SIGNAL_GOOGLE_REVIEWS in the vocabulary proves reviews are part of the system; it does not reveal how heavily reviews influence results for a given query.

Oyster Rank appears to be one internal layer among several. Results still pass through query understanding, semantic matching, candidate generation, geographic and quality filters, and multiple reranking stages. The corpus also documents an offline on-device scorer with its own signals and tiers. There is no single, global Maps ranking formula to reverse-engineer from the leaked list alone.

Geography, web evidence and semantics operate together

Measurements in the recovered material show Google does not use a fixed-radius model for local queries. The geographic candidate space adapts to the query and context: dense urban category searches produce tighter footprints than broad or brand queries, while rural searches enlarge the footprint. Tests indicate geography changes which candidates are considered, not only their order.

Geostore Features can connect to Knowledge Graph machine IDs (MIDs). On the web side, Google’s webref layer associates documents with entities, storing topicality, geographic metadata and document-level scores. That makes a location page or store locator more than an SEO landing page: it can serve as evidence for an entity’s attributes and topical relevance.

Google also uses a shared concept vocabulary (GConcepts) to represent cuisines, menu items, amenities and service modes. Structured concepts let the system answer complex, multi-constraint queries without reprocessing all raw review text at query time.

Practical implications for local search practice

The exposed architecture points to five strategic shifts for practitioners:

  • Treat the entity as the optimization unit. Make it easy for Google to link pages and data to the canonical place: consistent identifiers, accurate NAP, clear schema.org markup and matching geographic metadata.
  • Manage provenance across sources. Because Geostore conflates inputs, correct values should be present and trusted across multiple authoritative providers, not only in one listing.
  • Design pages as entity evidence. Use structured data, explicit entity mentions and consistent positional metadata so web documents can act as reliable references for entity attributes and topicality.
  • Optimize for concepts as well as categories. Mark up menu items, services and amenities so semantic matching and concept-level retrieval can surface them in AI-driven answers.
  • Measure beyond rank. Rendering and label visibility on the map are separate from retrieval ranking; an entity can rank well yet remain visually suppressed on certain map layers.

Because the leak does not include signal weights or full server-side details, these recommendations are strategic rather than prescriptive. They reflect the system architecture revealed by the material without claiming specifics about proprietary coefficients.

What to watch next: Google’s conversational layers will increasingly query the canonical entity graph, semantic concepts and device context. For local-search teams the next step is to instrument properties as entity-first assets, distribute correct data across multiple trusted sources, and monitor both search retrieval signals and map-rendering visibility as distinct KPIs.