PSentry does not read your server logs. It measures what the assistants say about you, which is a different question from what they fetched, and no amount of dashboard will turn one into the other. The log side you have to do yourself. It is worth doing, because it is the only place where the traffic is a fact rather than an inference, and because the file already exists on a machine you control.

What follows is a procedure. It assumes you can get at an access log, from your hosting panel, from a CDN, or over SSH. Everything in it is checkable in an afternoon.

Get the log, and know which one you have

If you sit behind a CDN, the origin log is the wrong file: it shows what the CDN forwarded, not what arrived. Cloudflare, Fastly and the rest expose their own request logs, and those are the ones with the whole picture. On plain hosting, look for access.log, or the equivalent in your panel.

You need one field above all: the user agent string. Ideally you also want the client IP and the status code you returned, and those three together are enough for everything below.

Search for the names that actually exist

There are more of them than the lists circulating suggest, and they do not all mean the same thing. Grep the user agent field for these:

GPTBot and OAI-SearchBot and ChatGPT-User, all OpenAI
ClaudeBot and Claude-User and Claude-SearchBot, Anthropic
PerplexityBot and Perplexity-User
Bingbot, which matters more than it looks: several assistants get their web results through it rather than crawling you directly

One name you will not find, and should stop looking for: Google-Extended is not a crawler. It is a token you can put in robots.txt to tell Google not to use your content for Gemini and its model training. Nothing fetches anything under that name, so it will never appear in an access log. Every checklist that tells you to look for it in your logs is repeating something nobody verified.

Separate the training crawl from the live question

This is the distinction that makes the exercise worth the hour, and almost nobody draws it.

GPTBot, ClaudeBot and PerplexityBot are bulk crawlers. They walk your site on their own schedule, gathering pages for training or for an index. A visit tells you the door is open. It tells you nothing about demand.

ChatGPT-User, Claude-User and Perplexity-User are the other kind. They fire when a person, mid-conversation, asks something that makes the assistant go and fetch a page right then. One of those lines in your log is a human being with a question, on your page, at that second. That is the closest thing to intent you will find in this whole category.

So when you count, count them separately. A rise in bulk crawling and a rise in user-triggered fetches mean opposite things, and averaging them into one number called AI traffic throws away the only signal in the file.

Check what you actually returned

Now look at the status codes next to those requests, because this is where sites find real problems.

A wall of 403 means something is blocking them: a WAF rule, a bot-management setting, a rule added during the scraping panic of 2023 and never revisited. A run of 404 against your product pages usually means a migration left the old paths in someone's index. Long stretches of 301 chained one into another are worth flattening. And if the crawler is being served your cookie banner or a challenge page instead of the content, you will see it as a suspiciously identical response size on every request.

Compare that with what your robots.txt says. The two disagree more often than you would expect, because the WAF and the robots file are usually owned by different people.

Verify the ones claiming to be crawlers

A user agent string is text. Anyone can send GPTBot in a header, and scrapers do it constantly, because sites tend to wave those through. So a line in the log is a claim, not a fact.

The check is the same one you already use for Googlebot. OpenAI, Anthropic and Perplexity each publish the IP ranges their crawlers use, as JSON files on their own domains, and several of them also support reverse DNS that resolves back to their infrastructure. Take the client IPs from your log, check them against the published ranges, and drop the ones that do not match. If you have never done this, expect the count of genuine AI crawler visits to come out lower than the raw grep suggested.

What the log will not tell you

Two limits, and they are the reason this procedure is a complement to measurement rather than a substitute for it.

A model can describe your company at length without fetching anything, from what it absorbed in training. Nothing appears in your log at all, and you can be quite visible in exactly that way. The log is blind to it.

And the reverse: a crawler can read every page you have and the assistant can still name a competitor when someone asks who supplies what you supply. Being fetched is not being recommended. The log measures access. What gets said in the answer is a separate measurement, and it is the one PSentry runs, across 4 assistants and in each language you sell in.

Do the log check anyway. It is free, it takes an afternoon, and it is the only part of this whole problem where you get to look at ground truth instead of a sample.