We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Check an IPv4 or IPv6 address from your access logs using PTR records, forward-confirmed DNS, and published crawler IP ranges.
Enter a source IP from your logs to inspect the full verification chain
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
Enter one IPv4 or IPv6 source address. Results show the address family, a provider label when supported evidence exists, and separate evidence for reverse DNS, forward DNS, and a match against selected published crawler ranges. This checks an IP, not a User-Agent or an entire log.
Reverse DNS (PTR) looks up hostnames for the submitted address. Forward confirmation resolves a recognized hostname and checks whether the original IP appears among the returned addresses. The independent range check compares the address with published lists used here for Google common crawlers, Bingbot, and DuckDuckBot.
These labels summarize evidence, not intent. Unverified does not mean malicious; verified does not decide whether the request should reach a particular route.
Range matching covers Google common crawlers, Bingbot, and DuckDuckBot. Recognized reverse-hostname suffixes also include Google, Bing, Baidu, and Yandex. The checker does not cover every search engine, preview fetcher, SEO service, or private bot. Baidu and Yandex use hostname and forward-DNS evidence here, not a loaded published range list.
DNS responses and published IP ranges change, and a source may be unavailable during a query. Read the source status and date shown with the result. Do not turn a previous result into a permanent allowlist.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use the address from the request being reviewed. Do not paste its User-Agent, hostname, URL, port, or multiple lines.
Enter a single IPv4 or IPv6 value and run the check. Invalid address text is rejected.
Read the PTR hostname, forward result, and range match independently. Note when a range source could not be checked.
Record request time, path, frequency, and proxy setup with the lookup before changing access rules.
An address used for a company’s other services is not automatically its search crawler. A familiar hostname is not enough if forward DNS does not return the submitted address. Evidence cards show which separate tests passed.
Use cases
See how the tool fits into real work and everyday tasks.
Take the source IP from the same log line as the claim and compare DNS and range evidence.
Save the result and compare it with current provider guidance and observed request behavior before allowing a disputed address.
If results conflict with expectations, determine whether the logged address is a CDN or proxy node instead of the original client.
Q&A
Find concise answers to common questions and confusing cases.
No. It means the supported tests did not establish identity in that lookup; coverage or upstream evidence may be incomplete.
No. This check takes one IP address. A User-Agent is request text, not proof of its sender.
DNS and published ranges may change, or a source can be temporarily unavailable. Save the lookup time and recheck important decisions.
No. Verification identifies supported crawler evidence, not whether access is suitable for a resource. Apply your own route and behavior policy.
Notes
Review scope, result limitations, and important precautions before use.
Do not rely on one lookup as a permanent allowlist or blocklist. If traffic passes through a CDN or proxy, determine the real client IP using trusted proxy configuration first. Combine the result with request behavior and current operator guidance before security or availability decisions.
Related
Discover related tools, collections, and available API capabilities.