A lot of traffic claims to be Googlebot. Much of it is not. The user-agent string is trivial to fake, so scrapers and bad bots wear the Googlebot label to slip past defenses and get preferential treatment. This guide shows how to verify that a request is really from Google, using DNS and IP ranges, and how the ASN exposes the fakes.
Why fake Googlebot is a problem
Sites often allow Googlebot through rate limits and bot filters so their SEO does not suffer. That allowance is exactly what impostors abuse: set the user-agent to Googlebot and a poorly defended site waves you through to scrape content, probe for weaknesses, or skew analytics. Because the user-agent is just a request header, it proves nothing on its own.
Real verification relies on things an attacker cannot forge: the DNS records Google controls and the IP ranges Google actually announces. An impostor can copy the label but cannot make their traffic originate from Google's network.
Method 1: reverse and forward DNS (Google's official method)
Google's documented verification is a two-step DNS check. Take the IP making the request and run a reverse DNS lookup; a genuine Googlebot IP resolves to a hostname ending in googlebot.com or google.com. Then run a forward DNS lookup on that hostname and confirm it resolves back to the original IP. Both halves must pass.
This works because Google controls those DNS zones. A scraper can set any user-agent, but it cannot make an arbitrary IP reverse-resolve to googlebot.com, and it cannot make googlebot.com forward-resolve to its own server. The round trip is the proof.
Method 2: Google's published IP ranges
Google publishes the IP ranges its crawlers use as JSON files, such as the Googlebot list at googlebot.json and the broader google.json for other Google fetchers. You can match a requesting IP against those ranges to confirm it falls inside Google's space. This is faster than DNS for high-volume checks, but you must refresh the lists, since the ranges change over time.
The ranges resolve back to Google's own AS15169. That is the deeper signal: real Googlebot originates from Google's ASN, while a fake almost always originates from a hosting ASN like OVH, Hetzner, or a cloud provider.
How the ASN exposes impostors
The fastest sniff test is the network behind the IP. Genuine Googlebot comes from AS15169 (Google). If a request claims to be Googlebot but its IP belongs to AS16276 (OVH), AS24940 (Hetzner), or any hosting ASN, it is fake, full stop. Real search crawlers do not run from rented servers.
This makes the ASN a cheap first filter: check the ASN before you spend effort on DNS round trips. A hosting-ASN Googlebot is an immediate reject; only IPs that plausibly belong to Google are worth the full reverse-and-forward DNS confirmation. It is the same datacenter-vs-residential logic applied to crawlers.
Verify crawler ASNs in real time
You can pull the ASN for any requesting IP inline. Abstract's IP Intelligence API returns the ASN, the operator's name, its type, and an is_hosting flag in one request, so your bot filter can reject a hosting-ASN Googlebot instantly and pass real Google traffic through. For a manual check on a suspicious log entry, drop the IP into the free ASN Lookup tool and read the operator. This is a core building block of bot detection.
Frequently Asked Questions
How do I verify that a request is really from Googlebot?
Run a reverse DNS lookup on the IP and confirm it resolves to a googlebot.com or google.com hostname, then run a forward DNS lookup on that hostname and confirm it returns the same IP. Both steps must pass.
Can you trust the Googlebot user-agent?
No. The user-agent string is a request header anyone can set, so scrapers routinely impersonate Googlebot. Verify by DNS or IP range, never by the user-agent alone.
What ASN does Googlebot use?
Genuine Googlebot traffic originates from Google's network, AS15169. A request claiming to be Googlebot from a hosting ASN such as OVH or Hetzner is fake.
Where can I find Google's crawler IP ranges?
Google publishes them as JSON, including a Googlebot-specific list and a broader list of Google fetcher ranges. Match a requesting IP against those ranges, and refresh the lists periodically because they change.
Is matching the IP range enough, or do I need DNS?
Range matching is a fast first pass and the ASN check is an even faster one. For a definitive answer on a single request, Google recommends the reverse-and-forward DNS method, since ranges can lag behind changes.
Get your free
IP Geolocation
key now
See why the best developers build on Abstract
get started for free
