Agent 来过你的网站，为什么访客统计里看不到

Agent 读取了一篇文章，访客统计没有变化，未必是统计出了故障。假如客户端只下载正文，没有运行页面里的统计脚本，这次读取就可能没有产生浏览器侧的访问事件。

第七期提到金刚做的一项尝试：基于 Umami，把访问日志和页面 JavaScript 统计放在一起。项目刚上线，网站流量还小，暂时无法据此判断 AI 与人类的流量占比。两种数据合起来，首先要解决的是口径问题。

一次页面访问，可能产生很多请求

Umami 的接入说明使用网页追踪脚本收集数据。只读 HTML 的客户端可能漏记，执行了脚本的自动化浏览器则也可能产生事件，所以脚本统计本身不能充当人类访问量。

服务器或 CDN 日志记录请求。浏览器打开一篇文章，可能继续请求图片、字体和接口；一个 Agent 也可能反复读取同一网址。把这些请求全加起来，会得到一个比读者人数大得多的数。

用户从 AI 答案里点击来源，又是一次独立访问。它可能带着可识别的推荐来源，也可能没有。仅靠本站日志，通常无法还原文章出现过多少次、出现在什么答案里。

Cloudflare AI Crawl Control 已经提供 AI 爬虫、运营方和请求情况等视图。节目里提出的统计缺口，不能理解为市面上没有相关工具。

Cloudflare 文档说明，免费方案依靠 User-Agent 识别已知、主动声明身份的 AI 爬虫。这个数字的含义是按该规则识别出的请求量，不能扩展为全部 Agent 活动。

对站长来说，可以先查几件有明确用途的事：文章正文是否成功返回，旧网址是否持续报错，Markdown 入口有没有被读取，某个爬虫是否频繁请求无效路径。即使无法识别所有客户端，也能据此修正链接和响应。

假设一天有一千次自动化请求和一百次页面浏览，直接相除没有意义。两边既可能重复，也可能漏记，而且单位不同。

若想比较文章正文的访问，可以先统一时间段和路径范围，排除静态资源，再分别记录成功请求、失败请求和客户端识别方式。即便做完这些，结论仍应称为某类请求的占比，不能写成读者构成。

若目标是知道 AI 是否带来了新读者，就单独查看能识别来源的点击，以及这些访问之后是否继续阅读。若目标是减少服务开销，则看请求频率、缓存命中和异常路径。把报表对应到要做的决定上，数字才不容易被误用。