GEO-023·第 02 期·度量与增长·23 / 132
用日志判断 AI 爬虫到底来了没有
厂商报表只覆盖自家爬虫，还常被采样和保留期截断。本文给出日志必看的六个字段、按路径模板与状态码做抓取热图的方法，以及把抓取层接进月度看板的四步，并说明哪些团队不适用。
本期主线先被看见：抓取、渲染与 AI 爬虫可访问性
二月第一周的复盘会上，一家做户外电源和折叠太阳能板的独立站，运营指着曲线说 ChatGPT 带来的会话两个月一直在涨。技术负责人把 CDN 日志拉出来，看到的是另一件事：检索类爬虫对商品页的请求，在换 CDN 那天之后就没有了，403 全落在 /products/ 下面。会话还在涨，因为老页面还在被引用；新上的那批 SKU，AI 一次都没读到。
厂商报表只能告诉你流量大概从哪来，服务器日志才能回答谁来了、抓了哪一页、拿到什么状态码；没有这一层，抓取问题只能靠猜。
报表看趋势，日志做取证
Google 的抓取统计只覆盖 Googlebot，Bing 的只覆盖 bingbot，检索类 AI 爬虫的请求不在这两份报表里。CDN 与 WAF 的控制台会按 bot 分类，但常见三个折扣：按比例采样、保留期短、把未验证的 bot 并进一个笼统的桶。前端分析工具靠 JavaScript 采集，爬虫不执行脚本，天然不在其中。
还有一个更隐蔽的缺口：一部分请求是用户当场触发的。有人把商品链接贴进 ChatGPT，它去打开那个页面——这次访问在日志里有，在任何”抓取报表”里都没有。
所以两者的分工要分清。报表回答”要不要担心”，日志回答”哪一层坏了”。用报表排优先级，用日志做取证和验收。抓取问题分五层，顺序见一次完整的 AI 抓取审计，日志是唯一能同时给出这五层证据的地方。
日志里真正有用的只有六个字段
一份 access log 有几十个字段，做抓取分析只需要六个。多留不是坏事，但判断只建立在这六个上，团队才有共同语言。
| 字段 | 它回答什么 | 什么算异常 |
|---|---|---|
| 时间戳（带时区） | 抓取发生在哪一小时 | 时区没对齐，把凌晨的抓取当成白天断流 |
| 来源 IP | 请求是否真的来自那家公司 | 反查归属与官方 IP 段对不上 |
| User-agent 全串 | 是哪个爬虫、哪个版本 | 串里同时出现两个产品名，或没有版本号 |
| 路径与查询串 | 抓的是内容页还是参数页 | 同一个 SKU 被不同参数反复抓 |
| 状态码 | 有没有拿到内容 | 403、429 落在商品页 |
| 响应字节与耗时 | 拿到的内容是不是空壳 | 200 但字节远低于同模板中位数 |
其中两项最容易被误读。状态码 200 不代表抓到了内容：缺货页、空壳页、被前端兜底成 200 的错误页，爬虫拿到的都是 200。必须配响应字节看，字节明显偏低，就当作没抓到。响应耗时不只是性能指标：耗时拉长之后爬虫会自行降频，请求量下滑看起来像被封，其实是源站慢。
抓取热图：按路径模板和状态码摊开
按原始 URL 聚合会得到一张没用的表，参数一多就是几十万行。聚合到路径模板，才看得出注意力怎么分配。
三个切面要分开算。bot 之间：训练类与检索类不同组。如果训练类占了绝大多数、检索类接近零，问题在可访问性，不在内容质量。路径模板之间：商品、类目、对比、文章这些内容页，与筛选、排序、站内搜索这些参数页分开统计。参数页吃掉大部分请求，就是抓取预算被浪费的直接证据，机制见AI 爬虫的抓取预算。状态码之间：最值钱的不是 5xx，而是落在商品页上的 403、429，以及”200 但很小”。
三个切面叠起来，才能得到一句可派工单的结论，比如”检索类爬虫三周没碰过商品页，请求全在 /filter”。“AI 抓取下降了”不是结论，是标题。参数页怎么收敛成可抓的结构，另见可抓取的分类与筛选导航。
把抓取层接进月度看板
日志不进看板，三个月后没人再打开它。四步足够，不要更多。
| 步骤 | 做什么 | 谁来做 | 怎么算过 |
|---|---|---|---|
| 1 定口径 | 写清哪些 UA 算 AI 爬虫、用哪个时区、采样率多少、保留多久 | 增长与工程 | 一页口径文档，口径外的请求不进看板 |
| 2 落聚合表 | 按 日期 × bot × 路径模板 × 状态码 每日聚合 | 工程 | 任意一天能下钻到路径模板 |
| 3 设告警 | 商品页 200 请求连续七天为零、403 占比突增、响应耗时翻倍 | 值班 | 告警能定位到路径，不只是一句”抓取异常” |
| 4 月度复盘 | 抓取层与引用层放在同一页对照 | 增长 | 每月能回答”哪些页面进来了却没被引用” |
第 1 步最容易被跳过。口径不写清，三个人会算出三个数，会议后半段就变成对数字的互相怀疑。衡量抓取健康度的不是总量，是内容页 200 的绝对量与占比。
示例：一次只改了三处的修复
示例：一个假设场景，不含真实品牌与数据。某跨境家居站有数千个 SKU、一套筛选页和一套实时库存接口，日志已接进看板。
看板上只有两个信号：参数页吃掉大部分请求；/products/ 下的 403 集中在新上线的 SKU 上。前者浪费预算，后者等于新品对 AI 不存在。
于是只改三处：WAF 放行已验证的 bot 名单，只对 /api/ 限速；robots 拒绝 /filter 与站内搜索；sitemap 只留 canonical 的商品页与类目页。
验收不看总请求量，看路径分布变没变：商品页的 200 请求是否恢复、403 是否只剩预期路径、参数页请求是否下降。三件都通过，才进入引用侧的复测。总请求量上涨不能当成功标准——那可能只是筛选页被多抓了几轮。
边界：什么时候别从日志入手
平台内为主的时候。 亚马逊、Shopee、TikTok Shop 不给你 access log，只能用平台自己的报表与品牌分析。硬套这套方法，得到的是编出来的数。
CDN 采样率高的时候。 采样率与保留期取决于套餐。日志能支撑趋势与路径分布，不适合拿两个月做精确同比；单日的小幅波动可能只是采样噪声。
要回答”有没有被引用”的时候。 日志只证明它来过，证明不了它用了。这一层要回到固定 prompt 的复测，方法见AI 可见度基线。
涉及个人数据合规的时候。 日志里有 IP，在欧盟口径下通常按个人数据对待。保留期、访问权限与脱敏规则要写进口径文档，别让一份调试日志变成合规问题。
没有工程资源的时候。 先用 CDN 的 bot 报表粗筛，只查一件事：商品页有没有被检索类爬虫以 200 抓到。答案是否，再谈工具。
这条线上其他文章在度量与增长主题页。
这个月挑一件事做：导出上一个完整月的日志，按 bot、路径模板、状态码三维聚合，找出商品页 200 请求最少的那一周和 403 最集中的路径，把这两行写在月度看板最上面。下个月同一个位置就有对比。