A typical scenario: a Shopify shop sells in 12 countries, each with its own subdomain, translated catalog, local currency and local payment gateway. The team hands out 12 different links to partners and creators — one per country. One partner mixes them up, another puts the Mexican link in a German blog, a third just shares en.shop.com everywhere. As a result, some visitors land in the wrong region, and conversion in those visits is noticeably lower.

The fix is one rule: give partners one link and let the server decide where to send each visitor. That is a geo-redirect. Easy from the outside, with a few traps under the hood: VPN, country-language mismatches, SEO consequences. This piece — how to do it without the pain.

TL;DR

A country-level geo-redirect on a good IP database rarely gets it wrong. The language from the Accept-Language header helps with edge cases. VPN confuses geo — do not force those visitors anywhere, let them pick a country on your site. SEO needs canonical + hreflang, and a search crawler must never be shown something other than what people see. For most teams, a geo-redirect plus a visible “wrong region?” line on the landing page is enough.

How accurate is IP-based country detection?

Commercial IP databases (MaxMind GeoIP2, IP2Location, ipinfo, SypexGeo) paint roughly the same picture:

  • Country: errors are rare. Good enough for a commercial redirect.
  • Region (state): already noticeably worse. Online stores use it for tax and shipping; for a redirect it is usually overkill.
  • City: misses are common, sometimes by tens of kilometres or into the next town. City-level redirects are almost always a bad idea.

Where the country-level errors come from. The main source is mobile networks and providers with infrastructure in several countries: an address can be registered to a Dutch network while the user is physically in Moscow. Such cases are few, but they exist.

Takeaway: country-level redirects are safe. City-level — only with a language fallback.

Language: when IP is not enough

Sometimes the IP says one country but the user speaks a different language. Switzerland has four national languages: the IP says “CH”, and the Accept-Language header tells you which language to greet them in. Real examples:

  • a German on a business trip in Italy (IP=IT, Accept-Language=de-DE);
  • a Russian speaker in Germany (IP=DE, Accept-Language=ru-RU);
  • an English-speaking expat in Japan (IP=JP, Accept-Language=en-US).

The rule we recommend: geo decides currency and payment, language decides the interface. The Swiss user sees Swiss prices and Swiss payment options, but the interface in their own language.

The Accept-Language header is often multi-part: 

Accept-Language: de-DE, de;q=0.9, en;q=0.7, *;q=0.5

The user prefers German, then English. Parse it by weight (the q parameter). On your own server that is ten lines of code; in TDS.SO it is the “Language” condition in a rule.

VPN: the traffic that breaks geo

A noticeable share of visitors to commercial sites use a VPN: more on privacy-focused products and media, fewer on marketplaces. These people see geo that is not theirs. What to do:

  1. Do not block without a reason. The temptation to “cut off VPN traffic” comes up regularly, but real people who just value their privacy go along with the bots. Especially painful on B2B audiences.
  2. Do not force a redirect to the “detected” country. Instead, show a line at the top of your site: “In the Netherlands? Pick another country”. The person confirms or changes the choice themselves.
  3. Remember the choice in a cookie for a year. Do not re-trigger the geo-redirect when the cookie already states a preference.

Good IP databases flag VPN addresses (is_proxy, type=hosting). Use that flag as a signal “geo is unreliable, ask the user”, not as a reason to refuse.

Advice

A hard geo-redirect with no confirmation line hurts expats and business travellers the most: the user is used to the US version, and from London gets bounced to the UK one — they assume they ended up in the wrong place. A country selector line at the top of the page takes a day to build.

SEO: canonical and hreflang

Search engines are wary of a URL that shows different things to different visitors, and serving search engines different content — showing the crawler something other than what people see — can get a site removed from results. To make regional versions look legitimate, two technical pieces matter:

  1. Canonical URL. Each localized version declares itself: <link rel="canonical" href="https://es.shop.com/promo">. Google understands that the Spanish landing is a real separate page, not a duplicate.
  2. hreflang. Each version lists all the others: 
    <link rel="alternate" hreflang="es-ES" href="https://es.shop.com/promo">
<link rel="alternate" hreflang="es-MX" href="https://mx.shop.com/promo">
<link rel="alternate" hreflang="en" href="https://en.shop.com/promo">
<link rel="alternate" hreflang="x-default" href="https://en.shop.com/promo">
    Googlebot follows the links and understands the relationship. Without it, your regional versions compete with each other in search results.

Googlebot itself is a separate story: it usually arrives from US IPs, and if you redirect it to en.shop.com, it will only index the English version. So search crawlers do not get a geo-redirect: the crawler should see each regional page at its own address — exactly the page people see.

Keep this in mind with TDS.SO: the antibot counts search crawlers as bots, so they go to the default page for non-target traffic, not through your geo rules. That is why a TDS.SO link should not be the address you promote in search. Search results should list the regional pages themselves, with canonical and hreflang; hand the link to partners and use it in ads and newsletters.

When you do not need a geo-redirect at all

Geo-redirect is optional. Cases where it adds noise:

  • Single-country shop. If you only sell in the US — extra logic for nothing.
  • Content site without localization. Single-language blog, no regional versions. The visitor's browser figures it out.
  • B2B SaaS with one global interface. One English landing for the world, one currency (USD), nowhere to redirect to.
  • Landing tied to one ad campaign. If the ad network settings already target a specific country, visitors are already arriving from the right region.

What this looks like in TDS.SO

A geo-redirect in TDS.SO is a set of distribution rules on a link or a template: “if country = X, send to address Y”. A visitor who matches no rule goes to the link's main address.

For VPN traffic the rules have a “Proxy / VPN” condition: you can add a separate rule and send those visitors to, say, a country selection page on your own site. TDS.SO does not show a selection page itself — you build it. Whether to block VPN, proxies and Tor outright is a separate filter setting; when it is on, those visits go to the default page for non-target traffic. The stats for every click show the detected country and city, the proxy flag and where the visitor was sent.

Conclusion

Geo-redirect is simple when done right. Three rules:

  1. Redirect by country, not by city.
  2. Do not block VPN traffic without a reason or force it anywhere — let people pick a country on your site.
  3. Do not geo-redirect search crawlers, and tag your pages with canonical + hreflang.

Two or three markets and one currency? Skip the geo-redirect entirely. Twelve countries with local payments? Without one, life gets hard. Especially if you also need to route by device and source — in that case look at a full smart-link, where geo is one of six signals.