How Google Maps Local Ranking Actually Works: An Audit Guide

If your Google Business Profile is accurate but local rankings still jump between queries, neighborhoods or devices, the problem may not be the field you last edited. Google Maps does not simply score a listing against nearby competitors. It assembles evidence about a place, interprets the search, retrieves candidates, applies geographic and quality systems, reranks the results and decides what the interface can display.

That architecture changes how you should investigate poor visibility. Instead of chasing a supposed master list of ranking factors, you can identify the layer where the failure is probably happening and make a change that addresses it.

Key takeaways

• Your Google Business Profile is an interface to a larger geographic entity. Editing the profile adds evidence; it does not necessarily replace every competing value Google already holds.
• The exposed Oyster Rank vocabulary contains 72 named signals, including 25 marked as deprecated. It does not reveal the live weights used to order results.
• Maps ranking is a pipeline. Entity importance, query relevance, candidate retrieval, geography, quality, personalization, reranking and rendering can each affect what you see.
• Local search does not operate within one fixed radius. The geographic footprint can change with the query, local density and search context.
• A useful audit holds the query, origin and surface constant. Otherwise, a ranking change may reflect a different retrieval problem rather than the work you performed.

Your listing is not the complete business entity

Google represents geographic objects internally as Features in a system called Geostore. For an establishment, a Feature can contain identity, geometry, provider information, websites, chain relationships, concepts, ranking information and a Knowledge Graph machine ID. The listing displayed in Maps is assembled from that underlying representation.

This is more than a technical distinction. A business owner may enter one phone number while another provider supplies an older one. The website may imply one business name while a directory, map feed or legacy record uses another. Google then has to determine whether those records describe one place, several places or a place that has changed.

The exposed provenance system identifies 793 data providers and mechanisms for trust, priority and conflation. Conflation is the process of reconciling records that appear to describe the same object. Depending on the field and available evidence, a value may be selected, merged or combined with other values.

That helps explain a familiar pattern: you correct an attribute, it appears briefly, and then it changes back. Your edit entered the evidence pool, but other evidence may still support the old value. Repeating the same edit without locating the conflict treats the visible symptom rather than the underlying identity problem.

Build a small identity ledger before making more changes. Record the exact public name, primary URL, phone number, address or legitimate location description, map pin, primary business category and any old identities still visible online. Compare that ledger with your profile, homepage, contact page, location pages, structured data and important external citations. Look especially for moved locations, old telephone numbers, duplicate profiles and inconsistent business names.

Use LocalBusiness or the most accurate applicable subtype in your JSON-LD to describe the same identity your pages present to people. Keep the name, URL, telephone, address and stable @id consistent across your own graph. Structured data makes your site less ambiguous, but it is supporting evidence, not a command that forces Maps to accept a value or improve a position.

If a correct field keeps reverting, stop treating it as a ranking problem. Document the conflicting versions, correct the records you legitimately control and investigate whether Google is merging your business with an old location or duplicate entity. Until identity is stable, content and review work may be evaluated against an entity that Google does not understand the way you expect.

Maps ranking is a pipeline, not a 72-factor checklist

Oyster Rank appears to characterize the importance of a Feature inside Geostore. Its visible vocabulary includes Google reviews, web query volume, listing impressions, listing opens, direction requests, website clicks, chain membership, Wikipedia signals, popularity, prominence, landmark information and road usage.

The existence of a signal name establishes that the system can represent that observation. It does not establish its current weight, whether it applies to every search or whether causing more of the observed event will improve rank. The recovered schema shows raw observations being extracted, normalized and mixed, but the coefficients needed to calculate their contribution were not exposed.

Even a complete Oyster Rank score would not by itself predict the order of a local result set. Maps still has to understand the query, establish geographic context, find eligible candidates, assess semantic relevance, apply geographic and quality considerations, personalize where applicable, rerank the candidates and render the permitted result or label. A separate offline scorer with eight signals across 13 tiers was also identified on the device, distinct from Oyster Rank and server-side Places ranking.

These symptoms are diagnostic clues, not proofs. A business missing from one result can have more than one problem. The table is useful because it tells you what to inspect next. Wrong identity data points upstream toward entity reconciliation. Query-specific absence points toward intent, eligibility or semantic matching. Position changes across origins point toward geography and competitive reranking. Label-only disappearance may be a rendering issue rather than a loss of search eligibility.

This is also why manufacturing clicks, direction requests or listing opens is not a defensible strategy. The vocabulary does not reveal the causal effect or weight of those events, and artificial activity contaminates your own measurements. Improve the listing and destination pages so qualified users can make decisions more easily; treat genuine interactions as outcomes to monitor, not buttons that mechanically raise rank.

The geographic market changes with the query

A fixed-radius model is appealing because it makes reporting easy: draw a circle around the searcher, collect the businesses inside it and rank them. Maps behaves more dynamically. Candidate geography can expand or contract according to what was searched and the environment in which that search occurs.

At the same origin in Paris, a dense category query such as pharmacie produced a much smaller geographic footprint than a brand query such as Carrefour. Those measurements do not define a universal radius for either query. They demonstrate the more useful principle: the search area itself is query-dependent.

This matters when you use a local rank grid. A grid is a sample of changing results, not a map of territory Google has permanently granted to the business. A position for the exact business name, a broad category and a specific service should not be averaged as if all three searches drew from the same candidate market.

Separate your query families before interpreting coverage:

• Branded queries test whether Google can identify and retrieve the intended entity.
• Category queries test broader eligibility and relevance within a competitive local set.
• Service or product queries test whether Google connects the entity with a more specific need.
• Qualified queries, such as those containing a neighborhood or attribute, may create a different intent and geographic context again.

For before-and-after comparisons, keep the wording and measurement origins unchanged. Compare branded performance with branded performance and service performance with the same service phrase. Report the share of sampled origins where the business appears, along with the positions at those origins, instead of reducing the entire market to one rank at one point.

Content cannot move a physical business closer to a searcher. It can make the business’s relationship to a legitimate service, product or location clearer, which may help query interpretation and candidate matching. Write location and service pages to resolve real ambiguity: what the location offers, who it serves, where it operates and how the offering differs from similarly named services. Do not create unsupported location claims in an attempt to simulate proximity.

Run a local ranking audit in architecture order

The most efficient audit moves from upstream identity problems to downstream ranking and rendering problems. If you start by publishing more content while Google is conflating two entities, you add material without resolving the fault that controls everything below it.

1. Define the exact failure. Record whether you are investigating an incorrect attribute, a duplicate, absence for a query, a low position among retrieved candidates or a missing map label. Those are different problems.
2. Freeze a measurement baseline. Save the exact query text, origin coordinates, device or measurement method, result surface and date. Use the same configuration after making changes.
3. Verify the canonical identity. Reconcile your profile, map pin, website, contact information, location pages, structured data and important external records. Give special attention to previous names, moved addresses, tracking phone numbers and duplicate profiles.
4. Test retrieval by intent. At the same origin, check the exact brand, primary category and a small set of accurately described services. Branded retrieval with weak non-branded visibility points toward a different layer than total failure to find the entity.
5. Inspect on-site semantic evidence. Make sure each relevant page identifies the offering, location and business relationship in visible copy as well as structured data. A schema property should agree with the page; it should not introduce claims the visitor cannot verify.
6. Map geographic variation. Measure the same query across a stable set of origins. Keep branded, category, service and qualified queries in separate reports because each may generate a different candidate footprint.
7. Improve real customer evidence. Ask eligible customers for honest reviews, keep decision-critical profile information accurate and make calls, directions and website actions easy for genuine users. Do not assign a ranking weight to any one interaction merely because its name exists in an internal vocabulary.
8. Change one class of evidence at a time. Identity corrections, page revisions, structured-data changes and reputation work should be annotated separately. Retest the original query-origin matrix before deciding what to change next.

Use the pattern of results to form your next hypothesis. If an attribute repeatedly reverts, investigate conflicting entity evidence. If the correct business appears for its exact name but not for a legitimate service at the same origin, inspect semantic relevance and candidate eligibility. If it appears close to the location but loses visibility where competitor density changes, investigate geography and relative prominence. If search retrieves it but the viewport does not display its label, separate rendering from rank before rewriting the listing.

Do not call any one of those patterns conclusive. Personalization, changing competitors and different retrieval systems can produce similar symptoms. The purpose of controlled measurement is not to reverse-engineer a secret coefficient. It is to eliminate explanations until the next useful action becomes clear.

Start with the identity ledger and a stable query-origin matrix. Correct one evidence class, repeat the same measurements and then decide whether the next move belongs in entity cleanup, content, reputation or conversion. That sequence gives you a defensible local strategy even when the live ranking weights remain unknown.

References

• Search Engine Land — Inside Google Maps: 72 ranking signals and the architecture behind local search