Geo-Redirects for International SEO

TL;DR — A geo-redirect automatically sends a visitor to a different version of your site — a /de/ page, a German domain, a subdomain — based on a guess about where they are or what language they speak (usually their IP address or browser language). It feels helpful, but it’s one of the most common ways international sites accidentally hide their own pages from Google. The safer move is to suggest the local version with a banner or a link, not to force it.

What a geo-redirect is

Say you have an English site and a German site. A geo-redirect is a rule that says: “if this visitor looks like they’re in Germany (or their browser is set to German), send them to the German version automatically.” The visitor never asks for it — the server or a script decides for them, based on:

• their IP address (which roughly maps to a country),
• their browser’s Accept-Language setting, or
• a cookie that remembers a previous choice.

On the surface that’s a nice touch. The problem is what it does to search engines.

Why this is risky for SEO

Google’s crawler, Googlebot, is the thing that finds and reads your pages so they can show up in search. And here’s the catch that trips up so many international sites: Googlebot mostly crawls from IP addresses in the United States, and it doesn’t send a language preference.

So if your homepage automatically redirects “US-looking” visitors to the English version, Googlebot — which looks like it’s in the US — gets sent to the English version too, every time. It may never follow a path to your German, French, or Japanese pages on its own. If Google can’t reach those pages, it can’t index them, and they can’t rank. You built the German site, but you quietly walled it off from the one visitor who decides whether anyone finds it.

The thing people get backwards

There’s a related tag called hreflang that tells search engines “here are the other language/country versions of this page.” A lot of people assume hreflang “fixes” whatever a geo-redirect breaks. It’s the other way around: hreflang can’t help a page the crawler was never allowed to reach. The redirect can stop Google from ever seeing the hreflang tags in the first place. (There’s a whole primer on hreflang on this site if you want the mechanics.)

What to do instead

Google’s own advice is short and clear: don’t force it, suggest it. Instead of redirecting automatically:

• Show a small banner (“Looks like you’re in Germany — view the German site?”) that the visitor can click or ignore.
• Put links to every language version on the page so both people and crawlers can reach them. Evidence for this claim Google recommends avoiding automatic language redirects and providing hyperlinks that let users and crawlers reach each language version. Scope: Google Search guidance for language switching and discovery. Confidence: high · Verified: 2026-07-14 Google: Let users switch language
• Add hreflang so search engines can figure out and serve the right version on their own.

That way a real person still gets nudged toward their language, but Google can still crawl and index every version. Want the deeper version — why 302 vs 301 matters, the one narrow exception where a redirect is okay, and the data on how often this breaks? Switch to the Advanced tab.

Troubleshooting geo-redirect failures

Alternate locales are absent from the crawl

Symptom: the crawler repeatedly lands on the default locale. Likely cause: IP, cookie, or Accept-Language routing forces requests away from direct locale URLs. Fix: make each locale URL return directly and replace forced routing with a visible suggestion.

Hreflang targets return redirects

Symptom: annotations point to 3xx responses rather than final pages. Likely cause: routing or URL normalization changed without regenerating the locale map. Fix: update hreflang to direct canonical 200 destinations and retest every cluster member.

Users cannot switch back after a redirect

Symptom: selecting another locale immediately sends the visitor to the assumed market. Likely cause: IP logic overrides explicit user choice. Fix: let the chosen locale win, provide persistent crawlable switcher links, and reserve any cookie for remembering—not forcing—the choice.

Bots and equivalent users receive different content

Symptom: the same request path and locale context produce bot-specific routing. Likely cause: a crawler exception was added to work around discovery problems. Fix: remove bot-only behavior and solve access for all equivalent requests; bot exceptions create a separate cloaking risk.

Test geo-routing behavior yourself

Compare the default request with language preferences

Pass a representative locale entry point as the first argument. This tests header-dependent routing; it does not simulate another IP location.

url="${1:?Pass a representative entry URL as the first argument}"
for language in "" "en-US,en;q=0.9" "fr-FR,fr;q=0.9"; do
  echo "Accept-Language: ${language:-<none>}"
  curl -sS -o /dev/null -D - ${language:+-H "Accept-Language: $language"} "$url" \
    | grep -Ei '^(HTTP/|location:|vary:|set-cookie:)'
done

Check that declared locale targets resolve directly

Put one expected locale URL per line in locale-urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code}\t%{redirect_url}\t%{url_effective}\n' "$url"
done < locale-urls.txt

A healthy target normally reports 200 with an empty redirect destination. Review intentional exceptions rather than following redirects and hiding them.

Validate a geo-redirect change

Direct locale access

Test to run: Request representative locale URLs without cookies and without following redirects. Expected result: Each intended locale returns its own direct 200 response. Failure interpretation: Routing is overriding an explicit URL and can block discovery. Monitoring window: Immediately after deployment and through the next scheduled crawl. Rollback trigger: Any priority locale becomes unreachable without a redirect chain.

Request-header matrix

Test to run: Compare the same entry URL with no Accept-Language header and with supported language preferences. Expected result: Content remains accessible and any locale recommendation does not prevent navigation to another version. Failure interpretation: Header-based logic is forcing a locale or trapping user choice. Monitoring window: During release verification and for the first full traffic cycle. Rollback trigger: Requests are redirected away from an explicitly chosen locale.

Hreflang target response

Test to run: Extract hreflang targets from representative clusters and request each without following redirects. Expected result: Every annotation resolves directly to an indexable canonical 200 URL. Failure interpretation: The locale map is stale or routing contradicts hreflang. Monitoring window: After the release and again after the next sitemap or template generation. Rollback trigger: A material cluster points to redirected, blocked, or erroring targets.

Equivalent-request parity

Test to run: Compare ordinary and crawler user agents under otherwise equivalent request conditions. Expected result: Status, destination, and substantive content are equivalent. Failure interpretation: Bot-specific handling may be masking access problems and creating cloaking risk. Monitoring window: Every routing release and quarterly thereafter. Rollback trigger: Bot-only exceptions change the destination or content for equivalent requests.

TL;DR — Geo-redirects and hreflang operate at different layers: a geo-redirect is a serving decision, hreflang is a discovery signal. The core failure is a discovery problem, not just an indexing one — Googlebot mostly crawls from US IPs and sends no Accept-Language, so a redirect on your entry point can stop it from ever reaching (and thus discovering) the alternate URLs your hreflang points at. hreflang can’t rescue a URL the crawler never sees. Cloaking is a separate risk: even a fully compliant, non-cloaking redirect still causes the discovery problem. Google’s prescription is “suggest, don’t force” (a banner/links + hreflang). The one narrow exception is a homepage-only 302 for dynamic locale suggestion — but in my study of 374,756 domains, 16.9% had hreflang pointing at redirected or broken pages, which is exactly this exception going wrong.

Two mechanisms, two different layers

Almost every geo-redirect mistake comes from conflating two things that live at different layers of the stack:

• A geo-redirect is a serving decision: what do I show this specific visitor, right now, based on what I think I know about them?
• hreflang is a discovery/annotation signal: what alternate URLs exist for this content, so a search engine can find them and swap in the right one in its own results?

They don’t substitute for each other. A geo-redirect changes what one visitor sees; hreflang tells search engines the alternates exist so they can serve the right one at query time without anyone forcing anything at serving time. If you internalize one thing from this article, make it this distinction — most breakage flows from treating a redirect as if it were a discovery signal.

The core mechanical failure: discovery, not just indexing

Here’s the part most competing content gets slightly wrong. It frames the risk as “your other pages won’t get indexed.” The sharper, more accurate framing is that your other pages may never get crawled — never even discovered — in the first place.

Google is explicit about the cause. Its locale-adaptive pages doc says that if your site returns different content based on the perceived country or preferred language of the visitor, “Google might not crawl, index, or rank all your content for different locales.” Why? Because Googlebot’s default IPs appear to be in the USA, and the crawler sends HTTP requests without setting Accept-Language.

Now trace that through a typical setup. Your redirect logic fires on IP and/or Accept-Language, and it fires at the entry point — very often the homepage or root domain, which is exactly the page that carries (or links to) your hreflang annotations. Googlebot arrives looking like a US visitor with no language preference, gets redirected to the US/default version, and stops. The only crawlable path to your /de/ tree was gated behind that redirect. So:

1. Googlebot never reaches the alternate-locale URLs.
2. It therefore never discovers the hreflang annotations that would have told it those URLs exist.
3. hreflang tags on a page Googlebot can’t reach do nothing.

hreflang assumes crawl access. It doesn’t create it. That’s the whole trap in one line.

Geo-redirects vs. cloaking: two separate risks

There’s a second risk here that people constantly merge with the first, and the merge produces bad advice. Treating Googlebot differently from a real user in the same location — say, special-casing the Googlebot user-agent so it skips the redirect and sees everything — is cloaking, and it’s a guidelines violation. Google’s guidance on geo-distributed crawling is a consistency rule: Googlebot does crawl from some non-US IP addresses in addition to US ones, and when it appears to come from a given country you should treat it exactly like any other visitor from that country (block US Googlebot if you block US users; allow Australian Googlebot if you allow Australian users).

Here’s the part worth its own subsection: not cloaking does not rescue you from the discovery problem. A lot of writing says “as long as you don’t cloak Googlebot, geo-redirects are fine.” That’s incomplete. A fully compliant geo-redirect — where the bot and a same-location user get identical treatment — still traps Googlebot on the default version if that’s where a US-looking request lands. You’ve avoided a cloaking penalty and still starved your other locales of crawl access. Two separate problems; solving one doesn’t solve the other.

And don’t over-read the geo-distributed crawling nuance as a fix. It’s a cloaking-consistency requirement, not a promise that Google will reliably discover every locale by simulating every region. Google’s current doc still leads with “Googlebot’s default IPs appear to be US-based” as the reason this breaks — because that’s still the reason.

What Google officially recommends: suggest, don’t force

Google’s prescription isn’t “redirect more carefully.” It’s “don’t redirect — suggest.” Two lines from the multi-regional sites doc are the spine of the fix:

“Avoid automatically redirecting users from one language version of a site to a different language version of a site.” — Google Search Central

“Consider adding hyperlinks to other language versions of a page. That way users can click to choose a different language version of the page.” — Google Search Central

And on IP detection specifically, Google doesn’t mince words:

“Don’t use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly. Most, but not all, Google crawls originate from the US, and we don’t attempt to vary the location to detect site variations.” — Google Search Central

Because targeting is never perfect, Google also tells you to plan for the wrong-version visitor: “geotargeting isn’t an exact science, so it’s important to consider users who land on the ‘wrong’ version of your site. One way to do this could be to show links on all pages for users to select their region and/or language of choice.” That’s the banner/link-list pattern, straight from the source.

What Bing recommends — and why it’s arguably higher-stakes there

Bing doesn’t have a hreflang-equivalent to sabotage, so you might think it’s less exposed. It’s the opposite. Bing leans on actually crawling the real localized URLs and on the content-language meta tag/HTTP header rather than a declarative hreflang annotation. Fabrice Canel of Microsoft Bing has said hreflang is a far weaker signal than content-language at Bing (a point I dig into in the hreflang deep dive on this site). The practical consequence: a geo-redirect that Bingbot can’t get past is at least as damaging to Bing visibility as it is to Google’s — arguably more, because Bing depends on reaching and reading those localized URLs directly, not on an annotation that could in theory be discovered elsewhere.

The data: how often this actually breaks

I don’t have to argue this hypothetically. For my Brighton SEO 2023 talk, I studied hreflang across 374,756 domains (full writeup on the Ahrefs blog). My blunt takeaway on this exact topic: automated redirects based on cookies, IP, or browser language are generally a bad idea. The numbers back it:

• 16.9% of domains had hreflang tags referencing redirected or broken pages — this is essentially a direct measurement of how often sites’ redirect setups collide with their own hreflang.
• 67% of the hreflang-using domains in the study had at least one issue overall.
• 56.3% were missing x-default — the hreflang value designed around the “which version does an unmatched visitor see” problem (there’s a dedicated x-default article on this site).

As I put it in the writeup: “Hreflang is complex and hard to get right. It can break in so many different ways.” A geo-redirect is one of the most reliable ways to make it break.

The one narrow exception: a homepage-only 302

There is a defensible pattern, and it’s narrow. A 302 (temporary) redirect on the homepage only, doing dynamic locale suggestion based on location/language, has been a workable, long-used setup on many sites. The reason it’s a 302, not a 301: the “correct” destination is visitor-dependent — it changes per person, per session — so it’s not a single permanent target. A 301 declares one permanent destination, which isn’t what’s happening here. (This is industry practice — mine and Ahrefs’ framing — not a status-code recommendation Google publishes for geo-redirects specifically.)

But the moment a redirected URL shows up as a target inside your hreflang annotations elsewhere on the site, that’s a bug, not a feature — every hreflang target should resolve 200 directly, not 3xx. That 16.9% figure above is largely this exception going wrong: sites running the homepage-302 pattern (or worse, sitewide redirects) and then pointing hreflang at pages that redirect.

What to do instead of a hard redirect

Put together, the fix is a handful of moving parts:

• Suggest, don’t force. A visible, dismissible banner/interstitial (“View the German site?”) that the visitor can accept or ignore. This is Google’s recommended alternative to an automatic redirect.
• Keep every localized URL directly crawlable and linkable. Real <a href> links to each version — a language/country switcher in the footer or header — so crawlers reach every locale without being redirected away first. (A switcher on its own isn’t a fix if the redirect still fires before the crawler can load the page.)
• Pair it with correct, reciprocal hreflang so search engines can determine and serve the right version in results on their own. Every hreflang target resolves 200.
• Use x-default for the “no explicit match” case on a language-selector or auto-suggesting homepage — it names what to show a visitor who matches none of your tags. It solves the serving question for unmatched visitors; it does not solve the crawl-access problem, so don’t lean on it as a rescue.

The related fundamentals here — the language vs. country targeting distinction, the ccTLD / subdomain / subdirectory URL-structure choice, reciprocal hreflang, and x-default — all sit in this same international-SEO cluster and are worth reading alongside this. The short version: fix the crawl path first, then let hreflang and x-default do the serving.

AI summary

A condensed take on the Advanced version:

• A geo-redirect automatically sends a visitor to a location-/language-specific URL based on IP, Accept-Language, or a cookie. It’s a serving mechanism; hreflang is a separate discovery signal. They don’t replace each other.
• The core failure is discovery, not just indexing. Googlebot mostly crawls from US IPs and sends no Accept-Language. A redirect on the entry point (usually the homepage) can trap the crawler on the default version, so it never reaches — and never discovers — the alternate-locale URLs your hreflang points at. hreflang can’t rescue a URL the crawler never sees.
• Cloaking is a separate risk. Treating Googlebot differently from a same-location user is a violation. But even a fully compliant, non-cloaking redirect still causes the discovery problem — not cloaking doesn’t save you.
• Geo-distributed crawling is a consistency rule, not a discovery guarantee. Google crawls from some non-US IPs too, but that’s about not cloaking, not a promise to find every locale.
• Google’s prescription: “Avoid automatically redirecting” + “Consider adding hyperlinks to other language versions” — i.e., suggest with a banner/links, don’t force, and pair with hreflang. Google also calls IP analysis “difficult and generally not reliable.”
• Bing is arguably higher-stakes: it leans on crawling real localized URLs and the content-language signal rather than hreflang, so a redirect Bingbot can’t escape hurts at least as much.
• The data: in my study of 374,756 domains, 16.9% had hreflang pointing at redirected or broken pages; 67% had at least one hreflang issue; 56.3% were missing x-default. My take: automated redirects based on cookies, IP, or browser language are generally a bad idea.
• The one narrow exception: a homepage-only 302 for dynamic locale suggestion (302, not 301, because the destination is visitor-dependent). But no redirected URL should ever be a hreflang target.

Official documentation

Primary-source documentation on redirects, locale-adaptive serving, and geotargeting.

Google

• Managing Multi-Regional and Multilingual Sites — the “avoid automatically redirecting,” “add hyperlinks to other language versions,” and “don’t use IP analysis to adapt your content” guidance, plus the geotargeting section.
• How Google Crawls Locale-Adaptive Pages — why Googlebot’s US-based default IPs and missing Accept-Language header mean locale-adaptive content may not be fully crawled/indexed, the recommendation to use separate locale URLs with rel="alternate" hreflang, and the geo-distributed crawling (cloaking-consistency) rule.
• Localized versions of your pages — hreflang implementation reference: HTML tags, HTTP headers, sitemap entries, and reciprocity requirements.
• Crawling and indexing of locale-adaptive pages (Search Central Blog, Jan 2015) — the same core message, showing Google has said this consistently for a decade.

Bing / Microsoft

• Going international: considerations for your global website (Bing Webmaster Blog, Feb 2009) — the long-standing warning that cookie- and JavaScript-based locale switching (with no navigational path and no URL change) hides non-default content from crawlers, since crawlers don’t keep cookies or execute the switcher.
• Bing Webmaster Guidelines — Bing’s signal stack, including its preference for content-language over hreflang.

Quotes from the source

On-the-record statements from Google, plus my own take. Each Google link is a deep link that jumps to the quoted passage on the source page.

Google — don’t force redirects; suggest instead

• “Avoid automatically redirecting users from one language version of a site to a different language version of a site.” — Google Search Central docs. Jump to quote
• “Consider adding hyperlinks to other language versions of a page. That way users can click to choose a different language version of the page.” Jump to quote
• “Remember that geotargeting isn’t an exact science, so it’s important to consider users who land on the ‘wrong’ version of your site. One way to do this could be to show links on all pages for users to select their region and/or language of choice.” Jump to quote

Google — IP analysis is unreliable

• “Don’t use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly. Most, but not all, Google crawls originate from the US, and we don’t attempt to vary the location to detect site variations.” Jump to quote

Google — locale-adaptive crawling (the discovery problem)

• “If your site has locale-adaptive pages (that is, your site returns different content based on the perceived country or preferred language of the visitor), Google might not crawl, index, or rank all your content for different locales.” Jump to quote
• “We recommend using separate locale URL configurations and annotating them with rel=“alternate” hreflang annotations.” Jump to quote
• “Googlebot crawls with IP addresses based outside the USA, in addition to the US-based IP addresses.” — the geo-distributed crawling caveat, which is a cloaking-consistency rule, not a discovery guarantee. Jump to quote

Me, on the pattern

• “Automated redirects based on cookies, IP, or browser language are generally a bad idea.” — my Brighton SEO 2023 hreflang study of 374,756 domains (deck, Ahrefs writeup).
• “Hreflang is complex and hard to get right. It can break in so many different ways.” — the Ahrefs writeup of that study.

Should I geo-redirect — and if so, how?

Most “should I geo-redirect?” questions collapse to one thing: can crawlers still reach every locale on their own? Click through it.

Geo-redirect myths and mistakes to avoid

Each of these is a common belief that’s wrong (or dangerously incomplete), with what to do instead.

• “As long as I don’t cloak Googlebot, geo-redirects are totally safe for SEO.” Why it’s wrong: Not cloaking only avoids a penalty. A fully compliant, non-cloaking redirect still traps the crawler on the default locale if that’s where a US-looking request lands, so your other locales never get crawled or discovered. Do instead: Treat crawl access as a separate problem from cloaking — keep every locale reachable by a real link, redirect or not.

• “hreflang fixes whatever my geo-redirect breaks.” Why it’s wrong: Backwards. hreflang assumes crawl access; it can’t do anything for a URL the crawler was never allowed to reach. If the redirect stops Google from loading the page that carries the hreflang tags, the tags are never even discovered. Do instead: Ensure crawlers can reach every locale first, then let hreflang handle version-swapping in results.

• “Google crawls from every country now, so the old ‘Googlebot only sees the US version’ problem is solved.” Why it’s wrong: Overstated. Google does crawl from some non-US IPs, but its own docs frame that as a cloaking-consistency requirement — not a guarantee it will discover every locale. The current guidance still leads with “Googlebot’s default IPs appear to be US-based” as the reason this breaks. Do instead: Don’t rely on geo-distributed crawling to find your locales for you; give every locale an explicit, crawlable path.

• “A 301 is always the most SEO-friendly redirect, so use it for geo-redirects too.” Why it’s wrong: For a dynamic homepage locale suggestion, the “correct” destination is visitor-dependent, not a single permanent target — a 301 misrepresents that as permanent. Do instead: Use a 302 for the narrow homepage-only dynamic pattern (industry practice — mine and Ahrefs’).

• “IP geolocation is accurate enough to safely gate content on.” Why it’s wrong: Google’s own docs call IP location analysis “difficult and generally not reliable.” VPNs, mobile carrier IP pooling, corporate proxies, and IPv6 allocation all degrade it — before you even get to the crawler-specific problems. Do instead: Don’t hard-gate content on inferred location; suggest, and let the user override.

• “If I add a language/country switcher, the redirect can stay.” Why it’s wrong: A switcher is a UI element on a rendered page the crawler still has to be able to load — if the redirect fires first and bounces the bot away, the switcher never gets a chance to help. Do instead: Keep the switcher and make sure the redirect doesn’t block crawlers from reaching alternate URLs on their own path.

• “Bing doesn’t care about this since it doesn’t use hreflang.” Why it’s wrong: Bing cares arguably more. It leans on crawling the real localized content and the content-language signal rather than a declarative annotation, so a redirect Bingbot can’t escape is at least as damaging to Bing visibility. Do instead: Treat Bingbot’s crawl access to every locale as at least as important as Googlebot’s.

Geo-redirect audit checklist

A quick pass to confirm your location-based serving isn’t quietly hiding your locales from search engines:

• Every localized URL is reachable by a real <a href> link (footer/header switcher), not only via the redirect.
• The redirect, if any, is homepage-only — it does not fire on deep pages.
• Any dynamic locale-suggestion redirect uses a 302, not a 301.
• No hreflang target is a 3xx — every hreflang URL resolves 200 directly. (In my study, 16.9% of domains got this wrong.)
• hreflang is reciprocal — every version links back to the others, including x-default where appropriate.
• Googlebot/Bingbot is treated exactly like a same-location user — no user-agent- or IP-based bypass for the crawler (that’s cloaking).
• You prefer a dismissible banner/interstitial over a hard redirect wherever possible (“View the German site?” that the visitor can ignore).
• You’re not gating content on IP alone — you offer an easy manual override.
• Content is not switched by cookie or client-side JavaScript without a URL change (crawlers don’t keep cookies and won’t reliably reach JS-only locale content).
• You’ve spot-checked crawl access by requesting your non-default locales from a US IP / with no Accept-Language (e.g. curl -IL) to confirm a crawler wouldn’t be redirected away.

Resources worth your time

My related writing & speaking

• Over 67% of Domains Using Hreflang Have Issues (Study of 374,756 Domains) (Ahrefs) — my large-scale hreflang study; the source of the 16.9% redirected/broken-hreflang stat and the “automated redirects are generally a bad idea” take, plus the homepage-only 302 exception.
• The most common hreflang issues across 374,756 domains (Speaker Deck) — the Brighton SEO 2023 slides. Talk listing · video.
• Hreflang: The Easy Guide for Beginners (Ahrefs) — the mechanics of hreflang, reciprocity, and x-default that a geo-redirect can undermine.
• International SEO: The Weird Technical Parts (Pubcon Vegas 2019) and You’re Going To Screw Up International SEO (Pubcon Vegas 2017) — older but consistent background on where international setups (including geo-redirects) go wrong.

From around the industry

• Managing Multi-Regional and Multilingual Sites (Google Search Central) — the primary source for “avoid automatically redirecting,” “add hyperlinks to other language versions,” and “don’t use IP analysis to adapt your content.”
• How Google Crawls Locale-Adaptive Pages (Google Search Central) — the US-based-IP / no-Accept-Language explanation and the geo-distributed crawling caveat.
• Google On The Main Thing To Know About Geo IP Redirects (Search Engine Journal) — coverage of John Mueller’s Ask Googlebot answer (Oct 2022): Googlebot indexes essentially one version, so keep anything important in the default content.
• Google Says Geolocation Redirects Are Okay (Search Engine Roundtable) — Mueller’s “allowed if you don’t treat Googlebot differently than a user” framing (the cloaking condition).
• Bing Says Hreflang A Weak Signal For Its Search Engine (Search Engine Roundtable) — Fabrice Canel of Microsoft Bing on hreflang being weaker than content-language, which is why crawl access to real localized URLs matters more on Bing.
• Going international: considerations for your global website (Bing Webmaster Blog) — the long-standing warning about cookie- and JavaScript-based locale switching hiding content from crawlers.

Test yourself: Geo-Redirects for International SEO

Five quick questions on why geo-redirects break international SEO and what to do instead. Pick an answer for each, then check.

Geo-Redirect

A geo-redirect automatically sends a visitor to a location- or language-specific URL based on IP or browser signals — a UX/serving mechanism that's separate from, and can actively undermine, hreflang.

Related: Hreflang, Geotargeting, 302 redirect, ccTLD

Geo-Redirect

A geo-redirect (also “geo-IP redirect,” “geolocation redirect,” or “location-based redirect”) is a server- or script-side mechanism that automatically sends a visitor to a different URL, subdomain, or ccTLD based on a signal it infers about where the visitor is or what language they speak — typically IP-address geolocation, the Accept-Language HTTP header, or a stored cookie/preference.

It’s important to keep three related things distinct:

• hreflang is an annotation (an HTML <link> tag, HTTP header, or XML sitemap entry) that tells search engines which alternate URLs exist for other languages/regions of the same content. It’s a discovery and serving signal — not a redirect.
• Geotargeting is the broader practice of configuring a site or URL to target a specific country (via ccTLD, subdirectory, or Search Console settings). A geo-redirect is one (risky) implementation of geotargeting; suggesting a locale and letting the user choose is the safer one.
• Locale-adaptive pages are Google’s term for pages that return different content based on the perceived country or language of the visitor, whether or not a redirect is involved.

The core problem: a geo-redirect is a serving decision (what do I show this visitor right now), while hreflang is a discovery signal (what alternate URLs exist for crawlers to find). Because Googlebot mostly crawls from US IP addresses and doesn’t send an Accept-Language header, a redirect that fires on those signals can trap the crawler on the default version and stop it from ever reaching — and therefore discovering — the alternate-locale URLs your hreflang tags point at. Geo-redirects don’t replace hreflang, and can sabotage it.

Related: Hreflang, Geotargeting, 302 redirect, ccTLD