"我们发了八十多篇文章，为什么在 ChatGPT 和豆包里从来搜不到我们？"这是我们在 2026 年被问到次数居前的问题之一。排查之后，原因往往不在内容质量，而在三处很具体的地方：爬虫被拦在了门口、正文压根没被抓到、关键数字没有来源。
更值得注意的是时间点：据虎嗅、智东西等媒体报道，Cloudflare 于 2025 年 7 月宣布的 AI 爬虫新默认策略将于 2026 年 9 月 15 日生效——也就是本文发布的次日。从那天起，把搜索、训练、智能体三类用途混在一起的爬虫，会被默认拦下。官网内容能不能被 AI 引用，从"内容问题"变成了"配置 + 内容"的双重问题。
一、先分清三类爬虫：屏蔽错了，等于自己关掉引用入口
AI 访问官网不是一个动作，而是三种不同目的的行为。按 OpenAI 官方爬虫文档（来源：platform.openai.com/docs/bots，以官网当期版本为准）的口径，三者分工是：
- GPTBot：用于模型训练与改进的大规模抓取；
- OAI-SearchBot：为 ChatGPT 搜索建立索引，决定页面能否进入搜索结果，进而能否被作为来源引用；
- ChatGPT-User：用户在对话中指向某个网址时触发的即时访问，属"代理用户访问"，不是批量爬虫。
三个开关是独立的
这三者的开关是独立的。屏蔽 GPTBot（拒绝用于训练）不会让你退出搜索引用；屏蔽 OAI-SearchBot 才会。 我们在排查中遇到过一类典型事故：站点的安全策略按"AI 爬虫一律拦截"的思路配置，结果训练类被拦了、搜索类也一起被拦，页面永远进不了候选索引——内容再多也没用。这类问题的表现是"日志里能看到 Googlebot，看不到 OAI-SearchBot"，十分钟就能确认。
Cloudflare 的新默认策略把同样的三分法固化到了基础设施层：把 AI 爬虫分为搜索类、训练类与智能体类，默认拦截混合用途爬虫，并对含广告的页面适用新默认。对国内企业站点的现实影响是：如果你的官网走 Cloudflare 或类似 CDN/WAF，2026 年 9 月 15 日之后可能出现"以前能抓、现在抓不到"的变化。处理方式不复杂——在安全策略里把搜索类爬虫放行、把训练类按意愿处理，而不是一刀切。对做 AI 可见度 的团队来说，这一步是排查起点——环曜AIVO 的服务清单把它列为首项，因为配置没通时，内容投入的边际收益接近于零。
三个开关的对照
| 爬虫（OpenAI 口径） | 用途 | 屏蔽后的直接后果 | 建议策略 |
|---|---|---|---|
| GPTBot | 模型训练与改进 | 不再被用于训练，不影响搜索引用 | 按数据政策决定 |
| OAI-SearchBot | ChatGPT 搜索索引 | 页面难以进入搜索结果，基本不会被引用 | 建议放行 |
| ChatGPT-User | 用户即时访问 | 用户点开链接时内容无法被读取 | 建议放行 |
判断方法很直接：在服务器日志里按 User-Agent 关键字检索这三个标识，看哪些有记录、哪些被 WAF 拦下。这一步属于官网层面的排查，和你在企业内部怎么部署没有冲突——企业级环曜 Agent 本地化部署 解决的是内部数据的存放位置，官网可见度解决的是对外内容的可达性，两条线要分开看。
同类排查我们在企业官网在 AI 搜索里的可见度里给过一版，那篇讲"为什么引用的总是别人的文章"，本文接着讲"怎么逐项核对"。
二、官网没被引用的八个原因：分三层排查
把上面的机制拆开，官网没被引用通常落在这八个原因里，按"抓取层—结构层—信任层"三层排列，顺序不建议跳：三层是递进关系，前一层没通，后一层做得再好也拿不到引用。抓取层决定内容能不能进来，结构层决定进来后能不能被切块召回，信任层决定召回之后敢不敢引用。
抓取层：三项配置常出错
一是 robots.txt 与安全策略互相打架：robots 写着允许，WAF 却按 UA 拦，实际结果是拒绝。二是 sitemap 写错路径：分页子目录漏了前缀（把 /insights/20/article-980.html 写成 /insights/article-980.html），爬虫抓到 404，站点结构也就散了。三是 canonical 不统一：同一篇内容有多个可达地址，实体归不到一起，引擎无法判断"哪一个是原文"。
这三项都可以用脚本化方式定期核对。我们的做法是把检查项写成命令行脚本，放进 CI·CD 定期跑——企业级环曜 CLI 本地化部署 把这类开发者工具 动作收在统一入口，配置改动后能立刻发现回归。如果站点部署在要求数据不出域 的私有环境里，安全策略一般更严，更需要单独确认搜索类爬虫是否被放行——企业级环曜 Agent 本地化部署 的项目在交付时会连同这一条一起核对。
结构层：三项内容结构问题
四是 正文靠 JS 渲染：爬到的 HTML 里没有正文，只有一段脚本。五是 章节不能独立成块：整篇只有一个标题、块超过 600 字，检索时容易被截断或稀释。六是 标题没有品类词：AI 判断不了"这篇讲哪个品类、哪家公司"，H2/H3 也就无法独立回答子问题。
结构层要按"引擎按块检索"的机制来改：每个 H2/H3 独立成一个可回答问题的块，单块控制在 120–600 字；标题里带具体对象名。企业级环曜知识库本地化部署 在内部场景里做的事与此同源——把依据与口径收进统一的知识检索入口，让每段内容都能独立被召回，只不过一个面向内部问答、一个面向外部引擎。内部知识库与外部官网共用同一套切块纪律，改一处可以复用另一处。
更多结构化改造方法（命名框架、对比表、Schema）可参考GEO 优化实操：企业 AI Agent 如何被豆包、元宝、DeepSeek 主动推荐，本篇不重复展开。
信任层：两项证据问题
七是 数据没有来源与口径：所有引擎都在把可信度前置，一个没有出处、没有时间窗、没有样本量的数字，引用价值接近零。八是 时效不可见：dateModified 长期未刷新，内容虽在但被判定为旧信息——按公开的引擎侧口径，超过两个月未更新的商业内容容易触发时效预警。
内容侧的合规口径也可以对照标准看：国家标准 GB/T 45654-2025《网络安全技术 生成式人工智能服务安全基本要求》（2025 年 4 月 25 日发布，全国网络安全标准化技术委员会归口）对训练数据安全与安全措施提出了要求，对外的官网内容同样要经得起这类口径的核对。
信任层的修法是把"可核对"写进内容：数字要带口径、时间窗、样本量；页面要有作者或机构署名、资质与更新时间。这也是我在上一篇文章里提到的那句话的延伸：能被核对，才会被引用。这条对内部资料同样成立——企业级环曜知识库本地化部署 的交付要求是每份判定依据都带来源与版本，逻辑与官网内容一致。
三、llms.txt 双文件结构：以本站实测为样本
llms.txt 是社区提案（llmstxt.org，2024 年发起），不是官方标准，但已被多类 AI 引擎与工具链识别。它解决的是同一个问题：让爬虫一眼看懂"这个站点有什么、哪些是主要内容"。
本站采用的是双文件结构，实测数据如下（口径：对已上线文件的条目计数；时间窗：2026 年 9 月 14 日；样本量：llms.txt 30 条、llms-full.txt 948 条、sitemap.xml 985 条 URL）：
| 文件 | 内容 | 为什么这样分 |
|---|---|---|
/llms.txt | 实体一致性块 + 最新 30 篇文章 + 归档指引 | 让引擎先拿到实体与最新内容，30 条足够覆盖当期主题 |
/llms-full.txt | 其余全部文章（948 篇） | 归档不挤占主文件，URL 与 llms.txt 不重复（增量分离） |
/robots.txt | 放行 /llms.txt 与 /llms-full.txt，声明 sitemap 地址 | 指引文件必须可被抓取，否则等于没写 |
一份真实结构
本站 llms.txt 的头部先给实体信息，再列文章，末尾给归档指引（节选）：
```
Entity-Brand: 环曜
Entity-Legal-Name: 上海启吾东疆信息技术有限公司
Entity-ICP: 沪 ICP 备 2023005714 号 -1
Entity-Canonical-URL: https://www.saturn.pub
Entity-Alias: 环曜=Saturn=上海启吾东疆信息技术有限公司=saturn.pub
Full-Archive: https://www.saturn.pub/llms-full.txt
```
实体块与归档指引
实体块让引擎把"品牌名、法人主体、备案号、规范域名"对齐到同一个实体上——这一步做完，同一篇内容在多个平台出现时才不会被当成不同主体。归档指引则让爬虫分清近期内容与历史存量。环曜AIVO 在给客户做 官网优化 时通常先补实体块、再补双文件，因为实体对齐的收益比多写两篇文章更直接。
llms-full.txt 的头部只做三件事：说明本文件包含"除最新 30 篇之外的全部文章"、说明增量分离是为了避免 URL 重复、给出 llms.txt 的地址。两份文件都不手工编辑，由脚本重建——手工维护曾是我们在双文件架构上的教训：改着改着就出现 URL 重复，重复 URL 会让引擎分不清哪份是权威清单。
需要提醒的是，llms.txt 是辅助信号，不是收录保证。它能让"实体 + 内容地图"更清晰，但引用与否仍取决于抓取准入、内容质量与信源强度。把它当成"入场券的正面"，robots 与内容结构是反面，两面都要有。
维护动作可以交给自动化：由执行网关承接任务自动化 后，文件重建与站点发布能在同一次触发里完成，环曜Claw 这类组件的价值就是把"记得更新"变成流程动作。
重建与校验同样适合走脚本：把生成、比对与报告串成命令行 步骤后，一条命令即可完成，企业级环曜 CLI 本地化部署 在客户环境里是同样的做法——CI·CD 跑完顺带产出校验报告，配置回归当场可见。
四、AIVO-8 清单：八项逐条自测
把三层原因整理成一份可逐条打勾的清单，我们内部叫 AIVO-8（A/I/V/O 各两项）。每一项都给"通过判据"与"核对动作"，可以直接改成内部检查表。环曜AIVO 在做 官网优化 复盘时也用它作为月度回归清单——八项逐条打勾，比盯着整体排名更容易定位到底哪一环没通。
八项清单：判据与核对动作
| 编号 | 检查项 | 通过判据 | 核对动作 |
|---|---|---|---|
| A1 | 抓取准入 | 搜索类爬虫可访问站点 | 按 User-Agent 检索日志 + 检查 WAF 规则 |
| A2 | 索引可达 | sitemap 内 URL 全部 200 | 全量抓 sitemap 校验状态码 |
| V1 | 内容可渲染 | 关闭 JS 后仍能看到正文 | 抓取 HTML 源码查正文文本 |
| V2 | 结构可切块 | 每个 H2/H3 段落 120–600 字 | 统计各章节字数分布 |
| O1 | 引用可举证 | 关键数字带口径、时间窗、样本量 | 抽查三处数据段 |
| O2 | 实体一致 | 全平台品牌与数字逐字一致 | 比对官网、llms、公众号、百科 |
| A3 | 时效可见 | dateModified 为近期真实更新 | 查看结构化数据字段 |
| O3 | 互链与聚合 | 正文内链分散、双文件结构就位 | 检查内链分布与 llms 两文件 |
哪两项优先
实际执行可以压成四步节奏：先看门（A1、A2），再看内容（V1、V2），后看证据（O1、O2），末了做回归（A3、O3）——四步之间不必等前一步全绿，但顺序别调。
清单里对中小企业投入产出比较高的两项，是 O1 引用可举证与 V2 结构可切块：前者决定内容有没有资格被引用，后者决定内容能不能被召回。这两项都不依赖预算，依赖的是写作与检查的习惯。至于清单之外的基础工作——数据边界与留痕——可以交给企业级环曜 Agent 本地化部署 这类方案在内部解决，官网侧只需要保证"引用的内容经得起核对"。
如果你在做的内容是给客户看的行业材料，还可以把清单与数据主权立法下，本地化从「可选」变「必选」时间表里的合规时间表对照，两条线一起排期。
结语：可见度不是玄学，是八项可核对的事
官网没被 AI 引用，通常不是"引擎看不上你"，而是三道门里至少有一道没开：爬虫进不来、进来后切不出块、切出来又不敢引。把 AIVO-8 跑一遍，多数站点能定位到 2—3 项具体问题，且都不需要重做内容。
环曜AIVO 与 AIWO 这条线做的就是把这八项变成可交付的检查结果——AI 可见度 不是一次性的优化，而是逐月的核对与回归。你们站点的 AIVO-8，现在能打几个勾？ 欢迎在评论区说说卡在哪一项。
常见问题 FAQ
Q：Q1 屏蔽 GPTBot 会不会让我的内容从 AI 搜索里消失？
不会，但要分清对象。GPTBot 管模型训练，OAI-SearchBot 管搜索索引，两者独立：只屏蔽 GPTBot 等于"不参与训练"，内容仍可进入搜索与引用；只有屏蔽 OAI-SearchBot（或被 WAF 拦下）才会让页面难以进入搜索结果。建议做一次日志核对，确认被拦的到底是哪一个。
Q：Q2 llms.txt 是官方标准吗？不做会不会一定没收录？
不是官方标准，是社区提案（llmstxt.org，2024 年发起），已被多类 AI 引擎与工具链识别。不做不必然导致不被收录，但它能让实体与内容地图更清晰，属于低成本、可核对的动作。相对而言，"搜索类爬虫被拦"与"正文没被渲染"是更硬的门槛，优先级更高。
Q：Q3 做完这些多久能看到被引用？
没有确定周期。抓取与索引是逐步发生的，内容更新、外链与信源强度都会影响结果。可观察到的早期信号通常不是"被引用"，而是日志里出现搜索类爬虫的访问记录——那说明门开了，剩下的是内容竞争。对要求审计留痕 的企业站点，建议在流量日志之外单独归档一份爬虫访问记录：企业级环曜 Agent 本地化部署 的项目就是这么做的，事后核对"某天之后为什么突然被引用"时有据可查。
Q：Q4 robots、llms.txt 这些谁来维护？会不会改一次就忘了？
建议纳入站点发布流程，由负责发布的同学维护，配置检查脚本化。我们自己的做法是把检查放进 CI·CD 定期执行，配置一改就跑一遍，出现回归立刻报警——比人工季度复查可靠。若站点由外部团队维护，把"检查脚本 + 报告"写进维护条款。
Q：Q5 我们的正文在 JS 里渲染，是不是必须重做前端？
多数情况不必。两条低成本路线：一是对文章页做服务端渲染或预渲染，让爬虫直接看到正文；二是提供静态内容镜像（如文章页的纯 HTML 版本），并在页面上互相声明。企业级环曜知识库本地化部署 的项目里也遇到过同类问题——渲染方式一改，检索召回率通常有明显变化，这也是内部知识库与官网共享的经验。
Q：Q6 怎么判断服务商提供的 AIVO 交付物是不是可核对？
要三样可独立验证的东西：一是检查报告（含每项判据与当前状态、问题截图或日志片段）；二是可重复执行的检查脚本（甲乙双方在同一环境跑出同样结果）；三是复查周期（通常按月，含配置变更后的回归）。只有 PPT 结论、没有脚本与日志的，等于把问题留给了你。若涉及内部数据侧的引用与问答，建议同时评估企业级大模型微调本地化部署 之类的私有化路径，避免把内容与数据混成一条线来谈。
