This one comes up in almost every international technical audit we run, always phrased slightly differently, always the same underlying confusion. Someone pulls the logs, sees Googlebot arriving from an address their geo-IP database places in Mountain View, wires the site to serve the US locale to Mountain View traffic, and cannot work out why the German pages never index properly.
The answer arrived in plain language on August 14, 2026, when Barry Schwartz wrote up an explanation from Gary Illyes at Search Engine Roundtable. The short version is that the location on those IPs is something Google types in, not something the network measures.
“IP location is declared, meaning it is just a text bit you can set for the IPs you manage. In most cases it is set to US, Mountain View, but the actual egress points vary.”
The question that keeps coming back
Here is why this confusion is so durable. Geo-IP databases feel like measurements. You look up an address, you get a city, and the city looks like a fact. It is not. Commercial geolocation data is built largely from what network operators publish about their own ranges, which means for a network as large as Google's you are reading Google's own label back to yourself.
Illyes added the operational detail that makes it concrete. If an IP is assigned to a cluster in Atlanta, traffic from that IP leaves from Atlanta. The declared location did not change. The packets did. He also noted the 2011 precedent of Google crawling from within China for regional legal reasons, which is the older, louder version of the same point: Google puts crawling capacity where it needs it and does not renegotiate the labels every time.
What Googlebot IP location actually tells you
It tells you the request is Google's, and only if you verified it properly. That verification is a reverse DNS lookup on the requesting address followed by a forward lookup on the resulting hostname, or a match against Google's published crawler ranges. Neither of those steps involves geography, and both are worth doing regardless of anything else in this piece, because user-agent strings are trivially spoofed.
| WHAT YOU WANT TO KNOW | DOES THE IP LOCATION ANSWER IT | WHAT ACTUALLY ANSWERS IT |
|---|---|---|
| Is this really Googlebot | No | Reverse and forward DNS verification, or published range match |
| Which country is this crawl for | No | Nothing at the request level, use hreflang and separate URLs |
| Where did this request physically originate | No | Not reliably determinable, and not something you should depend on |
| Which of my locales should this request see | No | The URL being requested, which you control |
| Should I rate limit this traffic | Partly | Verified identity plus your own capacity signals |
Read down that middle column. There is exactly one partial yes, and it is not about geography. The honest conclusion is that crawler IP geolocation is not an input to any decision worth making, and the sites that treat it as one built that dependency by accident years ago.
Where the geo-redirect breaks
Picture a normal international setup. Your site detects visitor country from IP, redirects them to the matching locale, and serves the right currency and language. Sensible for humans, and it is the most common international pattern on the web.
Now send a crawler through it. Google requests a German URL. Your geolocation layer resolves the requesting address to the United States, decides this visitor is in the wrong place, and issues a redirect to the US page. Google follows it, records that the German URL redirects to the US URL, and concludes the German page is not a separate destination. Your German content quietly stops existing as far as the index is concerned.
Nothing errors. Nothing appears in a crawl report as a failure. The pages return healthy status codes, the redirect is intentional, and the only symptom is that an entire locale never ranks. This is the same shape of quiet failure we documented in blocking AI crawlers by accident: a working system doing exactly what it was told, to a visitor it was not designed for.
Where international locale problems traced back to, across our international technical audits. Illustrative distribution from engagement experience, not a survey.
Googlebot IP location and accidental cloaking
There is a worse version of this, and it is worth naming because teams stumble into it while trying to fix the first version. Someone realizes crawlers are being redirected wrongly, and the fix they reach for is to detect Googlebot and exempt it from the geo-redirect. Now the crawler sees something a user in the same apparent location would not.
That is the definition of serving different content to crawlers than to users, and it does not stop being that because your intentions were good. The safe version of the exemption is narrow: crawlers are exempted from redirection only, and they receive exactly the page a human requesting that same URL directly would receive. The unsafe version is any branch where the crawler gets different body content, different pricing, or different availability.
How to serve locales without guessing
The pattern that works has been stable for a decade and is boring enough that people keep trying to improve on it. Give every locale its own URL. Serve that URL to anyone who requests it, human or machine, without redirecting. Declare the relationships with hreflang, including self-references and reciprocal links. Offer a suggestion rather than a redirect when you think someone is in the wrong place.
The suggestion is the part teams resist, and it is the part that solves everything. A small banner saying you appear to be in Germany with a link to the German site keeps the visitor in control, keeps the crawler on the URL it asked for, and removes the need for any decision based on network geography. Conversion teams worry it costs them; in the ecommerce work we run across ecommerce clients, the measured difference is small and the indexing difference is enormous.
| APPROACH | HUMAN EXPERIENCE | CRAWLER OUTCOME | VERDICT |
|---|---|---|---|
| Hard IP redirect to detected locale | Fast, sometimes wrong | Locales collapse into one | Avoid |
| Redirect with crawler exemption | Fast, sometimes wrong | Works, with cloaking risk nearby | Only if tightly scoped |
| Locale suggestion banner, no redirect | One extra click when wrong | Every locale crawlable and indexable | Recommended |
| Locale by cookie or session only | Inconsistent across devices | Crawler sees default forever | Avoid |
| Separate URLs plus correct hreflang | Predictable and shareable | Relationships declared explicitly | Required foundation |
If you also serve content that depends on JavaScript to render the locale, layer on the constraint we covered in what AI crawlers do and do not render. A locale decision made in client-side code is invisible to a large share of the crawlers that now matter, and it fails silently in exactly the same way the redirect does.
The fix list
Start by finding out whether you have the bug at all, which takes about twenty minutes. Fetch three of your non-default locale URLs using a tool that reports the full redirect chain, from a network outside your primary market if you can. If any of them redirect to a different locale, you have found it.
Then check the crawl side. Pull server logs for verified Googlebot requests to those locale URLs and look at what you returned. A pattern of 301s or 302s on locale URLs to a single default is the signature. While you are in the logs, it is worth checking your response codes generally, since conditional request handling has its own effect on how much of your site gets refreshed, which we walked through in shared crawl capacity and 304 responses.
The remediation is straightforward and mostly a matter of getting the change prioritized: remove the redirect, add the suggestion banner, verify hreflang self-references and return links, and confirm nothing in your edge configuration is making a locale decision before your application sees the request. That last one hides the longest, because it is owned by a different team and does not appear in the application code at all. It is a standard finding in our technical audits and it is almost never where anyone looks first.
The broader lesson is worth keeping. When a system gives you a value that looks like a measurement, find out whether anyone measured it. In this case nobody did, and a great deal of international SEO has been built on a text field. The original explanation is at Search Engine Roundtable's August 14 write-up.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.