The site shows an English-speaking user from the USA one page, while Googlebot, which is physically located in the Mountain View data center, sees a completely different one. Formally, this is already cloaking, even if you just wanted to adapt the content for the region. We analyze 6 typical mistakes in geo-redirects that cause websites to lose rankings, receive manual penalties, and get entire domains banned in affiliate networks.
What is a geo-redirect and why is it needed for business?
A geo-redirect is a mechanism that automatically redirects a user to a version of the site tailored to their country: different language, currency, prices, offers. Online stores use it so that a customer from Germany immediately lands on the German version with prices in euros, rather than browsing a catalog in dollars. Arbitrage marketers use geo-redirects in their setups to show different offers depending on the geo traffic — for example, one landing page for users from Tier-1 countries and a placeholder or different product for others.
The problem is that the same logic used to determine a user's country by IP is also applied to Googlebot. And the IP addresses of Google bots are physically located in the USA, regardless of whether they are indexing a page for Russian, Kazakh, or German search results. If the geo-redirect system does not distinguish between a crawler and a real person, the result is that Google sees a different page than what real visitors see. This is the formal definition of cloaking according to Google Search Central guidelines, and the penalty for it ranges from lower rankings to complete exclusion of the domain from the index.
Why do Googlebot and humans see different pages?
The discrepancy arises for three reasons simultaneously, and they usually overlap. First, Googlebot crawls the site from IP addresses owned by Google, and these addresses are identified by geo services (MaxMind, IP2Location, and similar) as American almost 100% of the time. Second, Googlebot sends its own User-Agent, which is often processed by a separate branch of code — sometimes intentionally, to avoid breaking indexing, and sometimes simply due to a developer's mistake. Third, Googlebot's behavior during JS rendering differs from that of a user's browser: the crawler may not execute a redirect that relies on client-side JavaScript, and thus it indexes a completely different version of the page than what a person sees with JS enabled.
Add to this CDN caching, which can "stick" to a version for one country and serve it to everyone indiscriminately, and you get a situation where even without malicious intent from the site owner, the search engine indexes content that does not match what the audience sees. Below are six specific scenarios where this occurs most frequently.
Error 1: IP-based redirect without checking the bot's User-Agent
The most common mistake is that the redirect logic is based solely on determining the country by IP, without any check on who is making the request: a person or a crawler. As a result, Googlebot, accessing from an American IP range, automatically lands on the US version of the site, even if the page was originally promoted for queries from Russia or Kazakhstan. After a few weeks of crawling, Google's index becomes filled with the "wrong" version of the content, and positions for target regions begin to decline without any visible reason.
The solution is to always exclude known User-Agents and IP ranges of search bots (Googlebot, Bingbot, YandexBot) from geo-redirects, serving them the canonical version of the page regardless of the determined country. Checking the User-Agent is a necessary but not sufficient barrier, as it can be easily spoofed, so serious projects additionally verify IP through a reverse DNS lookup, as recommended by Google's own documentation for verifying Googlebot.
Error 2: Testing with data center IPs instead of real user IPs
The second mistake occurs at the testing stage. A developer or marketer tests the geo-redirect through a regular data center proxy or VPN, and the logic triggers as if it were a real user from the desired country. However, data center IPs are easily distinguishable from residential traffic — many CDNs and anti-fraud systems mark them with a separate flag, and part of the geo-targeting logic may behave differently for such addresses than for a regular home IP provider.
As a result, the test "passes," the redirect on the dev server works perfectly, but in production, real users from the target country receive the wrong version because the provider's geolocation database or CDN rule interprets their IP differently than the test data center address. For proper testing, it is advisable to use residential proxies — they have IPs from real home providers in the desired country, and geo services identify them just as they would a real user. This gives an honest picture of what a real site visitor will see, rather than a simplified version for a "typical" data center IP.
Error 3: Cache and lack of Vary headers
If the site is behind a CDN (Cloudflare, Fastly, Akamai) and the geo-redirect is implemented at the origin server level rather than at the CDN itself, it is easy to end up in a situation where the CDN caches the first served version of the page and distributes it to everyone indiscriminately — regardless of the country of the next visitor. This happens when the server response does not include the correct Vary: Accept-Language header or a similar geo-caching key.
In this case, Googlebot may encounter the "correct" version on its first visit, cache it in its own indexing systems, and then receive the same version for weeks on subsequent visits, even if the content for other countries has long changed. Users, meanwhile, see the relevant but different version — the desynchronization gradually increases, and it is difficult to diagnose without directly comparing server responses for different geos using tools like curl with header spoofing or through proxies with the desired geolocation.
Error 4: JS redirect interpreted differently by the bot
Googlebot can execute JavaScript, but it does so with significant delay (the second wave of rendering can take days) and not always identically to a user's browser. If the geo redirect is implemented via client-side JS — for example, through window.location after a fetch request to a geo API — there is a risk that during the first pass, the crawler will index the page before the redirect triggers, meaning it will index the "wrong" version of the content for that specific region.
This is especially critical for single-page applications (SPAs), where all personalization logic is held on the client side. The correct approach is to perform geo-detection and redirect on the server side (CDN edge function, Node.js middleware, Nginx rule) so that both Googlebot and the user receive an HTTP 302 redirect before the page starts rendering in the browser. This removes the dependency on how exactly the crawler will process JS at a specific moment in time.
Error 5: One URL without hreflang for different language versions
The fifth mistake is attempting to serve multiple language versions at the same URL without hreflang markup. Google explicitly recommends: if the content at one URL differs depending on the user's locale, you should either provide different URLs for each version (subdomains, subfolders, or separate domains) with cross hreflang markup, or honestly show the same version to everyone, including bots, while providing an option to manually switch the language.
Without hreflang, Google cannot physically understand that /product in Russian and /product in English are intentionally different content for different audiences, rather than an attempt to hide one version from indexing in favor of another. The result is that a random version (usually the one that was available to the bot during the last crawl) gets indexed, and that version starts ranking in all regions simultaneously, which negatively affects relevance and conversion.
Error 6: No fallback for users with VPNs and mobile proxies
The sixth mistake concerns not so much Googlebot as real users — but it is directly related to the topic of geo-redirects, because often the attempt to "fix" behavior for bots breaks it for real people using VPNs or mobile internet. Mobile users often access the internet through CGNAT (Carrier-Grade NAT), where tens of thousands of subscribers use the same external IP, and the geo-database may mistakenly identify such an IP as belonging to a neighboring country or completely incorrectly.
If the site does not have a manual country/language switch as a fallback, a user with a "wrongly" identified IP gets stuck on an irrelevant version without the ability to change it — and simply leaves. To test such a scenario, it is worth checking the site's behavior through mobile proxies, which emulate IPs from real mobile operators with CGNAT-like geolocation behavior — this helps to see the problem in advance before real users discover it and write to support.
How to check geo-redirects from Google's perspective in different countries
The main tool for initial diagnostics is the "Fetch as Googlebot" feature in Google Search Console (URL Inspection Tool), which shows what HTML the Google crawler actually receives. If the version displayed there is not the same as what you see in your browser from your country, the problem is confirmed. However, Search Console always crawls from American IPs, so a separate layer of testing is needed to compare site behavior across regions.
In practice, marketers and SEO specialists set up several profiles in an anti-detect browser — Dolphin Anty, AdsPower, Multilogin, or GoLogin — and link each profile to a proxy from the desired country to manually go through the user journey: open the site, see which version loads, what Accept-Language header is sent, whether the redirect worked, and to which URL. For such checks, residential proxies with precise city or operator selection are convenient — they provide the most honest simulation of a real visitor, unlike data center addresses, which some services may flag as suspicious even before assessing geo.
| Proxy Type | Suitable for Which Check | Risk of False Result |
|---|---|---|
| Residential Proxies | Simulating a typical home user in the desired country/city | Low |
| Mobile Proxies | Checking behavior under CGNAT and mobile geolocation | Low |
| Data Center Proxies | Quick check of whether the country redirect triggers | Higher: some geo databases mark IPs differently than residential ones |
To check the behavior of server logic (rather than visual rendering), it is also useful to look at the raw server response through curl by spoofing the User-Agent to Googlebot and the X-Forwarded-For header to the IP of the desired country — this will show what HTTP status and Location the server returns before any JS rendering, allowing you to catch Error 4 and Error 1 from the list above with just one command.
Checklist for safe geo-redirect setup
- Googlebot, Bingbot, and YandexBot are excluded from geo-redirect logic by User-Agent and verified through reverse DNS
- The redirect is implemented on the server side (302/307), not just through client-side JavaScript
- The
Varyheader is set for correct CDN caching by geo/language - Each language version has a separate URL with cross hreflang markup
- There is a visible manual country/language switch as a fallback for incorrectly identified IPs
- Testing is conducted through residential and mobile proxies from the desired countries, not just data center addresses
- Once a quarter, check what Google Search Console shows — the version matches what real users see
Conclusion
The discrepancy between what Googlebot sees and what a user sees is rarely an intentional deception of the search engine — more often, it is accumulated technical debt: IP-based redirect without checking the bot, cache without Vary header, JS redirect that the crawler does not execute in time, and lack of hreflang for language versions. Each of these mistakes may seem minor on its own, but together they create a classic picture of cloaking in the eyes of Google — with corresponding penalties.
The only reliable way to ensure that the site behaves equally honestly for both bots and humans is to regularly check it from real IPs of the desired countries. For such diagnostics, we recommend using residential proxies to simulate a typical home user and mobile proxies to check CGNAT scenarios — this provides the most honest picture of what your audience really sees in each region and helps catch problems before Google’s algorithm finds them.