Google's reverse DNS steps let any Google Cloud server pass as Googlebot

Two rules on the same page

Google's page Verify requests from Google crawlers and fetchers gives the command-line method in four steps. Step 2 says to verify that the domain name is googlebot.com, google.com or googleusercontent.com. Steps 3 and 4 run a forward lookup and check it matches the original IP.

Further down, the same page has a table of reverse DNS masks for each type of Google crawler. It's much stricter:

By the table, googleusercontent.com is only valid as gae.googleusercontent.com, and only for user-triggered fetchers. It is never valid for Googlebot itself.

Why the loose rule fails

Google Cloud gives each VM's external IP a reverse DNS name under bc.googleusercontent.com, and the forward lookup of that name returns the same IP. A script that follows the four steps sees a Google domain and a matching forward lookup, and marks the visit as real.

$ host 34.xx.xx.xx
xx.xx.xx.34.bc.googleusercontent.com   # ends in googleusercontent.com: passes step 2

$ host xx.xx.xx.34.bc.googleusercontent.com
... has address 34.xx.xx.xx            # same IP: passes steps 3 and 4

Anyone can rent one of those servers for a few dollars a month and send Googlebot as the user agent.

What we saw in our own logs

We ran the SenseGap verifier over 8 days of traffic (28 October to 5 November 2026) on four sites we run: sensegap.com, a news site, a medical test site and a PDF tools site.

On sensegap.com, 89 requests from Google Cloud VMs called themselves Googlebot and passed our reverse DNS check. They weren't crawling pages. They were asking for files like .env, .git/config and cloud credentials.

The same machines also used AI bot names. Every fake AI bot visit across the four sites came from 7 Google Cloud IPs, and each scanner IP on sensegap.com rotated through the same 8 AI bot names. For bots whose operators publish IP ranges, this is how much of the traffic using their name was fake:

The pattern is simple: fakes are a fixed number of scanners, so they dominate the names that get little real traffic. On a small site, most “CCBot” and “PerplexityBot” visits may be scanners. The busiest real AI crawler, OAI-SearchBot, was 99% genuine.

About two thirds of the fake requests were looking for secrets: .env files, credentials.json, .aws/credentials, Kubernetes service account tokens and path traversal to /proc/self/environ.

The scanners also used names nobody can check, including ClaudeBot, Meta-ExternalAgent and cohere-ai. Those operators publish no IP ranges or reverse DNS domains we could use, so real and fake visits under those names look the same.

The stricter check

Match the hostname to the crawler type, as Google's table does:

• Googlebot and other common crawlers: the hostname must end in googlebot.com.
• Special-case crawlers like AdsBot: google.com.
• User-triggered fetchers: gae.googleusercontent.com or google.com.
• Never accept a bare googleusercontent.com suffix.

Better still, check the IP against Google's published lists for that crawler type, and use reverse DNS as a second check. If you verify Googlebot in a firewall rule, a log script or a plugin, it's worth checking which rule it uses. Code copied from the step-by-step list will have the gap.

We fixed our verifier on 5 November 2026. The rule is in the open-source bot list, so you can read it or reuse it.

Method and limits

• The data comes from Cloudflare's sampled analytics, so exact counts shift by a few percent between runs. The shares above held across three runs.
• Four sites, all ours, small to medium in size. This is a field report, not a survey of the web.
• A visit is called fake only when it fails a check the operator publishes: its IP lists, or reverse DNS confirmed by a forward lookup. Names with no published check are counted as unverified, never as fake.

To run the same check on your own logs, see how to verify AI bots or paste a log sample into the log checker.