Cloudflare 测出 57.5% 请求来自机器人：企业 AI Agent 官网的 AI 搜索贡献，怎么读才算数-环曜Agent

我们把自己官网四个多月的入口页数据拉出来复盘时，先看到的不是 AI 搜索的贡献，而是一堆"不像人"的访问：9,084 次浏览量里有 40.3%–56.6% 来自本地开发机；再剔掉疑似采集与预取之后，四个月里能被确认来自 AI 引擎引荐的访问只有 3 条。

但紧接着出现了一个矛盾的数字：这 3 条里有一条，同一访客连读 6 页、停留 8 分 43 秒、跳出率 0%。

对企业决策者来说，这件事的意义是：AI 搜索很可能已经在给你带人，只是你的后台读数把这类信号埋掉了——它们与本地自测、抓取预取、同一访客反复刷新混在同一张表里，一并被算成"几秒钟就走的无效流量"。本文给出一套可核对的做法：八个失真源、五条读数纪律，以及一页纸的数据可信度体检。文中合规与采样口径的结论仅作落地参考，请结合自身数据现状核对。

一、先看一个反直觉的实测：AI 引荐只有 3 条，其中一条连读 6 页

判断这类数据之前，先要接受一个前提：原始导出不能直接用，它不是"数据错了"，而是它把所有访问都算作同一类。 下面先把本次复盘的两类数据源与口径摊开，再由浅入深地看结论。

数据来源与口径

本次复盘用的两类自有数据，口径与样本量如下（便于你复算，也便于判断可比性）：

外部数据也在说同一件事

这不是孤例。Adobe Digital Insights 的 AI 流量报告（2026 年 7 月数据，2026 年 8 月 19 日发布；口径为美国零售网站的线上交易数据，样本量超过 1 万亿次访问、覆盖 200 家以上大型零售商）显示：AI 引荐流量的停留时长比非 AI 流量长 59%、跳出率低 33%、转化率高 60%、单次访问收入高 53%，且转化优势已连续 11 个月存在。

把它和我们那 3 条放在一起看，结论就清楚了：AI 引荐是典型的小样本、高深度渠道。如果只看条数，你自然会得出"AI 搜索没什么用"；只有把深度指标单独拎出来看，它才显出价值。这也是后文五条读数纪律里把"AI 引荐单列"写进纪律的原因——环曜AIVO 在做 AI 可见度 复核时，同样把这一步当作前置项：先确认这类访问能被单独认出来，再谈优化动作。

二、为什么你会把它看丢：流量里混着八个失真源

先给一个量级参照。Cloudflare Radar 数据（由 Cloudflare 联合创始人 Matthew Prince 于 2026 年 6 月 3 日公布）显示，自动系统已占全球网络内容 HTTP 请求的 57.5%，人类为 42.5%，这是该口径下机器请求首次过半；其中 OpenAI 的 GPTBot 一年内增长 305%。

需要如实标注两条限定：该口径统计的是请求数而不是人的注意力（按使用时长、流媒体等互动指标衡量，人类仍占多数）；且这是单一厂商的可见切片，公布者也承认分类方法"有些粗糙"。

我们的站点数据与它方向一致但量级更低——疑似采集占线上浏览量的 20.9%–35.2%。差异主要来自口径：一边是全部 HTML 请求，一边是统计后台里的页面浏览量。两者在报告里不要相加或换算。

前四类失真源：来源层污染

第 7 条为什么常被漏掉

前六类都是"多算进来的"，第 7 类相反——它是被算漏的。行业操作口径里，AI 平台的引荐来源并不总能被正确识别：部分助手类入口会把来源显示为普通搜索域名，或直接落入直接访问，因此实测到的 AI 引荐数字通常是下限而非全貌。

想让它可见，只能靠主动标注与单列统计；这一层没做，你在后台里永远看不到它。这也是我们主张"先修读数口径、再谈效果"的原因——内容侧改得再好，读数看不见就等于没做。关于内容如何被 AI 搜索读到，企业官网内容为什么没被 AI 搜索引用 里有另一条线索：内容侧的可读性与数据侧的可见性，必须同时成立。在 官网优化 项目里，环曜AIVO 通常把这两侧做成同一张检查表：内容侧改动与数据侧复核对齐到同一个月度节点，避免一边改完、另一边读不出来。

三、八个失真源怎么过滤：识别信号与处理动作

过滤动作不需要复杂工具，需要的是把判定条件写死。所谓写死，就是把"什么算本地流量、什么算采集、什么算 AI 引荐"变成一句可执行的条件，而不是留在某个人的经验里——否则换个人做，同样的数据会得出不同的结论，前后月也没法比。本次复盘实际使用的八条动作如下，前四条处理"来源层"，后四条处理"读取层"。

前四条：来源与主机层

其中"标注迁移点"与"单列 AI 引荐"两项适合固化成定时任务：环曜Claw 的 任务自动化 可以按周跑一遍，把结果直接落进月度报表，不必每次人工重算。

三个容易做错的判定

其一，首页的 PV/UV 比高是正常现象。 同一访客多页浏览、回访折返都会推高比值，实测首页曾出现 PV 579 / UV 98（比值 5.9）——若把首页也算进"异常"判定，必然大面积误报。这条判定只对具体落地页生效。

其二，落入采集行的访问不能当"深读"。 本次每月有 56–127 条落在这一行，占线上浏览量两成到三成半；一些公开转述会挑出其中时长漂亮的样本，讲成"用户平均停留两分钟"，这在口径上站不住。

其三，带包装参数的链接不是自然入口。 这类访问多来自内嵌浏览器或采集器桥接，算进自然来源会让渠道结构判断整体偏移。

看到一个数字先问三件事

口径、时间窗、样本量。三者缺一，这个数字就只能当参考、不能当结论。举个反例：复盘期间检索到某类公开转述称"信通院测算国内 GEO 市场规模 286 亿元、年增速 125%、AI 搜索用户转化率 14.2%"，但页面未给出报告名称、发布日期、页码与统计口径，还把另一家机构的预测混排在同一语境里。这类数字不宜引用——问题不在于大小，而在不可追溯。

更省事的做法是把这些判定写成固定文档：谁在看哪张表、用的哪套口径，都记在一处，企业级环曜知识库本地化部署 的 知识管理 入口就是用来放这类材料的，换人接手时不必重新问一遍。

四、过滤之后读什么：五条读数纪律

过滤只是把噪声拿走，剩下的数字怎么读，还需要一套固定纪律。原因很直接：同一组过滤后的数据，既可以读成"某篇文章很受欢迎"，也可以读成"某个渠道开始起量"，差别只在读的人有没有统一判定。以下五条是本次复盘采用的判定方式，前三条保证趋势可比，后两条指导动作顺序。

五条纪律

这套判定不依赖特定工具：用命令行 跑一次脚本，把导出文件过一遍，就能得到上面五组读数，企业级环曜 CLI 本地化部署 的客户环境通常把它并进既有的批处理流程，不新增一套系统。

为什么第 4 条优先级最高

因为它直接决定你的动作顺序。企业官网的入口浏览量往往集中在较早写的老文上，而这批老文恰恰是结构较弱的一批：抽样核对发现，早期文章的"正文内链、结构化问答"覆盖率接近零，而新规范下发布的文章覆盖率很高。

这意味着同样的编辑工时，投给"已经被搜索进入过的老文"，回报高于平均分给全站——补两条正文内链、补一组问答、补一句商业出口，就能让已经在进来的流量多走一步。反过来，如果只按编号顺序平均用力，你会在没有流量的页面上花掉大部分时间。内容侧如何让 AI 更愿意引用，可参考企业官网在 AI 搜索里的可见度，它讲的是引用机制本身，与本文的读数方法互补。

补链前先要有一份"哪些老文被进入过"的清单，企业级环曜知识库本地化部署 的 文档检索 入口可以按月承接这份清单，谁改过哪一篇、改在哪个版本，都能查到。

五、读到真数据之后：缺口不在内容，在出口

口径修对之后，你会发现原本担心的问题往往不成立。本次复盘看到的结构是这样的：内容侧的入口并不少，真正缺的是把读者送出去的那一跳。这一节先看入口与出口的落差，再看两个可以把落差补回来的动作，以及一套每月可复用的一页纸流程。

入口占比与出口占比的落差

这组数字里值得注意的一点是：问题不在商业页没人看，而在文章没有把读者送过去。48 条文章入口会话里只有 4 条产生第二页、1 条走到商业页，而商业页自身的平均停留达到 273 秒，转化损失就发生在这个出口环节。

把出口补回来可以做两件事：让内容之间互相跳转，以及让正文明确给出落点。环曜Claw 的 业务系统集成 能力可以把"读者点出去之后落到哪张表单、进哪个队列"变成配置项，而不是每次改页面。

承接句为什么必须写进正文

做法很小：在正文里用一句与上下文相关的话，把读者接到服务页或方案页，锚文本要能读懂，不要放裸路径。例如讲完过滤流程后写"这套判定我们按可交付清单拆过，也写进了本地化部署的服务页的验收项里"。固定页脚的按钮不算——它全站都有，只有出现在正文里，才算真的承接。

出口的设计属于 官网优化 的一部分，环曜AIVO 在承接 AI 搜索 来源的访问时，会把锚文本与落地页一起看，而不是只加一个链接。这一点与高盛说 AI 抢了一半流量，那你的客户去哪了判断的是同一件事：流量迁移会带来结构失衡，而结构性缺口只能用结构性动作补上，不能靠多写几篇。

政策与合规口径

数据取样与自动化判断也要对齐合规要求。中央网信办、国家发展改革委、工业和信息化部《智能体规范应用与创新发展实施意见》（2026 年 5 月 8 日）对授权范围与责任边界提出了要求：凡由智能体代为访问、采集或判断的环节，都应明确授权与责任归属。落到本文场景，建议把"谁授权我们采集统计、留存多久、谁可查看"写成一句话放进流程文档，而不是默认"后台里能看到就能用"。

对留在私有环境内处理的流量项目，企业级环曜 Agent 本地化部署 会把授权范围与审计留痕一起写成交付项——谁在什么时候看了哪张表，事后可回溯。

一页纸的数据可信度体检

把上述动作压成一页纸，共四步：① 冻结口径（写明数据源、字段、时间窗、剔除比例）；② 过滤（八个失真源逐条判定）；③ 读数（五条纪律逐条出具）；④ 归档（口径文档、过滤脚本、验收结论按版本留存）。

五个验收指标

这五项建议随月度报表一起出，用命令行 跑一次即可生成对照，企业级环曜 CLI 本地化部署 的客户环境把它并入既有的检查单，不额外占用人力。

这套流程适合自动化

上述四步每月重复，适合写成固定任务：导出、过滤、读数、归档串成一条流水线，环曜Claw 的任务自动化 就能承担这一段，不必改动现有业务系统。流水线每月自动运行，人工只做复核与结论判定。

口径文档与历史基线建议集中存放、按版本检索，企业级环曜知识库本地化部署 的文档检索入口可以按版本对照，不必再翻各人本地保存的文件。

流量原始数据的处理位置同样值得写进流程：建议留在自有环境内完成，并保留完整的审计留痕，这属于 企业级环曜 Agent 本地化部署 交付时的常规要求，通常与权限表、口径文档以及回退步骤一起归档并逐项验收。

至于内容侧的另一套动作，它与数据侧共用同一套判定条件，具体由 环曜AIVO 承接：让 AI 搜索 带来的访问在数据上可核对，把 AI 可见度 做成按季度复核的固定项。

结语：先修口径，再谈效果

回到开头那 3 条访问。它们之所以引人注意，不是因为数量，而是因为在被正确识别之后，它们的深度显著高于站内平均——而在此之前，它们一直混在四成本地流量和两三成疑似采集里，谁都看不见。

所以给决策者的建议只有一句：下次拿到流量报表，先过口径，再读结论。 具体动作是三个——把这八个失真源做成固定过滤、把五条读数纪律写进月度复盘模板、把每篇新文的商业出口做成可统计项。做完这三件事，你才真正拥有"AI 搜索有没有用"这个问题的答案；在那之前，所有结论都是在噪声上做的判断。你们现在后台里的 AI 引荐这一栏，能看清吗？

常见问题 FAQ