Permission, visits, and outcomes are different.
robots.txt can express crawler policy, infrastructure logs can record requests, and citations or referrals require their own evidence. One layer cannot prove the next.
Verify the crawler, inspect the requested paths, and report only what the evidence supports.
Turn a verified access or traffic finding into one bounded website task.
Open the AI Workspace
An AI bot traffic checker should inspect server, CDN, edge, WAF, or supported tracker records; normalize canonical paths and timezones; match documented crawler identities; verify requests with provider IP data or trusted verified-bot signals where available; group results by provider and purpose; show URLs, status codes, frequency, first and last seen dates, and uncertainty; and explicitly avoid calling a request an index, citation, human visit, or conversion.
This action page covers observed AI crawler traffic. It complements the access checker, which evaluates public robots policy, and the analytics monitor, which summarizes trends over time.
robots.txt can express crawler policy, infrastructure logs can record requests, and citations or referrals require their own evidence. One layer cannot prove the next.
A User-Agent string can be copied. Use provider guidance and available IP or verified-bot evidence before labeling a request as confirmed.
Audit, AI visibility, research, content optimization, and reporting-organized around the website you are improving.
Third-party names and logos are trademarks of their owners and are shown for comparison. Other-tool prices are illustrative monthly benchmarks; exact plans and costs may vary.
Start with the question you need to answer, then use the evidence layer that can actually answer it.
Begin at the collection layer. Browser analytics may not execute for automated clients, so use infrastructure evidence. Confirm which host and proxy layer owns the reliable request record, whether logs cover cached responses, how long they are retained, and whether sampling or exclusions affect the total.
Normalize before counting. Map host variants and redirected paths to the canonical URL, use one timezone, distinguish successful content requests from redirects and errors, and filter assets or health checks when they are outside the question. Show both request totals and unique requested pages so a burst on one URL does not look like broad coverage.
Classify provider purpose without guessing. Training, search, and user-triggered agents can have separate identities and controls. Report unknown or unverified matches explicitly instead of silently assigning them to a provider.
Keep a small evidence record for every important observation: canonical URL, requested path, timestamp and timezone, status code, response bytes, User-Agent, verification state, and the edge or origin source. Aggregate by provider purpose only after preserving raw evidence. Sampling, caching, proxying, log retention, and privacy controls can change totals, so document those boundaries beside the chart.
Separate crawler families by purpose. OpenAI documents GPTBot, OAI-SearchBot, and ChatGPT-User separately; Anthropic distinguishes ClaudeBot, Claude-SearchBot, and Claude-User; Perplexity distinguishes PerplexityBot and Perplexity-User. A policy intended for training collection may not be the policy intended for search discovery or a user-triggered fetch.
Use the result as a diagnosis, not a visibility score. A verified request proves a resource was requested at a particular time. It does not prove indexing, model training, answer inclusion, citation, recommendation, referral traffic, or conversion. Measure those outcomes with their own named reports and dates.
Not reliably. Many crawlers do not execute browser analytics; infrastructure logs are the primary request evidence.
No. It proves only a request at that time. Citations and referrals require separate evidence.
Yes. Use provider verification guidance and label unverified matches honestly.