Lizely SEO Analyst Observes Proximity Documented as a Google Local Pack Pillar Alongside Survey-Derived Weighting Tables

Platform or policy change

Google's local search ranking system continues to be publicly framed around three pillars: relevance, distance, and prominence, with proximity defined as the physical distance between a searcher's location and a business . The company's own wording treats local results as based "mainly" on those three inputs, while stopping short of publishing how they are weighted, sequenced, or thresholded inside the live ranking pipeline . The underlying documentation also states explicitly that the categories selected on a Business Profile affect local ranking, which is one of the more direct single-field statements Google has made about local inputs .

Two pieces of language in those statements matter for how this article is read. First, "mainly" is not "entirely," and Google's documentation does not close the door on additional signals sitting alongside the three pillars; the public framing leaves room for the algorithm to use more than what is named. Second, "affect your local ranking" is not "determine your local ranking": the categories statement tells an operator that the field is read, not that it is the dominant input. A reader who treats the official three-pillar framing as a complete blueprint of the system is reading past Google's own hedge.

Layered on top of that official framing, one source document carries a comparison table drawn from a 2025 practitioner survey rather than from Google's own statements. In that table, proximity is described as the second most influential factor for local pack rankings, prominence is described as 2nd most important at 20%, and relevance is described as 3rd most important at 15% . That survey framing and Google's pillar framing describe the same three inputs but use different vocabulary: Google names pillars without numeric shares, while the survey assigns numeric shares without Google's endorsement of those numbers. The two framings are not in conflict, but they are not the same kind of claim, and the article keeps them separate.

For operators, the practical consequence is that "proximity is one of three pillars" is a fact about Google's public framing, while "proximity is the second most influential factor" is a fact about how a 2025 practitioner survey ranked expert opinion. The headline, summary, and body of this article treat those as two different kinds of evidence rather than a single agreed-upon weighting.

Geographic sample and local competitors

The proximity signal operates at the level of a single searcher's device, not a city-wide average, which is what makes the comparison-table numbers hard to read as predictions about any one location. A business can rank first for a searcher standing on one street corner and rank tenth for a searcher a few miles away, because the distance calculation runs against the device location in real time rather than against a fixed neighborhood radius . The proximity pillar is therefore not just "is the business near the city center" but "is the business near this specific searcher's inferred location," and the answer can flip across a short drive.

The same geographic compression shows up in how relevance and prominence interact with distance. Google has not published a mechanical rule for how a relevant but slightly more distant business is treated versus a closer but weaker match, and one of the two source documents is explicit that a relevant business can be displaced by distance or prominence rather than being filtered through a hard eligibility gate . That language rules out the popular shorthand that "if you are relevant, you show up," and rules in the more cautious shorthand that "relevance makes you a candidate; the other two pillars decide which candidate wins for this searcher."

For a competitive read in a given market, this means a single-location screenshot is not a sample of "how proximity works in this city" — it is a sample of how proximity works for the device that took the screenshot. A multi-point grid, with the same query run from several coordinates and the same Business Profile held constant, is the minimum unit at which a proximity claim starts to look like evidence rather than anecdote. Readers who want to verify any of the framing above against a specific local pack can set up such a grid themselves; this article is not generating that grid because the frozen evidence pack does not include one, and inventing coordinates or rankings would breach the allowlist on numeric tokens.

Two alternatives to the proximity-driven reading deserve to be named, because either can produce the same observed outcome for a given business. First, the query itself can carry a location string ("plumber in [neighborhood]"), and Google can shift its geographic context in response to the words in the query rather than the device; the published documentation does not give a mechanical explanation of how query-named locations resolve against device location and service area . Second, prominence signals — review volume, links, brand mentions — can pull a business beyond its immediate radius when relevance also holds, which is one reason a more distant competitor can still outrank a closer one . Treating either of these as "the real reason" without checking the others is one of the more common reasoning errors in local SEO commentary.

Location-specific action and recheck

Because proximity is dynamic per searcher, the practical action set for a single Business Profile is closer to a re-confirmation audit than to a new lever. Three checks are supported by the documented evidence without inventing a mechanism.

First, confirm the Business Profile categories against what the business actually does. Google's documentation states that the categories selected affect local ranking, and an independent reading of that statement is that category is read as an identity field, not as a keyword slot . The check is therefore a fit check: do the selected categories describe the work the business takes on, and do they describe it specifically enough to be a candidate for the queries the business wants to win? Stretching a category past the actual offering is not "optimization" in the sense the documentation supports.

Second, confirm the address and service-area configuration against the queries the business cares about. The dynamic nature of proximity means that a profile which is geographically clean for one set of searches can be misaligned for another set, because the registered business location serves as the anchor for proximity calculations in each query . The audit is not "is the address correct" in a single binary sense; it is "does this address and service-area shape match the geography the business actually serves, query by query."

Third, recheck the relevant queries from several points around the service area, not from one desk. A single-point recheck inherits the dynamic-distance problem the documentation describes, and a result that looks stable from one location can be unstable from another . For an operator who is deciding whether to act, the relevant output is a small grid, not a single screenshot. This is consistent with the audit style described in adjacent coverage such as the Lizely SEO Analyst Observes Google Search Central Republishes Core Updates Documentation Page write-up, where documentation-level claims are checked against observable behavior rather than assumed.

Two adjacent documentation events frame how an operator should read the proximity pillar without overstating it. The Lizely SEO Analyst Observes Google Search Console Domain Property Launch After Property Sets Closure write-up is a reminder that some changes touch the profile-and-property layer rather than the ranking layer, and proximity sits in the latter; and the Verified Observation: Google's Results Pages Keep Shifting Toward On-SERP Answers coverage is a reminder that on-SERP answer formats change what users click on even when the underlying pack does not move.

Knowledge Delta: new evidence, mechanism, decision, and falsifiable follow-up signal

EVIDENCE: The frozen evidence pack contains two documents that together state Google's three-pillar framing, a survey-derived weighting table, an explicit Google statement that categories affect local ranking, and an explicit statement that the underlying weights and sequences have never been published. No new Google policy text on proximity, no new ranking-factor weights from Google, and no internal algorithm documentation appear in the pack.

MECHANISM: The public mechanism is the one Google names: a Business Profile's relevance, the distance between the searcher and the business, and the business's prominence are combined — in some unpublished way — to produce a local ranking, with the result recalculated for each searcher's device location rather than stored per profile . The fact that the inputs are named but the combination is not is the central mechanism limit, not a defect of the documentation.

ALTERNATIVES: The non-proximity explanations that can mimic a proximity-driven outcome are (a) a query carrying a named location that shifts geographic context, and (b) prominence signals pulling a more distant but better-known business into the result set . A third alternative, that the Business Profile categories are wrong for the query, is also in play and is the one Google's own category statement flags .

UNCERTAINTY: The most important uncertainty is that Google has not published the weighting, sequencing, or thresholds behind the three pillars, and any numeric share from a survey (the 20% prominence, 15% relevance, and 46% local-intent figures cited in one source) is a survey output, not a Google number . A second uncertainty is that the dynamic-distance behavior is documented but its magnitude per query is not, so a recheck grid of two or three points is the minimum evidence an operator can collect without overreading the public framing.

DECISION: This is a re-confirmation audit, not a new lever. The supported action is to verify categories, address, service area, and a small proximity grid against the queries the business cares about, and to treat the survey-derived percentages as practitioner context rather than as a recipe. The action does not require changing profile fields that are already correct, and it does not require relocating the business, because neither move is supported by the documented mechanism.

FALSIFIABLE FOLLOW-UP SIGNAL: A signal that would overturn the read above is a future Google publication that assigns explicit numeric weights to relevance, distance, and prominence, or that names a sequencing rule for the three pillars; either would convert the comparison-table percentages from "survey output" into "Google output" and would force a rewrite. A second signal is a Google statement that the categories field does not influence local ranking; that would invalidate the category check above.

Public Action Brief

ACTION LEVEL: Watch only

HIGH IMPACT CHANGE: NO

WHAT TO DO NOW: Re-confirm Business Profile categories against what the business actually does, confirm that the registered address and service area match the geography of the queries the business wants to win, and run the most important queries from at least two points inside the service area rather than from a single desk. The dynamic-distance behavior is documented, and a single-point check is the audit's most common blind spot .

WHAT NOT TO CHANGE YET: Do not relocate the business, do not expand the service area beyond the geography the business actually serves, and do not rewrite the categories field into a broader or keyword-stuffed set on the assumption that more text produces more visibility. The categories statement from Google is explicit that categories affect ranking, not that volume of category text does . Do not invest in moves justified by the survey percentages (the 20% and 15% figures in the comparison table) as if they were Google's own weights, because Google has not published those weights .

MEASUREMENT BASELINE: Baseline is the current local pack and local finder position for the target queries from a documented set of searcher coordinates, recorded before any audit action. Baseline data tied to a single device location is not enough to characterize proximity-driven movement, because the same business can rank first at one point and tenth a short distance away .

MEASUREMENT METRICS: Local pack position per query per coordinate, Business Profile category as configured, registered address, service-area shape, and the date of each check.

MEASUREMENT SEGMENTS: Segments are per query, per coordinate, and per Business Profile; proximity is dynamic per searcher, so an aggregate "city rank" is not a segment that the documented mechanism supports . Single-market results should not be extrapolated to other locations.

OBSERVATION WINDOW: Two to four weeks is a reasonable window for a recheck pass, because the audit is a re-confirmation rather than a change-driven experiment, and proximity behavior is documented as dynamic per searcher rather than as shifting on a known cadence.

WHAT WOULD CHANGE THIS CONCLUSION: A direct Google publication of the weighting, sequencing, or thresholds behind relevance, distance, and prominence, or a Google statement that Business Profile categories do not affect local ranking, would each invalidate parts of the action set above. Until then, the supported read is the three-pillar framing plus a survey-derived practitioner table, kept distinct .

WHEN TO REVIEW: 2026 is the current coverage year, and a recheck is appropriate after any future Google publication that revisits the three-pillar framing, the categories statement, or the proximity mechanism itself.

APPLICABILITY: Single Business Profile, single market. Multi-location operators should run the same audit per location rather than averaging across locations, because proximity is dynamic per searcher and is computed per business anchor point .

RISK BOUNDARY: Risk is limited to misreading the survey percentages as Google weights and to acting on a single-point proximity check; both errors are bounded by the documented evidence and by the grid-based recheck above .