Agent activity answers the question robots.txt cannot: which AI agents actually requested your site, and what happened on those requests? It reads the logs you already own — your CDN or edge worker's view of each request — rather than adding any code to your pages.
Setup sources and coverage
Each transport ships its own panel on Analytics; panels are never combined, because the same request can legitimately arrive through more than one transport and a combined total would double-count it:
| Source | Coverage label | Why |
|---|---|---|
| Cloudflare Worker (you install) | Near-complete | Runs on every edge request |
| Vercel Log Drains | Sampled | Drains are batched and can drop entries |
| Manual API | Customer-reported | You choose what to ship |
Connect any of them from Dashboard → Settings → Integrations → AI crawler logs. Available on Scale and Agency plans during beta.
Installing the Cloudflare Worker
You can install the Worker yourself by pasting the code from the setup guide, or let Stride install it. For the automatic install, create a Cloudflare API token (My Profile → API Tokens → Create Custom Token) with three permissions: Account · Workers Scripts · Edit, Zone · Workers Routes · Edit, and Zone · Zone · Read, limited to your site's domain. Paste it into the setup guide and choose Install Worker.
Stride uses the token once and does not save it; you can delete it in
Cloudflare afterward. The install adds one Worker and routes for your domain
and its www subdomain. If another Worker already runs on your domain, Stride
stops without changing anything, so your existing Worker keeps working. In
that case, add the logging code to your own Worker instead. The Worker only
runs on hostnames proxied through Cloudflare (orange cloud in DNS).
If you installed the Worker before October 1, 2026, replace it with the current version from the setup guide, or reinstall it automatically. The earlier version reported every request and could drop crawler visits on busy sites.
Verified, claimed, rejected
Every request is classified into exactly one of three identity states:
- Verified — the source IP checks out against the agent operator's published identity (forward-confirmed reverse DNS or their published IP ranges). Only verified requests can ever attach to your proof records.
- Claimed — the user agent says "I'm GPTBot", but the identity could not be checked. Counted separately, never as verified.
- Rejected — the IP contradicted the claimed identity. These count as rejected and never as verified or claimed activity.
Identity is one dimension and the HTTP status is another: a verified request that got a 404 still counts as a verified request, and as a 4xx failure.
What is collected, and for how long
- The Cloudflare Worker sends only requests from known AI crawlers and agents. Requests from everyone else never leave Cloudflare.
- Requests are stored path-only — no query strings, no visitor personal data, no response bodies.
- Raw log events purge after 30 days.
- Daily aggregates — including per-path, per-status breakdowns — keep for 400 days. The "All" range on Analytics means this retained window, not unlimited history.
- Deleting your site or organization deletes the data (cascade), and revoking an ingest key stops collection immediately. Proof records already written from verified visits are historical ledger entries and are not deleted by a key revocation or plan downgrade.
User-triggered fetches are different
Fetches from user agents like ChatGPT-User fire when a person opens a cited
link inside an assistant. They are a live signal that humans are clicking
through to your site from AI answers — an activity proxy, not a retained
AI response. Citation evidence in Stride always comes from retained AI
answers, never from these fetches.
Associated evidence, not causation
When a verified agent requests the exact page a shipped change targeted — on a UTC day after the deployment day — Stride records a dated "Agent visit" step on that effort's Proof of work timeline. The strict day boundary exists because daily aggregates cannot prove a request happened after a deployment on the same day, so same-day visits are conservatively not attached.
This is association: the visit is measured, dated, and real, but a visit after a change is not proof the change caused it — just as a later scan movement or a GA4 window is observed timing, not causation. Steps without evidence say what they're waiting on (Waiting on a visit for this step), Can't tell with the reason, or Not tracked.