How language and region influence the design of an AI visibility audit

If your brand sells in more than one country, a single English-language audit tells you about one slice of how assistants talk about you. People ask in their own language, and the same question can imply a different market ("best accounting software" means different vendors in the US, Germany and Brazil). This article is about designing an audit that respects that, without claiming more than the method can support.

Treat what follows as methodology. How much control a given tool gives you over language and market is a separate question, which we cover at the end.

Language and region are two different dials

• Language is the language of the question and the expected answer.
• Region (target country) is the market the person asking is assumed to be in.

They move independently. An English question can target Germany ("best payroll software for a company in Berlin"), and a German question can target Austria or Switzerland. Decide each separately, and record both.

Why a translated question is not the same question

Translating a question word for word does not guarantee it is the same query. Local phrasing, local competitors, local review sites and local regulation all change what a good answer looks like. Treat each language version as its own tracked question. That has a practical consequence: you cannot add together an English and a German result and call it one number. They answer different questions.

When you do want to relate versions to each other, group them by association (this German question is the counterpart of that English one) without relabeling any recorded response. The association helps you read results side by side. It does not make the two measurements one.

Design rule 1: one language and one country per question

Give every tracked question exactly one language and one target market. A question with no market set should be reported as "no market," not silently assigned to your home country. Multi-valued brand defaults ("we serve the US, UK and Germany") are fine as a starting point for new questions, but they should not fan one question out into many without you choosing and paying for that.

Design rule 2: compare markets only on matching question sets

Say you track 20 questions in the US and 8 in Germany. The German rate is computed over 8 questions, the US over 20. If the German questions are easier or harder, or simply different, the two rates are not comparable. For a fair market comparison, run the same question concept in each market and check that every market ran the identical set. If the sets differ, present the markets as separate audits, not as a comparison.

Design rule 3: be honest about what a country setting does

A "target country" on a question usually works as an instruction in the prompt ("the person asking is located in Germany"). That conditions the answer, but the request itself still comes from the same infrastructure as every other. It is not the same as measuring from a device or IP address in that country, and consumer apps may personalize in ways an API call does not. Say so in your report. Avoid headlines like "what Germans see."

Design rule 4: do not rewrite history

If you change a question's language or market, you have changed what is being measured. Version the question, and keep earlier responses attached to the version they ran under. Mixing old and new responses into one trend line hides the change.

Design rule 5: report what you could not place

Old data may predate the practice of recording language and market. Report it as "locale unknown" instead of folding it into a market, and show how much of the total it is. A market-filtered view that silently drops unknown-locale responses can look complete when it is not.

Planning the audit

1. List the markets that matter commercially, and the languages buyers actually use in each.
2. Draft each question concept once, then write a natural version per language and have a native speaker check it.
3. Choose competitors per market. The local set may differ from your global one.
4. Budget for it. More markets means more questions and more provider calls.
5. Write down the comparability rule before you see results.

A worked example (illustrative)

A hypothetical invoicing tool sells in the US, UK and Germany. The team plans three markets and 10 question concepts.

Reading the plan: US and UK can be compared on citation rate, because the question sets match, but not on share, because the tracked competitors differ. Germany stands alone. The team will write "Germany ran 8 of the 10 concepts" next to every German figure. All details here are invented.

Where to be cautious

• Small denominators. A single country usually has fewer measurements than the brand total, so single results swing more.
• Site-side signals. If you serve localized pages, check that language and region annotations point to pages that really exist in those languages; Google's guidance on localized versions describes using hreflang annotations that list every variant of a page, and one cannot assume every assistant uses them.

How Doclight helps

In Doclight each tracked question carries one language and one target country; brand-level target languages and countries seed new questions but do not multiply what a scan costs. Editing a question's language or country creates a new version with an automatic note, and responses keep the question snapshot they ran with. Reports, trend, share of voice, models and exports accept language and country filters that read this frozen snapshot, and unknown-locale responses are counted and shown separately, never folded into a market. A locale comparison view lists every measured language-and-country pair with its own coverage and flags whether the pairs ran the same question set. Questions can also be associated in comparison groups without relabeling recorded responses.

Doclight's country setting is prompt conditioning: it adds a short instruction about language and location to the request, and does not send a documented provider geographic-targeting parameter today. Reports say so.

Checklist

• Commercially relevant markets and languages listed.
• One language and one country per question.
• Natural-language versions written, not literal translations.
• Comparability rule written before results arrive.
• Market shares never compared with brand-wide shares.
• Unknown-locale data reported separately.
• Report states that country is prompt conditioning where that applies.

Sources and verification

Checked on 2026-10-12. Product behavior was verified against this repository: the "Market scoping" section of METRIC_DEFINITIONS.md, backend/app/llm/geo.py, and the locale comparison in backend/app/analytics. For the external point, Google's documentation on localized versions was read through a search-result summary only, because the page itself could not be fetched in this pass; check it directly before relying on details. No customer data is used. The planning table is illustrative.