Geolocation Redirect on Shopify — Send International Visitors to the Right Store

Blocking visitors from countries you don't serve is sometimes the right call. More often, you'd rather redirect them — to a partner site, a localized store, a "coming soon" page, or an info page that explains why they ended up here.

A redirect preserves brand impression, captures some engagement value, and avoids the support overhead of explaining a hard block.

The catch: redirects are technically tricky in ways most merchants underestimate. Configured wrong, they break analytics, damage SEO, create infinite loops, lose conversion data, and confuse search-engine crawlers. Configured right, they quietly route tens of thousands of visitors per month to the right destination.

When a redirect beats a block

Three patterns specifically favor redirect over hard block:

You have a local destination. You operate multiple stores — .com for the US, .eu for Europe. Routing European visitors to the European store improves their experience (right currency, right shipping, right tax) and increases conversion. The redirect serves the customer, not your blocklist.

You're not selling there yet but might. "Coming soon" pages preserve interest. A visitor from a country you'll eventually expand to gets directed to email-capture, joins your launch list, converts when you enter the market.

Partner or affiliate fulfillment. You have a fulfillment partner in the destination country. The redirect sends them to the partner's site (with attribution parameters) and you book revenue through the partnership.

Compliance with brand consistency. You don't sell to a country for regulatory reasons but want the brand experience to be respectful. A redirect to a clean "we don't currently sell in your region" page reads better than a generic blocking page.

The common thread: redirects work when there's a meaningful destination. Without one, "redirect to nowhere" is just a dressed-up block.

The three redirect types

Different mechanisms, different implications. Know which is which:

Server-side 301 (permanent)

301 Moved Permanently response. Search engines treat this as a permanent move and pass link equity to the new destination over time.

Use when: the destination is the canonical location for this kind of visitor going forward. Don't use for short-term campaign redirects — the SEO consequences last.

Server-side 302 (temporary)

302 Found response. Same mechanism as 301, but search engines understand it as temporary and don't pass link equity. Original URL retains rankings.

Use when: the redirect is conditional and might change. Most geographic redirects fit here — you might serve a different destination next year, or whitelist specific customers, so the redirect is conditional rather than permanent. Server-side 302 is the right default for most geographic redirects.

Client-side (JavaScript) redirect

A JavaScript snippet on your store detects the visitor's country (via IP API or browser locale) and uses window.location to redirect. The visitor's browser briefly loads your page, then navigates away.

Use when: you need detection logic that can't run server-side. Be aware that client-side redirects often confuse search engines and analytics, and fail entirely for visitors with JavaScript disabled.

Five redirect setups that work

Pattern 1: Country → regional store

Visitor from Germany hits .com, gets redirected to .de. Detection runs server-side based on IP geolocation; redirect is 302; destination preserves the path (.com/products/widget → .de/products/widget).

Pattern 2: Country → partner site

Visitor from India hits your store, gets redirected to your fulfillment partner's Indian site with an attribution parameter (?utm_source=mainsite&affiliate=us-brand). Same mechanism, different destination owner. Watch for partner-site quality issues that can hurt your brand perception.

Pattern 3: Country → "coming soon" page

Visitor from a country you'll eventually serve, gets redirected to a branded "coming soon" page with email capture. Builds a launch list. Make sure the page is content-rich enough that bouncing isn't immediate.

Pattern 4: Country → compliance page

Visitor from a country you can't legally serve, gets redirected to a page explaining why and pointing to legal alternatives or contact info. Cleaner UX than a blocking page; legally just as protective.

Pattern 5: City or state → conditional redirect

Visitor from a high-fraud city gets redirected to a "prepaid only" checkout flow rather than the standard checkout. Less common, more sophisticated, useful in COD-heavy markets.

The five pitfalls that trip merchants up

1. Redirect loops

The classic. Visitor from country X gets redirected to a destination that also triggers the country-X redirect rule, sending them back to the origin. Browser detects the loop and shows an error.

Signature: customers from a specific country report they can't reach your store at all.

Fix: Exempt the destination URL from the redirect rule, or use cookies/sessions to track that a redirect has already happened.

2. Search engine crawlers redirected

Google's crawler runs from data centers in specific countries. A geographic redirect can accidentally route the crawler to a destination that doesn't include the content the crawler was trying to index. Over time, your home country's pages lose ranking.

Fix: Detect known crawler user-agents and exempt them from geographic redirects. Shieldy's allowed-bot list handles this automatically when redirects are configured.

3. Analytics attribution broken

A redirect-then-conversion confuses most analytics. The visitor arrives at the destination with a referrer of "your-store.com," not the actual source (Google, Facebook ad). UTM parameters get stripped during the redirect.

Fix: Preserve query parameters through the redirect (most server-side redirects support this with a flag). Configure your analytics to handle the cross-domain case.

4. Cookie / session loss

Customers who started a session on the origin domain and got redirected to a different domain lose their cart, login, and preferences. They arrive at the destination as new visitors, see an empty cart, and bounce.

Fix: Either keep the redirect within the same domain (path-based, not domain-based), or implement cross-domain session sharing (more complex, requires careful security thinking).

5. Mobile-app webviews redirect badly

Mobile apps that embed web content (Instagram, Facebook, TikTok) sometimes handle redirects oddly. The browser opens externally; user-agent looks like a mobile browser but session context is broken.

Fix: Detect known in-app browser user-agents and either skip the redirect or handle them with a specific flow that preserves attribution.

Setting up a redirect in Shieldy

Five-step setup that avoids most problems:

1. Define trigger and destination. "Visitors from {country list} get redirected to {URL}, except for {exception list}." Write it out explicitly before configuring.
2. Exempt crawlers. Enable Shieldy's "Allowed bot list" before configuring redirects. Google, Bing, Facebook, LinkedIn, and major SEO tools reach the origin regardless of geographic detection.
3. Configure the destination to break loops. If the destination serves traffic from the original countries, add explicit handling so the redirect doesn't fire from there.
4. Preserve query parameters. Shieldy's redirect rules pass the path and query string through by default — verify in your test before going live.
5. Test from multiple realistic conditions. From a VPN to the target country, from a real mobile device, from a search-engine indexing tool, from your own browser.

Tracking the right things

Three metrics tell you if the redirect actually worked:

Redirect rate. Out of all visits from source countries, what percentage actually got redirected? Below 100% suggests detection issues.

Destination conversion rate. Among visitors who arrived at the destination via redirect, what conversion rate do they show? If dramatically lower than direct destination traffic, the redirect is degrading the user experience.

Origin bounce rate from source countries. For visits from source countries that *didn't* get redirected (because of opt-outs, cookie issues, or failed detection), what's the bounce rate? High bounce suggests these visitors needed the redirect and didn't get it.

Track these three weekly. Most redirect problems surface within a few weeks.

The takeaway

Geographic redirects are a UX choice, not a fraud-prevention choice. Use them when you have a real destination for the redirected visitor. Don't use them as a polite-looking block when what you actually need is a block.

Shieldy Fraud Filter supports redirect rules at country, state, city, and IP level. Configuration is a few hours; maintenance is occasional rule review.

Most stores in international ecommerce should have at least one redirect rule. Many should have several.