How to View Your Website From Another Country
Contents

- What does a site use to decide your country?
- Why is a proxy on its own not enough?
- How do I set up one Chrome profile per market?
- What should a regional check record?
- Why does a static address beat a rotating one for repeat tests?
- When is a VPN enough, and when is it not?
- Where does ProxyJam fit?
- Quick answers
In short: A site usually decides your country from your IP address, then adjusts what it shows by browser language, time zone, cookies and any signed-in account. To view your own website from another country, every one of those has to match the market. That means a proxy in that country for the address, and a separate Chrome profile with the market’s language and time zone and none of your cookies.
To view your website from another country, the request has to arrive the way a visitor’s would: from an address in that country, with that market’s browser language and time zone, and without the cookies your own visits left behind. A proxy takes care of the address, and the rest are browser settings. This guide is about checking your own site, the job our region testing page describes: how to set it up in Chrome, what to write down on each run, and when a VPN does the job as well.
What does a site use to decide your country?
Usually the IP address, often combined with other signals. There are five, and they come from different places.
- The IP address. The server, or a CDN in front of it, looks the address up
in a geolocation database. Cloudflare, for example, can pass the visitor’s
country to the origin as a two-letter code in a
CF-IPCountryheader (Cloudflare’s header reference). - The browser language. Chrome sends an
Accept-Languageheader built from the preferred languages in its settings, and page scripts read the same list fromnavigator.languages(MDN). - The time zone. A script can read the computer’s time zone as a name such
as
Europe/Berlinthrough theIntl.DateTimeFormatAPI, in thetimeZonefield of itsresolvedOptions()(MDN). - A precise location. The Geolocation API reports coordinates only after the visitor allows it (MDN), so most sites never get one.
- What the site already knows. A cookie holding the region or currency you picked last time, or the country on a signed-in account, can take precedence over the address.
The table “Which signal comes from where, and how to set it for a test” pairs each signal with the Chrome setting that controls it.
Why is a proxy on its own not enough?
The signals can disagree, and how a site handles the disagreement is part of
what you are testing. Route Chrome through a German address but leave the
language list on English (US), and a site that takes the language from
Accept-Language and the price from the address shows euro prices in English.
No real visitor in Germany with a German browser sees that page. Keep your
usual cookies, and the site may skip its country logic and serve the region
you chose last month.
So set every signal to the market before the first run, and keep it that way for the runs that follow.
How do I set up one Chrome profile per market?
Create a separate Chrome profile for each market and give it its own proxy. A profile keeps its own history, passwords and settings (Chrome Help), and its own cookies (Chromium’s notes on the user data directory). The German profile’s cookies never reach the French one, and neither touches your everyday browsing.
- Create the profile. Select your profile picture at the top right, then Add Chrome profile, and name it after the market, such as “Test DE”. Leave it signed out of your Google Account, so that nothing from your main profile syncs into it.
- Install a proxy extension in that profile. An extension sets the proxy for the profile it is installed in (chrome.proxy API). Add the market’s proxy to it. Our free ProxyJam Connector is one such extension.
- Send only the domains under test through the proxy. Add a rule for your site’s domain and its subdomains, and leave the fallback on Direct. Chrome’s own traffic and every other site keep your connection, and the proxy carries only the test. How rules become a PAC script, and why on HTTPS they match host names and never paths, is covered in using a proxy only for certain sites in Chrome.
- Add the hosts the page calls. Open DevTools, reload the page and read the Domain column of the Network panel (right-click the column headers to show it if it is hidden). Prices often come from an API on another host, and a consent banner may ask its vendor’s server which version to show. A host left out of the rule sees your own address, and the page ends up mixing two markets. Add each one.
- Set the language. In Settings, Languages, add the market’s language
under Preferred languages and move it to the top
(Chrome Help). That order
is what
Accept-Languagesends. - Set the time zone. Chrome takes the time zone from the operating system and has no setting of its own. For a test, DevTools can supply one: in DevTools Settings, Locations, add a location with the market’s Timezone ID and Locale, then pick it in the Sensors panel (DevTools documentation). The override belongs to the tab DevTools is open on, so open DevTools before loading the page. Changing the system time zone also works, for every program on the computer at once.
- Check the profile. Add proxyjam.com to the rule for a minute and open What Is My IP. It should show the proxy’s address, located in the market. Take the check page off the rule afterwards.
If the proxy needs a username and password and Chrome keeps asking for them, the proxy sign-in prompt explains why and what to do.
What should a regional check record?
The same fields on every run, so that two runs can be compared line by line. The list “Write down the same fields on every run” is a starting set: the redirect chain, price and currency, stock, the consent banner and the language, plus the address the profile was using.
For the redirect chain, turn on Preserve log in the Network panel, which keeps
the requests from before a redirect in the list
(DevTools Network reference).
From a terminal, curl prints the headers of every hop when given -I and -L,
sends the request through a proxy with -x, and adds a language header with
-H (curl manual). The proxy address
comes from a range reserved for documentation
(RFC 5737); put your own in its
place.
curl -sIL -x http://203.0.113.10:8080 -H "Accept-Language: de-DE,de;q=0.9" https://example.com/
Each status line followed by a location: header is one hop. A plain request
like this one sees redirects, headers and prices written into the HTML. Because -I sends a HEAD request, a
server that answers HEAD differently from GET can show a different chain; drop
-I and add -o /dev/null -D - to print the headers of a normal request. It
runs no scripts, so a consent banner or a price filled in after the page loads needs
the browser profile.
Keep one row per run and one sheet per market. A difference between two runs is worth investigating only when the address, the language and the time zone were the same both times; if any of them changed, you are comparing two setups.
The redirect chain matters beyond QA. Google says its crawler’s default
addresses appear to be in the United States and that it sends no
Accept-Language header
(Google Search Central),
so Google may not crawl or index a market version that is reachable only
through detection. A version with its own URL avoids that.
Why does a static address beat a rotating one for repeat tests?
A comparison needs one thing to change at a time. A rotating pool gives out a different address per request or per session, and each address has its own geolocation record and its own network. When a price moves between Monday and Thursday, you cannot tell whether the site changed or the address did. A static address keeps the vantage point fixed, so it drops out of the comparison. Holding one address and drawing from a pool are compared in more depth in ISP vs residential proxies.
A static address can still move: geolocation databases are updated, and an address can be recorded under another country. So the What Is My IP check comes before every run, the first one included. A rotating pool is the better tool when you need many different addresses in one market at the same time.
When is a VPN enough, and when is it not?
A VPN is enough for a one-off look: whether the German home page loads, whether the banner appears. It is quick, and many people already have one installed.
A VPN falls short in three ways when the check has to be repeated:
- A VPN app usually carries all of the device’s traffic, so every program and tab is in the test country together, and two markets cannot sit side by side.
- Its exit addresses are shared by many users and form a known category in IP data: commercial databases carry a field for addresses registered to anonymous VPN providers (MaxMind’s documentation). A site that reads it may treat a VPN visitor differently, and the run then records that treatment.
- The exit address can change from one connection to the next, which brings back the rotating pool’s problem.
Where does ProxyJam fit?
ProxyJam sells static residential (ISP) proxies: an address in the country you choose, registered to an internet provider, that stays yours for the period you paid for. For this job that means one address per market. The countries are listed on the proxy locations page, 77 today, with prices per IP per period on the pricing page. If an address starts to geolocate outside the country you bought, that is grounds for a free replacement, within the monthly limit set in section 2.5 of the Terms of Service.
The product is sold by country, so a difference between two cities is beyond what it can show. It is also meant for checking your own site: using an address to reach content that a site withholds from your country is prohibited by section 5 of our Acceptable Use Policy. The catalogue is on the ISP proxies page, and what an ISP proxy is in the first place is explained in what ISP proxies are.
