如何被 ChatGPT 引用：到底是什么决定了你会不会被引到

「怎么才能被 ChatGPT 引用？」这个问题通常会得到一份清单式的回答：写好内容、加结构化数据、做一个 llms.txt。这些建议与其说是错的，不如说打错了层。它描述的是一个页面应该长什么样，却跳过了真正决定结果的两个问题：检索系统到底够不够得着你的页面，以及页面上有没有哪一段话，被从上下文里揪出来之后还站得住。

这篇讲的是机制，按它实际运行的顺序讲。这些检查我们在自己站上跑，其中有两条帮我们发现了再多内容功夫也补不上的问题。

引用是检索问题，不是排名问题

ChatGPT 带链接回答时，并不是每个问题都去实时读一遍网络。一个检索步骤先从索引里捞出候选段落；模型再用捞回来的东西组织答案，并给它真正倚重的那部分标上出处。由此推出两条结论，对做惯了传统 SEO 的人来说都不太直觉：

• 单位是段落，不是页面。一个页面可以排得很好却毫无贡献——因为那个值得被引用的事实，藏在一张图里、一张没有文字等价物的图表里，或者一段要等 JavaScript 跑完才存在的文字里。
• 能被检索到和值得被引用，是两道不同的门槛。进索引只是前提。成为关于这个问题「现有最干净的那句话」，才是拿到出处标注的原因。大多数 GEO 清单只处理了第一道，然后困惑于流量为什么没动。

排名和引用在实践中是会分开的。你可以稳坐某个词的第三位却从没被引用过，因为你上面那两个页面恰好用一句自足的话把答案说清楚了，而你把答案埋在一个叫「我们的理念」的小节的第四段里。

三个爬虫，三份不同的工作

最贵的错误就发生在这里，因为人们把「OpenAI 的爬虫」当成一个东西来想。OpenAI 文档里写明的是三个独立的 agent，它们做的不是同一份工作：

• GPTBot——为模型训练做的大规模抓取。挡掉它，改变的是未来的模型从你站上吸收了什么。它不会把你从 ChatGPT 的实时引用里拿掉。
• OAI-SearchBot——构建检索所读的那个搜索索引。决定你到底能不能被引用的，是这一个。
• ChatGPT-User——当用户的问题触发实时浏览时，去抓取某个具体 URL。挡掉它，抓取就恰好失败在有人正在问起你的那一刻。

常见的翻车是这样的：一个团队决定不希望自己的内容被拿去训练模型，于是挡掉 GPTBot，并且认为自己做了个深思熟虑的决定。确实做了——关于训练的。关于检索，他们什么都没说。更糟的版本是：有人用一条通配规则挡掉所有 OpenAI 的 agent，悄无声息地把公司从 AI 答案里删了，然后花一个季度纳闷为什么被引用的都是竞争对手。

这些是可以分开的选择，那就分开做。我们自己的 robots.txt 三个都放行，只挡掉 /api/ 和分享链接——分享链接是用户内容，本来就不该进索引。你的选择可以不一样：训练和检索是两笔性质确实不同的交易。只是要按爬虫决定，而不是按厂商决定，并且隔一阵子重读一遍厂商文档，因为这些策略是会变的。

真正卡住你的那道门，不是 robots.txt

robots 是一个请求，也是所有人都会去检查的那一层。真正咬人的是你的 CDN 或 WAF。在不少默认配置下，边缘平台会对不认识的 user agent 做挑战或直接拦截，而结果是无声的：robots.txt 上写着 Allow，边缘返回 403，于是你实际上无法被抓取，而你仓库里的每一个文件都在坚称大门敞开。

这个检查花十秒钟，却几乎没人做：

curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "ChatGPT-User"  https://your-site/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot" https://your-site/

200 表示够得着。返回 403、503 或者一个挑战页，就意味着你有一个内容功夫永远补不上的可见性问题。要打到生产环境、从你自己网络之外打、并且每个域名都打一遍——每个域名通常有各自的边缘配置，而它们会随时间跑偏。

如果这篇文章你只做一件事，就做这件。它是单位时间回报最高的检查，而且对任何内容审计都是隐形的。

如果一个事实需要 JavaScript 才出现，它就不存在

检索爬虫通常只解析原始 HTML，不执行 JavaScript。所以判断一条主张能不能被引用，标准不是你浏览器里看到什么，而是这个：

curl -s https://your-site/page/ | grep -i "你希望被引用的那句话"

输出里没有，就等于没有东西可引。这有一个实打实的设计后果：对引用关键的文字——你的定义、关键事实、FAQ 答案、价格与安全主张——必须在服务端返回的 HTML 里。一个在 hydration 之后替换文案的运行时字典，作为增强很好；但它不能是这个事实唯一存在的地方。

这一点在多语言站上咬得最狠，也正是我们刻意绕开的坑。如果你的中文文案只活在一个 JavaScript 的 i18n 字典里，那么对一个读原始 HTML 的爬虫来说，你的中文内容压根不存在。我们的做法是把每种语言都内联成真实标记，再让 CSS 决定人类看到哪一种。爬虫拿到四种语言，读者拿到一种。代价是页面体积，值得。

把话写成能被整段揪走还站得住的样子

这部分才是真正在「写」，而不是在搭管道；管道通了之后，杠杆就在这里。

一个被检索出来的片段，抵达模型时是不带你页面的。没有标题层级、没有上一段、没有导航。就照这个前提去写：

• 先给答案。标题下的第一句话应该是答案，不是跑道。「X 是 Y」胜过「在当今快速演进的格局中……」——后者什么都没回答，也永远不会被引用。
• 主语要写出来。「它支持 OAuth」被摘出去之后没法用；「Orkas 支持 OAuth」能活下来。代词会死在切片里。
• 每条主张都要自足。实体、限定条件、边界，都在一句话里：「使用自己的供应商时，模型流量直接发往该供应商，不经 Orkas 代理。」这句话单独被引用也不会变成假话——这正是它可被引用的原因。
• 宁可可核实，不要显得漂亮。含混的最高级从不会被引用，因为它们没有回答任何人问过的问题。

问题本身就是检索的钥匙

用户是在提问，而检索匹配的是长得像问题的文本。一个直接就是那句问题的标题——「Orkas 会代理模型流量吗？」——比「模型架构」这种名词短语匹配得更好。FAQ 区块对 AI 可见性的收益之所以远超其体量，靠的是这个，而不是什么结构化数据的魔法：它们本身就是一问一答，而这正是被检索的那个东西的形状。

结构化数据让你可解析，不是让你被偏爱

JSON-LD 买不到引用。它买到的是无歧义的分类：这个页面是什么、谁发布的、哪段文字是问题、哪段是它的答案。有两条规则比其余的都重要：

• FAQ 结构化数据必须和可见文本逐字对应。结构化数据声称了页面没说的话，这是个信任问题；搜索引擎会把这种不一致当作垃圾信号，而不是排版失误。
• 永远不要伪造评分、奖项或数量。一个引擎抓到你编造了一个聚合评分，它就有了理由把你说的其他一切都打折。

1:1 这条规则属于会悄悄腐烂的那类——有人改了可见 FAQ、忘了改结构化数据，半年后两者开始互相矛盾。我们用一个测试来强制它：遍历 sitemap 里的每一个页面，从 JSON-LD 里取出 FAQ，断言每一条问题和答案都逐字出现在该页的可见文本里。一旦漂移，构建就挂。结构化数据是你对自己页面下的一个断言，就该按断言来检验。

llms.txt：便宜、有用，且被吹过头了

对这个文件要诚实。llms.txt 是一个提案性质的约定。没有哪个主流引擎承诺会读它，谁告诉你这是一条摄入通道，谁就是在猜。

它真正的用处更窄，但仍然值那一个小时：一个稳定的地方，把你的规范事实平铺直叙地讲清楚——产品是什么、模型与数据怎么处理、价格、真正重要的那些 URL。当爬虫或者真人研究者确实落到这个文件上时，他拿到的是没有话术的版本，而不用从营销页面里去拼。它同时是个不错的倒逼机制：如果你没法用四十行、不带形容词地把产品事实讲清楚，那你的页面也做不到——而这本来就是你早晚要面对的内容问题。

它不是什么：不是保证，也不能替代这些事实出现在页面本身上。

自相矛盾会让你被丢掉

答案引擎会交叉核对。如果你的价格页说一套、文档说另一套、首页 FAQ 说第三套，引擎不会替你裁决——它要么含糊其辞，要么去引用一个前后一致的人。

所以跨页面的事实一致性是真正工作量的大头，而且一点都不光鲜。当一个模型、价格或安全事实变了，它必须在同一次改动里到处都改——页面、文档、首页 FAQ、llms.txt——否则你就制造了一个比这次改动活得更久的矛盾。我们把这条当硬规则而不是习惯来执行，因为习惯是打不过 deadline 的。

外部佐证胜过自我声明

下面是最难接受的一点：关于你自己，你自己的站是现有最弱的信源。引擎会给佐证加权，而且这么做是对的。只出现在你自己域名上的主张，是营销话术；同一条主张出现在 GitHub 上、第三方对比里、论坛帖子里、别人写的文档里，就是事实。

所以一旦站内基本功真的做扎实了，站外的功夫就比再建一个落地页更划算——仓库、目录站、榜单、真实的讨论。说白了：站内功夫让你可被引用，站外功夫让你被引用。团队总是稳定地在前者上投入过度，因为那是他们能控制的那一半。

怎么衡量，而不自欺

GEO 类文章通常在这里开始发虚，所以直说：ChatGPT 的引用你没法干净地衡量。没有仪表盘。你手上只有三个不完美的信号：

• 服务器日志。去 grep OAI-SearchBot 和 ChatGPT-User。抓取频率、以及哪些 URL 被抓，会告诉你是否在索引里、以及什么正在被实时拉取。这是你拥有的最诚实的信号。
• 来自助手的引荐流量。真实，但只是一部分——大量引用被读到却从没被点击，而这恰恰就是答案引擎的意义所在。
• 人工抽查。把你想拿下的十个问题挨个问一遍，记录谁被引用了。笨、只能看方向，但仍然是唯一能观察到答案界面本身的办法。

这三个都只当方向看。任何人卖给你一个精确的「GEO 分数」，卖的都是他自己编出来的数字。

换我们会先做什么

按回报排序，不是按它在 PPT 里好不好看：

• 1. 用 curl -A 拿检索爬虫打生产环境。如果边缘在拦它们，这份清单上其他事都不重要。
• 2. 用 curl | grep 检查你的关键主张。把任何只靠 JavaScript 才出现的内容，挪进服务端返回的 HTML。
• 3. 把每个标题下的第一句话改写成答案，主语写出来。
• 4. 让 FAQ 文本和 FAQ 结构化数据完全一致；任何拿不出可见文本支撑的结构化数据，删掉。
• 5. 把页面、文档、llms.txt 之间互相打架的事实对齐。
• 6. 然后——也只有到这时——再去挣站外的佐证。

第 1 步和第 2 步通常就是那些消失的引用藏身的地方。它们也是没人写文章讲的两步，因为它们不是内容营销。

收尾

被 ChatGPT 引用，没有它周围那个缩写听起来那么神秘。让检索爬虫够得着你。不靠 JavaScript 也能读到你。用一句自足的话就能引用你。你自己的各个界面之间不打架。在你的营销站之外的某个地方，有人替你佐证。工具会换来换去；这五条不会。

这些检查我们在自己站上跑，也把它们做进了 Orkas 的一个工作流里——它会审计一个站点的搜索与 AI 答案可见性，并给回一份按优先级排好的修复清单。想看这底下那一层——主 agent 怎么规划工作、怎么派遣专才去干——去读多 Agent 编排实战。