A site that works perfectly in the country where it was built can be quietly broken in twelve others. A checkout button that was never translated in Italy, prices shown in dollars to German visitors, a consent banner that covers the whole page in France, a language version that search engines never find because its hreflang points to the wrong URL. None of these show up when the team tests from the office.
The reason is simple: most of what changes between markets is decided by where the visitor is. To see what a local customer sees, you have to test from that market. This guide covers how to run localisation QA across markets at scale: what to check, how to view each market as a local visitor does, and a small checker that catches the most common bugs automatically.
Why localisation bugs hide
Localised sites rarely serve one fixed page per language. They decide what to show at request time, based on signals the visitor sends:
- Location, from the IP address: currency, prices, shipping options, legal banners, product availability, and sometimes the language itself.
- Language preferences, from the browser: which translation to show and how to format dates and numbers.
- The URL, such as
/de/orde.example.com: the version the site was asked for, which may or may not match the other two.
Head-office testing usually covers one combination: the office’s own country, an English browser and the default URL. Translation reviews check the words but not the page as it is served. The bugs live in the combinations nobody tried.
What breaks in one market
| Bug | Example | How it usually happens |
|---|---|---|
| Untranslated strings | ”Add to cart” on the Italian site | New features ship with English strings that never reach the translation workflow |
| Wrong currency or price format | $49.99 shown to German visitors, or 49.99 € instead of 49,99 € | Currency picked from the URL in one place and from the IP in another |
| Broken hreflang | A language version points to a 404 or to another language | URLs changed after launch, alternates not updated |
Missing or wrong lang attribute | lang="en" on the German page | A shared template with a hard-coded attribute |
| Redirect loops or forced redirects | A visitor in Austria sent to the German shop and unable to return | Geo-redirects that ignore an explicit choice |
| Legal and consent layers | A banner covering the content in one EU country | Country-specific consent configuration |
| Layout overflow | German labels breaking buttons, right-to-left text breaking a grid | Designs tested only with short English strings |
Several of these affect search directly. A page with the wrong lang attribute or broken alternates can be indexed as the wrong language, or not at all. Our guide to using hreflang to find every language version of a page shows how to map a site’s alternates and spot the ones that point nowhere.
Step 1: see each market as a local visitor
The core requirement is to request each page from inside the market, with a browser set up like a local visitor’s. In practice that means three things that must agree:
- An IP address in the market. Residential proxies with country or city targeting give you an address on a local consumer connection, which is what the site’s geo-logic expects. Our residential proxies cover 195+ countries, with city targeting where you need it.
- The market’s language and locale. Set the browser’s language header and locale to match.
- The market’s timezone, if you test in a real browser, because some sites use it as another location signal.
If those disagree, you test a combination no real customer has, and you can chase bugs that do not exist. Our guide to matching proxy geo, timezone and locale covers how to derive all three from one setting.
Also test with a fresh session for each market. Cookies from a previous visit can pin the site to the last country you tested, which hides geo-logic bugs.
Step 2: check every market the same way
Visual review does not scale to dozens of markets and thousands of pages, but most localisation bugs can be detected in the HTML. The function below checks one localised page for four of the most common problems: the lang attribute, leftover English strings, prices in the wrong currency, and a missing hreflang entry for the market.
import re
from lxml import html as lxml_html
def market_problems(page_html, market):
"""Things that only break in one market, checked on one localized page.
market: {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]}
"""
doc = lxml_html.fromstring(page_html)
problems = []
lang = (doc.get("lang") or "").lower()
if not lang.startswith(market["lang"]):
problems.append(f"html lang is {lang or 'missing'}, expected {market['lang']}")
text = " ".join(" ".join(doc.itertext()).split())
for phrase in market["leftovers"]:
if phrase.lower() in text.lower():
problems.append(f"untranslated text: {phrase!r}")
prices = re.findall(r"[$€£¥₩R]\$?\s?\d[\d.,]*|\d[\d.,]*\s?[$€£¥₩]", text)
wrong = [p for p in prices if market["currency"] not in p]
if wrong:
problems.append(f"{len(wrong)} of {len(prices)} prices not in {market['currency']}, e.g. {wrong[0]!r}")
if not doc.xpath(f"//link[@rel='alternate'][starts-with(@hreflang, '{market['lang']}')]"):
problems.append(f"no hreflang entry for {market['lang']}")
return problemsRunning it on two pages (illustrative HTML, not a real site):
from locqa import market_problems
markets = {
"de": {"lang": "de", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
"fr": {"lang": "fr", "currency": "€", "leftovers": ["Add to cart", "Free shipping"]},
}
pages = { # in practice: the same product page, fetched from inside each market
"de": '<html lang="de"><head><link rel="alternate" hreflang="de" href="/de/p/1"></head>'
'<body><h1>Wasserkocher</h1><p>49,99 €</p><p>Free shipping</p></body></html>',
"fr": '<html lang="fr"><head><link rel="alternate" hreflang="fr" href="/fr/p/1"></head>'
'<body><h1>Bouilloire</h1><p>$49.99</p><p>Ajouter au panier</p></body></html>',
}
for code, page in pages.items():
print(code, market_problems(page, markets[code]) or "ok")de ["untranslated text: 'Free shipping'"]
fr ["1 of 1 prices not in €, e.g. '$49.99'"]The German page has a leftover English phrase; the French page shows a dollar price. Both would pass a translation review, because the translated strings themselves are fine.
Build the list of leftover phrases from your own interface: button labels, shipping and checkout messages, error messages. These are the strings most often added late. Price formats need care beyond the currency symbol, since the same symbol can be written several ways; our guide to normalising prices, numbers and dates across locales covers parsing them reliably.
Step 3: run it on a schedule
Localisation breaks after launches, not just at launch. A new feature, a template change or a pricing update can break one market while every other one looks fine. A practical rhythm:
- On every release: a small set of key pages (home, a category, a product, cart, checkout) in every market.
- Weekly: a wider sample of pages per market, including recently changed ones.
- After any change to geo-logic, pricing or consent: a full pass.
Report results per market and per check, so each team sees its own problems. The market with the most failures is usually the one with the least local testing.
Things automation will not catch
Some problems still need a person who knows the market: a translation that is correct but sounds wrong, an image or colour with an unfortunate local meaning, a legal requirement the template does not cover. Automated checks free people to spend their review time on those, instead of hunting for dollar signs.
Some sites also show different consent and privacy layers by country, which change both what users see and what an automated test can reach. Our study of consent walls by country shows how much that varies across the EU.
FAQ
What is localisation QA?
Testing that each language and market version of a site works and reads correctly for local visitors: translations, currency and price formats, layout, legal notices, redirects and the signals search engines use to find each version.
Why can’t I test other markets with a VPN?
You can for a quick look, but many sites recognise VPN and data-centre addresses and treat them differently from home connections, so you may not see what a real local customer sees. Residential IPs in the market are closer to the real experience.
Which pages should I test in every market?
At minimum the homepage, a category page, a product page, the cart and checkout, plus any page with prices or legal text. Expand to a rotating sample of recently changed pages.
How do localisation bugs affect SEO?
Wrong lang attributes, broken hreflang alternates and forced geo-redirects can make search engines index the wrong language version, or miss a version entirely, which costs visibility in that market.
The bottom line
Localisation bugs hide in the markets nobody tests from. View each market as a local visitor would, with an IP, language and timezone that agree, and run the same automated checks on every market after every release. Catch the mechanical problems (language attributes, leftover strings, currencies, hreflang) by machine, and save human review for what only a local reader can judge.