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 .
Baiduspider Pattern Reference Checker
Was this tool helpful to use?
Your feedback helps us make it better
Match User-Agent text and IPv4 input against the tool’s embedded Baiduspider patterns and reference ranges.
UA is spoofable; network-collected static ranges have unverified sources/dates and do not identify a crawler. DNS checks PTR suffix and forward address per Baidu documentation; lookup failures remain unknown. DNS runs on the server; UA/range comparisons run in the browser. Reference
Enter User-Agent for Baidu spider identification.
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
This checker gives you three separate clues about a suspected Baiduspider request. In User-Agent mode, paste the header text to see whether it contains the word Baiduspider, which recognized subtype pattern appears, any version-like number, and a help URL included in the text. In IP mode, enter an IPv4 or IPv6 address to check its format and compare IPv4 addresses with eight embedded historical network ranges. A range match means only that the address falls inside one of those references.
For a stronger check, IP mode also offers an explicit reverse-and-forward DNS lookup. It checks whether a reverse lookup returns a hostname beneath baidu.com or baidu.jp, then whether a forward lookup of that hostname returns the entered IP. Baidu’s guidance describes this two-way check against the source address in your server logs and says its crawler IP pool changes, so a fixed complete IP list is not available. The embedded ranges have unverified sources and dates; they are not Baidu’s official list. Baidu’s crawler identification guidance explains why a static range comparison is not enough.
These outputs answer different questions: a User-Agent match detects a claim in text, a range match compares an address with a local reference, and a successful DNS result checks the two DNS conditions for that address at lookup time. Only the DNS lookup uses DNS; the other two are pattern comparisons. None of these checks authenticates every part of an HTTP request or establishes that a request is safe.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use the User-Agent string and source IP from a trusted server or edge log. A browser’s own User-Agent can be loaded as an example, but it does not represent a Baiduspider visit to your site.
Choose User-Agent Identification and paste the complete value. The result can flag the main Baiduspider token or patterns such as image, video, news, mobile/render, favorites, alliance, and ads. It may also show a version, mobile indicators, and a URL written into the string. Treat all of these as text clues because a sender can copy or invent them.
Choose IP Range Lookup and enter a literal IP address; hostnames are not accepted. A valid IPv4 may show one matching embedded range or no range match. IPv6 can be submitted for the DNS check, but it cannot match the IPv4 reference ranges. Select “Verify reverse + forward DNS” when you want the additional check. It is an explicit lookup, not an automatic result of entering an IP.
“Verified” means a returned hostname met the Baidu suffix rule and a forward lookup returned the entered address. “Does not pass” means the available DNS result did not satisfy that rule. “Unknown” means DNS could not establish a conclusion, such as when lookups fail. Keep the source IP and timestamp with the log evidence when reviewing the event.
Use cases
See how the tool fits into real work and everyday tasks.
A site operator can compare the request’s complete User-Agent and logged source IP, then run the DNS check before deciding how to classify the event.
If requests claiming to be Baiduspider behave unexpectedly, use the DNS result as one identity signal and compare it with timestamps, paths, and other server-side evidence.
Record whether the finding was a UA text match, an embedded-range match, or a successful two-way DNS check. Naming the check prevents a preliminary pattern result from being recorded as a confirmed identity.
Q&A
Find concise answers to common questions and confusing cases.
No. The User-Agent is a sender-provided string and can be spoofed. Use the source IP from a trusted request log and check reverse DNS followed by forward DNS; the text match alone is not authentication.
No. The ranges are historical network references with unverified provenance and dates. Baidu says its IP pool changes and does not provide a complete fixed list. A match is not proof, and no match does not prove the request is fake.
The lookup could not confirm or reject the DNS rule, commonly because DNS did not return a usable answer. It is an inconclusive result, not a failed identity check. Retry later or run the two lookups in an environment where you can inspect DNS responses.
Notes
Review scope, result limitations, and important precautions before use.
Use an IP taken from a trusted request log, not an arbitrary address or an untrusted forwarded header. The DNS action makes DNS queries for the supplied address; it does not connect to that address. A successful result applies to the checked IP and DNS responses at that time, not to the integrity of the whole request. A failed or unavailable lookup can reflect DNS conditions and should not automatically be treated as proof of impersonation.
Do not use the embedded historical ranges or a User-Agent match alone to create firewall allowlists, block rules, or access permissions. Baidu notes that its crawler IP pool changes and recommends checking actual request IPs through DNS rather than relying on a fixed complete range list. Review your logs and operational context before taking action.
Related
Discover related tools, collections, and available API capabilities.