AI爬虫抓取诊断不能只检查 robots.txt。 完整诊断需要验证三条证据链:爬虫能否取得页面、关键内容能否被提取、内容是否进入答案或引用。
页面返回 200,仍可能只是 JavaScript 空壳、验证码、登录页或 WAF 挑战页;日志里没有某个 AI User-Agent,也不能证明平台从未使用该内容,因为答案可能来自搜索索引、合作数据源或用户触发访问。
MaxAEO 建议把每次测试记录为一个四元组:
访问身份 + 最终响应 + 正文指纹 + 渲染差异
缺少其中任何一项,都容易把“抓取失败”“内容不可提取”和“没有被引用”混为一谈。

什么是 AI 爬虫抓取诊断?
AI爬虫抓取诊断是通过抓取规则、HTTP 响应、正文提取、渲染结果、服务器日志和答案测试,判断页面卡在访问、理解还是引用环节的分析过程。
它与传统的“是否被搜索引擎收录”检查并不等价。AI 产品可能使用自己的爬虫,也可能调用第三方搜索索引或在用户请求后临时访问页面。
| 诊断层级 | 核心问题 | 主要证据 | 常见责任方向 |
|---|---|---|---|
| 传输层 | 请求是否真正取得目标内容? | robots.txt、状态码、响应正文、WAF/CDN 日志 | 运维、安全、技术 SEO |
| 内容层 | 抓取器是否能提取关键事实? | 原始 HTML、渲染 DOM、标题、正文、实体与链接 | 前端、内容架构、技术 SEO |
| 答案层 | 内容是否被提及或引用? | 固定 Prompt、原始答案、引用 URL、测试条件 | 内容、品牌、公关、GEO |
| 证据不足 | 当前数据能否支持结论? | 观察窗口、身份验证方法、日志覆盖范围 | 先补监测,不宜归因 |
“未理解”通常只能判断为较高风险,因为站外无法直接观察模型内部处理过程;“日志中没有请求”同样不能单独证明“从未抓取”。
开始诊断前需要准备什么?
先固定 URL、访问身份、观察时间和成功标准,再运行测试。 如果边测边换页面、Prompt 或平台,结果无法复现。
建议准备:
- 5—20 条代表性 URL: 首页、产品或服务页、权威指南、案例页,以及已知存在问题的页面。
- 两个对照页面: 一个确认可抓取的静态页,一个故意阻断或仅客户端渲染的页面。
- 访问记录: CDN、WAF、负载均衡和源站日志,时间统一到同一时区。
- 页面快照: 原始 HTML、渲染后 DOM、响应头、最终 URL 和正文哈希。
- 固定答案测试: 保存平台、模型、地区、登录状态、时间、Prompt、原始回答和引用链接。
- 明确验收条件: 例如“原始 HTML 可提取核心答案”“已验证爬虫不再返回 403”,而不是笼统写“抓取已优化”。
为什么不能只检查 robots.txt?
robots.txt 是爬虫自愿遵守的抓取规则,不是身份认证、防火墙或引用指令。放行某个 User-Agent,只能移除一个潜在限制。
RFC 9309定义了 Robots Exclusion Protocol;Google 的 robots.txt 文档进一步说明,规则按协议、主机和端口分别生效。因此,以下地址可能对应不同的 robots.txt:
https://example.com/https://www.example.com/https://cdn.example.com/http://example.com/- 非标准端口上的站点
AI 平台还可能区分不同用途的访问器。以 OpenAI 官方爬虫说明为例,GPTBot、OAI-SearchBot 和 ChatGPT-User 的用途不同,不能把一个 User-Agent 的测试结论套用到全部访问场景。
检查时应回答四个问题:
- 目标 URL 实际使用哪个协议、主机和端口?
- 规则针对训练爬虫、搜索爬虫,还是用户触发访问器?
- robots.txt 放行后,CDN、WAF、地区策略和登录墙是否仍会拦截?
- 页面能访问后,原始响应是否真的包含正文?
是否允许训练抓取还涉及版权和业务策略,不应直接复制通用模板。具体决策可参考 GPTBot、豆包等 AI 爬虫的 robots.txt 放行方法。
AI爬虫抓取诊断的完整步骤
第一步:固定测试 URL 与预期内容
每条 URL 都要预先定义“成功取得了什么”,否则 200 无法验收。
至少记录:
- 规范 URL 和预期最终 URL;
- 预期 H1、正文中的一句唯一文本和主要实体名称;
- 预期内容类型;
- 是否依赖登录、Cookie、地区或 JavaScript;
- 页面更新时间和测试时间。
选择一句页面独有、不会出现在导航或页脚中的文本作为“正文探针”。后续即使页面返回 200,只要探针缺失,就不能判定正文抓取成功。
第二步:用 GET 建立网络基线
不要把 curl -I 的 HEAD 结果当作主要证据。 部分服务器、CDN 和 WAF 对 HEAD 与真实 GET 请求采用不同规则。
curl --compressed -sS -L --max-redirs 5 \
-A "Mozilla/5.0" \
-D browser.headers \
-o browser.html \
-w "url=%{url_effective} code=%{http_code} redirects=%{num_redirects} type=%{content_type} bytes=%{size_download}\n" \
https://www.example.com/target-page
shasum -a 256 browser.html
除状态码外,还要保存:
- 最终 URL 和跳转次数;
Content-Type、Content-Encoding、Content-Length;Cache-Control、Age、Vary、X-Cache或同类 CDN 头;- 正文大小、标题、唯一文本探针和哈希;
- 请求时间、请求编号及边缘节点信息。
动态时间戳、CSRF token、实验编号等字段会改变哈希。比较正文指纹前,应先移除这些动态字段,或同时比较正文探针和主内容长度。
第三步:核对 robots.txt 与页面级指令
先取得线上真实文件:
curl --compressed -sS -D robots.headers \
-o robots.txt https://www.example.com/robots.txt
curl --compressed -sS -L -D page.headers \
-o page.html https://www.example.com/target-page
逐项检查:
- robots.txt 是否返回
200,是否为当前生产版本; - User-Agent 分组是否误封内容目录、接口或必要资源;
- 最终页面是否含
noindex、错误 canonical 或登录页 canonical; - 响应头是否存在
X-Robots-Tag; - 重定向后的 URL 是否仍允许抓取;
- HTML 中的 canonical 是否指向可访问且内容等价的页面。
noindex、canonical 和 robots.txt 的作用不同:robots.txt 管理抓取,noindex 管理支持该指令的平台是否索引,canonical 表达规范地址偏好。三者都不能绕过 WAF,也不能保证 AI 答案引用。
llms.txt 可以整理重要内容,但不能替代访问控制或服务端正文。可进一步查看 llms.txt 与 robots.txt 的能力边界。
第四步:比较不同访问身份的真实响应
使用完全相同的 URL、网络环境和 curl 参数,只改变 User-Agent:
curl --compressed -sS -L --max-redirs 5 \
-A "GPTBot/1.0" \
-D bot.headers \
-o bot.html \
-w "url=%{url_effective} code=%{http_code} redirects=%{num_redirects} type=%{content_type} bytes=%{size_download}\n" \
https://www.example.com/target-page
shasum -a 256 browser.html bot.html
这种测试只能发现按 User-Agent 分流的配置问题。它不能证明请求来自真实 GPTBot,也无法复现真实浏览器的 TLS 指纹、Cookie、JavaScript 和完整请求头。
重点检查以下差异:
| 结果 | 更可能的故障 | 验证动作 |
|---|---|---|
200,标题和正文完整 |
传输层基本通过 | 继续检查内容提取和引用 |
200,正文是验证码或挑战页 |
WAF 软阻断 | 对比正文探针、标题、哈希和安全事件 |
200,HTML 只有应用容器 |
客户端渲染空壳 | 比较原始 HTML 与渲染 DOM |
| 301/302 多次跳转 | 规范地址或地区分流不稳定 | 收敛跳转并检查最终页面 |
| 401/403 | 鉴权、地区或机器人策略阻断 | 查 WAF 规则、访问策略和请求编号 |
| 404/410 | URL 不存在或已删除 | 修复内链、站点地图和外部引用 |
| 429 | 速率限制 | 核对阈值、重试策略和已验证爬虫政策 |
| 5xx | 源站、边缘节点或依赖故障 | 按时间和请求编号追踪调用链 |
状态码相同不代表正文相同;正文相同也不代表来源身份真实。
第五步:比较原始 HTML 与渲染后 DOM
浏览器能看到内容,不代表不执行 JavaScript 的抓取器能取得内容。
应分别保存:
- 服务器最初返回的 HTML;
- 浏览器完成渲染后的 DOM;
- 主内容区域提取出的纯文本。
比较以下元素:
<title>、H1 和开头答案;- 品牌、产品、作者、日期和价格适用范围;
- 表格、FAQ、证据来源和内部链接;
- canonical 与结构化数据;
- 正文长度和唯一文本探针。
Google 的 JavaScript SEO 文档说明了抓取、渲染和索引是不同阶段。AI 访问器的渲染能力并不统一,因此定义、结论、产品信息和原创数据等关键内容,宜直接出现在服务端返回的 HTML 中。
如果原始 HTML 只有 <div id="app"></div>,应判定为内容提取风险,而不是直接归因于“内容不权威”。相关修复方式可参考 AI Crawler Optimization。
第六步:用日志验证真实访问与阻断位置
模拟 User-Agent 是配置测试;服务器日志才是判断真实请求是否到达的重要证据。
日志至少应包含:
- 时间、时区、主机、路径和查询参数;
- 状态码、响应字节和处理时长;
- User-Agent、来源 IP 和请求编号;
- CDN 缓存状态、WAF 动作和命中规则;
- 最终源站状态或上游错误。
身份验证应遵循平台公布的方法。可使用官方发布的 IP 范围;只有在平台明确公布主机名规则时,才采用反向 DNS 后再做正向 DNS 校验。不要把任意 PTR 记录或带有 bot 字样的 User-Agent 当作可信身份。
建议按三个维度汇总:
| 维度 | 建议指标 | 用途 |
|---|---|---|
| 爬虫 × 日期 | 成功请求、403率、429率、5xx率 | 发现策略或容量变化 |
| 页面 × 日期 | 最近访问时间、最终状态、响应字节中位数 | 定位页面级异常 |
| WAF 规则 × 路径 | 命中次数、动作、来源身份 | 找到实际阻断规则 |
“观察期内未发现已验证的直接请求”是严谨结论;“AI 平台从未使用本站内容”不是。
第七步:检查内容是否可被准确提取
传输通过后,从原始 HTML 中提取主内容,检查是否能脱离页面设计独立回答问题:
- 页面开头是否直接给出定义或结论;
- 品牌名、产品名和类别关系是否明确;
- 数据是否有日期、样本、口径和来源;
- 表格表头脱离样式后是否仍有意义;
- 代词是否有清楚指向;
- 重要信息是否藏在图片、交互组件或登录后;
- 多个 URL 是否发布冲突事实。
结构化数据可以辅助识别实体,但不能补救正文缺失或事实冲突。
第八步:用固定 Prompt 检查提及与引用
答案测试只能证明特定条件下的输出,不能反向证明平台是否直接抓取过页面。
建议同时设置三类 Prompt:
- 事实检索: 要求回答页面中的一个独有事实并给出来源。
- 非品牌发现: 使用目标用户会搜索的通用问题,不在 Prompt 中提示品牌。
- 对比验证: 要求比较方案、列出适用场景并提供引用。
每次保存平台、模型、地区、登录状态、时间、完整 Prompt、原始回答和引用 URL。前后测试必须使用同一组条件,并保留未提及品牌的结果,避免只记录成功样本。
12 请求最小实验如何执行?
用四类页面分别进行浏览器 UA、AI 爬虫模拟 UA 和普通客户端访问,可形成12个最小样本,快速识别空壳、硬阻断和软阻断。
以下为受控诊断夹具的一次示例结果。字节数只适合同一环境内横向比较,不是任何平台的抓取率或行业基准。
| 受控页面 | 浏览器请求 | AI爬虫模拟请求 | 普通客户端 | 关键发现 |
|---|---|---|---|---|
| 静态正文 | 200 / 15,041字节 | 200 / 15,041字节 | 200 / 15,041字节 | 三种请求取得相同正文 |
| JavaScript 空壳 | 200 / 687字节 | 200 / 687字节 | 200 / 687字节 | 渲染后增至11,741字节,原始响应缺正文 |
| WAF 规则页 | 200 / 15,041字节 | 403 / 9字节 | 403 / 9字节 | 浏览器正常不能证明爬虫可达 |
| 软阻断页 | 200 / 2,448字节 | 200 / 2,448字节 | 200 / 2,448字节 | 三者均取得挑战页,200属于假成功 |
实验应固定网络位置、请求头、压缩方式、重定向设置和测试时间。每个样本至少保存:
- 访问身份;
- 最终 URL、状态码和跳转次数;
- 响应头、正文大小和正文指纹;
- 唯一文本探针是否存在;
- 原始 HTML 与渲染 DOM 的差异;
- 对应的 CDN、WAF 和源站请求编号。
这组样本说明:AI爬虫抓取诊断的最小单位不是状态码,而是“身份、最终响应、正文指纹、渲染差异”四元组。
如何区分未抓取、未理解与未引用?
使用传输、内容和答案证据交叉判断,并为结论标注置信度。单次回答没有出现品牌,不足以证明页面未被抓取。
| 传输证据 | 内容证据 | 答案证据 | 建议结论 |
|---|---|---|---|
| 已验证身份被 robots.txt 或 WAF 明确阻断 | 未取得正文 | 无提及 | 确认存在抓取阻断 |
| 返回200,但正文为挑战页或登录页 | 无有效主内容 | 无提及 | 确认软阻断 |
| 成功取得页面 | 原始 HTML 缺少核心正文 | 无提及 | 内容提取风险高 |
| 成功取得页面 | 品牌、事实和证据均可提取 | 无提及或引用竞品 | 未引用,继续查意图与证据竞争 |
| 无直接访问日志 | 页面可被搜索索引发现 | 有引用 | 可能来自第三方索引或其他数据源 |
| 有成功访问 | 内容完整 | 品牌描述错误 | 检查信息冲突、时效与实体混淆 |
| 无可靠日志 | 无页面快照 | 无引用 | 证据不足,不能归因 |
如果问题属于“未引用”,继续调整防火墙通常没有价值。此时应检查:
- 页面是否直接回答目标问题;
- 结论是否包含日期、条件和证据;
- 品牌、产品和组织实体是否一致;
- 其他页面是否存在冲突信息;
- 第三方权威来源是否支持该结论;
- 竞品内容是否更具体、更新或更易引用。
修复任务如何排序?
先恢复访问和正文,再优化实体、证据与引用竞争。403、挑战页和空壳未解决前,不应优先投入 llms.txt 或内容扩写。
-
P0:访问故障
修复 DNS、TLS、401、403、429、5xx、循环跳转和关键资源阻断。 -
P1:假成功与正文缺失
修复200挑战页、客户端空壳、正文接口鉴权、错误 canonical 和意外noindex。 -
P2:内容提取与实体问题
统一品牌和产品名称,让定义、答案、日期、作者、方法与来源直接出现在 HTML 中。 -
P3:引用竞争
增加有口径的一手数据、可引用表格、专家说明、第三方佐证和清晰内部链接。 -
P4:增强与实验项
评估 llms.txt、结构化数据和低影响爬虫规则。关于实际采用情况,可参考 llms.txt 的引用数据验证。
每项修复都应绑定可验证结果:
| 修复项 | 合格标准 |
|---|---|
| WAF 放行 | 已验证目标爬虫的403率降至预设阈值,异常来源仍被拦截 |
| 服务端正文 | 原始 HTML 可提取 H1、核心答案、品牌实体和证据 |
| 重定向 | 目标 URL 一次跳转到稳定规范地址 |
| 软阻断 | 正文探针存在,挑战页指纹不再出现 |
| 内容改版 | 固定 Prompt 的事实准确率和目标域引用率按同口径复测 |
| llms.txt | 文件可访问、URL 有效,但不把是否被引用作为短期保证 |
如何把技术日志与 AI 可见度监测对齐?
日志回答“谁访问了什么”,答案监测回答“平台说了什么”。两套数据只能用于寻找时间关联,不能在没有对照的情况下宣称因果。
建议保留以下指标:
- 成功访问率: 已验证目标请求中返回有效正文的比例;
- 软阻断率: 返回2xx但正文命中挑战页、登录页或空壳指纹的比例;
- 正文可提取率: 样本 URL 中原始 HTML 含核心答案的比例;
- AI提及率: 出现品牌的有效回答数 ÷ 有效回答总数;
- 目标域引用率: 引用品牌官网的回答数 ÷ 含引用回答数;
- 竞品替代率: 提及竞品但未提及本品牌的回答数 ÷ 有效回答总数;
- 事实准确率: 品牌描述中无可验证事实错误的回答比例。

技术修复后先在同日复测状态码、正文和日志,再用固定 Prompt 持续观察答案变化。不要因为引用率恰好上升,就把全部变化归因于一次 WAF 或 robots.txt 修改。
常见问题
robots.txt 放行 GPTBot 后多久会出现引用?
没有统一时间保证。放行只移除一个潜在抓取障碍,访问频率、数据来源、内容相关性和引用选择仍由平台决定。应使用相同 Prompt 和等长观察窗口进行前后对比。
页面返回 200 是否代表抓取成功?
不代表。200 可能返回空壳、登录页、验证码或 WAF 挑战页。至少还要验证最终 URL、内容类型、正文探针、主标题、正文哈希和渲染差异。
日志里没有 AI 爬虫,是否说明网站从未被使用?
不能。日志只能证明观察期内没有识别到直接请求。平台仍可能通过搜索索引、合作数据源、缓存或未公开访问器取得信息。
是否应该按 User-Agent 在 WAF 中直接放行?
不建议。User-Agent 很容易伪造。应优先使用平台公布的 IP 范围、官方身份验证方法或 CDN 的已验证机器人能力,并保留速率限制和异常行为检测。
llms.txt 能解决抓取和引用问题吗?
不能单独解决。它可以提供内容导航和站点说明,但无法绕过 robots.txt、鉴权、WAF 或客户端渲染,也不保证平台采用其中的页面。
Search Console 能完成 AI 爬虫抓取诊断吗?
不能单独完成。Google Search Console 主要反映 Google 搜索的抓取、索引和搜索表现,不能代替 CDN、WAF、源站日志或其他 AI 平台的答案监测。
能否允许 AI 搜索抓取,同时阻止训练抓取?
如果平台公开了用途不同的 User-Agent,可以分别配置。例如 OpenAI 为不同用途提供不同访问标识。但规则只对遵守它的访问器有效,仍需结合版权政策、WAF 验证和实际日志检查。
AI爬虫抓取诊断清单
一次完整诊断应能回答:
- 目标 URL 的最终地址、状态码、内容类型和有效正文是什么?
- robots.txt、页面指令、canonical、CDN 与 WAF 是否相互冲突?
- 原始 HTML 是否直接包含 H1、核心答案、品牌实体和证据?
- 浏览器、模拟爬虫和普通客户端取得的正文是否一致?
200响应中是否存在验证码、登录页或挑战页?- 日志中的爬虫身份是否经过官方方法验证?
- 当前问题属于抓取阻断、内容提取风险、未引用,还是证据不足?
- 修复后用哪个状态码、正文探针、日志指标和 Prompt 指标验收?
只有传输、内容和答案三条证据链闭合后,团队才应把问题归因于内容质量或引用竞争,而不是继续盲目修改抓取配置。