Verify Bot IP Address Claims:
Is That Crawler Really Who It Says?
To verify bot IP address claims properly you need two checks, not a user-agent string. Paste an IP from your access log, pick what it claimed to be, and this tool runs forward-confirmed reverse DNS and checks the address against the operator's live published ranges — then gives you one of six honest verdicts, because "we could not check" and "it failed the check" are not the same finding, and most verifiers pretend they are.
Quick Answer: How Do You Verify a Bot IP Address?
To verify a bot IP address, reverse-DNS the address, confirm the hostname matches the operator's documented suffix, then forward-resolve that hostname back to the same IP. Also check it against the operator's published CIDR ranges. The user-agent proves nothing — the client writes it.
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.
The reason this tool has six verdicts instead of two is a support ticket I have answered too many times. Somebody runs an address through a checker, gets a red X, blocks it, and three weeks later notices pages falling out of an index. The red X did not mean the bot was fake. It meant the operator publishes nothing to check against, or the checker could not reach the file — completely different sentences that a binary result flattens into one.
The caveat I would put on every result here: a range non-match is weak evidence. Operators change infrastructure faster than they update published files. Microsoft's bingbot range file still carries a creation date from January 2024. Google quietly moved and renamed its range files this year, so anything built against the old names stopped finding data without erroring. If a verdict here contradicts what your logs plainly show, trust the logs and re-check in a week.
Last reviewed 21 August 2026 · Ranges read from operator feeds · DNS resolved at request time · No lookups logged
View all articles by Jessica WrightWhy a user-agent is a claim, not an identity
When a request arrives saying Googlebot, that string was written by the client. HTTP has no mechanism to check it. Anyone can run curl -A "Googlebot/2.1" from any machine on earth and your log records it exactly as it records the real thing.
This is measurable rather than theoretical. Research published by HUMAN Security put the share of traffic carrying a well-known AI crawler's user-agent that was not actually from that crawler at roughly 5.7%, rising to about one request in six for the ChatGPT-User agent. Cloudflare documented a separate case in August 2025 where a crawler was reaching sites with a generic Chrome user-agent, from addresses outside its own published range, rotating across networks at millions of requests a day.
That matters in both directions. Sites that allow traffic on the strength of a crawler user-agent hand scrapers a free pass by typing one header. Sites that block on the same basis catch only the honest bots, because a scraper simply stops declaring itself. Either way the header is doing no work.
Two things about a request cannot be written by the client. The first is the source address, which comes from the TCP connection. The second is what the operator's own DNS says about that address. Verifying a bot IP address means testing those two, and nothing else.
Before you start: make sure the address in your log is the real client. Behind a CDN or load balancer the connecting address is your own edge, and the original client sits in a forwarded header. Verifying your load balancer against Googlebot's ranges will fail every time and tell you nothing. If you are not sure what you are looking at, a geolocation and network lookup on the address settles it in one step.
The two checks that verify bot IP address claims
FCrDNS is three steps, and the third is the one that matters. Most explanations stop after the second, which is why plenty of people believe a PTR record is proof.
Reverse lookup the address
Ask DNS what hostname the address points to, via its PTR record. For a genuine Googlebot address you get something like crawl-66-249-66-1.googlebot.com.
Check the hostname suffix
Confirm it ends in a domain the operator documents. Google uses googlebot.com and geo.googlebot.com for its common crawlers; Microsoft uses search.msn.com; Apple uses applebot.apple.com.
Forward-resolve that hostname back
Resolve the hostname you just got and confirm it returns the address you started with. This is the step that closes the loop. Anyone who controls the reverse zone for their own address space can set a PTR record saying whatever they like — but they cannot make Google's nameservers resolve a googlebot.com hostname to an address Google does not own.
Because step three cannot be forged, a confirmed loop is conclusive on its own. That is worth stating plainly, because it is where most verifiers go wrong: they demand a published range match as well, and then report a genuine crawler as fake whenever its address has not yet reached the operator's file. Google documents this exact procedure, including the hostname masks for each crawler category, in its crawler verification documentation. You can run the same three steps from a terminal:
# 1 + 2: what does the address say it is?
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
# 3: does that hostname resolve back to the same address?
host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1
# If step 3 returns a different address, the claim fails.
Both checks run on IPv4 and IPv6. That matters more than it used to: Google publishes well over a hundred IPv6 prefixes for its common crawlers alone, and a verifier that only handles dotted-quad addresses silently fails every IPv6 request. If you want to see the range a matched prefix actually covers, the CIDR calculator expands any prefix into its full address range.
The tool above runs both, with a hard time limit on the lookup, and tests the range check against every operator rather than only the one you selected — which is how it can tell you that an address claiming to be GPTBot actually belongs to Google. Once you know the answer, the crawler blocker turns the same vendor feeds into nginx, Apache and Cloudflare rules.
The six verdicts, and why two would not be enough
Almost every tool that claims to verify bot IP address requests returns a green tick or a red cross. That collapses situations calling for opposite responses. Here is what this tool returns instead.
| Verdict | What happened | What it means for you |
|---|---|---|
| Verified | Reverse DNS confirmed, or every check the operator supports passed. | Genuine. Stop challenging or rate limiting it. |
| Range match only | Address is in a published range, and the operator documents no reverse-DNS scheme — or has one that did not confirm. | Usually genuine. For operators like OpenAI this is the ceiling, so treating it as failure would be wrong. |
| Inconclusive | A check that should have run did not — the range file would not load, or DNS was unavailable. | No evidence either way. Re-run in a minute. Never block on this. |
| Unverifiable | The operator publishes no ranges and documents no hostname scheme. There is no test to run. | Nobody can verify this, including tools that say they can. Judge it on behaviour instead. |
| Not a known crawler | The address matches no operator we check, and made no claim. | Neutral. Most internet traffic is neither crawler nor attacker. |
| Failed verification | It claimed a specific crawler and failed a check that operator supports and that actually ran. | The claim is unsupported. Strongest when the address turns out to belong to a different operator. |
Two distinctions here cost people real traffic.
The first is Range match only against Failed. An address in OpenAI's published GPTBot range with no PTR record is not a failure, because OpenAI documents no PTR scheme — there is no second check to fail. A binary tool marks it red, the site owner blocks it, and their content quietly stops being crawled.
The second is Inconclusive against Failed, and it is the one almost nobody implements. If a vendor's range file will not load, an address that is genuinely inside it produces no match — identical output to an address that is genuinely outside it. A tool that cannot tell those apart will accuse honest crawlers every time a feed has a bad day. This one tracks whether each check actually executed and says so.
Microsoft is the clearest example of why the grey tier exists. Bing documents reverse DNS as its verification method and separately publishes a range file. Site owners have reported subnets that appear in bingbot.json and pass Microsoft's own verify tool while failing the reverse DNS check Microsoft tells you to run. That file also still carries a creation date of January 2024. Both sources are official, they disagree, and one of them is over two years stale — Microsoft's own verification guidance describes only the reverse DNS route. A tool that forces that into a yes or no is inventing certainty that does not exist.
What each operator actually lets you check
Your ability to verify bot IP address claims is capped by what each operator chooses to publish, and they differ enormously. This is the current state, read from the operators' own documentation and feeds.
| Crawler | Range feed | Reverse DNS | Best verdict possible | Source |
|---|---|---|---|---|
| Googlebot (Search)Google | Published | .googlebot.com, .geo.googlebot.com | Verified | Docs |
| Google special-case crawler (AdsBot, etc.)Google | Published | .google.com | Verified | Docs |
| Google user-triggered fetcher (not Google-controlled)Google | Published | .gae.googleusercontent.com | Verified | Docs |
| Google user-triggered fetcher (Google-controlled)Google | Published | .google.com | Verified | Docs |
| Google user-triggered agentGoogle | Published | .google.com | Verified | Docs |
| BingbotMicrosoft | Published | .search.msn.com | Verified | Docs |
| GPTBot (OpenAI training)OpenAI | Published | Not documented | Range match only | Docs |
| OAI-SearchBot (ChatGPT search)OpenAI | Published | Not documented | Range match only | Docs |
| ChatGPT-User (live fetch)OpenAI | Published | Not documented | Range match only | Docs |
| ClaudeBot / Claude-User / Claude-SearchBotAnthropic | Published | Not documented | Range match only | Docs |
| PerplexityBot (index)Perplexity | Published | Not documented | Range match only | Docs |
| Perplexity-User (live fetch)Perplexity | Published | Not documented | Range match only | Docs |
| CCBot (Common Crawl)Common Crawl | Published | .crawl.commoncrawl.org | Verified | Docs |
| Amazonbot / Amzn-SearchBot / Amzn-UserAmazon | None | .crawl.amazonbot.amazon | Verified | Docs |
| ApplebotApple | None | .applebot.apple.com | Verified | Docs |
| YandexBotYandex | None | .yandex.ru, .yandex.net, .yandex.com | Verified | Docs |
| BytespiderByteDance | None | Not documented | Unverifiable | None |
| Meta-ExternalAgentMeta | None | Not documented | Unverifiable | Docs |
Google renamed and moved its range files in 2026
If you built anything against Google's crawler IP ranges before this year, check it. 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. There are five files now, not one: common crawlers, special-case crawlers, two user-triggered fetcher lists, and a newer user-triggered agents list for Google systems acting on a person's behalf.
The failure mode here is silent. A verification script that stops receiving range data does not usually crash. It just starts finding no matches, and every Googlebot request begins failing verification. If your bot rules turned unexpectedly strict this year, this is the first thing to check — and it is exactly why this page reports a missing feed as inconclusive rather than as a failed check.
When a verdict tells you the address belongs to somebody else entirely, the next question is which network. An ASN lookup names the operator behind any address, and a datacenter check tells you whether it is simply rented cloud space — which is where most impersonation traffic originates.
What this tool cannot do
A tool that only lists its strengths is not much use when you are deciding whether to block real traffic. There are real limits on what any attempt to verify bot IP address claims can establish, and here is where this one stops.
It cannot prove intent
A verified Googlebot address is verified as Google's. It says nothing about how hard it is crawling you or which paths it is hammering. Identity and behaviour are separate questions.
A non-match is weak evidence
Operators move infrastructure faster than they update published files. Perplexity's range file has not been revised since February 2025 and Microsoft's since January 2024. An address outside a stale list can be perfectly genuine.
It cannot see your user-agent
You tell it what the request claimed. It has no access to your logs, so it cannot catch a request that declared nothing at all — and a scraper running a headless browser from a residential proxy declares nothing.
It checks one address at a time
Log analysis needs volume, patterns and repeat offenders, none of which a single lookup gives you. For one suspicious line in a log this is the right tool; for a week of traffic it is not.
It depends on DNS answering right now
The reverse lookup runs against our resolver with a hard time limit. A slow authoritative server produces a timeout here where a patient resolver would have got an answer — which is reported as inconclusive, not as a failure.
It cannot separate bots that share ranges
Anthropic publishes one file for three agents, and GPTBot and OAI-SearchBot overlap. Where an address matches several, the range check has genuinely reached its limit — and the tool says so rather than picking one.
If a verdict here disagrees with what your logs plainly show, trust the logs. This tool reads what operators publish, and operators are sometimes wrong about themselves. When you want to know who runs an address regardless of what it claims, an ASN lookup on the network operator is the more reliable question to ask, and a reverse IP lookup shows what else lives on the same host.
Frequently asked questions about bot verification
How do I verify a bot IP address?
Run two checks. First, reverse DNS the address and confirm the hostname sits under a suffix the operator documents, then forward-resolve that hostname and confirm it returns the same address. Second, check the address against the operator’s published CIDR range file. A user-agent string on its own proves nothing, because the client writes it.
What is FCrDNS and why does it matter?
FCrDNS means forward-confirmed reverse DNS. You resolve the IP to a hostname using its PTR record, then resolve that hostname back to an IP and confirm you land on the address you started with. The second step is what makes it meaningful, because whoever controls the reverse zone for an address can point the PTR record anywhere they like.
Why does this tool give six verdicts instead of yes or no?
Because a single failure label hides four different situations: an operator that publishes nothing to check against, an operator that publishes ranges but documents no reverse-DNS scheme, a check that could not run at all, and a check that ran and failed. Only the last points toward a forged user-agent, and only the last should ever make you block anything.
Can a fake Googlebot pass verification?
Not if you run both checks properly. A spoofer can send any user-agent and can set a PTR record on address space they control, but they cannot make Google’s forward DNS resolve their hostname to their address, and they cannot place their address inside Google’s published ranges. The forward confirmation step is the one that closes the door.
My IP passed reverse DNS but is not in the published range. Is it fake?
No. A confirmed reverse DNS loop is conclusive on its own, because the forward lookup has to be served by the operator’s own nameservers. Range files lag behind infrastructure, so a genuine new crawler address routinely sits outside the file for a while. This tool reports that as verified. A checker that demands both will tell you a real Googlebot is a fake.
My IP is in the published range but reverse DNS fails. Is it fake?
Not necessarily. Operators do publish addresses whose reverse DNS is incomplete, and Microsoft is a documented example where the range file and the reverse DNS guidance disagree for some subnets. Treat the range match as the stronger signal, re-run the check, and look at how the traffic behaves before acting.
Which AI crawlers can actually be verified?
OpenAI, Anthropic, Perplexity and Common Crawl publish machine-readable range files, and Common Crawl also recommends reverse DNS. Google, Microsoft, Apple, Amazon and Yandex document reverse DNS schemes. ByteDance and Meta publish neither for their AI crawlers, so requests claiming to be Bytespider or Meta-ExternalAgent cannot be verified at all.
Did Google change its crawler IP range URLs?
Yes. In 2026 Google moved the files from the search API path to a crawling path, and renamed googlebot.json to common-crawlers.json. The old directory redirects, but a script hardcoded to the old filename will not find the new file. Anything you built before 2026 against those URLs is worth re-checking.
Does a failed check mean I should block the IP?
No. A failed check means the claim is unsupported, not that the traffic is hostile. Published range files lag behind infrastructure changes, so a genuine new crawler address can sit outside a list for weeks. Combine the verdict with request rate, the paths being hit, and whether robots.txt is honoured — noting that RFC 9309 states plainly that its rules are not a form of access authorization.
Related IP & network tools
Verification answers who. These answer where, what, and what to do next.
Browse the full set on the TrustMyIP tools directory.
Now decide what to do about it
Knowing a crawler is genuine is step one. If you have decided it should not be crawling you, the blocker builds robots.txt and firewall rules from the same live vendor ranges this page just checked against.
Last updated 21 August 2026 · Ranges read from operator feeds · DNS resolved at request time · No lookups logged