Case study: The unexpected impact of blocking GoogleOther on SEO performance
What happened
A client’s IT team blocked GoogleOther by IP to relieve an overloaded translation database. Within days, Search Console started reporting server connectivity errors, on some domains up to 40% of requests failing.
GoogleOther runs on the same IP ranges as Googlebot. An IP-level block aimed at one crawler caught the other. Google’s own documentation says GoogleOther has no effect on Search indexing or rankings, and that held true here. The damage came entirely from the way the block was built.
We removed the firewall rule, disallowed GoogleOther in robots.txt, and the errors cleared. Here’s the full incident and the reasoning behind the fix.
The trigger: a translation database under load
In January 2025, the client’s team noticed their translations database taking unusual strain.
Their logs pointed at Google. Bot traces spiked on January 23, 2025. In Azure monitoring, a “trace” is a logged event tracking how a specific bot interacts with the application, used for performance monitoring and debugging.
The source was GoogleOther, a crawler Google introduced in April 2023. Google describes it as a generic crawler that various product teams use to fetch publicly accessible content, for example one-off crawls for internal research and development. At launch, Gary Illyes explained that GoogleOther exists to take strain off Googlebot, so Googlebot’s crawl jobs stay dedicated to building the Search index. Before GoogleOther, regular Googlebot handled these non-Search crawls.
Google frames GoogleOther as a separate, non-Search crawler, so the IT team decided the safe move was to block it. They wrote an Azure Front Door WAF rule to block it by IP.
The consequence: Search Console connectivity errors
Blocking GoogleOther by IP caused a spike in Search Console connectivity errors.
The screenshot above is one of the least affected domains. On others, up to 40% of server requests were failing. So we dug in. Why would blocking a supposedly non-Search crawler break Search Console?
Why the block hit Search: shared IP ranges
GoogleOther and Googlebot crawl from the same IP ranges. Block one by IP and you block the other.
Google documents this, but it’s easy to miss. GoogleOther uses the same infrastructure as Googlebot: same host-load limits, same HTTP protocol handling, same IP ranges. Only the user-agent token differs. Illyes called it basically Googlebot under a different name.
Our logs confirmed it directly:
- The IP most often caught by the client’s “BlockGoogleOther” rule was 66.249.70.66, blocked 123,384 times in a single week.
- That same IP served over 10,000 regular Googlebot requests in the same week.
The WAF rule was blocking a shared Google crawl IP. Googlebot was collateral damage, and that’s exactly what Search Console reported.
This shared-range behavior has been discussed in the WebmasterWorld forum and other SEO communities. SEOs who work in logs tend to know it. IT teams almost never do, because it lives in crawler documentation they have no reason to read.
The fix: switch to robots.txt
The right way to limit GoogleOther is robots.txt. GoogleOther obeys robots.txt and uses its own user-agent token, so a robots.txt rule targets it specifically and leaves Googlebot untouched.
We did two things:
- Removed the Azure Front Door WAF rule blocking GoogleOther by IP.
- Added this to robots.txt:
User-agent: GoogleOther
Disallow: /Results after the fix
Switching to robots.txt resolved the incident cleanly.
- Search Console connectivity errors returned to normal.
- Site performance stabilized, with server resource usage back to 3-4 instances.
- GoogleOther stopped hammering the translation database.
- Rankings and indexing were never affected.
Lessons learned
Google’s “separate crawler” framing hides an operational trap. GoogleOther is a distinct crawler with its own user agent, but it shares Googlebot’s IP ranges. Treating “separate crawler” as “separate everything” is how this incident started.
IP blocking is a blunt instrument for Google crawlers. Block one Google IP and you can take out Googlebot without realizing it. The user agent is the only reliable way to tell these crawlers apart, and firewalls that match on IP can’t see it.
Robots.txt is the right tool for GoogleOther. It respects robots.txt precisely and honors its own user-agent token, so you can limit it without touching Search.
Watch the Search Console crawl report after any technical change. It surfaced this problem fast and kept a database fix from turning into an SEO incident.
What this means for your team
IT teams reach for firewall rules to shed unwanted traffic, which is reasonable server management. For Google crawlers it backfires, because an IP block can’t distinguish GoogleOther from Googlebot, and robots.txt is rarely the first tool a security-focused team reaches for.
GoogleOther doesn’t secretly affect Search. The real damage here came from a crawler decision made without SEO input, which turned into failed requests and Search Console errors. Get involved early in any technical decision that touches crawler access, before the firewall rule ships.
