Why your AI visibility tool is measuring you in the wrong country (ours was too)

For twenty days this month, our Czech measurement pipeline asked AI engines about Czech brands — and quietly received answers grounded in Denmark. Nothing errored. Nothing looked wrong. Every report rendered beautifully. The country was simply incorrect, and no part of the system was capable of noticing.

We found the bug ourselves, fixed it the same day, and published it in our changelog the same day too. This post is the longer version: what exactly broke, why this class of failure is invisible by design, why we think much of the AI visibility industry has a quieter version of the same problem, and — most usefully — the five questions you should ask any vendor in this category before trusting a localized number. Including us.

The bug: one wrong integer, twenty days of Danish data

Our Czech self-serve grader went live on July 3. It runs real Czech buyer questions against three AI engines and shows a Czech business who the engines recommend instead of them. The measurement locale was configured with DataForSEO's location_code parameter — the integer that tells the API which country's search infrastructure to answer from.

We shipped it as 2208.

2208 is Denmark. Czechia is 2203. Five integers apart in a database of 267,107 location rows, and we picked the wrong one.

The consequence: from July 3 until July 23, every Czech grader run — and every Czech-market dashboard scan — sent its location-coded engine calls (Google AI Mode, the ChatGPT scraper, Gemini, AI Overview) to Danish search infrastructure. Perplexity was unaffected, because it doesn't take that parameter. But for the Google-family engines, we were showing Czech shop owners how visible they were in a country most of them have never shipped to.

Why nobody catches this

Here is the property that makes this failure class genuinely dangerous: a wrong location code does not produce an error. It produces an answer.

Send 2208 instead of 2203 and the API does exactly what you asked. It returns well-formed, plausible results — for Denmark. Your parser parses them. Your scoring scores them. Your charts chart them. Every layer downstream of that one integer works flawlessly on the wrong country's data. There is no exception to catch, no 4xx to alert on, no empty response to investigate. The system is healthy. The measurement is fiction.

Worse, the output is not even obviously foreign. AI engines answer in the language you prompt them in. Ask a Danish-located engine a Czech question and you'll frequently get a fluent Czech answer — assembled over the wrong country's retrieval. Unless a human reads the sources closely and wonders why the citation mix looks off, plausibility carries the day.

How we actually caught it: in late July we were building out measurement for 26 markets, and the program's rule was that no location code ships on trust. So we pulled the authoritative locations database — one call, 267,107 rows — filtered it to countries, and checked every one of our 26 codes against the country_iso_code the database itself reports. Twenty-five matched. One said DK.

The detail that stings most: Slovakia (2703) was correct — because we had verified it live when that market shipped. Czechia never got the same treatment; the code came from an assumption, and the assumption sat in production for three weeks. The market you verify is fine. The market you assume is the one that bites you. We fixed the code the same day, verified it live, and published the bug in the changelog that evening.

The industry pattern: "multi-language" usually means a translated UI

We would love to tell you this was a uniquely embarrassing mistake. Our reading of the field suggests otherwise — and this is a pattern observation about how the category is built, not an accusation aimed at anyone in particular.

Most AI visibility tools default every customer to US/English measurement. Not maliciously; it's simply the path of least resistance. The APIs default to it, the demo looks identical either way, and — as we've just demonstrated at our own expense — no customer can tell from the dashboard which country their numbers came from. When tools do advertise international support, it commonly takes one of three shapes: a country dropdown wired to a parameter nobody has verified end-to-end; market support reserved for enterprise contracts; or a dashboard translated into your language while the measurement underneath stays English. "Multi-language," in practice, usually describes the UI.

The trouble is that localized measurement is not a display concern. It has three load-bearing requirements, and skipping any one of them produces numbers that look local and aren't.

1. Verified per-country location codes. Not codes copied from a forum post or an old integration — codes checked against the provider's own authoritative database, ideally re-checked live at ship. Ours failed precisely at the "ideally" step, which is why it is now a hard rule.

2. Prompts generated in the market language. German buyers do not ask English questions, and engines do not give the same answer twice across languages — retrieval, sources, and recommended brands all shift. When we ran our live German-market probe through the shipped pipeline on July 23, the German prompt came back with a German answer citing German sources — a different answer, over different sources, than the English equivalent. A tool that asks English questions "for" the German market is measuring an audience that doesn't exist. Machine-translating an English prompt is only marginally better; buyer questions have local phrasing, local units, local intent.

3. Per-market filtering of aggregators and comparison sites. Every market has a layer of domains that AI engines cite constantly but that are never anyone's competitor: heureka in Czechia, idealo in Germany, leboncoin in France. A tool with a single global blocklist — or none — will either report "Heureka is beating you" (noise dressed as insight) or silently hide a genuine rival because it over-blocked. The list has to be researched per market, and it has to be careful: a marketplace that is also a first-party retailer is a real competitor to another retailer, so the exclusion has to depend on what the customer sells.

None of this is exotic engineering. It is tedious, verifiable, per-country homework — which is exactly why it so rarely gets done.

What we shipped (and where the limits are)

The bug fell out of a bigger program, which shipped this week. GeoTracker now measures a domain in any of 26 markets across 14 languages. Concretely:

• Every location code verified against the authoritative locations database, ISO code by ISO code — the pull that caught our own bug is now the standing procedure, not a one-off.
• Prompts generated in the market's language — written natively per market by the generation pipeline, not translated from English templates, with per-language quality guards so a localized badge is never sitting on top of English questions.
• Per-market non-competitor blocklists — roughly 450 researched domains across the 26 markets, covering price comparators, coupon sites, marketplaces, and directories, with the retailer-marketplace hybrids excluded only for customers who don't compete with them.
• The market shown in the dashboard. Your measured market is displayed on the dashboard and in the methodology, so "which country is this number from?" is answered on the page rather than in a support ticket.

And the honest limitations, because a post like this earns nothing if it turns into a brochure: monitored prompts run on a weekly cadence with repeated samples, not daily. The engine set varies by tier — the free tier measures one engine, and the full five-engine set is a paid feature. And this is a v1: 26 markets' worth of per-country research will contain errors we haven't found yet, and when we find them, they will be handled the way this one was — fixed, verified, published.

How to audit your own tool: five questions for any vendor (including us)

If you pay for AI visibility measurement in any non-US market, these five questions will tell you more than any feature page. We include ourselves in the audience for every one of them.

Question 1: Which location code ran my last scan, and how was it verified?

Not "do you support my country" — which code, verified how, when. A vendor with a real answer can name the parameter and the verification step. A vendor without one will talk about their language coverage. Our answer: the code for your picked market, checked against the provider's authoritative locations database, with the verification pull documented — a discipline we adopted after twenty days of measuring the wrong country.

Question 2: What language were my prompts generated in?

Ask to see three actual prompts from your last scan. If you're a German business and they're in English, your numbers describe an audience that doesn't ask questions the way your buyers do. Follow-up worth asking: are the prompts written in the market language, or translated from English templates? The difference shows up in phrasing, and phrasing changes what the engines retrieve.

Question 3: Is your competitor filtering per-market, or one global list?

If a price-comparison site appears in your competitor list, the filtering is not localized — heureka, idealo, and leboncoin are never your competitor. If the vendor does maintain per-market lists, ask the harder version: what happens when a marketplace is also a retailer? The answer reveals whether anyone actually thought about your market.

Question 4: What happens when a location parameter is wrong?

This is the question we failed. A wrong location code returns plausible data, so "our API calls succeed" is not an answer — success is precisely the failure mode. What you want to hear is some form of verification that binds the parameter to ground truth: a check against the provider's own country database, a live probe whose sources are inspected, anything that would catch a healthy pipeline measuring the wrong country. If the vendor's answer is that it has never happened, it may simply mean nobody has looked.

Question 5: Where is your methodology published?

Engines, weights, cadence, sampling, market handling — public, specific, and current. A vendor who publishes methodology can be checked, which is uncomfortable and useful in equal measure; a vendor who doesn't is asking you to trust the dashboard. Ours is at /methodology, and this post exists because publishing your methodology also means publishing its failures.

The uncomfortable takeaway

The lesson we took from this is not "be more careful," which is what a post-mortem says when it has learned nothing. The lesson is structural: in AI visibility measurement, correctness is invisible from the inside. A healthy pipeline and a wrong pipeline produce equally beautiful dashboards. The only defences are verification against ground truth, at ship and on a schedule — and enough public transparency that hiding a mistake costs more than admitting it.

We measured the wrong country for twenty days. We told you the same day we found out. As far as we can tell, that combination — the bug and the disclosure — is currently rarer in this industry than it should be. We'd prefer a field where it's unremarkable.

Methodology & sources

Editorial review for factual claims (as of 2026-07-24).

The facts behind this post: the Czech measurement locale shipped 2026-07-03 with DataForSEO location_code 2208 (Denmark, per the provider's own locations database) instead of 2203 (Czechia). Affected: the location-coded engine calls (Google AI Mode, ChatGPT scraper, Gemini, AI Overview) for Czech grader runs and Czech-market dashboard scans between 2026-07-03 and 2026-07-23. Perplexity calls were unaffected (no location-code parameter). Found 2026-07-23 during the verification pull for our 26-market localization program: one call to the provider's locations endpoint (267,107 rows), filtered to countries, each of our 26 codes checked against the returned country_iso_code. Fixed to 2203 and verified live the same day; published in the public changelog the same day. Historical Czech runs before the fix retain Denmark-located data for the affected engines, by decision, documented rather than back-filled.

Why we're a credible reporter on our own bug: the same reason as our Day 1 score of zero — the methodology is public, the changelog is public, and anyone can re-run the measurement. The cheapest credibility we have is being the brand that publishes its own mistakes with dates attached.

Sources and further reading

Everything in this post is verifiable against our own public surfaces:

• Changelog — the 2026-07-23 entry documenting the location-code bug and fix, and the multi-market launch entries.
• Methodology — engines, weights, cadence, and market handling, current.
• Day 1 of tracking our own AI visibility: GEO Score 0 — the first post in this radical-transparency series, and the standard this one is held to.
• AI search visibility in 2026: the hygiene checklist — the measurement-discipline primer; this post is what that discipline looks like when it catches your own bug.

Frequently asked questions

The same Q&A pairs ship as FAQPage structured data so AI engines can quote them verbatim.

How do I know if my AI visibility tool is measuring the right country?

+

Ask the vendor which location code ran your last scan and how it was verified against the provider’s authoritative locations database. Then ask to see three actual prompts from your scan — if you sell in Germany and they’re in English, the measurement is not localized regardless of what the dashboard language says.

Why does a wrong location code not produce an error?

+

Because the API does exactly what it was asked: it returns well-formed, plausible answers — for the wrong country. Every downstream layer (parsing, scoring, charts) works flawlessly on that data, so nothing alerts. Correctness is invisible from the inside; only verification against ground truth catches it.

Does "multi-language support" mean localized measurement?

+

Usually not. In most AI visibility tools "multi-language" means a translated dashboard while measurement stays US/English. Localized measurement requires three things: verified per-country location codes, prompts generated natively in the market language, and per-market filtering of aggregators and comparison sites (heureka, idealo, leboncoin are never your competitor).

What went wrong with GeoTracker’s Czech measurement?

+

From 2026-07-03 to 2026-07-23 our Czech locale shipped DataForSEO location_code 2208 — which is Denmark; Czechia is 2203. Location-coded engine calls measured Czech brands against Danish results for twenty days. We caught it by verifying all 26 market codes against the authoritative locations database, fixed and disclosed it the same day.