技术项全过、引用次数为零：AI 爬虫配置清单实测复盘：原理解析、实操步骤、常见问题与优化建议，覆盖关键步骤与实践要点

Q: 怎么确认 AI 爬虫真的来过

所有配置都部署了，怎么知道 AI 平台的爬虫到底来没来过你的网站？ 看 Nginx 的 access log。 ```

Q: 为什么 /.well-known/ai.txt 访问返回 403？

Nginx 里常见的 location ~ /\. 规则本意是拦截 .git、.env 等敏感文件，但会误伤 /.well-known/ 路径。在该规则前加 location ^~ /.well-known/ { try_files $uri =404; } 即可，注意 ^~ 修饰符不能省。

核心洞察

这篇文章最有意思的地方是那个实验：技术项全部通过，引用次数还是零。作者没有回避这个尴尬，反而把它当成整篇文章的起点。如果你正在做 GEO 但只盯着技术配置，这篇值得看完再动手。

我最近做了一个实验。

把一个新上线的静态站点做了一轮 AI 爬虫可访问性整改，然后用两套检查脚本复测：一套检查 robots.txtA text file that instructs web crawlers which pages or files to access or ignore on a website.、Schema 和 JSON 端点的可访问性，另一套检查页面结构化数据完整度。整改后，技术项基本都通过了。

然后我拿真实问题去通义千问的 API 上搜。10个语义变体问题，99条引用来源。

测试站点的引用次数，0。

这个结果让我重新审视了「技术优化」和「AI 实际引用」之间的差距。技术优化是地基，地基打得再好，上面没盖房子，AI 还是不知道这个站点提供了什么内容。

但技术优化当然重要。地基没打好，后续内容再完整，AI 爬虫也可能访问不到。这篇文章只整理技术配置和验证方法，一项一项来。

核心结论

技术项全部通过不等于被 AI 引用：作者对一个静态站点完成 AI 爬虫可访问性整改后，用 10 个语义变体问题在通义千问 API 测试，99 条引用来源中该站点引用次数为 0，说明技术优化只解决「可见性准入」，不解决「引用率」。
AI 爬虫需区分「搜索引用型」和「训练型」：OAI-SearchBot、Claude-SearchBot、PerplexityBot 应 Allow；GPTBot、ClaudeBot、Google-Extended 属训练爬虫，ClaudeBot 在某些站点的爬取引用比低至 20600:1，可按带宽承受力决定是否 Block。
ChatGPT-User 和 Google-Agent 不遵守 robots.txt：OpenAI 自 2026 年 1 月起声明 ChatGPT-UserOpenAI 的 User-Agent，从 2026 年 1 月起被声明为人类用户的代理，不遵守 robots.txt 约束。视为人类用户代理，Google 于 2026 年 3 月新增的 Google-AgentGoogle 于 2026 年 3 月新增的 User-Agent，用于 Project Mariner，同样忽略 robots.txt。（用于 Project Mariner）同样忽略 robots.txt，拦截这两个 UA 只能靠服务器端 IP 防火墙。
llms.txtA standardized file format that allows website owners to communicate AI training and usage policies to AI crawlers, language models, and AI-driven search engines. 尚未被主流 AI 平台官方支持：一份 48 天公开服务器日志审计（2026 年 2-3 月，12099 次 AI 爬虫请求）显示 AI 爬虫对 llms.txt 的请求次数为零，但该文件在 Cursor、Continue、Aider 等开发者工具和 RAG 框架中有实际采用，属「做了不保证被读取，不做也无损失」的选项。
Schema JSON-LD基于 Schema.org 词汇表的结构化数据格式，使用 JSON-LD 语法嵌入网页，帮助搜索引擎和 AI 理解页面内容的语义。建议给 @graph 每个节点显式加 @context：虽然 Schema.org 规范支持文档级 @context 继承，且 Google Rich Results Test 支持继承解析，但部分检查脚本会逐节点校验 @context，只写顶层可能被判定为字段不完整。

robots.txt，AI 爬虫能看到你的页面吗

这听起来太基础了，基础到很多人会跳过。但在实际排查里，robots.txt 配置问题经常排在前面。

不是配置错了，是根本没想过 AI 爬虫这件事。

传统的 robots.txt 通常只关注 Googlebot 和 Baiduspider。但现在有一批新的 AI 爬虫 User-Agent 需要放行。

但在写 Allow 规则之前，有一件事得先想清楚：你放行的这个爬虫，是来搜索引用你的，还是来爬训练数据的。

搜索引用爬虫（OAI-SearchBot、Claude-SearchBot、PerplexityBot），它们的抓取结果直接决定你在 ChatGPT Search、Claude Search、Perplexity 里能不能被引用。这些应该 Allow。

训练爬虫（GPTBot、ClaudeBot、Google-Extended），爬取量巨大但回传引用率极低。ClaudeBot 在某些站点的爬取引用比甚至达到了 20600:1，也就是爬了两万多次才产生一次引用。站点的带宽开销是实打实的，但可回收价值很低。很多站点选择直接 Block 训练爬虫。

# 搜索/引用爬虫 —— Allow
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /

# 训练爬虫 —— 视带宽承受力决定 Allow 或 Disallow
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Google-Extended
Disallow: /

还有一个需要知道的事实。

ChatGPT-User 和 Google-Agent 这两个 User-Agent，不遵守 robots.txt。OpenAI 从 2026 年 1 月起明确声明 ChatGPT-User 被视为人类用户的代理，不受 robots.txt 约束。Google 在 2026 年 3 月新增了 Google-Agent，用于 Project Mariner，同样忽略 robots.txt。

要拦截这两个，只能靠服务器端 IP 防火墙，robots.txt 管不到。

还有一个很容易被漏掉的点。

Nginx 配置里经常会有一条规则，禁止访问以点号开头的路径。

location ~ /\. {
    deny all;
}

这条规则的目的是防止别人访问 .git、.env 这种敏感文件。但它也会拦截 /.well-known/ 路径。

而 /.well-known/ai.txt 是给 AI 爬虫看的权限声明文件。

实际部署中很容易碰到这个问题：访问 /.well-known/ai.txt 返回 403，最后发现是这条 Nginx 规则命中了。

修法很简单，在这条 deny 规则前面加一行。

location ^~ /.well-known/ {
    try_files $uri =404;
}

注意那个 ^~ 修饰符。它告诉 Nginx 这个前缀匹配优先于后续的正则匹配。没有这个符号的话，location ~ /\. 还是会先命中。

配完之后，验证一下。

curl -I https://你的域名/.well-known/ai.txt
# 应该返回 200，不是 403/404

curl -A "GPTBot" https://你的域名/robots.txt
# 确认 AI 爬虫的 User-Agent 没有被拦截

llms.txt，大模型专用的索引文件

robots.txt 告诉爬虫「你可以看哪里」。llms.txt 告诉大模型「我这里有什么值得看的」。

这个概念最早由 Jeremy Howard 提议，他把它类比为「给 LLM 看的 robots.txt」。大模型处理信息的方式跟搜索引擎不一样，它更愿意读纯文本，而且读网页的时候 token 是有限的。你给它一个结构清晰的 markdown 索引，比让它自己爬整个网站效率高。

这玩意不是 W3C 标准，当前也没有任何一家主流 AI 平台在官方爬虫文档里确认支持 llms.txt。一份 48 天的公开服务器日志审计（2026 年 2-3 月，12099 次 AI 爬虫请求）显示，AI 爬虫对 llms.txt 的请求次数为零。

但 llms.txt 在开发者工具（Cursor、Continue、Aider）和 RAG 框架里确实有实际采用。在当前 GEO 实践里，它也是部分检查脚本的检查项。所以结论是：做了不保证被任何平台读取，但不做也没什么损失。如果带宽和精力允许，顺手放一个就行。

一个基本的 llms.txt 长这样。

# ExampleSite

一个用于演示 AI 爬虫可访问性配置的示例站点。

## 核心页面
- [首页](https://example.com/)
- [文档](https://example.com/docs)
- [常见问题](https://example.com/faq)

## AI 结构化数据
- [站点摘要](https://example.com/ai/summary.json)
- [能力说明](https://example.com/ai/capabilities.json)
- [常见问题](https://example.com/ai/faq.json)

## 技术信息
- Schema.org JSON-LD: Organization, WebSite, SoftwareApplication, Service, FAQPage
- 框架: 纯静态 HTML + Nginx
- 更新频率: 周级

写这个文件的时候注意几个点。

第一，不要写成 SEO 式的关键词堆砌。大模型不吃那套。写清楚你是谁、你有什么、别人怎么找到你，就够了。

第二，如果你网站内容很多，可以再单独做一个 llms-full.txt，把主要页面的正文内容都放进去。但注意别太大，太大的话大模型会截断。

第三，llms.txt 本身不能保证大模型一定会读。这取决于具体平台的实现。但这个文件现在已经成为 GEO 的事实标准之一了，做了比不做好。

Schema JSON-LD，结构化数据的正确姿势

这是技术栈里最容易被搞错的地方，也是审计扣分最狠的地方。

从 JSON-LD 和 Schema.org 的规范来说，文档级声明的 @context 子节点是可以继承的。Google 的 Rich Results Test 和 Schema.org 官方验证器都支持这种继承。

但现实是，某些检查脚本会逐个节点检查 @context，不支持继承解析。如果你只写在顶层，这些脚本可能会把子节点判定为字段不完整。

所以实操建议还是给 @graph 数组里的每一个节点显式加上 @context。这不是 Schema.org 的规范要求，纯粹是为了兼容部分工具的解析逻辑。

一个正确的 Organization schema 长这样。

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@context": "https://schema.org",
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "ExampleSite",
      "url": "https://example.com/",
      "sameAs": [
        "https://github.com/example/example-site",
        "https://example.com/docs"
      ]
    }
  ]
}

几个容易踩的坑。

@id 不是必填但强烈建议加上。这个值是一个 URI，作为这个实体在语义网里的唯一标识。加上之后，不同页面或不同系统引用同一个实体时能用这个 URI 做关联，这是 Schema 互联互通的核心逻辑。

sameAs 数组放的是这个实体在其他平台上的页面链接。生产环境里可以放官方文档、代码仓库、组织主页或其他可信来源。不要为了凑字段放无关链接，关联错了反而会干扰实体识别。

除了 Organization，一个内容站点通常还会用到这几个 schema 类型。

WebSite 类型，告诉搜索引擎这个网站的基本信息。

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "ExampleSite",
  "inLanguage": "zh-CN",
  "dateModified": "2026-05-15"
}

dateModified 这个字段值得专门说一下。很多检查脚本会关注内容是否「新鲜」。如果页面内容有更新，记得同步更新这个日期。

FAQPage 类型，如果你网站上有问答内容。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "GEO 和 SEO 有什么区别？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO 主要优化搜索结果排名和点击，GEO 更关注 AI 答案是否认识你、是否说准你、是否引用你的官方内容。"
      }
    }
  ]
}

FAQPage 对 GEO 来说很重要。因为用户跟 AI 搜索引擎的交互就是问答模式，而 FAQPage 的结构天然对问答友好。AI 在做 RAG 检索的时候，FAQ 格式的内容更容易被匹配到。

Schema 配完之后，用 Google 官方的 Rich Results Test 验证。

# 在线验证
https://search.google.com/test/rich-results-test?url=你的页面URL

# 或者用 Schema.org 的通用验证器
https://validator.schema.org/

如果你的 JSON-LD 有语法错误或者 @context 缺失，这两个工具会直接标红。比自己对着一堆花括号检查靠谱得多。

Service 类型，描述站点提供的一类功能。

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "站点文档检索",
  "description": "提供站点文档、常见问题和结构化说明，方便搜索引擎和 AI 爬虫理解页面内容",
  "provider": {
    "@type": "Organization",
    "name": "ExampleSite"
  }
}

AI Discovery 端点部分检查脚本自定义的 JSON 端点检查项，包括 summary.json、faq.json、capabilities.json，用于向 AI 爬虫提供站点摘要、常见问题和能力说明。，告诉 AI 你是谁

这三个端点目前不是 W3C 标准，也跟 IETF 在 2026 年 3 月讨论的 “AI Discovery Endpoint” 规范草案不是一回事（那个草案要求的字段结构和这个完全不同）。部分检查脚本会把这类文件作为机器可读性检查项，所以这里按常见 JSON 端点来举例。

更准确地说，这是部分检查脚本自定义的检查项，而非行业通用约定。如果你的流程会检查这些端点，那就配；如果不检查，也可以先不做。

在你的网站 /ai/ 目录下放三个 JSON 文件。

summary.json - 站点摘要。

{
  "name": "ExampleSite",
  "description": "ExampleSite 是一个示例站点，用于演示如何向搜索引擎和 AI 爬虫提供清晰的站点摘要、页面索引和结构化数据。",
  "url": "https://example.com/",
  "lastModified": "2026-05-15"
}

文件名和字段名要求很严格。name 字段必须在根部，不能嵌套在 site 对象下面。name 至少3个字符，description 至少20个字符。很多检查脚本就是直接按这些规则校验的，字段不对就会判定不通过。

faq.json - 常见问题。

{
  "faqs": [
    {
      "question": "GEO 和 SEO 有什么区别？",
      "answer": "SEO 主要优化搜索结果排名和点击..."
    }
  ]
}

注意根键名是 faqs 不是 faq，每条记录的字段名是 question 和 answer，不是 q 和 a。question 至少10个字符，answer 至少20个字符。

capabilities.json - 能力说明。

{
  "name": "ExampleSite capabilities",
  "description": "列出示例站点可被机器读取的公开内容入口。",
  "provider": {
    "name": "ExampleSite",
    "url": "https://example.com/",
    "areaServed": "CN"
  },
  "items": [
    {
      "id": "docs",
      "name": "文档索引",
      "url": "https://example.com/docs"
    }
  ]
}

这三个文件的格式不是国际标准，在行业里也还没形成广泛约定。如果你的检查脚本或内部规范会读取这些端点，就按它的字段要求配置；如果不检查，也可以先不做。

放完之后逐文件验证。

curl -s https://你的域名/ai/summary.json | python -m json.tool
curl -s https://你的域名/ai/faq.json | python -m json.tool
curl -s https://你的域名/ai/capabilities.json | python -m json.tool

三个都返回 200 且 JSON 格式正确，就说明 AI 爬虫能读到这些端点了。

`.well-known/ai.txt`，AI 爬虫的权限声明

跟 robots.txt 互补的一个文件。格式没有严格规范，当前常见写法是这样。

Allow: /
Allow: /llms.txt
Allow: /llms-full.txt
Allow: /sitemap.xml
Allow: /robots.txt
Allow: /ai/
Cite-As: ExampleSite (https://example.com/)

Cite-As 行告诉 AI，如果你要在回答里引用这个网站的内容，应该用什么样的格式标注来源。

关键词密度，一个反直觉的发现

大多数人的直觉是，品牌名出现得越多，AI 越容易记住你。

但实际上，部分检查脚本对关键词密度有上限检查。同一段文本里实体名出现太多次，可能会触发「过度优化」判定。

实操中可以把一个页面上反复出现的同一实体名，替换成「本站」「这个项目」「该页面」这样的自然表述。关键词占比从偏高降到正常区间后，页面也更接近正常技术文档。

不是说别用品牌词，是用得自然，别硬塞。

怎么确认 AI 爬虫真的来过

所有配置都部署了，怎么知道 AI 平台的爬虫到底来没来过你的网站？

看 Nginx 的 access log。

# 过滤常见 AI 爬虫的 User-Agent
grep -E "GPTBot|Claude|Perplexity|ChatGPT|anthropic" /var/log/nginx/access.log

# 看最近7天的
grep -E "GPTBot|Claude|Perplexity" /var/log/nginx/access.log | awk '$4 >= from' from=$(date -d '7 days ago' '+%d/%b/%Y')

如果日志里能看到这些 User-Agent 的请求记录，说明你的内容已经进入了 AI 爬虫的抓取队列。如果没有，检查下 robots.txt 和 Nginx 配置再确认一遍。

修完这些东西，拿到 80 分，然后呢

回到文章开头那个故事。

技术项全部通过，实际引用次数仍然可能是 0。

这个落差不是技术优化没用，而是技术优化解决的是「可见性准入」问题，不是「引用率」问题。

你修好了路，路上才会有车。但不是修好路了车就自动来了。你还得让司机们知道这里有一条路，你还得让他们觉得走这条路值得。

换句话说，技术优化是让 AI 能读到你，内容优化是让 AI 想引用你。两者缺一不可。

而内容优化的第一性原理其实特别简单。

在 AI 真正会去看的那些平台上，写 AI 真正需要的那些内容。

对于不同技术主题，AI 会引用的平台不一样。可以用一组固定问题做采样，统计回答里出现的来源域名，再判断该补哪类内容。

然后去那些地方写。

不是写广告，是写对用户有用的东西。

以上。

常见问题（FAQ）

robots.txt 里哪些 AI 爬虫该放行，哪些该拦截？

搜索引用类爬虫如 OAI-SearchBot、Claude-SearchBot、PerplexityBot 应 Allow，它们决定你能否被引用；训练类爬虫如 GPTBot、ClaudeBot、Google-Extended 爬取量大但引用率极低，可按带宽承受力选择 Disallow。

为什么 /.well-known/ai.txt与 robots.txt 互补的 AI 爬虫权限声明文件，格式无严格规范，可包含 Allow 规则和 Cite-As 引用格式声明。访问返回 403？

Nginx 里常见的 location ~ /. 规则本意是拦截 .git、.env 等敏感文件，但会误伤 /.well-known/ 路径。在该规则前加 location ^~ /.well-known/ { try_files $uri =404; } 即可，注意 ^~ 修饰符不能省。

技术项全部通过，AI 引用次数还是 0 是怎么回事？

作者实测发现，robots.txt、Schema、JSON 端点全部通过后，99 条引用来源中测试站点仍为 0 次。这说明技术优化只是「可见性准入」，决定引用率的关键还是内容本身是否值得被 AI 引用。

技术项全过、引用次数为零：AI 爬虫配置清单实测复盘

AIAI Summary (BLUF)

核心洞察

核心结论

robots.txt，AI 爬虫能看到你的页面吗

llms.txt，大模型专用的索引文件

Schema JSON-LD，结构化数据的正确姿势

AI Discovery 端点部分检查脚本自定义的 JSON 端点检查项，包括 summary.json、faq.json、capabilities.json，用于向 AI 爬虫提供站点摘要、常见问题和能力说明。，告诉 AI 你是谁

`.well-known/ai.txt`，AI 爬虫的权限声明

关键词密度，一个反直觉的发现

怎么确认 AI 爬虫真的来过

修完这些东西，拿到 80 分，然后呢

常见问题（FAQ）

robots.txt 里哪些 AI 爬虫该放行，哪些该拦截？

为什么 /.well-known/ai.txt与 robots.txt 互补的 AI 爬虫权限声明文件，格式无严格规范，可包含 Allow 规则和 Cite-As 引用格式声明。访问返回 403？

技术项全部通过，AI 引用次数还是 0 是怎么回事？

上下文工程落地实战：为什么塞满窗口反而让 Agent 变笨

上下文工程只是子集：Harness Engineering 才是 Agent 稳定干活的关键

上下文窗口越大越好？Agent 稳定用上资料的真正门槛

Googlebot 抓不到你的网站，AI 搜索里也不会有你

AIAI Summary (BLUF)

核心洞察

核心结论

robots.txt，AI 爬虫能看到你的页面吗

llms.txt，大模型专用的索引文件

Schema JSON-LD，结构化数据的正确姿势

AI Discovery 端点部分检查脚本自定义的 JSON 端点检查项，包括 summary.json、faq.json、capabilities.json，用于向 AI 爬虫提供站点摘要、常见问题和能力说明。，告诉 AI 你是谁

.well-known/ai.txt，AI 爬虫的权限声明

关键词密度，一个反直觉的发现

怎么确认 AI 爬虫真的来过

修完这些东西，拿到 80 分，然后呢

常见问题（FAQ）

robots.txt 里哪些 AI 爬虫该放行，哪些该拦截？

为什么 /.well-known/ai.txt与 robots.txt 互补的 AI 爬虫权限声明文件，格式无严格规范，可包含 Allow 规则和 Cite-As 引用格式声明。 访问返回 403？

技术项全部通过，AI 引用次数还是 0 是怎么回事？

相关文章

上下文工程落地实战：为什么塞满窗口反而让 Agent 变笨

上下文工程只是子集：Harness Engineering 才是 Agent 稳定干活的关键

上下文窗口越大越好？Agent 稳定用上资料的真正门槛

Googlebot 抓不到你的网站，AI 搜索里也不会有你

`.well-known/ai.txt`，AI 爬虫的权限声明

为什么 /.well-known/ai.txt与 robots.txt 互补的 AI 爬虫权限声明文件，格式无严格规范，可包含 Allow 规则和 Cite-As 引用格式声明。访问返回 403？