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, that means there is no single national result to rank for. There is a set of local recommendation jobs that must be tested under controlled conditions.
Important
A location-aware answer is not a universal ranking. Record the market, provider, product surface, prompt, session state, and date before comparing two results.
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.
ChatGPT may use IP location, device location, and memory
OpenAI's ChatGPT Search documentation says the product may use a general location estimated from an IP address to improve results. Its example shows a "near me" search rewritten with a city. Users can also enable precise device location for more relevant local answers.
The same documentation says Memory may influence how ChatGPT rewrites a search query. A tester's saved context can therefore change the retrieval request even when the visible prompt looks similar. OpenAI also says there is no way to guarantee top placement in ChatGPT Search. That is a useful boundary for anyone selling a fixed local ranking formula.
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 location settings guidance says users can set a precise location for more relevant local answers and that, without that setting, responses can be based on network location. The setting is optional, so two users can enter the same words with different location 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.
Next step
Is AI recommending your business?
Find out how visible you are across ChatGPT, Gemini, Perplexity, and AI Overviews.
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
- Google Search Help: Understand and manage your location when you search on Google. Location estimation from device, saved places, activity, IP address, and user controls
- Google: AI Mode advances from Google I/O 2026. Conversational context, optional Personal Intelligence, and local-service agent capabilities
- Google Search Central: AI features and your website. Search foundations, visible content, structured data, Business Profile information, and AI reporting guidance
- OpenAI Help Center: ChatGPT Search. General IP location, optional precise location, near-me query rewriting, Memory, and placement boundaries
- Anthropic: Claude web search tool. Approximate user-location input for applications using Claude web search
- Perplexity Help Center: Account settings. Optional precise location and network-location behavior
Amadeus Peterson is the CTO & Co-Founder of Cheers, the local search platform for multi-location service businesses.