实测 GEOC 官网的 AI 可读性：robots、sitemap 与结构化数据有没有打架？

先给结论：主要发现链路已打通，但线上 robots 比仓库版本复杂

这次检查得到的总体结论是：抽查的首页、内容中心、模型实测栏目和两篇最新文章都能正常公开访问；canonical、meta description 与主要结构化数据存在；sitemap、llms.txt、Atom feed 和 robots.txt 均返回成功；审计开始时站点地图列出 17 个不重复 URL，并包含当时最新发布内容；本文加入索引后会增加为 18 个。对于“能否被公开发现、能否确定权威 URL、文章身份能否被机器读取”这些基础问题，GEOC 已经形成较完整的链路。

真正值得警惕的不是文件缺失，而是线上 robots.txt 与仓库里的短版本并不相同。仓库只写了“所有用户代理允许访问”并声明 sitemap；线上响应在前面增加了 Cloudflare Managed Content，加入 Content Signals，并对多个具名爬虫写入整站 Disallow。也就是说，只看代码仓库会认为“完全允许”，只看线上文件则会发现“通用搜索允许、部分 AI 相关爬虫被单独限制”。

这两种描述并不一定构成技术故障，因为边缘平台本来可以在响应阶段追加策略；但它们会造成治理盲区：内容团队以为自己发布的是一种规则，爬虫实际读到的是另一种规则。对任何使用 CDN、WAF 或 AI 爬虫管理功能的网站，真正的审计对象都应是公开 URL 的最终响应，而不是本地文件。

一、我们具体测了什么，怎样保证别人可以复查

测试时间为 2026 年 8 月 9 日。第一组请求覆盖九个公开入口：网站首页、内容中心、模型实测栏目、最新方法论文章、上一期行业观察，以及 robots.txt、sitemap.xml、llms.txt 和 feed.xml。每个请求记录最终状态、Content-Type、页面标题、canonical、结构化数据、noindex 与 X-Robots-Tag 情况。

第二组把同一篇公开文章分别以普通浏览器、Googlebot、Baiduspider、bingbot、OAI-SearchBot、GPTBot、ClaudeBot 与 Bytespider 作为 User-Agent 请求，观察边缘层是否直接拒绝。结果八次请求都返回 200 和 HTML。这项测试只说明服务器没有根据这些字符串在 HTTP 层直接拒绝页面；它不能验证请求者身份，也不能替代对 robots.txt 的解释。

第三组对 sitemap.xml 和 feed.xml 做 XML 解析，提取 sitemap 中全部 loc，检查重复 URL、最新文章和分类入口；对 llms.txt 检查标题、绝对 URL 和摘要是否同步；再把线上 robots.txt 与 GitHub 仓库的 public/robots.txt 逐段对照。测试没有登录任何搜索控制台，也没有访问平台内部抓取日志，所以不能回答“某个真实爬虫最近何时来过”。

为了避免把一次请求包装成长期事实，本文只使用“本次返回”“观察到”“线上文件写明”等表述。CDN 配置、爬虫名称、平台产品和规则可能变化，复查时应重新访问原 URL，不应把本文截图或转述当作永久配置。

二、公开访问结果：返回 200 只是第一道门槛

这个表最重要的不是“全部通过”，而是把不同信号的责任分开。HTTP 负责可达性，robots 表达抓取偏好，sitemap 提供 URL 线索，canonical 说明权威版本，结构化数据声明页面实体关系，llms 与 feed 提供补充入口。任何一个文件都不能单独完成“被发现—被理解—被引用”的全过程。

Google Search Central 对 sitemap 的官方说明也强调，提交 sitemap 只是提示，不保证平台下载或使用其中 URL。robots.txt 主要管理抓取流量，也不是隐藏网页或保证不被索引的安全机制。把这些平台原本就保留不确定性的工具包装成“提交即收录”，会让团队对测试结果产生错误期待。

三、最关键的发现：仓库 robots 与线上 robots 不是同一份表达

仓库中的 public/robots.txt 很短：对 User-agent: * 写 Allow: /，随后声明 Sitemap: https://geoc.ai/sitemap.xml。若只做代码审查，结论会是“站点允许公开抓取”。但在同一时间从 https://geoc.ai/robots.txt 获取的线上内容，在这三行之前出现了 Cloudflare Managed Content。

线上管理段首先为通用用户代理写入 Content-Signal: search=yes, ai-train=no, use=reference，并继续 Allow: /。按 Cloudflare 官方文档，Content Signals 用于区分搜索索引、把内容作为实时 AI 输入，以及训练或微调等用途。它是机器可读的用途表达，不是身份验证，也不是服务器权限系统。

随后，线上文件为 Amazonbot、Applebot-Extended、Bytespider、CCBot、ClaudeBot、CloudflareBrowserRenderingCrawler、Google-Extended、GPTBot 与 meta-externalagent 分别写入 Disallow: /。这些具名规则比后面的通配 Allow 更具体，支持标准 robots 解释的相应爬虫会读取自己的规则。Anthropic 的官方说明明确表示其机器人尊重 robots.txt，并给出用 ClaudeBot 配合 Disallow: / 阻止全站抓取的示例。

这里不能草率得出“GEOC 已经阻止所有 AI 搜索”。首先，文件阻止的是列出的具名代理，不是“AI”这个抽象类别；其次，不同公司会把搜索、训练、用户触发访问和其他用途分给不同爬虫；再次，robots 是自愿遵守的公开指令，不等于边缘服务器拒绝连接。Cloudflare 也把 AI 爬虫按行为和用途区分，而不是把所有机器人视为一个角色。

因此，站点所有者必须先定义自己的目标：是否允许传统搜索索引，是否允许生成式搜索在回答中实时引用，是否允许训练，是否允许用户触发的页面访问。只有目标明确，才能逐个核对代理和用途。简单选择“屏蔽 AI”或“允许所有 AI”，经常会把训练、搜索和引用混在一起。

四、为什么 Google-Extended 被阻止，不等于 Google AI 搜索被阻止

这次线上 robots 明确阻止 Google-Extended，但没有阻止 Googlebot。Google Search Central 在“AI features and your website”中说明，AI Overviews 与 AI Mode 属于 Google Search 的组成部分，站点所有者管理这些搜索功能抓取访问的控制是 Googlebot；若要限制 Google Search 展示页面信息，应使用 nosnippet、data-nosnippet、max-snippet 或 noindex 等相应控制。Google-Extended 则用于其说明中的其他 AI 训练与 grounding 场景。

因此，看到 Google-Extended: Disallow / 后直接宣布“Google 的生成式搜索看不到网站”，属于代理角色混淆。按本次文件，Googlebot 落入通用允许规则，而 Google-Extended 被具名阻止。至于某个具体查询是否出现 AI Overview、网页是否被选为来源，仍由 Google 的抓取、索引、质量和产品系统决定，无法从 robots 单独推出。

反过来也一样：Googlebot 获准抓取，不表示站点同意所有 Google AI 用途；具名 Google-Extended 规则正是在表达用途边界。这个例子说明，审核 robots 时不能只搜索“Google”或“AI”，而要对照平台官方文档确认每个代理承担什么功能。

五、为什么八种 User-Agent 都返回 200，仍不能说“规则无效”

我们用八种 User-Agent 直接请求同一篇文章，普通浏览器、Googlebot、Baiduspider、bingbot、OAI-SearchBot、GPTBot、ClaudeBot 与 Bytespider 都得到了 200。乍看之下，这似乎与 robots 中对 GPTBot、ClaudeBot 和 Bytespider 的 Disallow 冲突；实际上，这两层控制解决的是不同问题。

robots.txt 是公开给合规爬虫读取的访问指令。服务器通常不会因为请求头写着某个名称，就自动按照 robots 文件返回 403。真正的爬虫应先取得 robots，解析适用于自己的规则，再决定是否请求页面。我们手工把字符串写进请求头，既没有证明请求来自真实平台，也不会自动触发爬虫自身的合规逻辑。

HTTP 层的封禁则由 CDN、WAF、访问规则或应用程序执行，它可以在请求到达页面时直接拒绝。两者可以同时存在，也可以只启用其中一种。本次只能观察到：对这些字符串的普通请求没有被直接拦截；不能观察到 Cloudflare 是否会通过 IP、行为或已验证机器人身份应用其他策略，也不能替真实平台证明是否遵守 robots。

这也是为什么审计报告应分别写“robots 策略”和“直接请求结果”。把 200 当成允许政策，会忽略爬虫自律规则；把 Disallow 当成物理封锁，又会高估 robots 的安全能力。涉及保密、付费或个人数据的内容，必须依赖认证和访问控制，不能只写 robots。

六、sitemap、canonical 与内部入口是否形成一致关系

本篇文章写入站点地图之前，sitemap.xml 可正常解析，共提取到 17 个 loc，未发现重复 URL；本文随同发布流程加入后，公开文件应增加为 18 个，后文会再次验证。内容中心、基础知识、方法论和模型实测栏目都在其中；8 月 7 日的行业观察与 8 月 8 日的品牌事实底稿指南也都已出现。内容中心和方法论栏目 lastmod 同步到 8 月 8 日，说明最新发布动作不仅增加文章地址，也更新了相关入口。

抽查的五个 HTML 页面都包含 canonical，分别指向不带临时参数的稳定公开地址；两篇文章各有 Article 与 BreadcrumbList JSON-LD，标题、描述、发布日期、修改日期和 URL 与页面可见信息一致。没有观察到 meta robots noindex，也没有收到 X-Robots-Tag: noindex。

这些信号组合起来的意义是：站内链接负责让读者和爬虫从栏目进入文章，sitemap 提供补充发现，canonical 告诉系统希望使用哪个 URL，Article 数据声明页面是一篇具有时间和发布者的文章。它们相互支持，但不应制造不同版本。若 canonical 指向 A、sitemap 列 B、内链又全部指 C，文件都存在仍然会增加判断成本。

这次也发现一个小但真实的结构问题：五个抽查页面中，内容中心、实测栏目和两篇文章各有一个 h1，首页源码没有 h1。首页仍有 title、meta description、canonical 以及 Organization 与 WebSite JSON-LD，因此它并不是“机器完全看不懂”；但从语义文档结构看，首要页面标题缺失会让视觉主标题和文档主标题之间少一层明确对应。它不应被夸大成收录故障，但值得在后续首页维护中单独修正。

七、llms.txt 与 feed.xml 提供了什么，又没有提供什么

线上 llms.txt 返回纯文本，包含站点定位、官方入口、基础知识、方法论、模型实测和使用边界；最新品牌事实底稿文章已经以标题、绝对 URL 和真实摘要列入。它对支持该约定的模型或工具是一份紧凑导航，也便于人工核查哪些页面被站点明确视为公开内容。

但 llms.txt 不应被当作“AI sitemap”。Google 在生成式搜索优化官方指南中已经说明，Google Search 不需要这类特殊 AI 文件。不同工具是否读取、如何解释，目前并无统一保证。维护它的合理价值是减少支持者的导航成本，而不是用它替代 HTML、robots、sitemap、canonical 和高质量正文。

feed.xml 本次也可解析，最新条目排在最前，标题、URL、发布日期和摘要与文章一致。feed 对订阅器、聚合工具和一些内容发现流程有用，尤其适合表达更新顺序；但它通常只承载摘要，不应成为事实唯一来源。用户从 feed 进入后，仍应落到有完整正文、稳定 URL 和明确日期的文章页面。

维护这两个补充入口时，最容易出现的错误是“文章已经发布，索引以后再补”。静态站没有数据库自动替你保持一致，任何漏更都会造成公开入口不同步。GEOC 当前的做法是把文章页面、内容中心、分类页、sitemap、llms 与 feed 放在同一次发布中验证，这比单独追求某个文件更可靠。

把结果放进五层诊断链路，才知道问题应该由谁处理

第一层是网络可达。域名解析、TLS、状态码、Content-Type、重定向和页面资源要正常。这里失败时，内容写得再好也无法被稳定取得。负责人通常是开发、运维或 CDN 管理者，证据是公开请求和响应头，而不是编辑器里的预览画面。

第二层是访问政策。robots、meta robots、X-Robots-Tag、CDN 爬虫规则和登录权限共同决定不同主体可以做什么。这里最容易发生“各层都正确，合起来却冲突”：源站允许，边缘追加禁止；robots 允许，页面又带 noindex；希望搜索展示，却把搜索使用的代理和训练代理一起阻止。负责人必须同时覆盖代码仓库与边缘平台，不能只让内容编辑检查一份文本。

第三层是发现关系。导航、正文内链、分类页、sitemap、feed 与外部链接让系统知道 URL 存在。一个孤立页面即使返回 200，也可能长期没有稳定入口。发现层的检查不是机械追求链接数量，而是确认首页到栏目、栏目到文章、旧文到新文的路径是否表达真实关系，站点地图是否列出同一个 canonical URL。

第四层是语义理解。title、description、唯一 h1、可见日期、正文结构、Article 与 BreadcrumbList 帮助系统判断页面是什么、由谁发布、何时更新、属于哪个主题。这里的关键是一致，而不是标记越多越好。本次首页缺少 h1 就属于这一层的轻微问题；它不影响网络可达，也没有制造 noindex，但应在页面结构维护时修正。

第五层是采用与结果。平台是否抓取、是否进入索引、是否在某个查询中作为来源、用户是否点击，属于站点外部系统的决策。企业可以观察和复测，却不能通过前四层“配置正确”推导必然结果。报告只有把五层分开，才不会把一次 200 写成“AI 已收录”，也不会把一次未提及误判为网站彻底不可读。

这套分层还能帮助排优先级。网络与访问政策错误通常优先处理，因为它们可能影响整个站点；canonical、noindex 冲突其次，因为会误导权威版本与索引目标；单页 h1、摘要和内链问题按页面价值逐项修正；平台是否采用则需要持续观察，不适合用频繁改页来追逐短期波动。

八、这次实测真正暴露的风险，不是缺文件，而是责任分散

代码仓库负责静态 robots 内容，Cloudflare 又能在边缘追加 Managed Content；文章作者维护 HTML 和 JSON-LD，索引文件由发布流程同步；真正的爬虫访问还可能受到安全规则、缓存和平台自身政策影响。如果没有一张责任图，团队很容易只检查自己能看到的那一层。

第一类风险是配置来源不透明。开发者在仓库里看见 Allow: /，内容人员在浏览器里看见一长串 Disallow，双方都以为对方改了文件。解决办法不是争论哪个版本“才是真的”，而是记录线上最终响应由哪些层组成，并把边缘平台设置纳入变更流程。

第二类风险是目标不清。网站可能一边希望进入生成式搜索，一边开启了广泛 AI 爬虫阻止；也可能希望拒绝训练，却误伤用于搜索发现的代理。正确动作是先写清允许搜索、允许实时引用、拒绝训练等业务偏好，再对照各平台官方代理说明逐项实施。

第三类风险是把补充文件当成结果。llms、feed 和 sitemap 都很有用，但它们只是发现和表达工具。真正能支撑引用的仍是可访问正文、清楚事实、稳定页面、原始证据和一致维护。上一篇《AI 搜索越来越重视来源链接：品牌官网怎样成为可引用信源？》讲的是方法判断，这次审计给出了同一问题在线上配置里的真实样子。

九、企业如何复刻这次审计

如果企业还没有统一的品牌事实版本，应先按品牌事实底稿指南完成资料盘点与冲突裁决。技术入口打通之后，页面仍然需要清楚、真实且可核验的内容；否则系统只是更顺利地抓到一份低质量或互相冲突的资料。

十、常见误判与反例

误判一：“sitemap 有 URL，所以一定会收录。”反例是平台可能尚未抓取、认为页面重复、内容质量不足或选择其他 canonical。sitemap 是提示，不是收录凭证。

误判二：“请求返回 200，所以爬虫获准访问。”反例是本次 GPTBot、ClaudeBot 与 Bytespider 字符串请求都返回 200，但线上 robots 对这些具名代理写着 Disallow: /。HTTP 可达和 robots 授权是两回事。

误判三：“阻止 Google-Extended，就不会进入 AI Overviews。”Google 官方说明把 Search 中 AI 功能的抓取控制归于 Googlebot；两种代理用途不能混同。

误判四：“有 llms.txt，就比没有的站点更容易被所有模型引用。”当前没有这样的通用保证，而且 Google Search 已明确表示不需要专用 AI 文件。llms 可以维护，但不能成为宣传承诺。

误判五：“结构化数据里的内容越多越好。”如果 JSON-LD 出现正文没有的评价、数字或关系，它不是补充证据，而是在制造第二套事实。结构化数据的价值来自与可见页面一致。

误判六：“robots 能保护私密文件。”Google 和 Cloudflare 的文档都提醒，robots 是公开指令且遵守具有自愿性质。真正的私密信息应通过认证和访问控制保护，不能依赖 Disallow。

十一、边界与局限：这次审计没有观察真实平台后台

本次请求来自一个公开网络环境，没有验证 User-Agent 对应的真实 IP，也没有登录 Google Search Console、百度搜索资源平台、Cloudflare AI Crawl Control 或任何模型提供商后台。我们看见的是网站对公开请求返回的内容，不是爬虫日志。因此无法判断真实 Googlebot、Baiduspider 或其他代理最近一次访问时间、抓取数量与是否遵守策略。

我们也没有用模型提问来测试“GEOC 是否被推荐”。站点可读性与答案可见度有关，但中间还隔着抓取、索引、质量判断、查询匹配和模型生成。用一次模型回答倒推技术配置，或者用技术配置预测一定出现，都会越过证据边界。

Cloudflare Managed Content 与 Content Signals 是会变化的产品能力，本文只描述 2026 年 8 月 9 日线上响应和当日可访问的官方文档。网站所有者应在修改边缘配置后立即重新访问线上 robots，并在不同网络和浏览器环境复核缓存结果。

十二、资料依据

• Cloudflare：Managed robots.txt 与 Content Signals 官方说明。
• Cloudflare：AI Crawl Control 的爬虫管理与行为区分。
• Google Search Central：AI Overviews、AI Mode 与 Googlebot 控制说明。
• Google Search Central：sitemap 是发现提示而非收录保证。
• Anthropic：ClaudeBot 遵守 robots.txt 的官方说明。