How to Test AI Visibility Across Engines for Different Cities
To test AI visibility across engines for different cities, build a prompt matrix of your main services crossed with each city or neighbourhood. Put the place in the wording buyers use and run each prompt several times per engine. Then report results city by city rather than as one average. Name the place in the prompt instead of relying on a VPN, and add location settings where a tool supports them. About 30 answers per city per engine is enough to tell visible from invisible; chain-level figures come from pooling cities.
Why do local businesses need per-city AI visibility tracking?
AI answers to local questions are built from local sources: business listings, reviews, local directories, neighbourhood guides and news. Those sources differ from one city to the next, and so do competitors. A chain can be the default recommendation in one city and absent in the next, because:
- one location's Business Profile is complete and well reviewed, another's is not;
- a local directory or "best of" article includes one branch but not others;
- competitors are stronger in some cities;
- a location page exists for some cities and not for others.
A single national prompt such as "best urgent care near me" cannot show any of this. Only city-level prompts can.
Why do AI visibility tools miss city-level differences?
Several design choices hide local gaps:
- Roll-up scores. Tools often average everything into one visibility figure, so a strong city masks a weak one.
- One location setting. Many projects run from a single country or city, so every answer reflects that place.
- Prompts without a place. Generic prompts measure an average answer that no real local buyer sees.
- Cost. Every city multiplies the number of answers, so tools and teams cut cities first.
When evaluating a tool for multi-location work, check whether it can run the same prompt for many places, and report each place separately. More on agency-scale setups is in how agencies track AI visibility across multiple clients and locations.
How should you split prompts by city and service?
Use a matrix: services down one side, places across the other.
- Choose three to six core services that drive most bookings, such as "boiler repair", "boiler installation" and "gas safety certificate".
- Choose the places: every location you operate from, or a fixed sample if there are many.
- Write one or two prompts per service, in the words local buyers use, with a slot for the place: "Who can repair a boiler today in [place]?"
- Add a few city-specific prompts that do not fit the template, such as questions about a local landmark, district or regulation.
- Freeze the matrix and run it the same way every period.
An illustrative matrix for a plumbing company:
| Service | Leeds | Bradford | Harrogate |
|---|---|---|---|
| Emergency boiler repair | "Emergency boiler repair in Leeds tonight" | same, Bradford | same, Harrogate |
| New boiler installation | "Best company to install a combi boiler in Leeds" | same | same |
| Gas safety certificate | "Landlord gas safety certificate in Leeds, cost" | same | same |
Template prompts keep cities comparable. The few city-specific prompts keep the set realistic.
Should localized prompts include a city name, postal code or landmark?
Use the place format local buyers actually use, and test more than one where it matters:
- City or town name: the most common in conversational questions and the best default.
- Neighbourhood or district: important in large cities, where "Shoreditch" and "Croydon" are different markets.
- Landmark: useful for hospitality, tourism and healthcare ("hotel near the convention centre", "urgent care near the stadium").
- Postal code: useful when coverage boundaries matter, such as delivery or home services.
- "Near me" without a place: the most natural phrasing, but results then depend entirely on the location the engine infers.
A practical rule: use city and neighbourhood names for the main matrix, and add a small set of "near me" checks run from the right place to see how inferred location changes things.
Is ZIP-code testing better than city-level testing?
It depends on how your service area works:
| Approach | Best for | Drawbacks |
|---|---|---|
| City-level | Most local businesses; comparing branches | Hides differences within large cities |
| Neighbourhood-level | Dense cities; chains with several branches in one city | More prompts to write and run |
| ZIP or postcode-level | Service-area businesses with firm boundaries; delivery | Volume multiplies quickly; buyers rarely phrase questions this way |
For most businesses, test at city level everywhere and at neighbourhood or postcode level only where boundaries decide whether you can serve the customer. Sample a handful of postcodes per area rather than all of them.
How can you test AI results by location without a VPN?
- Name the place in the prompt. This is the most reliable method for AI assistants and works without any tools.
- Use tool location settings, where your AI visibility tool lets you set country, region or city per project.
- Pass an approximate location through an API, where the engine's developer tools support it for web search, if you run your own checks.
- Ask people on the ground. Staff or trusted customers in each city can run a short list of prompts from their own devices in clean sessions.
- Browser location overrides, such as the geolocation setting in browser developer tools, only affect sites that use the browser's location feature, not those that infer location from your network. Treat them as a partial method.
Whichever you use, record it, so results from different methods are not compared as if they were the same.
Which engines should local city tests include?
Pick engines by where their local data comes from and what your customers use:
- Google's AI Overviews and AI Mode, and Gemini, draw on Google's index and Maps data, so Business Profiles and Google reviews weigh heavily.
- ChatGPT searches the web and, according to OpenAI, may share a user's location with third-party providers of local information such as business listings.
- Microsoft Copilot relies on Bing, including Bing Places listings.
- Perplexity uses its own search and cites directories, review sites and local articles.
Because each engine uses different local data, a city can look strong in one and weak in another for purely data reasons. That is useful: it tells you which listing or source to fix for which engine. For most local businesses, Google's AI results and ChatGPT come first, with the others checked monthly.
How many AI searches across cities and questions do you need?
Think in answers per city per engine. At a visibility rate around 50%, the margin of error at 95% confidence is roughly:
| Answers per city per engine | Margin |
|---|---|
| 30 (e.g. 10 prompts × 3 runs) | ±18 points |
| 45 | ±15 points |
| 60 | ±13 points |
| 90 | ±10 points |
About 30 answers per city per engine is enough to tell "usually recommended" from "rarely recommended", which is often the decision that matters. To compare cities more precisely, or to track change, increase prompts or runs. For chain-level figures, pool cities: 20 cities × 30 answers gives 600 answers, a margin of about ±4 points. The general statistics are covered in how many times to test a prompt.
How should an urgent-care chain measure visibility for separate neighbourhood locations?
An illustrative design for a chain with 12 clinics across three cities:
- Prompts per clinic neighbourhood: "urgent care open now near [neighbourhood]", "where can I get stitches in [neighbourhood] without an appointment", "urgent care in [neighbourhood] that takes [insurer]", "walk-in X-ray near [landmark]", "paediatric urgent care in [neighbourhood] on weekends".
- Engines: ChatGPT, Google's AI results and Gemini, which matter most for local health questions, plus Perplexity monthly.
- Runs: three per prompt per engine, giving 15 answers per clinic per engine per period, pooled over two periods for clinic-level decisions.
- What to record: whether the correct clinic is named, whether the answer points to the right location page and phone number, and whether hours, services and insurance are stated correctly.
- Priority checks: wrong hours, wrong insurance and answers sending patients to a closed or distant clinic, which matter more than position.
Each clinic's Business Profile, location page and reviews then become the fix list for its own neighbourhood. For writing those pages, see how to create city-specific service pages for local AI search.
How do you report city-level results?
A simple grid works best: places down the side, engines across the top, each cell showing "recommended in X of N". Colour the cells by band, such as mostly, sometimes or rarely, rather than by exact percentage, because small samples do not support fine distinctions. Add a column for the main competitor in each place and one for accuracy problems. Leadership can see at a glance where the chain is strong, where it is invisible and where it is being described wrongly.
What does a city-level result look like?
An illustrative month for a four-city home services company, 30 answers per city per engine:
| City | ChatGPT | Google AI results | Gemini | Main competitor named instead |
|---|---|---|---|---|
| Leeds | 19 of 30 | 22 of 30 | 17 of 30 | Rival A |
| Bradford | 4 of 30 | 9 of 30 | 6 of 30 | Rival B |
| Harrogate | 14 of 30 | 11 of 30 | 13 of 30 | Rival A |
| Wakefield | 0 of 30 | 2 of 30 | 1 of 30 | Rival C |
A chain-wide average would suggest the company is named in about a third of answers. The grid shows something more useful: it is strong in Leeds, middling in Harrogate, weak in Bradford and effectively invisible in Wakefield, with a different rival winning in each weak city.
What do you do when one city lags?
Work through the local causes for that city specifically:
- Business Profile: is it verified, in the right category, with services, hours and photos? Is the address the one customers use?
- Reviews: how many, how recent, and do they mention the services people ask about? Compare with the rival named instead.
- Location page: does the site have a page for that city, with services, prices or ranges, areas covered and contact details in text?
- Local sources: open the sources cited in the weak city's answers. Local directories, city guides and "best of" articles usually differ from those in your strong cities.
- Accuracy: check whether answers give the wrong address or phone number for that branch, which can make engines treat it as unreliable.
In the example above, Wakefield might turn out to have no location page, an unclaimed directory listing and a Business Profile with the wrong category. Those are fixable in days; the re-check a month later shows whether they were the cause.
How do you handle cities where you have no physical location?
Service-area businesses and chains planning to expand often want visibility in cities without a branch. Test them the same way, but set expectations differently:
- Be honest in listings and pages. Do not create addresses you do not operate from; describe the areas you serve and how customers reach you.
- Create genuine service-area pages that explain coverage, response times and prices for that area.
- Take a baseline before expanding, so the effect of opening a branch can be measured later.
- Expect lower rates than in cities with a branch, because local answers lean on businesses with a local presence and reviews.
What do people ask about city-level AI testing?
Do I need a separate prompt set for every city?
Use the same template prompts for every city, so results are comparable, plus a few city-specific prompts where local wording or landmarks matter.
Why does ChatGPT recommend my business in one city but not another?
Usually because the local sources differ: listings, reviews, local articles and competitors. Compare the cited sources for the two cities.
Can I trust "near me" results from my office?
Only for the area around your office. For other locations, name the place or test from there.
How often should city-level tests run?
Monthly for most chains, with extra checks after opening, moving or closing a location.
Published by The Kovmere Team · updated Sep 28, 2026 · More resources