无需 JavaScript 的机器人检测：我的博客测量的内容

没有 JavaScript 的机器人检测：我的博客测量的内容在我的博客上，网络和请求标头规则将 372 个浏览器用户代理请求中的 277 个移出浏览器类别：74.5%。这让我对到达我的 Cloudflare Worker 的流量有了更有用的了解。目前还没有确定有多少人阅读该网站。在相同的两个完整 UTC 日内，其余 95 个浏览器 HTML 观察结果仍然与 14 个 Cloudflare Web Analytics 页面加载不同。有用的结果是了解规则将哪些请求分开、为什么将它们分开以及证据在哪里停止。网络证据捕获通过标头检查的请求。在该窗口中，60 个云分类请求携带了浏览器规则所需的导航标头。每个分类的原因使得计数器可以解释。它还暴露了错误：我们的 HTML 接受检查错误地处理了有效标头，并且新行缺少其网络来源标记。两者均已修复。客户身份和读者群需要不同的证据。九个存储的签名验证可识别签名者，包括爬虫和故意测试。他们不计算请助理阅读的人数。剩下的分歧是一个衡量问题。较少的浏览器数量或与脚本计数器的一致都无法建立受众的准确性。将边缘页面视图与脚本计数器进行比较比较两个计数器暴露了我的第一方分析的问题：我将浏览器用户代理视为读者的证据。计数器测量不同的事件，因此它们的分歧是调查的起点。它本身无法告诉我哪些请求是自动化的。最初的警报来自于 9 月 3 日保存的比较： 源页面事件/加载 客户端或访问指标 D1 浏览器-UA 类，截至 9 月 2 日的 7 个 UTC 天 1,209 578 个每日客户端标识符 Cloudflare Web Analytics，其滚动的 7 天仪表板窗口 113 52 次访问 578 与 52 的差异看起来是读者数量的 11 倍。但每日客户标识符不是一次访问，时间窗口并不相同，并且脚本仪表板包含 /stats 。即使是更具可比性的 1,209 页与 113 页的总页数也需要这些资格。原始查询记录保留进行比较时的情况。请求中有更有力的证据。 9 月 2 日，每日 113 个客户中有 100 个加载了一个页面； 164 个浏览器 UA 页面观察中的 156 个不包含引荐来源网址。仅凭这些事实并不能建立自动化。然而，一个被归类为移动设备的客户端在同一时间戳秒内获取了 31 个不同的页面。那天晚上我的笔记是：我今天看到的每日客户数量为 113，这对我来说似乎令人难以置信，比如他们在阅读哪些文章，它们来自哪里等等...我刚刚发表了一篇新文章，它甚至没有出现在按浏览次数排列的首页中...就像发生了什么...就像有时当我发布帖子时，我想看看这篇特定帖子有多少读者到达以及通过哪些来源到达，这是不可能弄清楚的。但最奇怪的是数字，谁都在读这些文章，这看起来很疯狂，我很欣赏这一点，但我不想让自己受气，就像有些东西没有相加一样。有用的比较需要在计算比率之前做出四个决定：选择相同的主机和明确的开始包含、结束排除 UTC 窗口。将页面事件与页面加载进行比较。分别报告每日标识符和访问情况。记录每个系统排除的路由、响应类型、机器人、所有者和测试请求。保留采样信息和结果。检查差异请求并测试可能的集合差异。 Cloudflare 记录了脚本拦截器和浏览器或网络丢失，作为其信标可能错过页面加载的原因。浏览器缓存和不同的资格也需要根据边缘计数器进行检查。脚本可以在自动浏览器中运行。没有普遍的比率来区分这些原因。 Cloudflare Web Analytics 常见问题解答，于 2026 年 9 月 6 日查看。比较揭示了我们可以调查的问题。本文的早期版本的两岁以下验证阈值不受支持，我已将其删除。 Cloudflare Worker 中的请求规则 Worker 对记录的请求特征进行分类。它可以确定性地应用这些规则，而无需确定谁控制着客户端。本节是为实现分类器的人准备的；下面的测量结果可以在没有实现细节的情况下阅读。边缘计数器在符合条件的成功页面 GET 之后安排 D1 观察。它不包括预取、 /stats 、API 路由和非页面响应。它包括 HTML 和协商的 Markdown 页面响应；直接 .md 请求在此计数器之外。该集合边界来自资格代码。分类有四个证据来源： 网络元数据。 Cloudflare 提供客户的自治系统编号