How to Test Hreflang Live via Proxy from 10 Countries: Step-by-Step SEO Check

The hreflang markup in the page code is one thing, while what a visitor from Germany, Poland, or Brazil actually receives is quite another. Google may ignore tags, CDN may redirect incorrectly, and the server may serve the wrong version based on IP. The only way to ensure everything works is to check the site "live" from different countries, rather than trusting the markup on paper.

What is hreflang and why tags in the code are not enough

Hreflang is an attribute that informs search engines which language or regional version of a page is intended for which users. Technically, it appears as a set of links in <head> or in sitemap.xml, where each page links to its alternatives: ru-RU, en-US, de-DE, and so on.

The problem is that checking through code validators (Screaming Frog, Ahrefs, Semrush) only shows what is written in the markup. It does not answer the main question: what really happens when a live person from Warsaw or Madrid opens your site? Does the redirect trigger for the correct locale? Does the CDN redirect the user to the English version due to caching? Does geo-IP correctly identify the country if the user accesses through a mobile operator?

For marketers and SEO specialists testing multi-regional sites, landing pages for different geos, or advertising campaigns in Google Ads and Facebook Ads for specific countries, this is critical. If hreflang is set up incorrectly, a user from the desired country may see the wrong version of the site, lose conversion, and the search engine may index the wrong URL in the results for that country.

Why hreflang "lies": 5 typical reasons

In practice, discrepancies between the markup and the actual behavior of the site arise for several reasons, and most of them cannot be detected by simply looking at the page code.

• Geo-IP redirect overrides hreflang. The server determines the country by IP and forcibly redirects to the locale, even if the user explicitly opened another language version via a direct link.
• Caching CDN serves an outdated version. Cloudflare or another CDN may cache HTML without considering the request country, and all users receive the same version regardless of geo.
• Mismatch of language and region codes. The markup specifies en, while it should have been en-GB and en-US separately — as a result, users from Britain and the USA see the same version.
• Missing self-referencing tag. The page does not link to itself in the hreflang list, which may cause Google to not recognize the markup as valid.
• Different URL variants with www and without, http and https. The tags point to one protocol, while the server actually redirects to another, breaking the verification chain.

All these issues manifest only when accessing with the IP of the desired country. Therefore, the only reliable way to test is to emulate a visitor from each target country and see what the site actually delivers.

What is needed for checking from 10 countries

To check hreflang "live," you need to physically or programmatically obtain an IP address from each target country and see what version of the site the server delivers to that specific IP. There are three working methods for this:

1. Geo-targeted proxy servers — the most flexible and scalable method, suitable for both manual checks and automation.
2. Anti-detect browsers (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) — convenient when you need to maintain separate browser profiles for each country and compare visually, without confusion in cookies and cache.
3. Command line tools (curl, httpie) with proxies — for quick checks of HTTP headers, redirects, and server responses without loading an interface.

For testing hreflang from 10 countries, residential proxies are the best fit — they use IPs of real users from a specific country, so geo-IP services and CDNs identify them just like a regular site visitor. Datacenter proxies sometimes get blacklisted by geo services and may give false results when the server identifies them not by the declared country but as "datacenter, country unknown."

Setting up proxy in an anti-detect browser

The most practical way for a marketer without programming skills is to create separate profiles in an anti-detect browser for each of the 10 target countries and run hreflang checks visually through them.

Step-by-step in Dolphin Anty or AdsPower, it looks like this:

1. Create a new browser profile, name it by country, for example, "hreflang-DE" for Germany.
2. In the profile settings, open the "Proxy" section and select the type HTTP/SOCKS5.
3. Insert the proxy data geo-targeted to Germany: IP or host, port, username, and password.
4. Save the profile and wait for the check — the anti-detect browser will show a specific geolocation, timezone, and IP.
5. Launch the profile and open your site via the direct URL, without coming from search.
6. Check what version opened: the URL in the address bar, the language of the content, hreflang values via "View Page Source."
7. Repeat for each of the 10 target countries, creating a separate profile for each.

This approach is convenient because profiles are saved, and you can return to them in a week or a month to check if the site's behavior has changed after a CDN update or deployment of a new version. For this task, residential proxies tied to a specific city rather than just the country work well — this provides a more accurate emulation of a real visitor.

Checking via command line and curl

If you need to quickly check not the visual version but specifically the HTTP headers, redirects, and server responses, the browser does not always provide a complete picture — part of the logic is hidden in the response headers. For this, it is convenient to use curl with a proxy.

Basic check via proxy geo-targeted to the desired country:

curl -x http://login:password@proxy-host:port \
  -I https://example.com/ \
  -H "Accept-Language: de-DE"

The flag -I shows only the response headers, without the body of the page. This allows you to quickly see the redirect code (301 or 302), the Location header, which indicates where the server redirects, and the Vary header, which informs whether Accept-Language is considered in caching.

To extract the HTML itself and find hreflang tags in the server's response, remove -I and filter the output:

curl -x http://login:password@proxy-host:port \
  -s https://example.com/ | grep -i hreflang

This request will extract all lines mentioning hreflang directly from the HTML served by the server, rather than from what is expected according to documentation. If the result differs depending on which country's proxy the request is sent through, it means the server indeed changes content by IP, rather than just declaring it in static markup.

To automate the check for all 10 countries, you can write a simple script that iterates through a list of proxies and saves the response of each request to a separate file for comparison:

for country in de fr es it pl nl br mx jp kr; do
  curl -x "http://login:password@${country}.proxy-host:port" \
    -s https://example.com/ | grep -i hreflang > "result_${country}.txt"
done

After running the script, you just need to compare the files — if the hreflang tags are the same across the board, it means the server does not change the markup by geo, which can be expected behavior (markup is static and universal) or a problem (if different canonicalization was expected for different regions).

Checking via browser and DevTools

For visual checking and analyzing user experience, it is more convenient to use a regular browser with a configured proxy and open developer tools. This does not require code and is suitable for marketers who want to see with their own eyes what the user sees.

Steps to follow:

1. Set up the proxy in the browser through an extension (e.g., FoxyProxy) or through the system network settings, specifying the IP of the country being checked.
2. Open the site and immediately press F12 to open DevTools, then go to the "Network" tab.
3. Refresh the page and find the first document request (usually named the same as the site's domain).
4. In the right panel, open the "Headers" tab and check the "Response Headers" section for redirects and the value of Content-Language.
5. Open the "Elements" tab and use Ctrl+F to find all occurrences of hreflang in the page source.
6. Compare the URL in the address bar with the one you expected to see for this country.

This method is especially useful when you need to check both the technical correctness of the markup and the visual display of content simultaneously — for example, whether the currency, date format, or localized banners are correctly displayed for a specific country.

Which proxies to choose for geo-targeting tests

Not all types of proxies are equally suitable for checking hreflang. The difference lies in how geo-location detection services recognize IPs and how reliably the proxy maintains its connection to the declared country.

Proxy Type	Geo-IP Accuracy	When to Use
Residential Proxies	High, IPs of real providers	Accurate emulation of a live visitor from a country and city
Mobile Proxies	High, IPs of mobile operators	Testing behavior for mobile traffic and AMP versions
Datacenter Proxies	Lower, sometimes marked as datacenter	Quick checks of headers and redirects via curl, where geo-accuracy is not critical

For the final acceptance check before launching a multilingual site or international advertising campaign in Google Ads, it is best to use residential or mobile proxies — they provide results that are closest to what a real user from the target country will see.

Hreflang check-list for 10 countries

To ensure nothing is missed during mass checking, use the following list for each of the 10 countries:

• The proxy with the IP of that specific country is connected, and geolocation is confirmed via IP-checker.
• The direct URL of the site is opened (without coming from search and without referrer).
• The final URL after all redirects is checked — does it match the expected locale?
• The page code contains a self-referencing hreflang to itself.
• All other 9 language versions are listed in the hreflang without omissions.
• Language and region codes conform to the ISO standard (e.g., pt-BR, not just pt, if distinguishing between Brazil and Portugal is needed).
• The header Vary: Accept-Language is present if the content depends on the browser's language.
• The page content (currency, prices, banners) corresponds to the declared region.
• The canonical tag rel="canonical" points to itself, not to another locale.
• Recheck in a week — after the CDN cache update, the result has not unexpectedly changed.

Common mistakes during testing

When manually checking hreflang via proxy, marketers often make several recurring mistakes that distort the test results.

First, the check is performed from a logged-in account or with a saved session — in this case, the server may show personalized content rather than what a new visitor would see. Always check in incognito mode or in a clean profile of the anti-detect browser without history.

Second, they forget to clear the DNS and browser cache between switching proxies, causing the old version of the page to continue displaying even though the IP has changed. Use a hard refresh of the page (Ctrl+Shift+R) with each geo switch.

Third, they only test the homepage, ignoring internal sections and product cards — and it is there that hreflang markup often breaks due to dynamic URL generation on the fly.

Fourth, they use the same proxy for all 10 countries, changing only the Accept-Language header — this is not equivalent to real geo-IP and may give false positive results if the server relies on IP rather than browser language.

Conclusion

Checking hreflang by page code provides only half the picture. To understand what a user from a specific country actually receives, you need to emulate their visit through the IP of that country — using proxies, anti-detect browsers, or a simple curl request. This approach uncovers problems that cannot be found in a static audit: geo-IP redirects, CDN caching without considering the region, discrepancies in language codes, and broken self-referencing tags.

If you regularly test multilingual sites or prepare advertising campaigns for 10 or more countries, we recommend trying residential proxies — they provide the most accurate emulation of a real visitor for each target country and allow you to check hreflang as it would be seen by a live user, not a search bot.