AI爬虫抓取诊断指南:robots.txt、WAF、JS 渲染与日志排查

AI爬虫抓取诊断三证据链:请求到达、内容理解与答案引用

AI爬虫抓取诊断不能只检查 robots.txt。 完整诊断需要验证三条证据链:爬虫能否取得页面、关键内容能否被提取、内容是否进入答案或引用。

页面返回 200,仍可能只是 JavaScript 空壳、验证码、登录页或 WAF 挑战页;日志里没有某个 AI User-Agent,也不能证明平台从未使用该内容,因为答案可能来自搜索索引、合作数据源或用户触发访问。

MaxAEO 建议把每次测试记录为一个四元组:

访问身份 + 最终响应 + 正文指纹 + 渲染差异

缺少其中任何一项,都容易把“抓取失败”“内容不可提取”和“没有被引用”混为一谈。

AI爬虫抓取诊断三证据链:请求到达、内容理解与答案引用

什么是 AI 爬虫抓取诊断?

AI爬虫抓取诊断是通过抓取规则、HTTP 响应、正文提取、渲染结果、服务器日志和答案测试,判断页面卡在访问、理解还是引用环节的分析过程。

它与传统的“是否被搜索引擎收录”检查并不等价。AI 产品可能使用自己的爬虫,也可能调用第三方搜索索引或在用户请求后临时访问页面。

诊断层级 核心问题 主要证据 常见责任方向
传输层 请求是否真正取得目标内容? robots.txt、状态码、响应正文、WAF/CDN 日志 运维、安全、技术 SEO
内容层 抓取器是否能提取关键事实? 原始 HTML、渲染 DOM、标题、正文、实体与链接 前端、内容架构、技术 SEO
答案层 内容是否被提及或引用? 固定 Prompt、原始答案、引用 URL、测试条件 内容、品牌、公关、GEO
证据不足 当前数据能否支持结论? 观察窗口、身份验证方法、日志覆盖范围 先补监测,不宜归因

“未理解”通常只能判断为较高风险,因为站外无法直接观察模型内部处理过程;“日志中没有请求”同样不能单独证明“从未抓取”。

开始诊断前需要准备什么?

先固定 URL、访问身份、观察时间和成功标准,再运行测试。 如果边测边换页面、Prompt 或平台,结果无法复现。

建议准备:

  1. 5—20 条代表性 URL: 首页、产品或服务页、权威指南、案例页,以及已知存在问题的页面。
  2. 两个对照页面: 一个确认可抓取的静态页,一个故意阻断或仅客户端渲染的页面。
  3. 访问记录: CDN、WAF、负载均衡和源站日志,时间统一到同一时区。
  4. 页面快照: 原始 HTML、渲染后 DOM、响应头、最终 URL 和正文哈希。
  5. 固定答案测试: 保存平台、模型、地区、登录状态、时间、Prompt、原始回答和引用链接。
  6. 明确验收条件: 例如“原始 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-TypeContent-EncodingContent-Length
  • Cache-ControlAgeVaryX-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 的抓取器能取得内容。

应分别保存:

  1. 服务器最初返回的 HTML;
  2. 浏览器完成渲染后的 DOM;
  3. 主内容区域提取出的纯文本。

比较以下元素:

  • <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:

  1. 事实检索: 要求回答页面中的一个独有事实并给出来源。
  2. 非品牌发现: 使用目标用户会搜索的通用问题,不在 Prompt 中提示品牌。
  3. 对比验证: 要求比较方案、列出适用场景并提供引用。

每次保存平台、模型、地区、登录状态、时间、完整 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 或内容扩写。

  1. P0:访问故障
    修复 DNS、TLS、401、403、429、5xx、循环跳转和关键资源阻断。

  2. P1:假成功与正文缺失
    修复 200 挑战页、客户端空壳、正文接口鉴权、错误 canonical 和意外 noindex

  3. P2:内容提取与实体问题
    统一品牌和产品名称,让定义、答案、日期、作者、方法与来源直接出现在 HTML 中。

  4. P3:引用竞争
    增加有口径的一手数据、可引用表格、专家说明、第三方佐证和清晰内部链接。

  5. P4:增强与实验项
    评估 llms.txt、结构化数据和低影响爬虫规则。关于实际采用情况,可参考 llms.txt 的引用数据验证

每项修复都应绑定可验证结果:

修复项 合格标准
WAF 放行 已验证目标爬虫的403率降至预设阈值,异常来源仍被拦截
服务端正文 原始 HTML 可提取 H1、核心答案、品牌实体和证据
重定向 目标 URL 一次跳转到稳定规范地址
软阻断 正文探针存在,挑战页指纹不再出现
内容改版 固定 Prompt 的事实准确率和目标域引用率按同口径复测
llms.txt 文件可访问、URL 有效,但不把是否被引用作为短期保证

如何把技术日志与 AI 可见度监测对齐?

日志回答“谁访问了什么”,答案监测回答“平台说了什么”。两套数据只能用于寻找时间关联,不能在没有对照的情况下宣称因果。

建议保留以下指标:

  • 成功访问率: 已验证目标请求中返回有效正文的比例;
  • 软阻断率: 返回2xx但正文命中挑战页、登录页或空壳指纹的比例;
  • 正文可提取率: 样本 URL 中原始 HTML 含核心答案的比例;
  • AI提及率: 出现品牌的有效回答数 ÷ 有效回答总数;
  • 目标域引用率: 引用品牌官网的回答数 ÷ 含引用回答数;
  • 竞品替代率: 提及竞品但未提及本品牌的回答数 ÷ 有效回答总数;
  • 事实准确率: 品牌描述中无可验证事实错误的回答比例。
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 指标验收?

只有传输、内容和答案三条证据链闭合后,团队才应把问题归因于内容质量或引用竞争,而不是继续盲目修改抓取配置。