Languages

Googlebot Verifier

Free, no signup. Anything can put "Googlebot" in a user-agent string — the IP address is what actually tells you who's crawling. Paste it in and get a verdict from two independent methods: the operator's published IP ranges and forward-confirmed reverse DNS (FCrDNS). If it's a fake, you'll see who the IP really belongs to.

Built by Patrick Stox

Crawler lists updated 18 days ago.

Pick the bot the user-agent string claims — spoof detection only runs when there's a claim to test. Try it with a real one: — fills the form; press Verify to run the check (checks are rate-limited).

Example data — replace with your own, then press Verify

Checks run from our server; we fetch the URL you enter and don't keep the results. Submitted IPs are checked in memory, never stored. Anonymous aggregate verdict counts feed our research posts; domains are counted once via an anonymized hash, never stored in the clear. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Bot Verifier? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 
Bulk IPs or access-log lines
 
Paste up to 500 IPs or log lines. Published-range matching and user-agent claim extraction run entirely in your browser. Use Spot-check only for the few rows where you want live reverse-DNS confirmation.
  
    
 
 
 
 
Sample report Example data — real, DNS-verified result
 

You spot this line in your access log and want to know if it's really Google:

 
 
66.249.66.1 - - [08/Jul/2026:14:22:10 +0000] "GET /pricing HTTP/1.1" 200 "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
 
 

You paste 66.249.66.1 and choose Googlebot. The tool returns:

  
     
  • Both checks independently pass. The IP falls inside Google's published range
and its PTR record forward-confirms — see
what the five verdict tiers mean for why that combination is the
            strongest possible result.
    •  
  • Treat the identity as genuine. A green Verified badge means this really is
            Googlebot. Make any separate allow, rate-limit, challenge, or block decision from the crawler's
            behavior and your site policy.
    •  
  • What a fake would look like instead. Had the IP matched no range and failed
            reverse DNS, the badge would read Spoofed and the evidence would name the network the IP
            actually belongs to, with copy-paste block rules underneath.
    •  
  • New to crawler identity checks? User agent covers why the
            string alone proves nothing, and AI crawlers explains who's
            crawling and why.
    •  
 
 
 
How to use it
 
     
  1. Grab the IP address of the request from your server logs — not the user-agent
            string, which any script can forge. Paste it into the IP field (IPv4 or IPv6).
    2.  
  2. In Claims to be, pick the crawler the user agent says it is (for example
            Googlebot). Spoof detection only runs when there's a claim to test; leave it on
Auto-detect to just see whether the IP belongs to any known crawler.
    3.  
  3. Press Verify. The tool checks the operator's published IP ranges and runs
            forward-confirmed reverse DNS, then returns a coloured verdict badge.
    4.  
  4. Open Evidence to see the matched range, the PTR hostname, whether the forward
            lookup confirmed, and — for fakes — the real network owner (ASN).
    5.  
  5. If the verdict is Spoofed, copy the ready-made Cloudflare, nginx, or Apache
            block rule from the panel that appears.
    6.  
 
 
      
     
Supported bots and verification methods
 

Not every operator makes verification possible. Some publish IP ranges and support reverse DNS, some publish ranges only,
        and some publish nothing at all — a user agent alone proves nothing, since any script can send any user-agent string.

 
 
 
BotOperatorTypePublished IP listReverse DNS
  
 Googlebot · docs Google Search ✅ 315 ranges ✅ .googlebot.com, .google.com 
 Google special crawlers · docs Google Search ✅ 270 ranges ✅ .google.com 
 Google user-triggered fetchers · docs Google User-triggered ✅ 1550 ranges ✅ .gae.googleusercontent.com, .google.com, .googleusercontent.com 
 Bingbot · docs Microsoft Search ✅ 28 ranges ✅ .search.msn.com 
 YandexBot · docs Yandex Search ❌ none ✅ .yandex.ru, .yandex.net, .yandex.com 
 Baiduspider · docs Baidu Search ❌ none ❌ 
 Yeti · docs Naver Search ❌ none ❌ 
 GPTBot · docs OpenAI AI training ✅ 21 ranges ❌ 
 OAI-SearchBot · docs OpenAI AI search ✅ 35 ranges ❌ 
 ChatGPT-User · docs OpenAI User-triggered ✅ 258 ranges ❌ 
 ClaudeBot · docs Anthropic AI training ✅ 20 ranges ❌ 
 PerplexityBot · docs Perplexity AI search ✅ 8 ranges ❌ 
 Perplexity-User · docs Perplexity User-triggered ✅ 4 ranges ❌ 
 Applebot · docs Apple Search ✅ 12 ranges ✅ .applebot.apple.com 
 Amazonbot · docs Amazon AI training ❌ none ✅ .crawl.amazonbot.amazon 
 DuckDuckBot · docs DuckDuckGo Search ✅ 481 ranges ❌ 
 Meta-ExternalAgent · docs Meta AI training ❌ none ❌ 
 Bytespider ByteDance AI training ❌ none ❌ 
  
 
 
How verification works
 
 
     
  1. Published-range check. The IP is matched against the operator's official IP range list (the same JSON files Google, Microsoft, OpenAI, Perplexity, Apple, and DuckDuckGo publish), refreshed weekly.
    2.  
  2. Forward-confirmed reverse DNS (FCrDNS). For bots that support it, the IP's PTR record must resolve to an official hostname (e.g. crawl-66-249-66-1.googlebot.com) at a domain-label boundary, and a forward lookup of that hostname must answer the exact same IP. Both directions must agree — a PTR record alone is trivially fakeable.
    3.  
  3. Naming the spoofer. When a claim fails both checks, the IP's actual network owner is looked up via its ASN, so the verdict says who it really is instead of just "not Googlebot."
    4.  
 
The verdict tiers are deliberately distinct: reverse-DNS confirmed is proof; a published-list match is strong but not confirmation; and unverifiable bots such as Bytespider and Meta publish no machine-readable range list — treat those user agents with suspicion. ClaudeBot now has an official published list, so it can return a list match even though Anthropic does not document reverse-DNS verification.
 
 

Need evidence across many requests? Use the Log File Analyzer to inspect crawl budget by bot and section, status-code waste, and spoofing signals. Log parsing stays in your browser.

  
 
What the results mean
 
The badge colour maps to one of five verdicts:
 
     
  • Verified — reverse-DNS confirmed — the strongest
            result. Forward-confirmed reverse DNS resolves to an official crawler hostname. This is proof.
    •  
  • In published ranges — the IP falls inside the operator's
            published IP list. Strong, but not the same as reverse-DNS confirmation (used for crawlers that
            publish ranges but don't support rDNS).
    •  
  • Spoofed — the IP claims a crawler it isn't in any
            range for and fails reverse DNS. The evidence names who the IP really belongs to, and block rules
            appear below.
    •  
  • Unverifiable — the claimed operator publishes no
            machine-readable IP ranges and supports no reverse DNS (for example Bytespider and Meta), so the
            claim can't be confirmed or denied. Treat with suspicion. ClaudeBot can now return a published-list
            match, though Anthropic does not document reverse-DNS verification.
    •  
  • Not a known crawler — the IP doesn't match any known
            crawler's ranges and no claim resolved. It's ordinary traffic, or a bot you'd manage by behaviour.
    •  
 
How it works
 

Verification runs on a small server endpoint (/api/verify-bot) because it needs live
          DNS and a network-owner lookup your browser can't do. It never runs JavaScript against your site or
          stores the IP — the address is checked in memory and discarded.

 
     
  • Published-range match. The IP is tested against the operator's official CIDR
            ranges — the same JSON lists Google, Microsoft, OpenAI, Perplexity, Apple, and DuckDuckGo publish,
            baked into the tool and refreshed weekly.
    •  
  • Forward-confirmed reverse DNS. For crawlers that support it, the IP's PTR
            record must resolve to an official hostname at a domain-label boundary, and a forward lookup of
            that hostname must answer the exact same IP. Both directions must agree.
    •  
  • Naming the spoofer. When a claim fails both checks, the IP's ASN is resolved so
            the verdict can say who the network really is instead of just "not Googlebot."
    •  
 
Features
 
     
  • Two independent checks — published IP ranges and forward-confirmed reverse DNS — not a
            user-agent string match.
    •  
  • Five distinct verdicts, including an honest Unverifiable for operators that publish
            nothing.
    •  
  • Evidence drawer showing the matched range, PTR hostname, forward-confirmation result, ASN owner,
            and when the range lists were last fetched.
    •  
  • Copy-paste block rules (Cloudflare WAF, nginx, Apache) generated for any IP flagged spoofed.
    •  
  • A coverage table of every supported crawler — operator, type, whether it publishes ranges, and
            its reverse-DNS suffixes.
    •  
  • IPv4 and IPv6 supported; IPs are checked in memory and never stored; range lists refreshed weekly.
    •  
 
Limitations
 

Verification is only as good as what an operator publishes. Crawlers that publish neither a
          machine-readable range list nor a reverse-DNS method (including Bytespider and Meta) can only ever
          come back Unverifiable.
          Bulk mode can match up to 500 IPs or access-log lines against the committed range snapshot in your browser,
          but live reverse-DNS confirmation still runs one selected row at a time through Spot-check.
          For deeper crawl-budget analysis across a whole log, use the Log File Analyzer.
          The verifier reflects
          the IP as it is right now; a spoofer that has since moved will read differently. And it verifies
          identity, not intent — a genuinely verified crawler can still be one you'd rather rate-limit.

 
Frequently asked questions
 
How do I verify Googlebot is real?
Take the IP address from your server logs (not the user-agent stringA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., which anything can fake) and check it two ways: match it against GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.'s published IP ranges, and run a forward-confirmed reverse DNS lookup — the IP's PTR record should resolve to a hostname ending in googlebot.com or google.com, and a forward lookup of that hostname must return the same IP. This tool does both automatically when you paste the IP and pick Googlebot.
What is forward-confirmed reverse DNS (FCrDNS)?
FCrDNS is a two-way DNS check. First a reverse lookup turns the IP into a hostname via its PTR record; then a forward lookup of that hostname must resolve back to the exact same IP. Both directions have to agree at an official domain boundary. A PTR record on its own proves nothing because the owner of an IP block can set it to any string, so the forward confirmation is what makes it trustworthy.
Why does a crawler show as "unverifiable" instead of verified or spoofed?
Some operators — Bytespider and Meta's crawler among them — do not publish IP ranges or support reverse DNS, so there is no authoritative range/DNS check for their claims. The tool returns "unverifiable" rather than guessing. Anthropic is no longer in that bucket: it publishes an official crawler IP list. A match is reported specifically as a published-list match, not as reverse-DNS confirmation, and a user-agent string alone remains spoofable.
Can I block a fake crawler by IP?
You can, and the tool gives you copy-paste block rules for Cloudflare, nginx, and Apache when a verdict comes back spoofed. But blocking a single IP is whack-a-mole — spoofers rotate addresses. For persistent fake-crawler traffic it is more effective to block by the ASN (network owner) the tool names in the evidence, or to use your firewall's bot-management rules.
Does checking an IP here store or log it?
No. Submitted IPs are checked in memory against the published range lists and live DNS, and are not written to any store. The range lists themselves are refreshed weekly from the operators' official sources, so a verdict reflects ranges that are at most a few days old.
 
 
 
     
Next stepXML Sitemap Generator — generate the corrected version.

People also explore
ToolLog File AnalyzerToolrobots.txt TesterToolAI-Crawler Access CheckerArticleUser AgentArticleAI Crawler Log AnalysisArticleCrawling
 
 
 
Feature requests for Bot Verifier
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
   
 
Where this tool helps
Common use cases
Verify a claimed search crawler before allowlisting it
Check the request IP against the operator's published ranges and, where supported, forward-confirmed reverse DNS instead of trusting a user-agent string.
Investigate a suspicious crawler request
Compare a claimed identity with the matched range, reverse-DNS evidence, forward confirmation, and actual network owner before deciding whether the request is genuine.
Triage a batch of access-log lines locally
Paste up to 500 IPs or log lines, extract user-agent claims, match committed crawler ranges in the browser, and promote only selected rows to a live spot-check.
Create a firewall handoff for a confirmed mismatch
Use the spoofed verdict, evidence, result card, and generated Cloudflare, nginx, or Apache rule as a starting point for a least-privilege security review.
Separate crawler identity from crawler policy
Confirm who operates the request first, then make a separate decision about rate limits, access, or blocking based on behavior and site policy.
Watch the full workflow
Googlebot Verifier walkthrough
Read the transcript

      
      

        
Bot Verifier

        

        
This beginner walkthrough shows how Bot Verifier checks whether a request claiming to be Googlebot or another crawler is genuine. We will cover the practical use cases, a complete verified example, the evidence behind the result, browser-local bulk matching, a claimed-bot mismatch, exports, limitations, and the safest next step.

      

      

        
Step 1

        

        
Anything can send text that says Googlebot. Bot Verifier starts with the request’s network address instead. It compares that address with current operator-published ranges and, where the operator supports it, checks that the reverse hostname belongs to the official domain and resolves forward to the same address. That gives you evidence about identity before you allow, challenge, rate-limit, or block traffic.

      

      

        
Step 2

        

        
Use the tool before allowlisting a claimed search crawler, when investigating a suspicious request, when triaging a batch of log lines, or when creating a firewall handoff for a confirmed mismatch. The last use case matters most: identity and policy are separate. A genuine crawler can still be too aggressive, while an unverifiable claim is not automatically proof of abuse.

      

      

        
Step 3

        

        
Paste the address from your server or edge log into “IP address”. Under “Claims to be”, choose the crawler named by the request’s user-agent string. Leaving the selector on auto-detect can find a known published range, but a claimed crawler is required for mismatch detection. Submitted addresses are checked in memory and are not stored, while anonymous aggregate verdict counts support research.

      

      

        
Step 4

        

        
The sample report uses a known Googlebot address. The green badge says “Verified — reverse-DNS confirmed”. Beneath it, the evidence shows a Google range, an official Googlebot hostname, and a forward lookup that returns the same address. Two independent checks agree, so this is the strongest identity result the tool can show.

      

      

        
Step 5

        

        
The workflow is simple. Copy the request address from your logs. Select the claimed crawler. Choose “Verify”. Open “Evidence” and review the published range, reverse hostname, forward confirmation, range date, and network owner when available. If a claimed identity fails, investigate the request and review any generated firewall rule before changing production security.

      

      

        
Step 6

        

        
Choose the example labelled “66.249.66.1 as Googlebot”. It fills the address and crawler claim without spending a request. For this walkthrough, the verification endpoint is fulfilled locally with a fixed response built from the refreshed range snapshot. Every external response is blocked, so the result is safe, repeatable, and clearly a demonstration rather than a live lookup.

      

      

        
Step 7

        

        
Choose “Verify”. The status reports that the tool is checking published ranges and the two-way name lookup, then the result opens below the workflow. A live answer can change when operators rotate ranges or name records, so important access decisions should be rerun against current evidence. This fixed capture demonstrates exactly how to read the result.

      

      

        
Step 8

        

        
The verdict is “Verified — reverse-DNS confirmed”. The message explains that the address is genuinely Googlebot because the reverse record resolves to an official Googlebot hostname and a forward lookup returns the exact original address. The result-card download preserves a compact handoff, while “What this result means” jumps to the definitions for every verdict tier.

      

      

        
Step 9

        

        
Open “Evidence”. The matched range is 66.249.66.0 slash 27 from the operator-published list. The reverse hostname ends at the official googlebot dot com boundary. The forward lookup says “Yes”, the resolver state says “confirmed”, and the range result records an observed match. My favorite part is that the evidence stays separate from the headline, so a reviewer can reproduce the reasoning instead of trusting a green badge alone.

      

      

        
Step 10

        

        
The tool keeps five outcomes separate. Reverse-DNS confirmed is the strongest proof. “In published ranges” is a strong list match but not the same proof. “Spoofed” means a claimed crawler failed the available identity checks. “Unverifiable” means the operator publishes too little evidence to decide. “Not a known crawler” is neutral ordinary traffic or an unknown bot, not a security verdict by itself.

      

      

        
Step 11

        

        
For a quick batch, paste up to five hundred addresses or access-log lines. Published-range matching and user-agent claim extraction run entirely in your browser. That keeps the first pass fast and private. Use “Spot-check” only for selected rows that need the live reverse and forward name test, because the local range match alone cannot provide that confirmation.

      

      

        
Step 12

        

        
Choose “Match pasted rows”. The tool parses three fixed rows locally. The first Googlebot claim matches a published Google range. The documentation-only address with the same claim becomes “claim mismatch”, and the plain documentation address has no range match. These are triage labels. They help you choose what to investigate; they are not all complete identity verdicts.

      

      

        
Step 13

        

        
The status confirms that three rows were matched locally. Each row keeps the address, detected user-agent claim, range result, and a “Spot-check” action. “Download CSV” creates a spreadsheet-friendly handoff for the batch. Use the spot-check on a current public address when a range mismatch would affect access, and keep the original log line and timestamp with the review.

      

      

        
Step 14

        

        
Now check the fixed address 1.1.1.1 with a Googlebot claim. The fixture returns “Spoofed” because the address matches no Google crawler range, its hostname is not an official Googlebot name, and the network owner is Cloudflare rather than Google. This demonstrates the mismatch interface. It is not a fresh accusation about a live request.

      

      

        
Step 15

        

        
A confirmed mismatch opens exact-address examples for Cloudflare, nginx, and Apache. Do not paste one directly into production without checking the current request, rule syntax, scope, logs, and rollback path. Blocking one address is also temporary when an abusive client rotates networks. Use the generated rule as an engineering handoff, then prefer the smallest verified-bot or behavior-based control your edge supports.

      

      

        
Step 16

        

        
The coverage table shows each crawler, its operator and purpose, whether it publishes a machine-readable range list, and whether it documents reverse-domain verification. In this visible section, Googlebot supports both methods. GPTBot has a published list but no documented reverse-name method. Yandex documents reverse-domain checks without a list, while Baiduspider and Yeti show neither method.

      

      

        
Step 17

        

        
This feature summary highlights two independent identity checks instead of a user-agent match, five distinct verdicts including an honest “Unverifiable”, an evidence drawer with ranges, hostnames, forward confirmation, network owner, and fetch date, exact-address firewall examples, the supported-crawler coverage table, version four and version six addresses, in-memory handling, and weekly range refreshes.

      

      

        
Step 18

        

        
Verification is only as complete as the evidence an operator publishes. Bytespider and Meta can remain “Unverifiable” when neither a machine-readable list nor reverse-domain method is available. Local bulk mode uses the committed range snapshot, while live name confirmation runs one selected row at a time. Addresses can move, and a verified identity does not decide whether you want that crawler’s behavior. Rerun important checks, then make the access decision independently.

      

      

        
Verify the address. Read the evidence. Then choose the policy.

        

        
Save the request address, claimed crawler, range-list date, reverse and forward name evidence, verdict, and final access decision together. Recheck important requests against current operator evidence. Most of all, do not let a copied user-agent string become an allowlist. Verify identity first, then apply the smallest policy that fits the crawler’s behavior and your site.

      

    
 
          
 
Common issues & how to fix them
 
     
  •  Error Crawler IP is outside the operator’s published range Fix: Treat the crawler as unverified and block or investigate it until its IP matches a published range. 
  •  Error Reverse DNS does not match the claimed crawler Fix: Treat the request as unverified unless reverse DNS ends in the crawler operator’s published domain; block or investigate mismatches. 
  •  Error Forward DNS does not confirm the reverse host Fix: Resolve the reverse-DNS hostname and require it to map back to the requesting IP before trusting the crawler. 
  •  Warning Crawler identity cannot be verified conclusively Fix: Collect the missing evidence and treat the result as unverified until it can be confirmed. 
  •  Warning Published range snapshot is stale Fix: Refresh the operator range snapshot and rerun verification before trusting the IP verdict. 
    •