localization.country is not geolocation (and most Shopify country-blocking snippets are broken)

Search for how to block a country on Shopify and you will find the same snippet reproduced across a dozen blogs, each one confidently telling you to paste it into theme.liquid. It looks like this, give or take a variable name:

1{% assign blocked = "CN,RU,VN" | split: "," %}2 3{% if blocked contains localization.country.iso_code %}4  <script>window.location.href = "/pages/unavailable";</script>5{% endif %}

It is syntactically valid Liquid. It will render without errors. And it does not do what the article says it does, because localization.country is not the visitor's location. It is a value the visitor chooses.

What localization.country actually is

The localization object exists to power the market and currency switcher in your theme. Its four properties are all about what the shopper has chosen to browse as:

Shopify does seed the initial selection sensibly, which is exactly why the bug survives review. A first-time visitor from Berlin often does land on the German market, so the developer tests the snippet, sees the right country, and ships it. The property was never a location signal, though. It was a preference that happened to start with a reasonable default.

Three ways the snippet fails

The gap between "selected" and "detected" is not academic. It shows up as three distinct failures, in increasing order of how much they will cost you.

1. Anyone can switch it, in one click

The country picker is a control you put in your own header. A visitor in a blocked country opens it, picks a different country, and the gate opens. No VPN, no dev tools, no technical knowledge. The person you were most trying to stop is the person most motivated to click the dropdown.

2. The redirect runs after the page is delivered

Look again at what the snippet emits: a <script> tag that sets location.href. By the time that executes, the full page is already in the browser. Anyone with JavaScript disabled sees everything. Anyone running curl sees everything. Every scraper on earth sees everything, since scrapers are precisely the clients that do not execute your JavaScript. As access control it is a redirect for people who were not trying.

3. It poisons the CDN cache

This is the one that actually breaks stores, and almost nobody mentions it. Shopify renders Liquid once and caches the HTML at the edge for many visitors. If your template emits different markup depending on a per-visitor value, you have made the cached copy visitor-specific. A shopper in an allowed country can be served the cached page that contains the block redirect, and a blocked visitor can be served the cached page that does not.

What localization.country is genuinely good for

Do not conclude the property is useless. It is the correct tool for everything downstream of the shopper's own choice, which is a large and useful category:

• Rendering the country picker itself. Loop localization.available_countries and mark the current one. That is the property's whole purpose.
• Market-specific content. Different size guides, shipping copy, or compliance text per market, once the shopper is in that market.
• Flags. Passing a country object to image_url returns a CDN URL for that country's flag, normalised to 4:3.

1{{ localization.country | image_url: width: 32 | image_tag }}2 3{% for country in localization.available_countries %}4  {{ country.name }} ({{ country.iso_code }}) {{ country.currency.iso_code }}5{% endfor %}

The distinction to hold onto: localization tells you which storefront experience the shopper is in. It never tells you where their connection came from.

Detecting country correctly, by requirement

There is no single replacement, because "block a country" means four different things depending on who is asking. Pick the row that matches yours.

The first two rows cover most real merchant intent and cost nothing. If someone says "block Russia," they usually mean "stop accepting Russian orders," and Markets does that natively, at checkout, deterministically, with no code and no cache implications. Reach for it before anything else. Our step-by-step guide to blocking a country on Shopify walks through both native routes with the exact admin paths.

The fourth row is the genuinely hard one, and it is hard for the reason the whole post has been circling: on a Shopify-hosted storefront you cannot sit in front of the request. Cloudflare's proxy is explicitly unsupported on Shopify domains, Liquid renders too late and too cached, and client-side JS runs after delivery. What is left is a fast decision service reached from an app embed, which is what every blocking app on the App Store is underneath.

Country blocking that uses real geolocation

Cordon is built on that architecture, and it is a useful reference point because it does the thing the broken snippet only pretends to: the country comes from a geo-IP lookup on the actual connection, not from a dropdown the visitor controls. That single difference resolves all three failures above at once. There is nothing to switch, the decision happens before the page is usable rather than after, and it never branches the cached Liquid render.

What it gives you beyond the country list itself:

• 200+ countries, one click each, with a flag picker and presets for common cases like blocking China or turning on anti-scraper mode.
• The bypass path closed. Blocking a country is close to meaningless if a visitor can install a VPN and walk around it, so live VPN, residential-proxy and Tor-exit detection is the half that actually makes a country rule hold.
• Finer targeting than a country. Individual IPs, CIDR ranges, whole ASNs, and datacenter networks, for when the real pattern is one network rather than one nation.
• A customisable block screen. A branded explanation beats a broken page, and a redirect target is available if you would rather send blocked visitors somewhere specific.
• A visitor log that shows the reasoning. Country, network, and the exact rule that fired, which is what you need when a merchant asks why a particular customer was stopped. IPs are SHA-256 hashed with a daily-rotating salt, so the log is useful without becoming a GDPR liability.

Country blocking and IP rules are on the free plan, so you can verify the behaviour on a real store before paying anything; live VPN and proxy detection starts at Growth. For the merchant-side click-through there is a step-by-step guide to blocking a country on Shopify, and a guide to geo-restricting a store to specific countries if your requirement is an allowlist rather than a blocklist.

Whatever you choose, the thing worth carrying to the next problem is the habit: before you branch on a value, check the docs for who controls it. localization.country reads like a fact about the visitor and is actually a preference they set. Shopify's object model is full of properties that are one word away from meaning something entirely different, and the docs are always faster than the debugging.