Paste an address from your access log. This tool will verify a Googlebot IP two ways — forward-confirmed reverse DNS and a match against Google's own published range files — then tell you which of Google's five crawler categories it belongs to, because AdsBot and Googlebot arriving at your server mean very different things. It will also tell you when it could not check, instead of guessing.
Quick Answer: How Do You Verify a Googlebot IP?
To verify a Googlebot IP, reverse-DNS the address, confirm the hostname matches a pattern Google documents — crawl-*.googlebot.com for search crawlers — then forward-resolve it back to the same address. Check Google's published ranges as a second signal. Skip the user-agent: it is a string the sender chose.
Jessica Wright
Cybersecurity Threat Researcher
Jessica works on bot verification and IP reputation, separating traffic that is what it says from traffic that only claims to be.
Googlebot has been the most impersonated name on the web for the better part of two decades, and the reason is entirely rational: a great many sites wave it straight through. Forging one header buys a scraper past rate limits, bot challenges and paywalled previews in a single move. When I pull a week of logs for a site complaining about crawl load, a meaningful share of the traffic labelled Googlebot fails both checks on this page.
The other half of my inbox is the opposite problem, and it costs more. Somebody reads that Google-Extended controls Google's AI, blocks it, and cannot understand why they are still quoted in AI Overviews. Those two are governed by different levers, and until June this year there was no lever at all for the second one. The caveat I would attach to every result here: a range non-match is weak evidence. Google moved and renamed its range files this year, and anything built against the old names stopped finding data without erroring.
Last reviewed 21 August 2026 · Ranges read from Google's published feeds · DNS resolved at request time · No lookups logged
View all articles by Jessica WrightBecause forging it works. A great many sites are configured to wave anything calling itself Googlebot straight through, so one header gets a scraper past rate limits, bot challenges and paywalled previews in a single move. Nothing in HTTP checks that header — it is a sentence the client writes about itself.
The scale has been measured more than once. Imperva's Fake Googlebot study, published in 2014 across a thousand customer sites, found 16.3% of them receiving Googlebot impersonation traffic, and on the affected sites 21% of requests claiming to be Googlebot were impostors. That study is more than a decade old and still the most-cited figure on the topic, which tells you something in itself: the technique has not needed to change.
More recent numbers point the same way. A test published in Search Engine Journal in June 2026 found only 107 of 799 requests carrying the Googlebot name came from a verified Google address — though the author was careful to note that was two weeks of data on one new site. Treat it as a prompt to check your own logs rather than a figure to quote.
Two things about a request cannot be written by whoever sent it: the source address, which comes from the TCP connection, and what Google's own nameservers say about that address. Those two are what this tool tests. If you want the general method, written once and applied across nineteen crawler operators rather than just Google, the universal bot verifier explains forward-confirmed reverse DNS in full.
Check what you are testing first. Behind a CDN or load balancer, the connecting address in your logs is your own edge and the real client sits in a forwarded header. Running your load balancer through this tool will fail every time and tell you nothing. If you are unsure what an address even is, a geolocation and network lookup settles it in one step.
Knowing the traffic is fake is only half the job. The other half is knowing which Google you are looking at when it turns out to be real — and that is where most guidance stops far too early.
Because five different kinds of traffic arrive from Google, and they do not deserve the same answer. Most write-ups still say "check Google's IP list", singular. There are five, they carry different reverse-DNS masks, and knowing which one an address matched changes what you should do about it.
| Category | Reverse DNS pattern | Named by hostname? | Typical agents | robots.txt |
|---|---|---|---|---|
| Common crawler | .googlebot.com, .geo.googlebot.com | Yes | Googlebot, Googlebot-Image, Googlebot-News, Googlebot-Video, GoogleOther, Storebot-Google | Obeys robots.txt |
| Special-case crawler | rate-limited-proxy-*.google.com | Yes | AdsBot-Google, Mediapartners-Google, APIs-Google, Google-Safety | Some ignore the robots.txt wildcard group |
| User-triggered fetcher | .gae.googleusercontent.com | Yes | Feedfetcher, Google Publisher Center, Google Read Aloud, Google Apps Script | Generally ignores robots.txt - a person asked for the page |
| User-triggered fetcher, Google-controlled | .google.com | No — range file only | Google Site Verifier, Google-InspectionTool | Generally ignores robots.txt - a person asked for the page |
| User-triggered agent | .google.com | No — range file only | Google-CloudVertexBot and other Google systems acting on a person's behalf | Varies by agent |
Two of the five categories resolve under a plain google.com suffix with no distinctive shape. So does a large amount of Google that is not a crawler at all. A tool that treats any google.com hostname as proof of a crawler will label a mail relay as AdsBot, and plenty do.
Only rate-limited-proxy-*.google.com identifies a documented crawler by hostname. Anything else under that domain is Google-operated infrastructure — a real fact, but a different one. This tool reports that separately rather than folding it into a crawler verdict.
They resolve under gae.googleusercontent.com, not google.com. That is Google App Engine — infrastructure Google runs but does not control the code on. Anyone can deploy there. A hostname ending in googleusercontent.com tells you the request came from Google's platform, not that Google sent it, and treating those two as the same thing is how an allowlist gets abused. If you want to see what else sits on a given address, a reverse IP lookup lists the other names pointing at it.
If you built anything against Google's crawler ranges before this year, check it today. Google moved the files from the old search API path to a crawling path, and googlebot.json was renamed to common-crawlers.json. The old directory redirects, but a script hardcoded to the old filename finds nothing.
The failure is silent. A verification script that stops receiving range data does not crash. It simply stops matching, and every Googlebot request starts failing verification. If your bot rules turned unexpectedly strict this year, rule this out first. It is also why this page reports an unread file as inconclusive instead of as a non-match.
None of that touches the question most people actually arrive with, which is not about crawlers at all. It is about AI — and the control everyone reaches for first is the one that does the least.
Model training, and nothing else. Google-Extended is a robots.txt token — a name you list in a file, with no crawler behind it, no user-agent arriving at your server and no IP address to block. It tells Google not to use your content to train Gemini and Vertex AI. That is the whole of it.
This is the most expensive misunderstanding in the topic, because people arrive wanting to verify Googlebot IP traffic and leave having changed a setting that does something else entirely.
AI Overviews and AI Mode are not built from Google-Extended crawls. They are assembled in real time from the live Search index — the index Googlebot fills. A page you excluded from Gemini training can be crawled by Googlebot tomorrow and quoted in an AI Overview the same afternoon. Blocking Google-Extended does not change that by one page.
Be careful whose answer you trust here. Several crawler-checking tools state the opposite — that blocking Google-Extended removes you from AI Overviews. It does not, and acting on that advice means a publisher gives up Gemini training data believing they bought something they did not.
Almost all of the confusion comes from treating these as interchangeable. They are not.
| Control | What it stops | What it costs you |
|---|---|---|
| Block Googlebot | Search indexing, and everything downstream of it | Your Google Search traffic. Almost never the right move. |
| Google-Extended | Gemini and Vertex AI model training only | Nothing measurable. Search and AI Overviews are untouched. |
| nosnippet | AI features, by removing the text they would quote | Your organic snippet and featured snippets go too. |
| Search Console toggle | AI Overviews, AI Mode, AI features in Discover | Rankings and snippets stay intact. New in June 2026. |
Three of those four are robots.txt tokens and a meta directive — text in a file, not traffic at your firewall. Only the last one is a setting inside a Google product, and it arrived very recently.
Since June 2026, yes. Google added a Search generative AI section to Search Console containing two things: a performance report showing impressions from AI Overviews, AI Mode and AI features in Discover, and a toggle that excludes a property from those three surfaces. Each property can be set to Include, Exclude, or Inherit from parent.
Google has stated the toggle is not used as a ranking signal, so a site that opts out keeps its normal Search results and its Discover feed. It is the first control that removes you from AI features without the snippet trade-off nosnippet forces. Changes take roughly one to two days to propagate.
The timeline is worth knowing, because it explains why you may not see it yet. Google announced the controls on 3 June 2026 and they took effect on 17 June. The rollout began with a subset of UK site owners following a legally binding conduct requirement from the UK's Competition and Markets Authority — the first such mandate anywhere — and has since been appearing in waves beyond the UK. Availability still differs between Search Console properties.
Measure before you switch it off. The report shows impressions only — no clicks, no queries, no average position — so there is no clean baseline for what opting out would actually cost. For most sites a citation in an AI Overview is visibility rather than loss. Opting out on principle is a decision that deserves a few weeks of that report first.
One boundary that catches people: this toggle governs whether your content appears in AI answers. It does not govern training. That is still Google-Extended, and the CMA requirement separately obliges Google to let publishers opt out of fine-tuning as well.
None of this is a firewall matter. Google-Extended has no IP addresses and the Search Console toggle is a setting rather than traffic. If your goal is keeping AI crawlers off the server itself, that is a different job — the rule generator builds robots.txt and firewall rules from each operator's live published ranges. For the wider picture of what Google does with address data generally, our guide to Google IP addresses covers the ground this page does not.
There are real limits on what any attempt to verify Googlebot IP claims can establish, and a tool that only lists its strengths is not much help when you are about to block traffic. Here is where this one stops.
You paste an address; the tool has no access to your logs. It answers "is this Google?" and not "did this request claim to be Google?". A scraper that declares nothing at all is invisible here.
Google revises these files constantly — the common crawler list was stamped the same day this page was reviewed. A genuine new address can sit outside the published file for a while, which is why a confirmed reverse DNS loop is treated as conclusive here on its own.
Google-controlled fetchers and user-triggered agents share a plain google.com suffix with each other and with the rest of Google. Without a range match there is no way to tell them apart, and the tool says so rather than picking one.
Confirming an address belongs to Google settles ownership and nothing else. Crawl volume, the paths being requested and the load on your origin are separate questions, and the answer to all three is a crawl rate setting in Search Console rather than a firewall rule.
Verifying an address has no effect on AI Overviews, Gemini training or anything else. Those are robots.txt tokens and a Search Console setting, and no lookup tool can operate them for you.
Log analysis needs volume, repeat offenders and patterns over days. For one suspicious line this is the right tool; for a week of traffic it is not.
When an address turns out not to be Google, the useful next question is who it actually belongs to. An ASN lookup names the network operator behind it, the ASN range export gives you every prefix that operator announces in firewall syntax, and the residential-versus-datacenter guide explains why almost all impersonation arrives from rented space.
Reverse-DNS the address, confirm the hostname matches a pattern Google documents — crawl-*.googlebot.com for search crawlers, rate-limited-proxy-*.google.com for AdsBot and its siblings — then forward-resolve that hostname and confirm it returns the same address. Check Google’s published range files as a second signal. The user-agent proves nothing, because the client writes it.
Scrapers send a Googlebot user-agent because many sites wave it through without checking. It buys them past rate limits, bot challenges and paywalled previews in one move. The header costs nothing to forge, which is why Googlebot has been the most impersonated name on the web for over a decade.
No, and this is the most common misunderstanding on the topic. Google-Extended controls whether your content trains Gemini and Vertex AI. AI Overviews and AI Mode are built from the live Search index that Googlebot fills, so they are unaffected. Some tools state the opposite; they are wrong.
Yes. Google added a toggle in Search Console under Settings, Search generative AI, that excludes a property from AI Overviews, AI Mode and AI features in Discover. Google states it is not used as a ranking signal for organic search. It launched to UK site owners on 3 June 2026 under a CMA order, took effect on 17 June, and has since been appearing in other regions.
Googlebot is a real crawler with real IP addresses that indexes your pages for Search. Google-Extended is a robots.txt token with no crawler behind it and no IP addresses at all. You cannot block Google-Extended at the firewall, and you should never block Googlebot to try.
Because the second half of the check did not pass. Whoever controls an address also controls its reverse DNS zone, so anyone can publish a PTR reading crawl-1-2-3-4.googlebot.com on their own address. The forward lookup catches it: Google’s nameservers will not resolve that hostname to their address.
Not necessarily. Google runs a great deal that is not a crawler under that domain, and two of its five crawler categories share the plain google.com suffix with everything else. Only rate-limited-proxy-*.google.com identifies a documented crawler by hostname. Anything else resolving under google.com is Google-operated infrastructure, which is a different statement, and this tool reports it as such.
No. Blocking Googlebot removes pages from Google Search, which is almost never the trade you meant to make. Set a crawl rate limit in Search Console instead, or fix whatever is generating the URLs it keeps finding. Verify the traffic first, too — heavy “Googlebot” load is often not Googlebot.
This page answers one question about Google. These answer the rest.
Browse the full set on the TrustMyIP tools directory.
A failed check tells you the name was borrowed. The next question is whose network the request actually came from, and whether that address has a history worth knowing about.
Last updated 21 August 2026 · Ranges read from Google's published feeds · DNS resolved at request time · No lookups logged