Why does my business show on Maps near the office but disappear in the suburbs we serve?

The short answer

A service territory is not a promise of search visibility, and most reports of "we disappear in the next suburb" turn out to be partly a measurement artefact.

That is not a dismissal. Local results genuinely do change with the searcher's location. The point is that the first useful step is not optimisation. It is establishing what was checked, on which surface, from where, and with what query, because a report that cannot answer those four questions cannot support any conclusion about cause.

What Google actually says

Google names three considerations for local results, and rules out one popular theory in a single sentence.

"There's no way to request or pay for a better local ranking on Google."

Two things follow. Distance is explicitly a factor, so some falloff across a city is expected behaviour rather than a fault. And anyone selling a guaranteed map-pack radius is selling something Google says does not exist.

Check the gates before the grid

A profile is gated before it is scored, and a gate failure explains disappearing coverage better than any ranking factor. Measuring first is our advice only once these pass, because a suspended profile produces exactly the same map as a distant one.

• Verified, and not suspended or restricted. The obvious one, and the one nobody checks before buying a report.
• Open at the hour you are measuring. Hours are a profile field and they filter results. If you measure at 7pm and you close at 6pm, you are measuring a closed business.
• The address decision made deliberately. If you do not serve customers at your premises, Google requires the address to be hidden and service areas listed instead. Doing that is correct, and it is a decision with consequences, so document that you made it on purpose.
• No duplicate profiles. Two profiles competing for one business is a gate problem that looks like a ranking problem.
• The real-world name only. Adding a service or a suburb to the business name is against Google's guidelines, and it is the single most common thing an agency will do for you that can cost you the profile.

Which result did you measure?

Three different things get called "our Maps ranking", and they are not one scale. Comparing a position from one against a position from another produces a number that means nothing.

• The local pack in web Search. Three results inside an ordinary results page.
• The Maps app or Maps web list. A longer list with its own ordering.
• A Places API response. What most grid tools actually query, including ours.

That last one carries a documented catch. The Places Text Search bias parameter is a bias, not a fence: results can come from outside the biased area, and an explicit location written into the query text can override it. So an API result is not interchangeable with what a person physically standing in that suburb would see.

A location parameter is a request, not proof of a device position. If your report cannot say whether a location was physically observed or simulated, that belongs in the report.

Our own grid, recalculated

We published a 49-point grid in a case study earlier this year. We went back and recalculated all 49 cells, and found the headline number was answering a narrower question than it appeared to.

The scan covered a dental clinic in central Melbourne, query "dentist", a seven by seven grid at one kilometre spacing.

What the average was hiding

The two means answer different questions, and neither should replace a coverage map.

Coding a missing result as 21 assumes the business was just outside the recorded window. It might have been at 22 or at 200. The code is a placeholder for "we did not see it", and averaging placeholders produces a number whose precision is imaginary.

Excluding the absences instead produces a tidier 11.23, arrived at by deleting the six worst outcomes. That is the more flattering number and the more misleading one, because a business invisible at six points has a real problem that the average now conceals.

There is a second thing an average hides, and it matters more commercially. A mean of 12 could describe a business that is mediocre everywhere, or one that is excellent in three suburbs and absent in four. Those need opposite responses and the single figure cannot tell them apart.

Report the distribution and the censoring convention, or report nothing. A single average across a city is a number that has deleted its own evidence.

One more discipline worth borrowing: a failed API request is neither a rank of zero nor an absent business. Keep failures in a separate column and publish the request-completion rate next to the coverage rate.

What changes when the grid changes

We hold four further grids from an unpublished follow-up. Comparing them taught us something about grids rather than about the business.

Widening the spacing of a grid from two kilometres to five changes the area sampled. Recentring it on a city rather than on the business changes which competitors are nearby. In both cases the coverage percentage moves, and in neither case did the business do anything.

The practical consequence is blunt. A coverage percentage without its spacing, centre point, query, surface and capture time is not comparable to any other coverage percentage, including your own from last month. If an agency shows you a grid improving over time, ask whether the grid is the same grid.

It is also worth saying that an all-green grid is not automatically evidence of manipulation. It can reflect genuine local strength in a small area. It is a reason to check the scale and the sampling, not a proof of anything.

A nine-point worksheet you can run yourself

This is deliberately small enough to do by hand, which is the point. A method you can repeat beats a dashboard you cannot audit.

1. Write down your actual service territory, confirmed by whoever runs the business, before looking at any data.
2. Choose nine fixed points: the home area, the target suburbs, and one point where you suspect visibility stops. Freeze them before you see any results.
3. Pick two genuine service queries. Use the words a customer would type, not your category name.
4. Record for every capture: the query, the surface, whether location was real or simulated, language, device class, whether you were open at the time, and the result limit.
5. Repeat across three observation windows rather than once.
6. Log failed captures separately from searches where you simply were not found.
7. Never compare a local-pack position to a Maps list position as if they were one scale.
8. Report the denominator for every figure, including the failures.
9. Compare coverage as a map, not as a mean.

Nine points, two queries, three windows is 54 observations, which is a weekend rather than a project. If you also want to compare an API method against manual checks, only compare pairs where both captures succeeded, and state how many pairs you excluded.

What a visibility boundary can and cannot tell you

Finding the line where you stop appearing is genuinely useful. Explaining it is where people overreach.

A boundary tells you where to investigate. It does not tell you why, because distance, relevance, prominence, competitor density and measurement method all produce the same shape on a map. The honest sentence is that the observations are consistent with location-sensitive results, not that proximity is the only thing that could explain them.

The useful reframing is that the radius is the market. Scope the work around what is winnable inside the area you actually rank in, plus what a second genuine location or a named practitioner profile would open up. Anything outside that is not a target, and no setting extends it.

What it does support is a better question. If you disappear where a strong competitor is dense, that is a prominence and relevance problem in that area. If you disappear uniformly past a radius regardless of competitors, distance is doing more work. Those lead to different spending.

What it never supports is creating premises you do not occupy. Google's guidelines on representing a business rule that out, and it is the fastest route to losing the profile entirely.

The AI layer sitting on top

There is now a second local surface, and it does not have to agree with the first.

Google launched Ask Maps, a Gemini-powered conversational feature inside Google Maps, in March 2026. It answers questions in natural language and returns places, review summaries and actions rather than a ranked list. Local answers also appear inside AI Mode.

One correction to the usual pitch here. AI Overviews, the thing most GEO selling is about, fire far less often on local intent than on informational queries, and on a local search the map pack is still what answers. If someone is selling you AI Overview work for a local business, ask them to show you an AI Overview on your actual money queries first.

Practitioners report that these surfaces name different businesses than the three-pack for the same need, apparently weighting what reviews actually say over proximity and review count. We are repeating that as a reported pattern, not a measurement. The sources making the claim are agency blogs, we have found no primary Google documentation describing the ranking, and we have not run our own panel on it.

What follows regardless is a measurement instruction rather than a tactic. If you only grid the pack, you are measuring one of at least three local surfaces, and a report that says "our map rankings are stable" can be true while a conversational answer names someone else every time. Log the surface on every capture, which the worksheet above already asks you to do, and treat AI answers as a separate leaderboard with its own runs.

Limits

• The recalculation verifies the numbers embedded in our own published page. It is not a fresh scan and it does not verify the original collection, because the raw request and response logs are not in the files we hold.
• The four comparison grids come from an unpublished draft and use more than one query. Only like-for-like subsets are safe to compare spatially, and we have not published them as a finding.
• One clinic in one city is an example, not evidence about trades, and the grid tool we used queries an API rather than observing physical devices.
• We have not run a controlled test showing that any intervention widened a coverage area. This piece is about measurement validity, which has to come first.
• Check the current Places terms before you collect, retain, display or publish API-derived data. Do not inherit our earlier conclusions on that without reviewing them yourself.
• The gate list is drawn from Google’s own guidelines. The hours effect and the behaviour of AI local surfaces are reported by practitioners, mostly from United States data, and we have measured neither.
• Platform documentation checked 23 September 2026.

If you want the underlying build, the geo-grid tracker case study documents what it cost and how it works, and the wider question of whether local visibility is your actual constraint is a separate test.