AI 爬虫正在虚增您的流量数据，而通常的捷径——检查 User-Agent 请求头——并无法识别这一点。

最近一项为期八天的日志扫描显示，在 468 次真实的页面抓取之外，还有 991 次请求伪装成 AI 机器人，实际上却在探测 .env 或 .git 等文件。罪魁祸首是谁？任何人都可以向 HTTP 请求中插入自声明的 User-Agent 字符串，例如 GPTBot 或 ChatGPT-User。

为什么这一指标至关重要

网站会将“AI 流量”的激增视为相关性的标志。他们利用这些数据来证明广告费率的合理性、分配服务器资源，并向投资者邀功。当报告中的 AI 访问量有一半仅仅是噪音时，预算就会走向偏差，仪表板也会产生误导。

将虚假声明与现实区分开来的两种过滤器

  1. Cloudflare 的 verifiedBotCategory – Cloudflare 只有在通过反向 DNS 将请求的 IP 解析回已知的机器人域名后，才会填充此字段。如果请求头显示为“GPTBot”但 IP 解析失败，该请求就会被归入“未验证”类别。
  2. Sitemap 交叉检查 – 只有当请求的 URL 出现在您的 XML sitemap 中时，机器人才是真正地在阅读您的内容。请求那些不在 sitemap 中的路径，很可能是在搜寻漏洞，而不是在索引文章。

对同一份为期八天的样本应用这两个过滤器后，得出了惊人的数据：

  • ChatGPT-User – 39% 的请求通过了验证。
  • GPTBot – 13% 已验证。
  • PerplexityBot – 0% 已验证。
  • Google-Extended – 0% 已验证；该字符串并不对应任何官方的 Google 爬虫。

即使在已验证的调用中，许多机器人也仅抓取了 robots.txt 或 sitemap 本身，而不是您关心的文章页面。

开发者现在可以做些什么

  • 在您的分析流程中启用 Cloudflare 机器人验证。verifiedBotCategory 字段会出现在请求头中，可以与您自己的日志一起存储。
  • 维护一份最新的 sitemap，并实现自动化检查，在将每个传入请求的路径计为内容浏览之前，先确认其是否存在于 sitemap 中。
  • 过滤掉非 GET 方法以及针对典型开发文件（.env、.git、.bak）的请求。这些几乎都是恶意扫描。

反方观点

有人认为反向 DNS 检查可以被伪造，而且机器人的合法用途可能是发现尚未列入 sitemap 的新 URL。这些担忧是有道理的：一个蓄意的攻击者可能会破坏 DNS 记录，而新内容在下一个生成周期之前，自然不会出现在当前的 sitemap 中。

务实的应对方法是将验证视为一种置信度评分，而非绝对的门槛。结合 DNS 验证、sitemap 存在性检查和请求方法检查，来提高“真实 AI 流量”的认定标准。如果一个请求通过了三项检查中的两项，请将其标记为人工审核，而不是直接丢弃。

下一步需要关注的事项

  • Cloudflare 验证 API 的变化 – verifiedBotCategory 逻辑的任何改动都可能改变验证率。
  • 新的自识别机器人的出现 – 关注日志中出现的 User-Agent 字符串；突然的激增可能意味着出现了伪装成 AI 爬虫的新扫描器。
  • Sitemap 的生成频率 – 生成间隔过长会增加合法爬虫被误分类的概率。

结论很简单：不要再将 User-Agent 字符串视为证据了。通过叠加 DNS 验证和 sitemap 校验，您将能更清晰地看到究竟是谁在阅读您的内容。

Source: https://dev.to/aulvem/ai-crawler-user-agents-are-self-reported-468-real-fetches-991-fake-ones-bgo