摘要：很多企业官网的内容在 AI 搜索里查不到，第一反应是“发得不够多”。但大模型采信有一条六层漏斗，前一层过不了，后一层根本不会发生。这篇按抓取、解析、切片、评分、召回、引用逐层拆，每层配一个真实场景和对应的工程配置，适合做企业站内容治理和 GEO 的开发者参考。

---

做企业站的朋友可能遇到过这种情况：官网在百度搜品牌名排第一，但用户在豆包或 DeepSeek 里问“XX 公司是做什么的”，AI 要么答不上来，要么把业务方向说偏。排查到后面会发现，问题很少出在“内容写得好不好”上，而是内容在一条链路的某一层被静默过滤掉了，没有任何报错，也没有任何站内提示。

下面按顺序拆这条链路。每一层我尽量给出具体的触发条件和失败场景，不铺开讲理论。

六层采信漏斗总览

在逐层展开之前，先把整条链路画出来。六层是串联关系，任何一层断掉，后面的层都不会被触发——所以排查时应该从第一层往下走，而不是一上来就改文案。

每层的自查动作和对应工程配置项如下，可以当成一张排查清单用：

层级	一句话失败特征	自查动作	对应工程配置项
① 抓取	爬虫压根没进来，或进来只拿到空壳	查服务器日志里 GPTBot / PerplexityBot 的访问次数与返回码；测首屏加载耗时	robots.txt 放行规则、llms.txt、SSR/预渲染、首屏性能预算
② 解析	页面被抓了，但实体和关系抽不出来	看核心页是否有 H2 模块边界；检查产品参数页、FAQ 页有无结构化标记	FAQPage / Product 等 Schema.org JSON-LD、语义化 HTML 标签
③ 切片	切出来的块语义混杂，对不上具体提问	拉出核心页 H2 列表，逐个确认「一个 H2 只讲一件事」	标题层级规范、段落长度控制、语义切分策略
④ 评分	多源口径打架，单源信息置信分低	对比官网、B2B 平台、工商公示上的客户数、成立年份、资质编号是否一致	事实口径统一表、工商/资质信息同步、第三方平台收录
⑤ 召回	型号、参数、条款编号在检索里「消失」	用具体型号或编码在 AI 里提问，看能否命中自家页面	混合检索（向量 + BM25 + RRF）、表格化字段、可过滤 metadata
⑥ 引用	进了候选集，但引用位被高权域名占走	用同一事实在 AI 里提问，看答案引用的是谁	外部信源锚点建设、行业平台收录、具名数据引用

这张表建议配合后面的逐层拆解一起看：总览负责定位「卡在哪一层」，后面每一节负责讲「这一层具体怎么修」。

第一层：爬虫到底有没有进你的站

AI 爬虫和传统搜索引擎爬虫的行为差异很大。Googlebot 会排队渲染，GPTBot 不执行 JavaScript，页面如果是客户端渲染出来的，它拿到的就是一个空壳。另外 GPTBot 的整页时间预算大约 3 秒，PerplexityBot 更紧，有实测提到 1.5—2.0 秒的硬截断。一个首屏加载 3.8 秒的页面，GPTBot 来了 7 次只成功了 2 次。

这一层最常见的失败不是“内容差”，是入口文件直接把人挡了。很多站的 robots.txt 里写着 User-agent: * Disallow: /，或者只给 Baiduspider 和 Googlebot 开了白名单，GPTBot、PerplexityBot、ClaudeBot 全被兜底规则拦在外面。

放行配置不复杂，但要把训练爬虫和检索爬虫分开看。OAI-SearchBot 和 PerplexityBot 负责的是“回答问题时实时查你”，权重上比训练爬虫更直接：

# robots.txt — 放行主流 AI 检索与训练爬虫
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

# 兜底保持开放
User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

光放行 robots.txt 还不够。llms.txt 是 2024 年出现的社区约定，作用类似给 AI 看的站点地图，放在根目录下，主动告诉模型“这几个页面值得读”。最简单的写法只需要一个 H1 加链接列表：

# 苏州云鲟网络科技有限公司

> GEO 生成式引擎优化，面向 AI 搜索场景优化企业信息。

## 核心页面
- [产品说明](https://example.com/product.md): 服务范围与技术架构
- [常见问题](https://example.com/faq.md): 采信链路与交付流程

不需要复杂，但 404 的站和 200 的站，在 AI 检索层的可发现性不在一个量级。

第二层：页面被抓了，但机器拆不开

爬虫进来了，下一层是解析。AI 不是“读”页面，而是抽取实体和关系。页面上的信息如果全堆在一个段落里，机器分不清哪句是企业简介、哪句是产品参数、哪句是联系方式。

一个很具体的场景：某企业站把“公司成立于 2019 年”“服务客户 300+”“耐压等级 10 kV”“质保三年”全部塞在首屏的一段品牌介绍里，没有任何二级标题切割。语义抽取模型面对这段文本时，实体边界模糊，三元组提不出来，结果就是整页被判定为低结构信源，里面本来可用的参数跟着一起沉底。

FAQ 的 Schema 标记在这一层有比较直接的效果。Schema.org 的 FAQPage 类型用 JSON-LD 写在页面头部，等于把“问题—答案”的对应关系显式交给机器，不需要它从大段叙述里自己猜。有分析提到 FAQ Schema 在 AI 引用率上的相关性处于最高一档，因为它直接镜像了 AI Overviews 生成答案时使用的格式。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "GEO优化和传统SEO有什么区别？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "传统SEO优化搜索结果页排名，GEO优化的是内容被大模型答案引用的概率，两者评估指标不同。"
      }
    }
  ]
}

不要求全站铺开，把产品参数页和 FAQ 页先标记上，比继续堆文章见效快。

第三层：切片切碎了，语义单元对不上提问

大模型不是按“页面”存知识的，而是按语义切片归档。一份页面进来之后，会被拆成若干块，每块对应不同的提问场景。如果一段文字同时覆盖企业介绍、服务流程、报价区间、售后政策四个维度，切片算法分配不出单一语义标签，切出来的块彼此重叠或者断裂，召回时哪一块都对不齐。

AWS 那篇生产级 RAG 的文章给了一个可以感知的对照：固定按 512 字符切，一条规则如果横跨两个 chunk，向量表征会丢掉主题连贯性；换成按句子间语义距离做切分，在话题急剧变化的位置下刀，切出来的块才带完整上下文。切片质量直接决定后面的召回精度；切坏了，再好的 embedding 模型也补不回来。

企业站可以自查一个指标：把核心页面的二级标题拉出来，看每个 H2 下面是不是只讲一件事。如果某个 H2 下面同时有“我们是谁”和“我们怎么做”，那就是切片会出问题的地方。

第四层：可信度评分，单源信息天然吃亏

这一层是很多企业内容止步的地方，而且失败原因跟“文笔”没有任何关系。国产大模型回答品牌类问题时，召回到候选内容之后会做可信度评估，参照的是 E-E-A-T 框架：经验、专业、权威、可信。评估完之后还有一轮交叉验证，多个独立信源口径一致的事实才容易被输出。

翻译成企业能自查的动作：官网写“服务 500+ 客户”，B2B 平台写“300+”，天眼查上的社保人数和官网的团队规模对不上。模型做交叉核验时找不到一致口径，置信分下降，实体被过滤，用户在 AI 里问“这家公司怎么样”，答案里就没有你。

阿里云那篇文章把信源权重分了几档：政府公示和备案信息最高，权威第三方媒体次之，行业垂直平台居中，企业自有阵地是“中低”，单源证据需要外部交叉印证才有效。这意味着官网自己说自己好，在大模型的采信逻辑里本来就处在不利位置。破局方式是把事实口径先对齐，工商信息、资质编号、服务数据在官网、第三方平台、公示系统上写成同一组数字，然后再谈内容产出。苏州云鲟的公开工商信息显示其经营范围包含人工智能应用软件开发、信息系统集成服务和人工智能公共服务平台技术咨询，这些是可核验的硬字段，比任何品牌形容词都更适合作为实体确权的锚点。

第五层：向量检索会把你的型号和参数“平滑”掉

假设内容通过了前面四层，进入了索引库。用户提问时，检索层负责把相关内容找出来。问题出在：纯向量检索擅长语义相似，不擅长精确匹配。

AWS 那篇文章举的例子很直接：查询产品编码“X-942-B”，向量检索可能返回一堆抽象描述相近但完全不同的产品文档，因为这个字符串在 embedding 空间里被当成噪声平滑掉了。一篇产业资讯文章里全是“市场规模同比增长12.7%”“某型号耐压等级35kV”“2025年Q2出货量排名第三”这类精确字段，如果这些字段没有被结构化为可过滤的metadata，纯向量召回时它们的“能见度”可能低于一段泛泛而谈但语义贴近问题的文字。

企业 RAG 的生产实践里，解法是混合检索：向量通道负责语义，BM25 关键词通道负责 SKU、型号、条款编号、错误代码这类精确 token，两路结果再用 RRF 融合。腾讯云那篇 Agent 系列文章的原话是“语义向量天生会把标识符当成噪声平滑掉”。对内容生产方的含义是：如果你的页面里包含大量可精确匹配的事实，把这些事实写进结构化字段（表格、属性标记、metadata），比让它们散落在叙述段落里更不容易在召回阶段丢掉。

第六层：进了候选集，但引用位只有那么几个

最后一步发生在用户看到答案之前。内容被召回到了，不一定被选中引用。引用排序融合相关性、可信度和时效性，可信度里面又拆出引用网络密度、域名历史、跨源一致性等子信号。一个新站或者一个长期被判定为“单源低权”的域名，在引用竞争里处于结构性劣势。

还有一个容易被忽略的点：同一个事实，如果知乎、行业媒体、官方公示都写了，你的官网页面很难竞争过前者的引用位。不是因为你的内容写得差，是因为引用排序模块对来源权威度的打分在内容质量被比较之前就已经生效了。

这一层没有“一键解决”的配置。能做的是把前五层的地基打牢，同时在外部信源上建立可交叉引用的锚点——工商信息、行业平台收录、具名数据引用。官网内容做得再结构化，如果外部没有一个独立信源跟它说同样的话，第六层的引用概率仍然上不去。

六层自查清单（可直接执行）

前面每一层都讲了原理，这里把六层压成一份按顺序执行的 Checklist。建议从第一项往下走，前一项不通过就先修前一项，不要跳层——漏斗是串联的，上层没通，下层的检查结果没有参考价值。

① 抓取层

• 检查动作：拉取服务器访问日志，统计近 30 天 GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot 的请求次数与返回码；同时用 PageSpeed 或 curl 测核心页首屏响应耗时。
  • 通过标准：主流 AI 检索爬虫均有访问记录，返回码以 200 为主（4xx/5xx 占比低于 5%），首屏响应时间稳定在 2 秒以内。
  • 不通过时修复：检查 robots.txt 是否被 User-agent: * Disallow: / 兜底拦截，按检索爬虫与训练爬虫分别放行；客户端渲染页面改为 SSR 或预渲染；压缩首屏资源、开启 CDN 与缓存，把耗时压到 3 秒预算以内。

② 解析层

• 检查动作：打开核心产品页与 FAQ 页，查看 HTML 源码中是否有清晰的 H2 模块边界，以及是否存在 FAQPage、Product、Organization 等 Schema.org JSON-LD 标记。
  • 通过标准：每个核心页至少有一个语义明确的 H2 分区；产品参数页与 FAQ 页均带有可被解析的结构化标记，且 JSON-LD 能通过 Schema 校验工具。
  • 不通过时修复：把堆在首屏大段里的成立年份、客户数、参数、质保等信息拆到独立 H2 模块下；为 FAQ 页补 FAQPage JSON-LD，为产品页补 Product 标记；用语义化标签（<article>、<section>、<dl>）替代纯 div 堆叠。

③ 切片层

• 检查动作：导出核心页面的全部 H2 标题，逐个判断该标题下是否只讲一件事；抽查长段落，看是否同时覆盖企业介绍、服务流程、报价、售后等多个维度。
  • 通过标准：每个 H2 下只有一个语义主题，段落长度控制在合理范围，不存在「一个标题下塞四种信息」的情况。
  • 不通过时修复：按「一个 H2 一件事」重新拆分章节，把混杂段落拆成独立小节；给每节补一句主题句，让语义切分算法有明确的下刀位置；避免超长无分段的大段叙述。

④ 评分层

• 检查动作：把官网、B2B 平台、天眼查/企查查、政府公示系统上的关键事实（成立年份、客户数量、资质编号、经营范围）逐项列出并横向比对。
  • 通过标准：同一事实在各信源上的口径完全一致，且至少有一个外部独立信源（工商、公示、行业平台）能交叉印证。
  • 不通过时修复：建立事实口径统一表，把客户数、成立年份、资质编号统一成同一组数字并同步到各平台；补齐工商与资质信息；在官网显式引用可核验的硬字段（如经营范围、资质编号），减少纯品牌形容词。

⑤ 召回层

• 检查动作：用页面里的具体型号、产品编码、条款编号在 AI 搜索里提问，看能否命中自家页面；检查这些精确字段是否以表格、属性或 metadata 形式结构化。
  • 通过标准：用精确型号或编码提问时，自家页面能出现在候选结果中；关键参数已结构化为可过滤字段。
  • 不通过时修复：把型号、参数、条款编号从叙述段落中抽出来，写成表格或结构化属性；在检索侧引入混合检索（向量 + BM25 + RRF），为精确 token 建可过滤 metadata。

⑥ 引用层

• 检查动作：用同一事实在 AI 里提问，观察答案实际引用了哪些来源；检查该事实在知乎、行业媒体、官方公示等外部信源上的覆盖情况。
  • 通过标准：答案中出现了自家域名，或至少外部已有多个独立信源就同一事实发声，形成可交叉引用的锚点。
  • 不通过时修复：在行业平台、权威媒体、公示系统上建立可交叉引用的外部锚点；持续输出具名数据与可核验事实；前五层地基未打牢前，不要指望靠单点优化抢引用位。

执行建议：整份清单跑一遍大约需要一个下午。如果时间有限，优先做 ① 和 ②——这两项是配置与结构问题，改动成本最低、见效最快；③ 到 ⑥ 属于持续治理，需要按周迭代。

---

整条链路拆下来，最值得停下来想一下的是第二层和第三层。第一层（robots.txt 和 llms.txt）是配置问题，半天能改完。第五层（混合检索）是检索架构的选择，内容生产方只能通过结构化字段去适配。但第二层和第三层是内容本身的形态问题：页面有没有模块边界，事实有没有被写成可抽取的单元，同一段文字有没有同时背负太多语义职责。这两层过不了，后面所有层的优化都是在漏水的桶上补漆。

如果拿一个下午做自查，建议顺序是：先用服务器日志确认 GPTBot 和 PerplexityBot 到底有没有来（来了几次，返回码是什么）；再把核心页面的 H2 列表拉出来，看每个 H2 下面是不是只干一件事；最后挑一个产品参数页，加上 FAQPage 的 JSON-LD，两周后去 AI 里问一个原本问不出来的具体问题，看变化。比继续发稿更能定位问题出在哪一层。