Country-specific web content for LLMs: same URL, other page

Open a public pricing page from Berlin and from New York and you may get two different pages at the same URL: different language, currency, consent banner and legal notice. An LLM that reads one of them and answers a user in the other country gives a confidently wrong answer. This guide explains why it happens, which country to read from, and how to keep the model honest about it.

Why the same URL differs by country

Sites adapt pages to the reader in a few common ways:

• By the connection's location. The server or its CDN looks at where the request comes from and serves a regional variant or redirects to one.
• By language headers. The Accept-Language header states preferred languages. Sites that honor it may switch language without changing the URL.
• By regulation. Consent banners, cookie notices and legal disclosures differ by jurisdiction, so a page read from the EU often carries text that the US version does not.

The HTTP Vary header sometimes signals that a response depends on a request header, but many sites vary by location without saying so. The only reliable way to know what readers in a country see is to read the page from there.

What it does to an LLM answer

Country differences show up in answers in predictable ways:

None of these are model failures. The model answered from the page it was given.

Choose a default country on purpose

A simple decision order works for most apps:

1. The user's country, if your app knows it and the question is about something they would buy, use or comply with.
2. The country the question names, if it names one ("What does the German page say about returns?").
3. Your product's main market as the fallback default.

Write the default down in configuration. Live Web Data API reads pages from the US unless you set countryCode; the code is an ISO 3166-1 alpha-2 value such as de, jp or br. Every request reads the page live from the country you set, so there is no shared copy to mix up. If you store copies yourself, key them by URL and country; the guide on live vs cached web data covers how old those copies may be.

Consent banners in fetched pages

Pages read from the EU often include a cookie consent layer. With verbosity: "compact" (the default) the API returns the main content only; "full" keeps the whole body, including navigation and footer. Consent text can still get through: some sites build the banner into the page body, and then fragments of its text can appear in the main content. The guide on Markdown, text or HTML for LLMs covers when the full page is worth its tokens. Two mitigations:

• Strip known banner phrases in a post-processing step for sources where you have seen them.
• Ask the model to ignore consent and cookie text when summarizing.

Use verbosity: "full" only when you need the whole page, for example to check what a banner or footer says.

Pass the country to the model

Put the country next to the content, just like the URL and fetch time:

<source url="https://example.com/pricing" country="de" fetched="2026-10-27T09:14:00Z">
...page markdown...
</source>
Answer for readers in the country shown on the source. State prices in the currency used on the page.

If a question really is a comparison ("How do the US and German pages differ?"), fetch both and label each source clearly.

Check your own localized pages

The same technique is a cheap QA tool. Fetch your own public pages from each country you serve and compare the Markdown:

• Is the right language served, or does one market get the fallback?
• Do prices and currencies match what you intend for each country?
• Does any market see an outdated legal notice?

Because Markdown drops markup, the differences are easy to diff.

hreflang is not what a fetcher receives

hreflang annotations tell search engines which localized URLs exist for a page. They do not change what a server sends to a given request. A fetcher reading https://example.com/pricing from Germany receives whatever the site serves to that request. If you want a specific localized version, request its own URL, and if the site varies the page by location, read it from the matching country.

Public pages, by the rules

A country setting shows you the public page as it is served in that country. It is not a way to reach content that a site restricts by login, paywall or other access control; that is excluded by the product's acceptable-use policy and is not a topic on this site. Check robots.txt and the site's terms before fetching at volume. This is general information, not legal advice.

Where Live Web Data API fits

Set countryCode per request and the page is fetched through a connection in that country; the default is us. The result comes back as Markdown, text or HTML with the same per-URL statuses[] as any other request. See how countryCode works in the API reference, or request access as a business.

Checklist

• The app has a written default country and a rule for when to override it.
• Every fetched page is stored with its country.
• The country goes into the prompt with the content.
• Consent text is filtered for sources where it leaks through.
• Comparisons across countries label each source.
• Your own localized pages are checked from each market you serve.