做法是先在服务器日志中标记疑似机器人，再把标记结果传入统计工具做排除或单独分组；仅凭 User-Agent 过滤，可能漏掉伪装访问，也可能误删真实用户。访问频率、页面停留、资源加载、IP 反查和请求路径都要结合业务场景判断，最后对比过滤前后的有效访问率、有效表单率和数据量变化。
先把访问分成三种，别一上来全删
统计里至少要分出真实用户、已确认的搜索引擎抓取，以及暂时无法判断的异常访问。三者不能混成一个“机器人”标签：抓取行为可能有助于页面发现，但它不等于用户访问；分析工具里出现一次访问，也不等于产生了有效阅读或转化。
更稳妥的做法是保留原始数据，新增一个 bot_flag 或 traffic_type 字段。已确认的抓取流量单独看，疑似伪装访问先进入观察组，只有规则和人工抽样都支持时，才从核心报表中排除。
User-Agent 只能当线索，不能单独定案
User-Agent 是请求方主动发送的文本，访问者可以修改它，所以它适合用来发现线索，不适合独立作为删除条件。可以把包含常见爬虫标识、脚本库特征或异常设备描述的请求列入待观察集合，再和访问行为放在一起看。
如果同一设备短时间请求大量不存在的页面、连续访问 robots.txt、图片和脚本却没有正常页面链路，或者每次会话都只打开一个资源，异常程度会升高。但这些现象也可能来自监控程序、预加载服务或网络故障，处理前要和业务日志、发布时间及营销活动对照。
服务器日志里要看哪些信号
服务器日志比前端统计多出请求时间、状态码、路径、响应大小和客户端地址等信息。把这些字段按会话或地址聚合，可以发现前端统计没有记录的访问，也能看出同一来源是否持续请求相似资源。
建议观察四组信号：单位时间内的请求数量、路径是否呈规律变化、状态码分布是否异常、是否完成页面所需的脚本和图片加载。单个信号不能直接下结论，多个信号方向一致时，再把访问标为疑似机器人。
真实搜索引擎抓取要单独确认
如果访问声称来自搜索引擎，不能只看名称或 User-Agent。以 Google 抓取工具为例，Google Search Central《验证 Googlebot 和其他 Google 抓取工具》说明了反向地址解析与正向解析的确认思路；这类确认适用于声称来自 Google 的请求，不适用于所有伪装访问。
确认后可以把真实抓取保留在“搜索引擎抓取”分组，而不是直接混进用户统计。其他平台的抓取来源要按对应平台的说明处理。无法完成地址确认的请求，先放入疑似组，并记录判断时间和规则版本，后面根据新日志调整。
统计工具里怎么排除，才不会污染原始数据
过滤应放在报表层或分析视图层，原始采集数据尽量保留。配置时可按自定义维度、来源标记、请求路径或服务器传入的 bot_flag 排除；如果工具只支持固定规则，就先建立“全部访问”和“清洗后访问”两套视图，避免一次改规则后无法回看。
- 先记录过滤前的访问数、有效会话数、表单数和订单数。
- 把疑似机器人标记写入日志或数据仓库，不直接删除记录。
- 在测试视图运行一段完整业务周期，观察过滤前后有效访问率和有效表单率。
- 抽样查看被排除的请求，确认没有把监控、无障碍工具或真实用户网络误判进去。
- 通过后再更新正式报表，并记录规则名称、更新时间和调整原因。
这里的“完整业务周期”要按自己的销售流程确定，不能套用统一天数。过滤带来的访问量变化、转化变化和获客成本变化也无法通用判断，需用自家数据验证。
过滤后还要盯住搜索与 AI 引荐数据
机器人排除只解决统计口径，不会自动改变页面抓取、索引或 AI 引荐。搜索引擎抓取、AI 回答出现页面、用户点击进入、自然搜索进入和最终转化，是不同层级的信号，报表中应分别记录，不能把抓取次数当成引用次数。
可以建立一张周度记录表，保留引荐来源、落地页、有效表单、成交状态和规则版本。主转化事件只选一个，例如有效表单；归因窗口按销售周期设置。若 AI 引荐、品牌词搜索和直接访问之间无法清楚区分，就标为未识别，不要强行归因。
规则怎么判断做对了
规则做对的表现，不是访问量下降得越多越好，而是异常访问被隔离后，真实业务指标的解释空间变清楚。可以比较过滤前后的有效会话占比、有效表单率、页面路径分布和服务器请求量，重点看变化是否与被标记流量的特征一致。
如果过滤后表单量突然大幅变化，先回看被排除样本、前端埋点和表单接口日志；如果服务器请求持续增加但统计访问没有对应变化，再检查抓取、监控和接口调用。每次只改一组规则，保留版本记录，才能知道变化来自哪项调整。