AISubHub/AI news
Research

In-depth analysis · About 5 min read

AI search visibility depends on where it is measured, an API audit finds

A Toronto study separates declared location, network location and ordinary answer variation. It does not test a shortcut to higher search rankings.

Source published
Published here
Source checked

A University of Toronto preprint first submitted on October 16 audits location effects in generative search. Its main experiments produce 31,200 answers using OpenAI and Gemini APIs, finding different location channels in the tested configurations rather than one universal visibility score.

Listen to the news

Read this article aloud or keep listening to the news.

AI search visibility depends on where it is measured, an API audit finds

Preparing the reader…

Device voice

Speech is handled by your browser or device. AISubHub does not send the text to an audio API. Voice availability and playback with a locked screen vary by device.

Resuming may repeat a short phrase.

At a glance

  • The audit uses 300 English questions, 19 declared cities and five unique network locations; repeated requests provide a baseline for answer variation.
  • The tested OpenAI setup follows declared location, while the tested Gemini setup follows network country. These API observations need not describe consumer applications.

The study separates two meanings of location

A declared location is a place an application passes to a search tool. Network location is where the service sees a request coming from. These are not interchangeable controls. The paper tests gpt-5.4-mini through the Responses API with web search and gemini-3.1-flash-lite with Google Search grounding, rather than directly auditing every user-facing ChatGPT or Gemini experience.

There are 300 author-written English questions across commercial topics, split evenly into nearby requests, place-dependent questions and questions not intended to be local. No question itself names a place. The declared-location experiment uses 15 US cities and London, Toronto, Sydney and Dublin, plus an unset-location condition. This design helps distinguish a location signal from a city explicitly typed into the question.

Repeated answers are the noise control

The declared-location experiment produces 24,000 answers in two arms: ordinary questions and questions prefixed with a request to search. Each setting is repeated twice. The network experiment adds 7,200 answers from five unique locations in four countries, with the authors’ Canadian connection revisited after three days. That makes six network sessions, not six unique places. A smaller full-size-model robustness check is separate.

The authors compare sets of cited domains with Jaccard overlap. Their localization index subtracts overlap across locations from overlap between identical repeated requests. Zero means no location effect beyond observed variation. It is an index difference, not the percentage of websites displaced or the probability that a particular brand will be recommended. This matters because even unchanged requests can yield different answers.

Different channels in the tested services

For the OpenAI setup, declared cities change citations for nearby and place-dependent questions. Across network countries without a declared place, the reported indices are close to zero. The paper also separates location inserted into generated search queries from localization by the search backend: citations can still differ when neither query names a location.

For the Gemini setup, declared coordinates had no effect in the pilot, while network country changed citations. The index across countries reaches 0.43 for nearby questions and 0.23 even for non-local questions. New York versus Los Angeles stays at approximately zero. These are findings about the tested APIs and small models, not proof that Gemini never localizes to cities on residential connections or that OpenAI will always ignore every network signal.

Coverage is not the same as a successful optimization

The businesses recommended can change along with cited sources. In the study’s nearby-question pool across 15 US cities, monitoring one randomly selected city captures 9% of the businesses seen across all cities, compared with 36% for five cities. This is coverage of that experimental pool, not a universal sampling formula for a new website.

The extraction of recommended names also has uncertainty: a manual check found 29 of 36 extractions fully correct. Directories, review sites and public bodies were excluded from that recommendation measure. A report about named businesses therefore should not be treated as the same metric as directory citations. The paper audits variation; it does not randomize publishers into content treatments and prove that adding location keywords, backlinks or a markup type causes higher visibility.

How to make a monitoring claim easier to trust

AISubHub’s proposed approach is to preserve the question, language, model version, search mode and both location settings with every measurement, then repeat the same setting before interpreting movement. For a hypothetical service operating in several markets, compare like-for-like market samples over time instead of treating a single city’s result as a worldwide score. This is an audit design suggestion, not a new experiment we ran.

The authors limit their findings to English questions, API models and the measured service period. Network exits include data-center VPN addresses, and residential behavior could differ. Their larger-model check covers OpenAI only. A useful next test would hold these factors stable while checking another language or application. The practical lesson is to make measurement conditions explicit, without promising indexing, traffic or revenue from the observed differences.

Why it matters

AISubHub analysis: a visibility report needs query, model, search configuration, location and repeated-run context. A change in cited sources is not automatically a gain or loss caused by a publisher’s content changes.

Limits and availability

We read the full original paper and version history, without reproducing its API or network experiments. It covers English, a limited set of locations and October 2026 service behavior. It does not establish Google indexing rules, traffic gains or an effective content intervention.

Sources and evidence

Chen and Koudas · Location, Location, Generation, arXiv v1

Source published: Oct 16, 2026 · Source checked: Oct 21, 2026

Further reading

Location audit v1 · complete HTML methods, results and limitations

Source checked: Oct 21, 2026

AI-assisted editorial articles checked against linked primary sources. Vendor claims are attributed; inclusion is not endorsement.