Google's Gary Illyes said that Googlebot's IP addresses are declared as being in Mountain View in the United States in most cases, but that the real egress points vary. Search Engine Roundtable reported the exchange on 14 August 2026, after Illyes answered a question on Bluesky about where Google actually crawls from.
The distinction matters for anyone who has ever written a firewall rule, a CDN geo policy or a bot rate limit that keys off the country attached to an IP address. Illyes was describing a gap between what an IP says about itself and where the traffic physically leaves Google's network.
What Illyes actually said on 14 August
The thread started with John Mueller, who had written: "I'm pretty sure the physical location [of Googlebot] varies. What kind of issues are you seeing?" Barry Schwartz then asked whether crawling was mostly from California with some bots testing from elsewhere.
Illyes answered on Bluesky: "IP location is declared (this is just a text bit you can set for the IPs you manage) to be US, Mountain View, in most cases, but the actual egress points vary." He gave a concrete example: "if the IP is assigned to a cluster in ATL, the egress point will be ATL."
He also explained the networking underneath it. "IP addresses don't have a geographic location. They typically default to whatever the registrant's location is, or they're defaulted to some location based on BGP anycast routes. Think about addresses like 1.1.1.1 or 8.8.8.8. Where do you put these on a map? They're technically everywhere."
What "declared location" means in practice
The important phrase in Illyes' answer is the parenthesis: a declared location is "just a text bit you can set for the IPs you manage". It is metadata, entered by whoever administers the address block, recorded in registry data, and then read by the geolocation databases that firewalls and CDNs consult. It is not a measurement of anything physical.
That is why the Mountain View label on Googlebot IPs is not a claim that a machine in Mountain View made the request. It is a value in a record. Illyes' example makes the gap explicit: an IP can carry a declared US, Mountain View location while the cluster it is assigned to sits in Atlanta, in which case the egress point, the place the traffic actually leaves the network, is Atlanta.
His broader point about 1.1.1.1 and 8.8.8.8 generalises this. Those addresses are reachable from everywhere through anycast routing, so the question of where to put them on a map does not have an answer. As Illyes put it, they are technically everywhere. Any system that assumes a one-to-one mapping between an IP and a physical place is working from an assumption the routing layer does not honour.
The practical consequence: blocking US traffic breaks crawling
The consequence stated in the report is direct: blocking traffic from the United States would cause serious crawling problems. That is the version of this issue most site owners will actually hit, because a broad country block is a common shape for a security rule.
The subtler version is the one that catches people out. A rule that allows only Thai and United States traffic looks safe on the theory that Googlebot is a US crawler. But if the declared country is a text field and the real egress point varies, a rule built on country matching can still starve crawling on the requests that leave from somewhere the rule did not anticipate. The report also notes that Google can crawl from other regions using locally-aware crawlers, so US-only reasoning about Googlebot is not a complete model to begin with.
Schwartz notes in the same piece that Google was seen crawling from China in 2011, possibly for regional legal reasons. That is a single historical observation rather than a statement about current behaviour, and it should be read as such.
The claims and what they mean for your site
The table below pairs what was said on 14 August with the operational reading. The left column is sourced. The right column is analysis, and is labelled as such.
| What was said | What it means for your site |
|---|---|
| Illyes: "IP location is declared ... to be US, Mountain View, in most cases, but the actual egress points vary." | The country attached to a Googlebot IP is a label, not a location. Rules that match on country are matching on metadata. |
| Illyes: "if the IP is assigned to a cluster in ATL, the egress point will be ATL." | Requests can leave from data centres other than the one the label implies. Geo logic keyed to a single city will misread them. |
| Illyes: "IP addresses don't have a geographic location ... They're technically everywhere." | Geolocation databases return a best guess. Treat their output as a hint, never as an access-control primitive for crawlers. |
| Blocking US traffic would cause serious crawling problems; Google can also crawl from other regions with locally-aware crawlers. | A country allowlist is a crawl risk in both directions: too narrow blocks Googlebot, and country alone never proves a request is Googlebot. |
Where this shows up in a real stack
Four places in a typical setup make decisions based on the country of an incoming IP, and all four are exposed to the gap Illyes described.
- The WAF or firewall. Country allowlists and blocklists are the most common form. A rule that permits only a short list of countries can drop crawler requests that leave from an egress point outside that list.
- CDN geo policies. Rules that serve, challenge or block by country sit in front of everything else, so a wrong decision here is invisible in your application logs.
- Bot rate limiting. Limits that are relaxed for "US traffic" and tight for everything else will throttle crawler requests that arrive from an unexpected region.
- Geo-personalised or geo-redirected serving. If a US-labelled IP is redirected to a US page or shown US pricing, then what gets crawled is whatever your geo logic decided to serve, not necessarily the page you want indexed for a Thai audience.
That last one is worth separating from the others because it fails quietly. Nothing is blocked, nothing errors, and the logs look healthy. The crawler simply receives a different page than the one you intended, and the version that reaches the index is the version your redirect chose.
Verify Googlebot the way it is meant to be verified
The replacement for country matching is identity verification. Google publishes IP ranges for its crawlers, and Googlebot can be verified by reverse DNS: resolve the requesting IP to a hostname, confirm the hostname belongs to Google's crawler domains, then resolve that hostname forward again and confirm it returns the original IP. That round trip is what makes the check trustworthy, because a hostname alone can be spoofed.
Reverse DNS verification and Google's published crawler IP ranges both answer the question that actually matters, which is whether the request is Googlebot. Country answers a different question, and as Illyes explained, it answers it from a text field. If your crawler policy is written in terms of countries, it is written in the wrong unit.
The checks worth running in your own environment are short. Pull a week of server logs and list every distinct network Googlebot-identified requests arrived from. Then read your WAF and CDN rules and find every rule with a country condition. If any of those rules can touch a request that passes reverse DNS verification as Googlebot, that rule is a crawl risk regardless of which countries it names. A structured SEO audit is the usual place this surfaces, because it is a log and configuration question rather than a content question.
What the source did not say
It is worth being precise about the limits of this story.
- Illyes did not say which regions Google crawls from. He said egress points vary and gave Atlanta as an example.
- He gave no proportions. There is no figure in the source for how much crawling comes from any location.
- The source gives no Thailand-specific data. There is no statement about whether or how often Googlebot crawls from or into Thailand.
- The China observation is dated to 2011 and framed as something that was seen, with a possible legal reason suggested. It is not presented as current behaviour.
- Nothing in the exchange announces a change. This is a clarification of how the system already works, not a new policy.
What this means for Thai marketers
For a Thai site, the actionable core is that IP country is an unreliable basis for any rule that can affect crawling. Thai sites frequently run tight geo rules, either to cut bot noise or because a security vendor set a default allowlist during onboarding, and those rules are usually written as country conditions because that is the control the interface offers.
The correction is not to open everything up. It is to make crawler access depend on verified crawler identity rather than on geography, and to keep the country conditions for the traffic where they belong. If a Thai and US allowlist is the only thing standing between your site and a wall of scrapers, keep it, but add an explicit rule that lets verified Googlebot through ahead of it.
Geo-serving deserves a second look for the same reason. If your site redirects or personalises by detected country, decide deliberately what a crawler should receive, because whatever it receives is what has a chance of being indexed. That is a piece of technical SEO work rather than a content decision, and it sits close to local SEO whenever different regions are meant to see different pages.
Frequently asked questions
Does Googlebot crawl from Thailand?
The source does not say. Illyes stated that egress points vary and that Google can crawl from other regions using locally-aware crawlers, but he named no regions beyond the Atlanta example and gave no Thailand-specific information.
Should I block or allow traffic by country to manage crawlers?
Country is the wrong control for crawler access, because the country attached to an IP is a declared text value rather than a physical fact. Verify Googlebot by reverse DNS and Google's published crawler IP ranges, and let that verification decide access.
Is Googlebot actually in Mountain View?
Not necessarily. Illyes said the IP location is declared to be US, Mountain View in most cases, but that the actual egress points vary, and gave the example of an IP assigned to a cluster in Atlanta leaving from Atlanta.
Did Google change anything here?
No. Nothing in the 14 August exchange announces a change. Illyes was explaining how IP location declarations and egress points already work, in response to a question about where Googlebot crawls from.
Do I need to do anything to my site today?
Only if you have rules that gate traffic by country. If you do, check whether a request verified as Googlebot could ever be caught by one, and add a verified-crawler exception ahead of the country condition if it could.
Where to go from here
The quotes above come from the exchange reported by Search Engine Roundtable on 14 August 2026. If you want a second pair of eyes on how your firewall, CDN and geo-serving rules affect what Google can actually crawl, Relevant Audience is happy to take a look.
