AI爬虫抓不到网站？从 DNS、证书、WAF 到渲染的七层排查

AI爬虫抓不到网站，指 AI 平台的抓取程序在解析、连通、证书、风控、状态码、渲染、正文暴露这七层中的任意一层被挡住，页面因此从未进入它的索引或语料。

典型特征只有一个：浏览器打开一切正常，百度和谷歌收录良好，但 DeepSeek、豆包、Kimi、通义千问回答相关问题时从不提你。不是内容不够好，是它压根没读到。

先排除技术性失联，再谈内容优化。顺序反了，内容投入只是在填一个漏水的桶。

三分钟快速分诊：先确认是不是可达性问题

把下面这段贴进终端跑一次，七层的关键信号一次性拿到。 任何一项不达标，直接跳到对应章节细查。

#!/usr/bin/env bash
URL="https://example.com/your-page"
HOST=$(echo "$URL" | awk -F/ '{print $3}')
UA_BOT="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.1; +https://openai.com/gptbot"
UA_WEB="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36"

echo "== 1 解析 =="; dig +short "$HOST" A; dig +short "$HOST" AAAA
echo "== 2 连通 =="; curl -sS -o /dev/null -w "connect=%{time_connect} tls=%{time_appconnect}\n" "$URL"
echo "== 3 证书链张数(应≥2) =="
openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts </dev/null 2>/dev/null | grep -cE "^ [0-9]+ s:"
echo "== 4/5 robots =="; curl -sSI "https://$HOST/robots.txt" | head -n 1
echo "== 4 三身份 状态码/字节数 =="
for ua in "$UA_WEB" "$UA_BOT" ""; do
  curl -sS -o /dev/null -w "%{http_code} %{size_download}\n" -A "$ua" "$URL"
done
echo "== 6/7 爬虫可见正文字符数 =="
curl -sS -A "$UA_BOT" "$URL" | sed 's/<script[^>]*>.*<\/script>//g; s/<[^>]*>//g' | tr -s ' \n' ' ' | wc -c

合格输出长这样： 解析有 A 记录、tls 小于 1 秒、证书链 ≥2 张、robots 返回 200、三身份状态码全 200 且字节数接近、正文字符数 ≥800。

AI爬虫抓不到网站，通常卡在哪一层？

越靠后的层越隐蔽。 解析和连通层故障会让所有客户端一起失败，很容易被发现；风控、渲染、正文暴露这三层的特点是"人能看、机器不能看"，浏览器完全正常，所以往往潜伏几个月。

层级	环节	典型症状	常见返回
1	解析（DNS）	部分地区/线路无法解析	连接超时
2	连通（TCP/TLS）	握手挂起、端口不通	Connection reset
3	证书	浏览器正常、命令行报错	certificate verify failed
4	风控（CDN/WAF）	只有爬虫 UA 被拒	403 / 429 / 5 秒盾
5	状态码与协议	robots 5xx、软 404、重定向链	200 但内容为空
6	渲染	首屏 HTML 没有正文	200 且 HTML 极短
7	正文暴露	正文在 PDF、长图、iframe 里	200 且纯文本极少

一份 412 个中文站点的诊断分布

2026 年 3 月至 6 月，MaxAEO 对 412 个主动提交可达性诊断的中文站点做了统一检测。方法：同一批 URL（首页 + 3 个内容页）分别用桌面浏览器 UA、AI 爬虫 UA、空 UA 各请求 3 次，记录状态码、TLS 握手结果、首字节 HTML 长度与去标签后正文字符数，任一维度不达标即判定该层失败。

结果：147 个站点（35.7%）至少有一层不可达，断点分布如下。

断点层级	站点数	占失败站点
风控（CDN/WAF）	61	41.5%
渲染	38	25.9%
证书	21	14.3%
状态码 / robots	17	11.6%
解析	10	6.8%

两个数字值得注意：风控层占了四成以上，其中 43 个站点的运维完全不知道自己拦了 AI 爬虫，规则来自云厂商默认策略；证书层的 21 个站点里有 18 个是同一个原因——中间证书缺失。

先建立基线：浏览器能打开 ≠ 爬虫能抓到

所有排查从"三身份对照测试"开始：同一个 URL，用浏览器 UA、AI 爬虫 UA、空 UA 各请求一次，比较状态码和响应体长度。 三者一致，问题不在风控层；只有爬虫 UA 异常，风控层就是第一嫌疑人。

URL="https://example.com/your-page"

# 身份 A：桌面浏览器
curl -sS -o /dev/null -w "A %{http_code} %{size_download}\n" \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36" "$URL"

# 身份 B：AI 爬虫
curl -sS -o /dev/null -w "B %{http_code} %{size_download}\n" \
  -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.1; +https://openai.com/gptbot" "$URL"

# 身份 C：空 UA
curl -sS -o /dev/null -w "C %{http_code} %{size_download}\n" -A "" "$URL"

通过标准：三行状态码全为 200，响应体长度差异不超过 5%。 任何一行是 403、429、503 或长度骤降，记下来进入对应层细查。

把身份换成 Baiduspider、Bingbot 也跑一遍。多数国产 AI 的实时联网检索复用底层搜索引擎索引，这些爬虫被拦，等于把 AI 的信源入口一起关了。

第 1 层｜解析：DNS 把 AI 爬虫解到了哪里

DNS 层的故障不是"解析不了"，而是"解析到了不该去的地方"。 GeoDNS 按来源 IP 返回不同 A 记录，而 AI 爬虫出口 IP 多在境外或云厂商 IDC 段，很容易被解析到一个不对外服务的节点。

dig +short example.com A
dig +short example.com AAAA
dig +short example.com CNAME
dig @8.8.8.8 +short example.com A     # 用境外递归再解一次，对比结果

通过标准三条：

1. A 记录在境内、境外两个递归解析器下返回的都是可服务地址；
2. 配了 AAAA 记录，该 IPv6 地址必须真的能提供服务——只写不通的 AAAA，会让优先走 IPv6 的客户端直接失败；
3. CNAME 链不超过 3 跳，末端可解析。

诊断样本中解析层的 10 个案例里，6 个是"AAAA 记录指向已下线的旧节点"。浏览器上几乎看不出来，因为主流浏览器有 Happy Eyeballs 机制会快速回落到 IPv4，而命令行工具和不少爬虫不会。

第 2 层｜连通：TCP、TLS 握手能不能建立

这一层验证"能不能连上"，不是"内容对不对"。

curl -sS -o /dev/null -w "connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com/

通过标准：TLS 握手时间稳定在 1 秒以内，不出现 Connection reset by peer 或握手挂起。 若境内正常、境外超时，说明源站或云防火墙做了地域访问控制——这在国内政企站点上非常常见，也是海外 AI 爬虫拿不到内容的直接原因。

第 3 层｜证书：浏览器不报错，爬虫却握手失败

这是最容易被误判为"没问题"的一层，机制是中间证书缺失。 服务器只下发叶子证书，没下发 CA 的中间证书，客户端拼不出到根证书的完整信任链。

浏览器为什么不报错？主流浏览器实现了 AIA Fetching：发现链条断了，会按证书里的 Authority Information Access 字段自己去下载缺失的中间证书补上。而 curl、Go、Python requests 这类客户端默认不做这件事——绝大多数 AI 爬虫的 HTTP 客户端就建立在这些库之上。结果是：你和运维在浏览器上怎么看都是绿锁，爬虫那边是 unable to get local issuer certificate。

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E "^(Certificate chain|s:|i:|Verify return code)"

通过标准：输出中至少出现 2 张证书（叶子 + 中间），最后一行是 Verify return code: 0 (ok)。 只看到 1 张，就是缺中间证书，需要把 Nginx 的 ssl_certificate 改为包含完整链的 fullchain 文件。

一手案例：家居品牌站的绿锁陷阱

诊断样本中的一个家居品牌站，Nginx 的 ssl_certificate 指向 server.crt 而不是 fullchain.crt。浏览器全绿，百度收录 1.2 万条，但服务器日志里 6 个月没有一条 GPTBot、Bytespider 记录。改成 fullchain 并 reload 之后第 9 天，日志出现第一条 Bytespider 请求；第 14 天，Baiduspider 与 Bytespider 的日均抓取量分别回到 340 次和 87 次。整个修复动作是改一行配置。

第 4 层｜风控：CDN 与 WAF 怎么误杀 AI 爬虫

风控层是最高频的断点，占样本失败站点的 41.5%。 误杀通常来自四类规则，且大多是云厂商默认策略，不是有人主动配置的。

• UA 黑名单：把"非主流搜索引擎爬虫"整类拦掉，AI 爬虫全在里面；
• IP 信誉库：AI 爬虫出口多在 IDC 段，云 WAF 对 IDC 段普遍降权甚至直接拒绝；
• 频率阈值：AI 爬虫短时间批量抓取，容易撞上"同 IP 每分钟 N 次"限速，返回 429；
• 人机验证 / JS 挑战：5 秒盾、滑块、Cookie 校验——对不执行 JavaScript 的爬虫等价于永久 403。

排查方式很直接：在 CDN 实时日志里按 UA 关键字过滤，看拦截动作是 block 还是 pass。规则定位与放行写法照着CDN 与 WAF 误拦截排查清单逐项对；要先确认日志里哪些是真爬虫、哪些是伪装流量，服务器日志识别 AI 爬虫的方法给了 UA 与反向 DNS 双重验证步骤。

一个新变量：CDN 默认就在拦 AI 爬虫

如果你的站点是 2025 年下半年之后接入 Cloudflare 的，默认状态很可能就是屏蔽。 Cloudflare 在 2025 年 7 月的官方公告中宣布，新接入的域名默认阻止 AI 爬虫抓取，并推出按抓取付费（Pay Per Crawl）机制，把"是否放行"变成站长的显式选择。

这意味着**"我没配过任何拦截规则"不再等于"没有拦截"**。国内云厂商的 Bot 管理模块同样在扩充 AI 爬虫特征库，默认动作各家不一。排查时必须去控制台看实际生效的 Bot 策略，而不是回忆自己配过什么。

别照抄网传 UA：目前有公开标识的爬虫

很多流传的 Doubao-Bot、Qwen-Bot、DeepSeek-Bot 并没有官方文档背书，照着写放行规则等于写了一条永远不命中的规则。可靠做法是先从访问日志统计出真实出现过的 UA，再针对性放行。

厂商	公开 UA 标识	用途
OpenAI	GPTBot、OAI-SearchBot、ChatGPT-User	训练抓取 / 搜索索引 / 用户实时访问
Anthropic	ClaudeBot、Claude-SearchBot、Claude-User	抓取 / 搜索索引 / 用户实时访问
Perplexity	PerplexityBot、Perplexity-User	搜索索引 / 用户实时访问
字节跳动	Bytespider	抓取（豆包等产品共用）
华为	PetalBot	抓取（小艺、花瓣搜索）
阿里 UC / 神马	YisouSpider	抓取（夸克检索相关）
百度	Baiduspider	抓取（文心联网检索）
Apple	Applebot、Applebot-Extended	抓取 / 训练用途授权控制
Meta	meta-externalagent	抓取
Google	Google-Extended	仅 robots 令牌，不发起独立请求

秘塔、Kimi、DeepSeek 等目前没有公开爬虫文档，多数通过第三方检索 API 取数——放行它们的正确做法是放行底层搜索引擎爬虫，而不是猜一个 UA。

第 5 层｜状态码与协议：robots.txt 和重定向的隐性成本

这一层最贵的错误是 robots.txt 返回 5xx。 按 Google Search Central 的 robots.txt 规范，robots.txt 返回服务器错误时，Google 会在最初 12 小时内停止抓取整站，之后 30 天内沿用最后一份可用副本；连接超时、DNS 失败也按服务器错误处理。多数遵循 RFC 9309 机器人排除协议的爬虫采用同类逻辑。一次运维事故让 robots.txt 挂掉半天，代价可能是全站被暂停抓取。

自查清单：

• curl -I https://example.com/robots.txt 必须返回 200，Content-Type 为 text/plain；
• robots.txt 里没有 User-agent: * + Disallow: / 的遗留测试规则；
• 内容页不是"软 404"——返回 200 却渲染出"页面不存在"；
• 重定向链不超过 2 跳，不出现跨协议、跨主机的来回跳。

重定向和 404 的浪费比想象中大。Vercel 与 Merj 对十亿级爬虫请求的分析显示，ChatGPT 爬虫 34.82% 的抓取命中 404 页面，另有 14.36% 花在跟随重定向上，而 Googlebot 的对应比例只有 8.22% 和 1.49%。AI 爬虫抓取预算本就不宽裕，近一半消耗在无效 URL 上——清理死链和重定向链，等于直接给有效页面腾配额。

robots.txt 该按什么标准放行、要不要按目录限速，GPTBot、ClaudeBot 与 Bytespider 的放行取舍按业务目标给了可复制的模板。

第 6 层｜渲染：AI 爬虫不执行 JavaScript

结论明确：主流 AI 爬虫拿到 HTML 就走，不执行你的 JavaScript。 上述 Vercel 与 Merj 的分析测试了 OpenAI、Anthropic、Meta、字节跳动、Perplexity 的爬虫，无一渲染客户端内容；ChatGPT 爬虫有 11.50% 的请求在抓取 JS 文件、Claude 有 23.84%，但只是下载，不执行。目前明确具备渲染能力的只有复用 Googlebot 基础设施的 Gemini 和基于浏览器抓取的 AppleBot。

验证只有一行：

curl -sS -A "GPTBot/1.1" https://example.com/your-page | sed 's/<[^>]*>//g' | tr -s ' \n' ' ' | wc -c

通过标准：首字节 HTML 去标签后的正文字符数，不低于浏览器里可见正文的 80%。 输出只有几百字符，说明正文全靠客户端渲染，AI 爬虫看到的是一个空壳。

诊断样本中一个 B2B SaaS 站正是这种情况：Vue SPA，curl 拿到的 HTML 去标签后仅 46 个字符——一个 <div id="app"> 和几个 script 标签。产品页与文档页改成 SSR 之后，同一命令输出 3200 余字符，一个月内 3 个核心问题在国产 AI 平台的回答中开始出现该站引用。单页应用的具体改造与验收方式，SPA 站点的 AI 抓取验收清单拆得更细。

第 7 层｜正文暴露：抓到 HTML 也不等于读到正文

最后一层检查"HTML 里有没有可提取的纯文本"。 前六层全通过，正文仍可能被封在爬虫读不出的容器里。

四种最常见的封装方式：

1. 正文放在 PDF 或长图里——白皮书、产品参数、价目表最常踩；
2. iframe 嵌入——第三方文档系统、帮助中心常见，爬虫不跟进 iframe 内容；
3. 点击展开的折叠区——折叠内容靠 JS 动态插入，首屏 HTML 里就不存在；
4. Shadow DOM 与 Web Component——组件内文本不出现在原始 HTML 中。

通过标准：页面核心事实（定义、参数、价格区间、适用场景、结论）必须以纯文本形式出现在首字节 HTML 中，总量不少于 800 字符。 图片和 PDF 可以保留作为增强，但要有等价的 HTML 文本版本。

一次跑完的完整排查顺序

按下面的顺序执行，每一步不通过就先修，修完再往下——上游不通，下游的测试结果没有意义。

1. 三身份对照测试：状态码全 200、响应体长度差异 <5%；
2. DNS：境内外递归解析结果一致且可服务，AAAA 记录真实可用；
3. TLS 握手：time_appconnect <1 秒，无连接重置；
4. 证书链：openssl s_client 输出 ≥2 张证书，Verify return code: 0；
5. 风控：CDN/WAF 日志中 AI 爬虫 UA 的动作为 pass，无 JS 挑战，确认 Bot 管理默认策略；
6. robots.txt：返回 200、text/plain，无全站 Disallow；
7. 状态码：核心页无软 404，重定向 ≤2 跳；
8. 渲染与正文：curl 首字节去标签正文 ≥浏览器可见正文的 80%，且 ≥800 字符。

八步跑完仍找不到断点，问题通常已不在可达性上，而在内容与实体识别层面。

修复优先级：先修哪一层性价比最高

同时发现多层断点时，按"是否需要发版"排序，而不是按层级顺序。 下表是诊断样本里各层的中位修复耗时。

断点层	中位修复耗时	是否需要发版	影响面	建议顺序
证书	5 分钟（换 fullchain + reload）	否	全站	1
风控	10–30 分钟（改 WAF 规则）	否	全站	2
robots / 状态码	30 分钟	否	全站	3
解析	1 小时 + TTL 等待	否	全站	4
渲染	1–4 周（SSR/预渲染改造）	是	内容页	5
正文暴露	按页改写，无固定周期	是	单页	6

前四项加起来通常两小时内能做完，且覆盖样本中 74% 的失败站点。先把不需要发版的四层清干净，再排渲染改造的工期。

llms.txt 和 sitemap 能解决抓不到吗？

不能。 llms.txt 是一份放在根目录、给大模型看的内容索引提案，目前没有任何主流 AI 厂商公开声明会读取它；sitemap.xml 只是候选 URL 清单，不改变任何一层的可达性。

逻辑很简单：前七层不通，llms.txt 和 sitemap 本身也抓不到。 这两个文件的价值在于七层跑通之后——帮爬虫更快发现内容、更准确地理解站点结构。把它们当成修复手段，是典型的顺序错置。真要写，llms.txt 的文件规范与验证方法里有确认 AI 是否实际读取的做法。

修好之后怎么验收

不要用"AI 提没提我"作为第一验收信号，它滞后且噪声大。 按三级信号依次确认，时间尺度完全不同：

信号	观察对象	典型生效周期
一级	服务器日志出现目标爬虫 UA 且返回 200	3–14 天
二级	AI 平台回答中出现你的域名作为引用来源	2–6 周
三级	目标问题集上的 AI 提及率与排名回升	4–10 周

一级信号是可达性修复的直接证据，也是唯一能在两周内确认的。二级、三级涉及模型索引更新与重排周期，需要按固定问题集、固定采样频率持续观测才有意义——这也是"偶尔手动问一次 AI"得不出结论的原因。

常见问题

问：AI爬虫抓不到网站，但百度和谷歌收录都正常，可能吗？
非常常见，样本里绝大多数案例都是这个形态。搜索引擎爬虫在多数 CDN 和 WAF 的默认白名单里，AI 爬虫不在；再加上百度、谷歌具备 JavaScript 渲染能力，主流 AI 爬虫没有。收录正常只能证明前两层没问题，证明不了风控层和渲染层。

问：robots.txt 放行了所有 AI 爬虫，为什么还是抓不到？
robots.txt 是声明，不是执行层。真正决定放不放行的是 CDN、WAF、云防火墙和源站配置。robots 写了 Allow，WAF 照样能返回 403，两者互不知情。所以 robots 只是第 5 层，前面还有 4 层要过。

问：怎么确认日志里的 GPTBot 是真的，不是别人伪装的？
UA 可以随便伪造，需要反向验证：对请求 IP 做反向 DNS 查询拿到主机名，再对该主机名做正向解析，确认解回同一个 IP，并核对域名归属是否为该 AI 厂商。仅凭 UA 字符串统计抓取量，数据会明显偏高。

问：我用的是 Cloudflare，需要专门做什么？
去 Bot 管理页面确认 AI 爬虫的默认动作。2025 年 7 月之后新接入的域名默认阻止 AI 抓取，"没配过规则"不等于"没有拦截"。确认后按业务目标显式选择放行、限速还是收费。

问：限速能不能代替屏蔽？
可以，且通常更合适。担心带宽成本时，用 Crawl-delay 或 WAF 限速把 AI 爬虫压到可接受的 QPS，比整类拦掉更好——429 会让爬虫在退避后重试，403 则可能让它长期放弃该域名。

问：只有一部分页面 AI 抓不到，怎么定位？
按模板分组做对照，而不是逐页测。同一模板的页面走同一套渲染和风控路径，抽 3 个页面结果一致就能代表整组。重点比较"能抓到的模板"和"抓不到的模板"在渲染方式、CDN 规则组、正文容器上的差异，差异点就是断点。

问：修好可达性之后，多久能在 AI 回答里看到自己？
日志层面 3–14 天可见，AI 回答中出现引用通常 2–6 周，提及率的稳定变化在 4–10 周。周期取决于该平台的索引更新频率和话题竞争密度，不存在"改完立刻生效"。

---

技术可达性是 AI 搜索可见度的地基，不是加分项。七层里断掉任何一层，你的内容对 AI 而言就等于不存在——这一点不会因为内容质量更高、发布频率更快而改变。