Why Do AI Search Results Change by Location?

Cheers ran the same 32 home-services buyer prompts in 100 metro service areas across four engines over the 28 days ending September 2, 2026. Same wording, same engines, 356,019 classified citations. Directories took 12.3% of the citations in Toronto and 34.6% in Oakland, and the count of distinct cited domains ran from 373 in Medicine Hat to 852 in Toronto. Nothing about the prompt changed. The market did.

That is the practical shape of the problem. Suppose a CMO in Dallas asks an AI search product for the best emergency plumber in Phoenix while a customer standing in Phoenix asks what looks like the same question: they get different shortlists, and neither screenshot has to be wrong. The product may be using different location signals, account context, conversation history, query wording, retrieved sources, or timing. For a multi-location service brand, there is no single national result to rank for. There is a set of local recommendation jobs that have to be tested under controlled conditions.

The practical goal is not to eliminate every variation. It is to learn whether the correct branch appears reliably for the buyer questions that create revenue, which public sources support the answer, and which team owns the next fix. The Cheers AI Visibility Grader can provide an initial business snapshot. A portfolio program needs a stricter market-by-market record.

The short answer: location can change the retrieval job

Location can change what an AI product interprets the user to mean. "Who repairs heat pumps near me?" in Phoenix is a different local task from the same words in Boston. The available providers, likely service needs, business profiles, pages, reviews, directories, and current availability can all differ.

Location is only one control. The system may also rewrite the query, follow conversational context, use account settings, retrieve a different source set, or produce a different answer on another run. Official platform documentation confirms several of those inputs. It does not support a universal formula that says one local signal always outweighs another.

This distinction matters when an executive sees a missing brand and asks marketing to "fix the ranking." First determine whether the test represented the intended customer and branch. Then inspect the evidence the product used. Otherwise the team may rebuild a Phoenix page to solve a Dallas-session artifact.

What the platforms actually document

The products do not expose identical location controls, and their documentation describes different surfaces. Treat each statement at the level the provider supports.

Google can estimate location from several sources

Google's location guidance for Search says it may estimate current location from a device, saved home or work addresses, previous activity, and an internet connection's IP address. A user can also choose a location permission or update a search region.

Google's 2026 AI Mode update says the product can maintain conversational context. It also describes Personal Intelligence, when a user chooses to connect Google apps, and agentic local-service tasks such as checking availability or helping schedule an appointment. Those features make account and conversation state relevant testing notes. They do not prove that personalization controls every local answer.

Google Search Central's guidance for AI features keeps the publishing advice grounded: normal Search foundations apply, important content should be available in text, structured data should match visible content, and Business Profile information can appear in AI responses. Google does not prescribe a separate GEO markup or a guaranteed route into an AI answer.

OpenAI localizes web search from an approximate location

OpenAI's web search API documentation states the mechanism directly:

To refine search results based on geography, you can specify an approximate user location using country, city, region, and/or timezone.

City and region are free text, country is a two-letter ISO code, and timezone is an IANA identifier. The same page notes that user location is not supported for deep research models using web search, which is a reminder that one provider can behave differently across its own products.

An approximate location is enough to change which businesses a retrieval step considers. It is not enough to tell an operator why one branch was chosen over another, and OpenAI does not publish a placement guarantee for any of its search surfaces.

Claude and Perplexity expose different location controls

Anthropic's Claude web search API documentation allows an application to supply an approximate city, region, country, and timezone as user location. This proves that applications built on Claude can localize web search when they pass that context. It does not prove that every Claude consumer answer always uses a device location.

Perplexity's user location filter documentation describes the same capability in one line: "Personalize search by country, region, city, latitude, and longitude." Its API reference defines the field as the "User's geographic location for search personalization". Location is a parameter, not a constant, so two users can type the same words and hand the system different context.

Across the four products, the honest conclusion is modest: location can affect the search or retrieval task, but the inputs and controls differ. Test the product you actually care about instead of carrying assumptions from one provider to another.

Why headquarters screenshots mislead multi-location teams

Headquarters isn't the neutral observer people assume. The office connection can signal a different city, while a signed-in account may carry saved places, prior searches, or memory from earlier work. A conversation can also inherit old constraints, and "near me" may point to the tester instead of the intended branch.

Now add portfolio complexity. A 40-location HVAC group may have a strong heat-pump page and recent installation reviews in Phoenix, a furnace-heavy review history in Minneapolis, and an acquired brand name still circulating in Denver directories. Even a perfectly controlled system should not be expected to return one identical answer across those markets.

A screenshot can start an investigation. It cannot establish portfolio visibility, market share, or causation. The broader multi-location AI visibility audit explains how to organize providers, prompts, competitors, sources, and owners. The location protocol below narrows the conditions so those rows are comparable.

Build a controlled market test

Start with a small set of high-intent questions tied to real services and cities. Hold the wording steady long enough to compare runs. For each observation, preserve:

• Provider and product: ChatGPT Search, Google AI Mode, Claude web search, Perplexity, or another named surface
• Explicit market: city, neighborhood, or service area written into the prompt instead of relying on "near me"
• Session state: signed in or signed out, new or continued conversation, memory or personalization state, and location permission
• Prompt version: the exact buyer question and any follow-up context
• Run details: date, time, device or test environment, and at least three repeated runs as a Cheers operating recommendation
• Answer evidence: named businesses, correct branch, cited URLs, source types, and whether the customer route reaches that location

Repeat the same test cell before comparing locations. Three runs will not eliminate variation, but they make a one-off answer easier to spot. Keep the raw observation behind every score. An aggregate that cannot be traced to the prompt, market, answer, and cited source is not an auditable operating record.

If automation supplies an approximate location through an API, document that method separately from a consumer-product test. The two may use different interfaces and context. Do not label an API result "what customers see" without confirming the customer surface.

Read variation without inventing a ranking factor

Variation is evidence about the test, not an automatic diagnosis.

If the right branch is absent across repeated runs and providers, inspect whether its public evidence supports the exact service and market. If the branch appears only when the city is explicit, the original prompt may have carried weak or wrong location context. If the answer changes with the cited source set, compare the location pages, profiles, reviews, and directories that actually appeared. If only one signed-in session behaves differently, check personalization and conversation state before changing the website.

Do not turn a pattern into a platform rule too quickly. A competitor appearing after a fresh review does not prove that review caused the change. A cited directory does not prove every listing on that directory receives a boost. A branch missing once does not prove a penalty.

The useful output is a bounded finding: "In three dated Google AI Mode tests for AC repair in Mesa, the expected branch was absent and two cited sources described only the parent brand." That statement gives the team a market, service, provider, source gap, and next check without claiming access to Google's ranking system.

Fix the business evidence after the test is controlled

Once the test is trustworthy, fix the business evidence instead of chasing the answer. Make the intended branch easy to identify by publishing accurate services, areas, hours, qualifications, contact routes, and firsthand proof on its location page. Keep Business Profile facts aligned with the customer experience, build a policy-compliant stream of recent reviews, and correct material third-party discrepancies. Then route the inquiry to a team that can fulfill the promise.

The location-page guide for AI search covers the owned-page evidence. How AI search engines use different sources helps classify the external evidence. Neither should be used as a checklist to manufacture signals. The goal is to make the real branch, service, market, and proof consistent wherever a customer or retrieval system checks.

A 14-day operator plan

During days one and two, choose two priority markets and two high-intent services per market. Freeze the prompt wording and document the test environment. Run the same cells across the products customers use before booking.

During days three through seven, classify each miss. Separate wrong location context, prompt sensitivity, unstable answers, source gaps, wrong branches, and broken customer routes. Assign one evidence repair to whoever controls it: marketing for a thin location page, operations for missing service proof, the local manager for profile accuracy, or the contact center for a failed handoff.

During days eight through fourteen, verify the repair publicly and rerun the unchanged test cells. Report the original and new observations side by side. Keep a business change, such as a corrected branch phone number, separate from an AI-output change. The first can be verified directly. The second remains an observed result, not proof that the edit caused it.

The operating advantage is not finding a trick that forces identical answers. It is knowing which local recommendation jobs matter, controlling enough context to compare them, and improving the public evidence behind every branch.

Sources

Every link below was opened and checked September 2, 2026.

• Understand and manage your location when you search on Google. Google Search Help, checked September 2026. Source of location estimation from device, saved places, previous activity, IP address, and the user controls.
• AI Mode advances from Google I/O 2026. The Keyword, Google, 2026. Source of conversational context, optional Personal Intelligence, and local-service agent capabilities.
• Optimizing your website for generative AI features. Google Search Central, last updated July 2026. Source of the Search foundations, visible content, structured data, and Business Profile guidance.
• Web search tool. OpenAI API documentation, checked September 2026. Source of the quoted approximate user location fields and of the deep-research exception.
• Web search tool. Anthropic Claude documentation, checked September 2026. Source of the approximate city, region, country, and timezone input for applications using Claude web search.
• User location filter and the chat completions API reference. Perplexity documentation, checked September 2026. Source of the two quoted descriptions of the user_location field.
• Cheers Research methodology and the Home Services AI Visibility Index 2026. Cheers Market Baseline, 28 days ending September 2, 2026: 32 home-services prompts in 100 metro service areas across four engines, 356,019 classified citations, aggregate only. Source of the Toronto, Oakland, and Medicine Hat figures.

Amadeus Peterson is the CTO & Co-Founder of Cheers, the local search platform for multi-location service businesses.