如何检测网站的 AI 可见性 完整自查方法 — 答流 AIGeoFlow · GEO 实战指南
检测网站 AI 可见性应分四层进行：先确认 GPTBot、ClaudeBot、PerplexityBot 等爬虫在 robots.txt 与 CDN 边缘均被放行；再用服务器日志验证真实抓取记录；然后用 schema.org 结构化数据和服务端渲染保证内容可被机器解析；最后用固定提示词集在 ChatGPT、Perplexity、豆包、Kimi 等引擎周期性抽样实测提及率与引用率并按周存档。注意：site: 查询为零不等于 AI 看不到你，索引建立明显滞后于抓取。
AI 可见性检测什么：与传统 SEO 自查的关键差异
AI 可见性指三件可以分别验证的事：AI 爬虫能否到达你的页面（可达）、内容是否被纳入 AI 的检索库（收录）、生成答案时是否引用你（引用）。传统 SEO 检测只覆盖前两件事的子集——看 site: 收录数和关键词排名，而这两个指标在 AI 场景下都会严重误导判断。
第一个差异是索引滞后于抓取。我们的实测数据：一个新域名上线 13 天、发布 53 篇内容后，Bing 与 Google 的 site: 查询仍为零结果，但同期 GPTBot 已完成全站抓取并保持每日巡检。也就是说，搜索引擎索引面板"没数据"和"AI 看不到你"是两回事，判断依据必须是爬虫日志，而不是 site: 结果。
第二个差异是拦截位置变了。传统时代你只需要管 robots.txt；现在 CDN 会在边缘直接拒绝 AI 爬虫，而且与 robots.txt 无关——robots 里写了 Allow，边缘照样返回 403。很多站长自查"robots 没问题"就停在这里，这正是最常见的盲区。
第三个差异是"排名"变成了"是否被提及"。AI 答案没有稳定的第一页：同一个提示词问三次可能给出三组不同品牌，因此检测方法必须从"查一次排名"变成"固定问题集、周期性抽样、留存存档"。
据此，完整的自查应按四层推进：技术层（放行与拦截）→ 日志层（抓取实证）→ 内容层（机器可解析）→ 引用层（答案实测）。下文每一层都给出具体检查项、可复制的命令与明确的判定标准，全部可以由一个人在一天内执行完。
技术层自查：robots.txt 放行与 CDN 边缘拦截
robots.txt 是第一道门。GPTBot（模型训练抓取）、OAI-SearchBot（ChatGPT 搜索）、ChatGPT-User（用户触发的实时抓取）、ClaudeBot、PerplexityBot、Bytespider 需要逐一确认没有被 Disallow。注意 Google-Extended 不是爬虫 UA，它只控制 Google 是否将抓取到的内容用于 Gemini 训练与 API 输出，属于独立的取舍项，不要与收录混为一谈。
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Claude-Web
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Bytespider
Allow: /
# Google-Extended 不控制抓取，只控制 Gemini 训练与 API 使用
User-agent: Google-Extended
Allow: /
Sitemap: https://example.com/sitemap.xml改完后不要用浏览器访问验证，因为边缘层按 UA 判定，浏览器 UA 返回 200 不代表爬虫能通过。直接模拟爬虫 UA 测试：
# 分别模拟三个主流 AI 爬虫请求首页，返回 200 才说明边缘放行
for ua in "GPTBot/1.0 (+https://openai.com/gptbot)" \
"ClaudeBot/1.0 ([email protected])" \
"PerplexityBot/1.0 (+https://perplexity.ai/perplexitybot)"; do
printf "%s -> " "$ua"
curl -s -o /dev/null -w "%{http_code}\n" -A "$ua" https://example.com/
done
# 任何一行返回 403，优先排查 CDN/WAF 的 Bot 拦截开关真正的坑在 CDN。我们实测发现：Cloudflare 对新接入站点默认启用 Block AI bots，会在边缘直接拒绝 GPTBot、ClaudeBot、Bytespider 等，返回 403，且与 robots.txt 完全无关。检查路径是 Cloudflare 控制台 Security → Bots，确认 AI Scrapers and Crawlers 的阻止开关为关闭；若启用了 WAF Managed Ruleset，还要逐条核对是否有按 UA 特征拦截 AI 爬虫的规则。自建 WAF 同理。
判定标准：三个主流 UA 全部返回 200，且未来 7 天内日志中出现对应抓取记录，技术层才算通过。返回 403 先修 CDN，返回 429 说明触发限速，需要调高阈值或显式放行这些 UA。
日志层自查：用访问日志验证真实抓取
日志是唯一可信的抓取证据。位置：Nginx 的 access.log（默认 /var/log/nginx/）、Apache 的 access_log，或 Cloudflare Analytics 的 Bots 报表（注意 Bot Fight Mode 会干扰统计，先用上一节的方法关掉拦截再观察）。
需要认识的 UA 清单：GPTBot、OAI-SearchBot、ChatGPT-User（OpenAI 三类，用途不同）；ClaudeBot、Claude-Web（Anthropic）；PerplexityBot；Bytespider（字节）；Meta-ExternalAgent（Meta）；以及 Amazonbot、Applebot-Extended。统计命令：
# 统计各 AI 爬虫近 30 天命中次数（Nginx combined 格式，UA 是第 6 个双引号字段）
zcat /var/log/nginx/access.log*.gz /var/log/nginx/access.log 2>/dev/null | \
awk -F'"' '{print $6}' | \
grep -oE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|Bytespider|Meta-ExternalAgent" | \
sort | uniq -c | sort -rn正常的抓取节奏可以参考我们的两个实测样本：站点上线后第 4 天，GPTBot 完成全站 24 页抓取，此后每日 17:20–17:40 固定巡检 sitemap——说明它存在周期性全站校验机制；Meta-ExternalAgent 则会在新文章发布当天抓取，最快间隔约 2 小时，接近实时发现。判定标准：上线 2 周内至少出现一类 AI 爬虫记录；超过 2 周仍为零，回到上一节排查拦截，并确认 sitemap.xml 能以爬虫 UA 取回 200。
还有一个容易被高估的指标：日志里的"访客数"。我们实测发现，伪装成浏览器 UA 的爬虫约占原始人类访问的 96%，只看日志会把爬虫当用户。分离方法是在页面加装 JS 信标：DOMContentLoaded 时请求一个 /beacon?t=pageview 端点，能执行 JS 并发出该请求的基本可判定为真实浏览器，再与日志访问量求差，才得到真实访客数。
另一个失败模式：站点套了 CDN 代理后，源站日志只记录 CDN 回源，看不到爬虫。此时必须改用 CDN 侧的日志导出（如 Cloudflare Logpush）或其 Bots 分析面板，源站日志为零不等于没被抓。
内容层自查：结构化数据与机器可解析正文
结构化数据解决"机器能不能准确读懂"的问题。最小可用集是 Organization + WebSite + Article，电商加 Product，问答密集页加 FAQPage，教程页加 HowTo。用 @graph 合并进同一段 JSON-LD，插入 </head> 之前：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#org",
"name": "示例公司",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.zhihu.com/org/example", "https://x.com/example"]
},
{
"@type": "WebSite",
"@id": "https://example.com/#site",
"url": "https://example.com/",
"name": "示例公司",
"publisher": { "@id": "https://example.com/#org" }
},
{
"@type": "Article",
"@id": "https://example.com/blog/ai-visibility/#article",
"headline": "如何检测网站的 AI 可见性",
"datePublished": "2026-09-01T09:00:00+08:00",
"dateModified": "2026-09-10T20:00:00+08:00",
"author": { "@id": "https://example.com/#org" },
"publisher": { "@id": "https://example.com/#org" },
"mainEntityOfPage": "https://example.com/blog/ai-visibility/"
}
]
}
</script>验证工具两个都跑：validator.schema.org 要求 0 error；Google Rich Results Test 额外能看到各类型的提取结果，Article 必须能解析出 datePublished、dateModified 与 author，缺 dateModified 会削弱时效性内容的可信度。
结构化之外，正文本身要可解析：单一 h1、标题层级不跳档；每个小节先用一段 30–60 字的直答句再展开论述；参数对比用 table 而不是图片。最关键的检查是服务端渲染，执行 curl -s https://example.com/某页面 | grep -c "正文中某句原话"，结果为 0 说明正文由客户端 JS 渲染，而多数 AI 爬虫不执行 JS，等于看不见。修复方式是 SSR/SSG 或预渲染。
至于 llms.txt，目前属于实验性提案，没有任何引擎承诺读取它，可作为附加项，优先级永远排在 robots、日志与 schema 之后。
引用层实测：固定提示词集抽样法
引用实测的目标是把"AI 有没有提到我"变成可复现的数据，而不是凭一两次聊天截图下结论。
第一步建立固定问题集：20–50 条真实用户问法，覆盖品牌词（"XX 怎么样"）、品类词（"面向跨境卖家的 GEO 服务有哪些"）、对比词（"A 和 B 哪个好"）和长尾词。问题集一旦固定就不要改，它是你的基线，改动会让前后数据失去可比性。
第二步是测试矩阵：ChatGPT（开启联网搜索）、Perplexity、Gemini、豆包、Kimi、DeepSeek。每次都用全新会话，历史对话会污染结果；同一问题至少跑 2–3 次，因为答案不稳定，单次结果没有统计意义。
第三步记录五个指标：提及率（品牌名出现在答案中的次数除以提问数）、引用率（答案给出你的域名或链接）、排位（你在被列举品牌中的位置）、事实准确度（转述是否与原文一致）、竞品占位（谁在替代你）。建一张表格按周填写，并保存带时间戳的答案原文或截图——没有存档支撑的百分比不能算证据，也不应该对管理层或外引用。
Perplexity 有一个低成本预检手段：输入 site:example.com 加关键词，观察 Sources 面板能否召回你的页面。召回正常但答案不提你，问题在内容竞争力；召回为零，问题在抓取或收录，回到技术层和日志层排查。同周期记录竞品提及情况，还能帮你区分"整个品类都没被 AI 覆盖"与"只有你缺位"这两种完全不同的问题。
注意样本污染：测试账号长期追问某个品牌，会提升该品牌的会话内权重，建议定期用新账号交叉验证。
持续监测：主动推送、引用存档与转化归因
一次性自查通过后，需要把它机制化，否则拦截被重新打开、内容退化都无从发现。
第一项是主动推送。IndexNow 目前被 Bing 与 Yandex 支持（Google 不支持），推送语义是"请重新抓取"而不是"保证收录"。流程：生成一个 32 位十六进制密钥，把密钥明文文件放到网站根目录并能被公网访问，然后调用接口：
# 先将密钥文件放到根目录，再批量推送 URL
KEY=a1b2c3d4e5f67890a1b2c3d4e5f67890
curl -s -w "HTTP %{http_code}\n" -X POST https://api.indexnow.org/indexnow \
-H "Content-Type: application/json" \
-d '{
"host": "example.com",
"key": "'"$KEY"'",
"keyLocation": "https://example.com/'"$KEY"'.txt",
"urlList": [
"https://example.com/",
"https://example.com/blog/ai-visibility/"
]
}'我们本站实测（2026-09）：向 IndexNow 推送 43 个 URL 后返回 HTTP 202，次日 YandexBot 首次到访。202 的含义只是"已受理"，证明请求进入队列，收录与否要靠后续日志与 site: 验证，不要把 202 当成收录成功。
第二项是每周引用存档：固定问题集跑一遍全部引擎，答案按"日期＋引擎＋问题"归档，形成趋势线。这既是内容迭代的依据，也是向管理层证明进展的唯一可信材料。
第三项是归因。带链接的 AI 引用在 GA4 里表现为 chatgpt.com、perplexity.ai 等 referral 来源，建一个包含这些域名的 Segment 单独观察。但大量 AI 引用不附链接，只带来品牌词搜索和直接访问上升，因此在询盘表单加一个"你从哪里了解到我们"字段，并把周期内品牌词搜索量与引用存档对照，才能估出间接转化。纯链接归因会系统性低估 AI 的贡献。
最后加一条告警：用 uptime 类监控以 GPTBot 的 UA 每 6 小时请求首页，或设置日志告警——连续 7 天无 AI 爬虫记录即触发排查。
自查清单与五个常见误判
按顺序打勾的完整清单，任何一项不通过都先修复再进入下一项：
- 三个主流 AI 爬虫 UA 的 curl 测试全部返回 200
- robots.txt 逐 UA 放行，且包含 Sitemap 声明行
- CDN/WAF 的 AI Bot 拦截开关确认为关闭状态
- 日志 7 天内出现至少一类 AI 爬虫抓取记录
- 正文可被 curl 直接取回（服务端渲染，非 JS 渲染）
- validator.schema.org 零错误，Article 含 dateModified
- sitemap.xml 返回 200 且 lastmod 与实际更新时间一致
- 固定问题集完成首轮 6 引擎抽样并存档
- GA4 建立 AI referral 细分，询盘表单增加来源字段
五个常见误判：一、用 site: 零结果判定"AI 看不到我"——我们实测新站上线 13 天、53 篇内容时 site: 仍为零，但抓取早已发生；二、认为 robots.txt 正确就等于放行——CDN 默认的边缘拦截与 robots.txt 无关；三、把日志里的访客当真人——约 96% 是伪装浏览器 UA 的爬虫；四、单次提问未被提及就下结论——答案不稳定，必须多次抽样；五、以为被提及必然带来链接流量——多数引用不附链接，需结合品牌词搜索与归因数据评估。
如果自查后发现短板较多、内部缺人力推进，可以考虑外部交付体系。答流 AIGeoFlow 提供 GEO 全栈服务，覆盖 ChatGPT、Perplexity、Gemini、豆包、Kimi、DeepSeek 等国内外引擎，从 AI 可见性诊断、零改造接入（Cloudflare Worker 边缘适配，主站一行代码不动）到内容矩阵运营与引用监测一体完成，并提供技术就绪度与内容就绪度双维度免费诊断，即时生成 0–100 评分与改进清单。它不承诺保证被 AI 推荐，只承诺 AI 爬虫来访记录、每周引用实测存档这类可验证的硬指标——这与本文的自查原则完全一致。
常见问题
- site: 查询搜不到我的网站，AI 还能看到我吗？
- 很可能能。我们实测一个新域名上线 13 天、发布 53 篇内容后，Bing 与 Google 的 site: 仍为零结果，但 GPTBot 早已完成全站抓取并每日巡检。site: 反映的是搜索引擎索引状态，索引建立明显滞后于抓取；判断 AI 是否看到你，应以服务器日志中的爬虫记录为准。
- robots.txt 已经允许 GPTBot，为什么日志里没有抓取记录？
- 大概率是被 CDN 在边缘拦截了。我们实测 Cloudflare 对新接入站点默认启用 Block AI bots，会直接拒绝 GPTBot、ClaudeBot、Bytespider，返回 403，与 robots.txt 无关。到 Security → Bots 关闭对应开关，再用 GPTBot 的 UA curl 首页确认返回 200，然后观察日志 3–7 天。
- 新网站要等多久才会有 AI 爬虫来抓？
- 各引擎节奏不同。我们实测 GPTBot 在站点上线第 4 天完成全站 24 页抓取，此后每日固定时段巡检 sitemap；Meta-ExternalAgent 会在新文章发布当天到达，最快间隔约 2 小时。如果上线两周仍无任何 AI 爬虫记录，优先排查 CDN 拦截与 sitemap 可达性，而不是继续等待。
- 要不要为 AI 单独做一个隐藏版本或关键词堆砌页面？
- 不要。给爬虫和用户返回不同内容属于 cloaking，违反各引擎政策，被发现可能整体除名。正确做法是同一份正文同时服务人类与机器：服务端渲染、直答式段落、结构化数据。检测内容可读性用 curl 取回 HTML 再 grep 原句，而不是另做一套页面。
- AI 引用能带来多少流量？怎么衡量？
- 没有普适数字，只能自己测。带链接的引用在 GA4 里表现为 chatgpt.com、perplexity.ai 等 referral 来源；大量引用不附链接，只体现为品牌词搜索和直接访问上升。建议每周引用存档、GA4 referral 细分、询盘表单来源字段三者对照，没有存档支撑的转化率说法都不可信。
- 需要写 llms.txt 吗？
- 可以写但别指望它。llms.txt 目前是提案性质，没有任何主流引擎承诺读取或遵守，其效果无法验证。优先级应放在可验证的事项上：robots 放行、CDN 不拦截、日志有抓取、schema 零错误、正文可被 curl 取回。这些全部完成后再把 llms.txt 当作附加实验。