实测 GEOC 34 篇文章的内容索引一致性：sitemap、feed、llms 有没有漏收或日期漂移？

一、为什么内容索引一致性值得单独审计

静态网站发布一篇文章，不只是新增一个 HTML 文件。读者通常从内容中心或分类页进入，搜索爬虫可能从 sitemap 发现 URL，订阅工具读取 Atom feed，面向语言模型的内容说明则由 llms.txt 提供可读入口。五个表面都指向同一篇文章，却由不同文件维护；任何一个环节漏改，都会形成“页面存在但入口不完整”的半发布状态。

半发布不一定立即表现为 404。最隐蔽的情况是文章 URL 本身正常，canonical 和正文也正确，但分类页没有入口，feed 仍停留在旧版本，或 sitemap 的 lastmod 没有随旧文修订更新。人工打开新文章会觉得发布完成，只有逐项对照内容清单才会看见差异。随着文章数增加，靠记忆检查越来越不可靠。

这项审计也不能被简化成“sitemap 里有 URL 就够了”。sitemap 负责声明可发现页面和修改时间，feed 承担按时间分发内容更新，llms.txt 是一份面向机器与开发者的文本导航，内容中心和分类页则服务真实读者与站内关系。它们不是五份相同格式的名单，而是五种职责不同、核心实体必须相交的入口。

因此本文要回答的不是某个平台会不会收录，而是一个更基础、也更可验证的问题：在一个固定发布版本里，站点自己是否对“有哪些文章、文章叫什么、首发和最后修改时间是什么”给出了互相不冲突的答案。只有先把站内版本责任做好，才有资格讨论外部系统何时抓取和如何使用。

二、测试对象与时间：先固定提交，再建立真实文章清单

本次样本固定在 main 提交 063b550c2dde853a60c407be99f7d830d22b8811。该提交是 2026 年 9 月 1 日发布“GEO 事实责任页”后的完整版本。测试在 2026 年 9 月 2 日进行；所有仓库文件都从这个提交读取，而不是一部分读 main、一部分读不断变化的公开页面。固定 SHA 让文章数量、字段和差异能够复算。

真实文章清单不从 sitemap 反推，也不以内容中心为准。脚本遍历仓库树，只接收 public/blog/basics/、public/blog/methodology/ 和 public/blog/tests/ 下第二级 slug 目录里的 index.html，排除三个分类首页。这个规则得到 34 篇：基础知识 2 篇、方法论与趋势 21 篇、平台实测 11 篇。

这样做是为了避免循环证明。如果先把 sitemap 当作文章真相，再检查 sitemap 是否覆盖文章，漏进 sitemap 的页面永远不会进入分母；如果用内容中心做分母，也会漏掉同时缺失内容中心入口的文章。目录里的可发布详情文件是本次清单起点，其他索引只作为被比较对象。

这个起点仍有边界。仓库可能保存草稿或暂不公开页面，单靠路径无法理解发布意图。本站的约定是 public 下这些三级详情页均为公开文章，且没有草稿标记，因此目录规则适用。其他团队复制方法时，应先定义已发布状态，不要把预览、归档或受限内容自动塞进公开索引。

三、比较哪些字段：URL 是主键，标题与日期负责版本解释

每篇 HTML 先解析 canonical，再读取唯一 H1、Article JSON-LD 的 headline、datePublished、dateModified 与 mainEntityOfPage。canonical 作为跨文件主键，是因为 slug 稳定、能直接映射公开地址，也能避免两篇同名文章被错误合并。检查同时要求 Article 主页面 URL 等于 canonical，页面内部先自洽，才能和外部索引比较。

随后从内容中心和分类页提取文章链接与可见标题；从 sitemap 提取 loc 与 lastmod；从 Atom feed 提取 id、title、published 和 updated；从 llms.txt 提取 Markdown 链接、标题及摘要。每个表面都先做 URL 去重，再与 34 个真实 URL 做集合差异，最后才比较同一 URL 下的字段。

URL 比较使用严格字符串。路径末尾斜杠、协议、主机名或 slug 只要不同，就会被当作两个地址，因为这些差异可能产生重复页、重定向或错误 canonical。日期则先统一到自然日：页面使用 YYYY-MM-DD，Atom 使用带 +08:00 的完整时间，两者格式不同但可以指向同一天，直接逐字比较会制造误报。

标题使用两层规则。第一层保留原字符串并报告所有逐字差异；第二层只归一化直引号、弯引号和首尾空白，再判断是否仍有文字差异。本文没有删除词语、改变数字、忽略标点以外的内容，也没有使用模糊相似度，因为过度归一化可能把真正不同的标题误判为一致。

四、URL 覆盖结果：五个入口都没有漏掉这 34 篇

内容中心包含 34 个文章入口，和目录清单完全相等。三个分类页分别包含基础知识 2 个、方法论 21 个、平台实测 11 个，合计 34；每个 URL 只出现在所属分类，没有跨分类重复。这里的“重复”按完整 canonical 计算，同一篇文章的导航链接或相关阅读不在分类清单范围内。

sitemap 一共有 41 个 URL，其中 34 个是文章详情，另外 7 个是首页、关于、白皮书、内容中心及三个分类页。文章子集和目录清单完全相等，没有把分类页误算成文章，也没有出现同一个 loc 两次。全站 URL 总数大于文章数是正常结构，不应把 41 与 34 的差异误报成多收 7 篇。

Atom feed 有 34 个 entry，所有 id 都是文章 canonical，没有重复与额外条目。llms.txt 也有 34 个文章 Markdown 链接，并按基础、方法论和模型实测分组。两者均没有指向不存在详情文件的旧 slug，也没有漏掉 9 月 1 日刚发布的文章。

覆盖通过不代表这些入口在外部系统里拥有同等作用。内容中心有链接不保证爬虫一定访问；sitemap 有 URL 不保证收录；feed 有 entry 不保证订阅客户端刷新；llms.txt 有条目更不等于任何模型承诺读取。本文能证明的是发布源在这个提交里的清单关系，不会把站内声明升级成平台结果。

五、日期结果：34 个 sitemap lastmod 与 34 个 feed 版本日期全部对齐

对每篇文章，脚本把 sitemap 中同 URL 的 lastmod 与 Article dateModified 严格比较，34 篇全部相等。这个结果包含被补过双向内链的旧文章：旧文的可见更新时间和 Article 修改日期改变时，sitemap 也同步到同一天，没有保留原来的 lastmod。

feed 的日期比较分两条。published 应与 Article datePublished 同日，updated 应与 dateModified 同日。34 个 entry 的两条关系全部通过。多篇旧文章的 updated 晚于 published，说明 feed 没有为了简化而把两个字段都写成发布日期；文章首次发布和后来修改仍被区分。

日期一致也不能证明修改幅度。一次错别字、补充内链或重写结论都可能使用新的 dateModified，具体更新政策要由站点说明。审计只检查站点已经做出的版本声明是否在页面、sitemap 和 feed 之间同步，不判断某次改动是否“足够大”才配更新日期。

这项边界很重要。若把任何 lastmod 变化解释成重大内容更新，读者会被误导；若因为修改很小就允许三个表面写不同日期，又会失去可验证的版本关系。更稳妥的方法是先制定修改日期政策，再保证所有派生索引忠实反映页面当前声明。

六、标题结果：两个引号样式差异，为什么没有被隐藏或夸大

内容中心和三个分类页的 34 个可见标题都与对应 H1 逐字一致。feed 与 llms 各有两处逐字差异，发生在较早的 DeepSeek 系统门窗实测和豆包重庆木地板实测：H1 用英文直引号包住查询词，feed 与 llms 用中文弯引号。除两个引号字符外，标题文本完全相同。

如果审计只报告“逐字全等”，结果就不是 34 比 34，而是 32 比 34；如果直接说“标题冲突”，又会让人误以为两个入口描述了不同主题。本文同时保留两种结果：原始字符串有 2 篇排版符号差异；在仅归一化引号样式后，0 篇存在文字、对象、平台或问题差异。

本次没有为两个符号差异改动旧文章。原因不是忽略问题，而是它们不改变 URL、主题、事实或页面版本，且修改 H1 会触发旧文的标题元数据、结构化数据、日期与多个索引同步，维护成本和变更面远大于排版收益。把规则记录下来，比制造一轮没有信息价值的全链更新更诚实。

但同样的容忍不能扩大到词语差异。例如页面写“31 篇”，feed 写“34 篇”；H1 写“实测”，llms 写“指南”；或一个标题更换了平台名，都必须判为真实不一致。允许的归一化集合应很小、可审阅、固定版本，不能用相似度分数把差异自动吞掉。

七、摘要为什么没有做逐字统一：不同入口承担不同长度责任

本次确认 34 个 feed summary 和 34 个 llms 摘要均非空，也能通过 URL 关联到文章，但没有要求二者与 meta description 逐字相等。feed 摘要服务订阅读者，llms 摘要服务文本导航，meta description 面向搜索结果说明；站点当前多数内容会复用核心表述，但三者可以有合理长度差异。

若强行把所有摘要做成一个字符串，维护更简单，却可能牺牲入口用途；若完全不检查，又可能出现摘要声称正文没有的测试、数据或效果。本次采用的边界是：自动验证存在性与归属，人工复核对象、范围和核心结论，不把措辞差异本身当作错误。

对事实风险较高的页面，还应追加命题级检查。摘要不能把“观察到一次”改写成“长期稳定”，不能把“站内索引覆盖”写成“搜索引擎已收录”，也不能把“文章 URL 可访问”写成“大模型已经读取”。这类语义错误无法靠 URL 集合差异发现，仍需要内容审稿。

因此，索引一致性测试不是内容质量的替代品。它擅长找漏项、重复、错误 URL 和日期漂移；标题与摘要是否准确完整，还需要根据正文责任判断。把自动化的边界说清楚，能避免检查项越多、结论反而越虚假的问题。

八、四种常见失败怎样形成，以及应该从哪里修

第一种是新文章文件已经提交，却漏改分类页或内容中心。这通常发生在只验证目标 URL 的流程里。修复不能只补一个入口，还要重新以目录清单为分母检查所有表面，确认没有第二处遗漏。发布脚本应把新文件和索引更新放进同一个提交，避免先上线孤立页面。

第二种是复制旧 entry 后忘记替换 URL，造成 feed 或 sitemap 重复。肉眼看到条目数量增加，容易误以为发布成功；集合去重后才会发现一个旧 URL 出现两次、新 URL仍缺失。计数、唯一数和集合差异必须同时报告，只看总数量不足以判断覆盖。

第三种是旧文章修改了正文和 dateModified，却没有同步 sitemap lastmod 或 feed updated。页面本身看起来正确，但不同入口对“当前版本”给出不同日期。修复时应保留 datePublished，只更新修改日期及其派生字段，不能把首次发布日期一起改成今天。

第四种是 slug 迁移后只改了内容中心，旧 URL 仍留在 llms 或 feed。此时可能同时存在重定向、canonical 和历史订阅的兼容问题，不能机械删除所有旧地址。团队需要先决定迁移策略，再明确索引中应该保留新 URL、是否提供永久重定向，以及历史 feed entry 是否需要稳定。

这些失败都说明，索引文件不是发布后的附属文档，而是文章实体的多个投影。最可靠的修复点应是文章清单或内容数据源；如果静态站暂时没有统一生成器，也应让验证脚本从目录事实反向检查所有投影，而不是相信维护者记得每个文件。

九、为什么“没有发现问题”也需要保留可复算记录

零异常很容易被写成一句没有证据的“检查通过”。有用的记录至少要保留基准 SHA、文件识别规则、每个集合的原始数量、去重后的数量、差集和字段比较规则。本次报告同时给出目录 34 篇、三个分类的 2、21、11，以及 sitemap 全站 41 个 URL 中文章子集 34 个，就是为了让后来维护者能够重建分母，而不是只能相信结论。

负面结果还要说明检测能力。脚本能发现 sitemap 少一个 loc、feed 重复一个 id、llms 指向旧 slug，或 lastmod 与 dateModified 不同；它不能发现某个摘要把“可能”写成“必然”，也不能判断文章是否真的解决用户问题。只有列明能够发现和不能发现的错误，零异常才有解释力。

复算记录还应保留原始差异，而不是只保存归一化结果。两个标题引号差异就是例子：如果只输出归一化后零差异，未来规则变化时无法判断当时忽略了什么；如果只输出两处失败，又会把排版噪声当成实体冲突。本次同时保存原值、归一化方式和判断结果，使后续审计可以复核这项取舍。

当审计发现真正问题时，报告应记录修复前值、目标值和变更文件，并在最终提交上再次运行同一套规则。不能用修复后的零异常覆盖修复前事实，也不能因为文章主题需要“发现问题”就夸大正常差异。实测文章的价值来自可验证过程，不来自异常数量。

十、检查顺序为什么会影响结论可靠性

第一轮只分析仓库固定版本，不混入公开站点，是为了回答“准备发布的源文件是否自洽”。第二轮在创建候选版本后加入新文章和旧文回链，再复算全部集合；这时文章数应从 34 增至 35，tests 分类从 11 增至 12，其他分类不变。若只搜索新 slug，无法证明旧集合仍然完整。

第三轮在提交前重新读取 main 指针。若 SHA 不再是基准提交，说明期间出现并发更新，原先生成的索引可能覆盖他人内容；即使所有本地测试通过，也必须停止并基于新 main 重做合并。原子 tree 和非强制更新只能保证一次写入完整，不能替代并发检查。

第四轮从最终提交 SHA 回读所有变更文件并逐字比较。这样验证的是 GitHub 实际保存的版本，不是本地准备版本。第五轮才检查公开 URL 和索引端点，区分仓库写入成功与部署完成。任何一轮失败都应保留上一轮结果，不能把“main 已提交”误报成“公网已可访问”。

这种顺序看起来比打开页面多几步，却明确了故障所在：候选文件失败是生成问题，main 变化是并发问题，提交回读不同是写入问题，公网仍旧是部署或缓存问题。定位清楚以后，维护者才不会用重复提交、强制覆盖或改标题来解决并不存在的内容错误。

十一、怎样把审计变成发布门槛，而不是事后报告

发布前第一步是锁定基准提交，确认 main 没有在准备期间变化。新文章、内容中心、所属分类、sitemap、llms、feed 和需要回链的旧文章应在本地形成完整候选版本；验证全部通过后再创建一个基于原 tree 的新提交。若 main 已变化，应重新读取和合并，不能强行覆盖。

第二步建立结构断言：新页面只有一个 H1、一个 main 和一个 article；canonical、og:url、Article mainEntityOfPage 与 Breadcrumb 当前项都等于目标 URL；datePublished 和 dateModified 符合当天；Article 与 Breadcrumb JSON 可解析。页面内部失败时，不应继续验证索引。

第三步运行全量集合检查，而不只搜索新 slug。目录文章集合必须等于内容中心集合、分类集合、sitemap 文章集合、feed id 集合和 llms 链接集合；每个集合内部唯一。全量比较还能发现旧文章迁移或手工编辑造成的历史漂移，单篇冒烟测试做不到这一点。

第四步比较派生字段并记录允许差异。URL 和日期适合严格规则；标题可只归一化明确的排版字符；摘要需要存在性和人工事实审核。每条规则都应说明保护什么责任、为何允许哪些差异。没有解释的“相似度大于九成”不适合作为发布门槛。

第五步在提交后回读最终 SHA 的全部变更文件，确认写入内容与验证版本逐字相同，再检查公开文章、内容中心、分类页及四个索引端点。部署可能有短暂缓存差异，应以独立请求复核；只有仓库和公开页面都稳定后，才能报告发布完成。

十二、这项实测适用于谁，应该怎样缩放

对手写静态站点，这套方法几乎是必要的，因为同一文章常被复制到多个 HTML、XML 与文本文件。文章不多时可以在发布脚本里直接遍历目录；数量增加后，应考虑从统一内容元数据生成页面卡片、sitemap、feed 与 llms，减少人工分叉。不过即使改为生成，也要保留输出验证，模板错误会一次影响全站。

对 CMS 站点，文章清单通常来自数据库，内容中心和 feed 可能自动生成，漏项风险较低，但发布状态、栏目映射和缓存仍可能让输出不同步。此时真实清单应来自已发布内容 API，测试对象要覆盖不同内容类型、语言和历史模板，不能照搬本站目录规则。

对多语言或多地区网站，还要把 URL 集合扩展为语言—地区—canonical 关系，检查 hreflang、inLanguage、地区价格与政策版本。一个中文页面和一个英文页面不应仅因标题相似就合并；每个版本都要有明确主键和责任范围。本文的 34 篇单语言样本没有覆盖这些复杂关系。

对新闻、商品或招聘页面，feed 时间与页面状态的意义也不同。商品价格变化可能不需要把首发时间重置，职位关闭可能需要从某些入口移除但保留历史页面。可复用的是“先定义真实实体和各投影责任，再做集合与字段检查”的方法，不是本站每一条具体断言。

十三、边界与局限：通过测试仍不等于被搜索或 AI 使用

本次只验证固定 Git 仓库版本中的静态源文件，不能证明百度、Google、Bing 或任何大模型在测试时已经抓取这些入口。robots 允许访问、sitemap 声明 URL、公开端点返回成功，都只是可访问与可发现条件，不是索引、引用、推荐或商业结果保证。

测试也没有读取搜索平台后台的覆盖报告，没有核对每个 URL 的抓取时间，更没有向模型批量提问。把“34 篇进入 sitemap”改写成“34 篇被搜索引擎收录”，或把“llms 有 34 条”改写成“模型知道 34 篇”，都会超出证据。本文刻意把站内一致性和外部采用分开。

目录规则依赖当前站点约定。如果未来引入草稿、归档、分页、标签页或非 HTML 内容，需要更新清单定义；否则脚本可能把不应公开的文件当成漏收，或漏掉新的内容类型。测试脚本本身也是需要版本管理的规则，不是一次写完永久正确。

最后，零漏项不代表零内容问题。文章可能观点过时、证据不足、段落重复或标题没有回答清楚，但仍能在五个入口里完美一致。索引审计解决“同一个站点是否说同一套目录与版本”，内容诚实、证据质量和读者价值仍需其他审稿与复测承担。

十四、可引用要点与下一步

第一，内容索引一致性不是“文件数量相同”，而是以真实文章清单为基准，验证 URL 集合、唯一性、标题映射与版本日期。第二，sitemap、feed、llms 和导航页职责不同，不应强求所有文本逐字相同，但它们对文章身份与当前版本不能互相冲突。

第三，本次固定提交中 34 篇文章在内容中心、所属分类、sitemap、feed 和 llms 五个入口均完整唯一；34 个 sitemap 修改日期和 34 个 feed 版本日期与页面一致。第四，两篇早期实测只有直引号与弯引号的排版差异，归一化后没有标题语义冲突，本次没有把它夸大成错误，也没有隐藏原始差异。

第五，这些结果只能证明 2026 年 9 月 1 日固定 main 版本的站内发布关系，不能证明搜索引擎已收录或模型已读取。下一步最有价值的工作，是把同样的全量集合断言加入每次发布前验证，并在内容类型变化时更新“真实文章”的定义。