GEO-013·第 02 期·技术底座·13 / 132
一次完整的 AI 抓取审计：从 robots 到日志
抓取审计不能停在 robots.txt 的几行规则。本文把 AI 能不能读到商品页拆成允许、到达、渲染、解析、索引五层，给出每层的取证方法、三个常见误判，以及一份能同时交给工程与增长的审计报告格式。
本期主线先被看见：抓取、渲染与 AI 爬虫可访问性
周三上午，一家做折叠庭院家具的独立站准备上德国站新品。运营在 ChatGPT 里问“小阳台放得下哪种折叠桌”，答案给了四个品牌，没有他们。技术同事翻出 robots.txt，三组规则全是 Allow；搜索后台的覆盖率也没掉。两边都没说错，只是没人回答第三个问题：那张商品页，AI 到底读完了没有。
抓取不是一道开关，而是允许、到达、渲染、解析、索引五道连续的闸门；审计要证明的是问题卡在哪一道，而不是证明 robots.txt 写对了。
robots 通过，只说明第一道门开着
robots.txt 是一份偏好声明，不是访问控制。RFC 9309 规定了写法，没有规定执行；只有守规矩的爬虫才会读它。它只回答“准不准来”，不回答“来没来”“读没读懂”。
后面四层各有各的失败方式。CDN 或 WAF 可以在目标市场把请求打成 403；前端渲染的店铺会返回 200，但正文是个空壳；HTML 里有文字，价格和库存却躺在 JS 里；页面能被解析，却因为没有内链、sitemap 过期而很少被回访。哪一层断掉，最终结果都一样——AI 答案里没有你。所以只盯结果无法定位原因，必须逐层取证。
最常见的返工是：内容团队按“AI 还不够懂我们”改了三周商品页首屏，真实原因是一条只对商品模板生效的 bot 规则，把检索类爬虫的请求挡在了 403。谁在抓、抓走的是什么，得先分清；各家爬虫的用途差异见AI 爬虫地图，那是这份审计的输入，不是替代品。
五层排查：每层都要有取证
| 层 | 典型症状 | 取证方法 | 通过标准 |
|---|---|---|---|
| 允许 | * 组误伤、分组写反、模板带 noindex | 拉线上 robots.txt 存档，按 UA 逐组读规则 | 检索类 UA 在公开页面组内是 Allow |
| 到达 | 403 / 429、地区拦截、验证页 | 从目标市场出口 IP 带 UA 请求，记状态码与响应头 | 目标市场 IP 拿到 200，且不是 challenge 页 |
| 渲染 | 200 但正文为空、规格在 JS 里 | 关闭 JS 抓核心模板，与开 JS 的 DOM 对比 | 标题、价格、规格、库存无 JS 也可见 |
| 解析 | 关键信息在图片里、结构化数据与页面打架 | 校验 Product/Offer，比对 feed 与页面字段 | 实体、价格、库存三者一致 |
| 索引 | 可抓但少回访、新页不在 sitemap | 日志看回访与路径，sitemap 看 lastmod | 核心模板有稳定回访，新页当天进 sitemap |
五层里只有“允许”能靠读配置文件完成，其余四层都需要外部证据：请求结果、服务端日志、渲染后的 DOM。没有取证的审计报告，只是一份猜测清单。 排查必须按顺序来，上一层没通过就不要看下一层——顺序不是流程洁癖，是成本排序：前两层多数改配置就能解决，后三层要动模板和数据管线。
三个误判，会让前面全白做
用 UA 判断身份。 日志里的 UA 是最容易伪造的字段，写着某个官方名字的请求可能来自任何采集器。可靠做法只有两条：反向解析来源 IP 再正向解析回同一域名，以及对官方公布的 IP 段。对不上的，按未知爬虫处理。
把 200 当“读到了”。 前端渲染的店铺对任何请求都回 200，正文却要等 JS 执行完才有。这是最典型的假阳性，必须用无 JS 抓取对照，方法见AI 能不能渲染你的店。
用一次提问的截图判断恢复。 同一个问题，不同地区、账号、时间，答案会变。要固定一批问题、隔几天复测。另外，日志只能证明爬虫来过，证明不了它被引用；两件事得分开看，日志口径见用日志判断 AI 爬虫到底来了没有。
两周怎么排：四步加一份报告
- 定样本（工程）：一个市场、一个商品模板、20 个 URL，覆盖新品、变体、缺货页。导出近 90 天日志，按 UA 聚合请求量与状态码。过线标准是得到前五个 UA 和它们实际抓的路径。
- 逐层取证（工程）：对每个 URL 跑四组请求——目标市场 IP、裸 UA、关闭 JS、正常浏览器，记录状态码、首屏文本、价格是否可见。过线标准是每个 URL 有一张四列对照。
- 归因到层（技术负责人）：只允许指向唯一一层，指不出来说明取证不足，回去补，不要先排修复。
- 出报告并定复测（增长）：报告分两栏——工程拿到带 URL 的修复项，增长拿到复测用的固定问题集。过线标准是两周后能回答“变了没有”，或者能解释为什么没变。
一页纸就够：左侧写模板与断点层，中间贴证据（状态码、无 JS 首屏、字段对比），右侧写修复负责人与复测日期。不写“疑似”“可能”；写不出证据的那一行就留空，留空本身是下一次取证的待办。
示例：一家做户外储能电源的独立站（假设场景，无真实品牌与数据）做完这四步，发现三层问题叠在一起：robots.txt 全放行；WAF 的无头浏览器规则让检索类爬虫在商品模板上拿到 403；价格由 JS 注入，无 JS 抓取只剩一句“加载中”。报告只写了三行结论加三张 URL 清单，先修 WAF 规则，再改价格服务端渲染，最后补 sitemap。用同样的十个问题复测，答案里开始出现自己的域名。
边界：什么情况下别做完整审计
成交集中在平台内的品类，这套流程性价比很低——亚马逊、Shopee 的 AI 读的是 listing、评论与履约，先把 feed 修好。品牌明确不想被训练时，审计目标要改成“检索类放行、训练类拒绝”，用两套表，别混在一起下结论。SKU 不到五十个的站，索引层基本不成立，别为它搭看板，先做无 JS 与 WAF 两项就够。源站正被高频抓取拖慢时，先上限速和缓存，审计解决不了压力问题。
还有一种误用是把它当成一次性项目。规则、模板、CDN、前端框架，任何一次改动都可能重置某一层。入口为什么会变，回到AI 搜索把海外电商流量切成了四段；这条线的其他文章在技术底座主题页。
这个月，先做一件事：挑一个市场、一个商品模板、20 个 URL，从目标市场 IP 用检索类 UA 抓一遍，再关掉 JS 抓一遍，把状态码、首屏文本、价格是否可见填进同一张表。这四列填不满，就先别排内容日历。