You cannot benchmark local AI visibility by asking an engine a question from your desk. To know whether AI recommends you city by city, you need a method: an explicit-city prompt matrix, sampled repeatedly, reported as rates: plus the API location parameter where you can use it. This how-to lays out the method and the traps.
The reason hand-testing fails is built into how location works in AI engines: you can't fake a city-level IP in a consumer app, engines round your location, and the same prompt returns different answers run to run.
Step 1: Build the prompt matrix
Define three axes and take their product:
- Cities: the locations you serve or want to win (start with 5-20).
- Engines: ChatGPT, Perplexity, Gemini, Claude, Google AI Overviews/AI Mode.
- Prompts: the real questions buyers ask, in two flavors (see Step 2).
Each cell is one city × engine × prompt. That grid is your benchmark surface. Keep the prompts fixed and natural ("best fertility clinic in [city]," "affordable plumber in [city] open now") so results are comparable across the matrix.
Step 2: Measure implicit and explicit localization, and label which
There are two different behaviors, and they don't return the same answer:
- Explicit: you name the city in the prompt ("best dentist in Denver"). Reproducible anywhere; this is your backbone.
- Implicit: the engine infers the city from location and localizes silently ("best dentist near me"). This is what most real users trigger.
Measure both, and label every result with which method produced it. Reporting an implicit result as if it were explicit (or vice versa) is the most common way these benchmarks mislead.
Step 3: Set the city deterministically with the API where you can
For explicit, deterministic city-setting, use the web-search APIs that accept a location parameter. As of mid-2026:
| Engine | User-location parameter? | How to benchmark it |
|---|---|---|
| OpenAI web-search API | Yes. Approximate location | Set city via the API, sample repeatedly |
| Perplexity API | Yes. Approximate location | Set city via the API, sample repeatedly |
| Gemini | No exposed parameter | Explicit-city prompts only |
| Claude (web search) | No exposed parameter | Explicit-city prompts only |
| Google AI Overviews / AI Mode | No exposed parameter | Explicit-city prompts only |
Where the API carries no location, the API has no user city at all unless you pass it: so explicit-city prompting is the honest substitute. Don't pretend an API result is "localized" when nothing set the location.
Step 4: Sample repeatedly and report rates, not snapshots
Because answers are non-deterministic, a single pull is noise. Sample each cell several times and report presence (did you appear?) and share of voice (what fraction of the named businesses were you?) as percentages across samples. "Cited in 4 of 10 samples in Phoenix on Perplexity" is a real number; "I asked once and didn't see us" is not.
A local AI benchmark is a rate, not a screenshot. One prompt, one city, one pull tells you nothing durable. The signal lives in repeated sampling across a city-and-engine matrix.
Step 5: Read the gaps
With the matrix sampled, two patterns matter most:
- City gaps: cities where you're present elsewhere but absent here. Usually a local-footprint problem (listings, reviews, local pages) in that market.
- Citation gaps: the engine recommends your category but never names you, or cites a directory that omits you. That points at the third-party sources you're missing from.
Trend these over time, not once. Local standing shifts as listings, reviews, and the cited sources change.
The pitfalls, in one place
- You can't fake a city-level IP in a consumer app. Use the API parameter or explicit prompts.
- Engines round location to a coarse city/region, so precision is limited by design.
- Non-determinism means single pulls mislead. Always sample and report rates.
- Implicit ≠ explicit: measure both and label which produced each result.
This is measurement infrastructure, not a one-afternoon task. A city-and-engine matrix, sampled on a schedule, trended over time. It fits inside a broader AI-visibility reporting stack, and running it continuously across every engine and city is exactly what Buffy Intel is built to do.