实测最近 5 篇 GEOC 文章：可见正文与 Article JSON-LD 一致吗？

一、为什么要测“一致性”，而不只是看 JSON 能不能解析

结构化数据检查最容易停留在语法层：JSON 能解析、字段名存在，就认为页面已经完成。语法正确当然必要，但机器面对的不是一段孤立 JSON。页面还同时提供可见标题、摘要、发布日期、canonical、社交元数据、面包屑、站点地图和订阅源。如果这些位置描述的不是同一个页面版本，系统和读者就会收到互相竞争的信号。

Google Search Central 的结构化数据通用指南要求标记能够代表页面中对用户可见的内容；其结构化数据入门文档也强调，页面中的标记应描述该页面本身，而不是隐藏或无关的信息。Article 指南把 headline、datePublished、dateModified 等字段作为文章信息的一部分，同时说明结构化数据只提供资格，不保证产生富结果。Schema.org 对 BreadcrumbList 的定义则强调，它是一条有名称和 URL 的页面链，通常以当前页结束。

因此，本次没有把“Google 是否展示富结果”作为通过标准，也没有把 Article JSON-LD 当成 AI 收录开关。我们测的是更基础、也更可控的问题：同一篇文章在所有公开位置是否仍然是同一标题、同一 URL、同一日期和同一栏目；机器读到结构化声明时，读者能否在页面正文中看到相应信息。

这种检查对纯静态网站尤其重要。页面、栏目页、sitemap、llms 和 feed 都是独立文件，更新不会由内容管理系统自动联动。新增文章时可以一次写对，旧文章后来补内链或修订正文时，却很容易只改页面与 sitemap，忘记同步 feed 的 updated。今天发现的问题正是这种跨文件维护缺口，而不是 JSON 语法错误。

二、抽样范围与测试条件

样本选择最近连续发布的 5 篇文章，不按结果挑选，也不排除不同类型。它们分别是 8 月 11 日的方法论指南、8 月 10 日的行业观察、8 月 9 日的平台审计、8 月 8 日的品牌事实指南，以及 8 月 7 日的来源链接趋势文章。这样可以同时覆盖 methodology 与 tests 两个目录、三种 articleSection 表述，以及一篇后来发生过更新的旧文章。

检查分两层进行。第一层读取 GitHub main 分支中的 HTML 与索引源文件，用同一组规则解析 title、meta description、canonical、Open Graph、两个 JSON-LD 脚本、可见 h1、可见日期、sitemap、llms 和 feed。第二层对 5 个公开 URL 发起不使用缓存的 HTTP 请求，确认页面可访问，并从公开返回的 HTML 中读取同一 h1。两层结果一致，说明仓库源文件与公开页面在检查时没有出现内容分叉。

本次没有登录 Google Search Console，也没有使用 URL Inspection 查看 Googlebot 的已索引版本；没有调用 Rich Results Test 的内部接口；更没有让任何大模型对页面进行主观评分。原因很简单：这些条件当前并未授权或无法稳定复现，不能把普通 HTML 解析包装成平台官方验收。本文只报告我们真实执行的静态一致性与公开访问检查。

公开请求加入独立查询参数和 no-cache 请求头，是为了减少边缘缓存干扰；它不能强制搜索引擎重新抓取，也不能代表所有地区的缓存节点。检查时间固定为 2026 年 8 月 12 日，后续任何页面更新都可能改变结果，因此本文提供的是一份可重复方法和当日快照。

三、每篇文章具体检查哪 13 项

第一组是标题关系。每页只能有一个 h1；h1 文字要与 Article 的 headline 完全相同；HTML title 应由同一标题加站点统一后缀“GEOC｜AI 搜索与生成式引擎优化”组成。这里要求完全一致，是因为这些字段承担同一页面主标题责任，不需要为了覆盖关键词故意写成三个版本。

第二组是 URL 与描述关系。canonical、og:url 和 Article mainEntityOfPage 的 @id 必须指向同一个绝对 URL；meta description、og:description 和 Article description 必须一致。description 不要求逐字复制正文导语，但必须真实概括可见内容，不能在结构化数据中增加正文没有的效果、数据或承诺。

第三组是日期与导航。页面可见的“发布”和“更新”日期要分别对应 Article 的 datePublished 与 dateModified；BreadcrumbList 最后一项的名称和 URL要回到当前文章。面包屑前两层还应保持“内容中心—对应分类—当前页”的层级，不能把 tests 下的页面声明成 methodology 路径。

第四组是站点运行要求。页面源码必须含项目规定的百度统计 ID；canonical URL 必须出现在 sitemap、llms 和 feed 中。这三处存在性不表示搜索或模型会采用页面，但能确认站内提供了约定的发现入口。

第五组是更新时间同步。sitemap 的 lastmod 与 Article dateModified 对齐，feed 条目的 updated 也与 Article dateModified 对齐。这里使用“日期对齐”而非精确到秒，是因为现有页面按日期发布，feed 使用当天零点的时区时间；二者表达的粒度不同，但不应指向不同日。

四、原始结果：4 篇全部通过，1 篇在 feed 日期上失配

发布前首次运行同一套规则，前 4 篇均为 13 项全部通过。8 月 7 日的来源链接文章通过 h1、headline、title、URL、摘要、页面日期、Breadcrumb、百度统计、sitemap、llms 和 feed 存在性检查，也通过 sitemap lastmod；唯一失败项是 feed updated。

问题产生于文章的后续更新。来源链接文章最初发布于 8 月 7 日，后来在 8 月 9 日补充了与站点 AI 可读性审计相关的双向内链，因此页面可见更新日期、Article dateModified 和 sitemap lastmod 都改成 8 月 9 日。但 Atom feed 条目仍写着 8 月 7 日。它不会让正文突然变错，却会让订阅工具看到的版本时间与页面版本不一致。

本次发布已把该条目的 feed updated 改为 2026-08-09T00:00:00+08:00，然后重新执行同一组检查。修正后 5 篇共 65 个字段关系全部通过。我们没有为了结果好看删掉失败项，而是保留检查前结果、问题原因和修正后的状态，因为这才是实测记录能够被复核的价值。

这处问题也揭示了原有发布检查的盲点。过去我们确认新文章是否进入 feed，却没有把“旧文章发生修改时，feed updated 是否跟随”作为独立断言。存在性检查只能发现漏条目，无法发现条目中的日期已经过期。今后的检查应同时验证 URL 是否存在和版本字段是否一致。

五、标题、URL 与摘要为什么全部通过

5 个样本都只有一个 h1，且与 Article headline 一致。HTML title 在标题后统一添加站点名，没有另写一套夸张标题；这避免了浏览器标签、结构化数据和页面正文出现三种不同承诺。对于带中文引号和问号的长标题，JSON-LD 仍能正常解析，说明序列化处理没有破坏字符。

canonical、og:url 与 mainEntityOfPage 在 5 个样本中均指向各自稳定目录式 URL，没有查询参数，也没有把分类页写成文章主页面。公开无缓存请求返回的页面 h1 与仓库版本一致，说明检查时没有把旧缓存页面误当成最新源码。canonical 的一致性仍不等于搜索系统一定采用该 URL，但它至少消除了站点自身给出多个首选版本的冲突。

三处 description 也全部一致。统一描述有一个现实好处：更新文章定位时，只需要检查一套摘要是否仍然真实，而不是让社交分享、搜索摘要候选和 Article 描述各写一份。缺点是某些渠道可能希望不同长度，但当前静态站点更需要降低维护分叉；在没有明确渠道需求时，一致优先于差异化。

需要强调的是，“一致”不代表“优质”自动成立。一段空泛摘要可以在三处完全相同，却仍然没有信息价值。因此本次还人工确认摘要确实概括了标题与正文主任务，没有增加正文不存在的测试范围、客户结果或平台保证。自动断言负责找差异，内容诚实仍需要人工判断。

六、日期与栏目检查给了我们什么信号

所有页面都在首屏元信息中显示发布和更新日期，Article 中也提供相同日期。Google 的 Article 指南建议在适用时提供 datePublished 与 dateModified，并使用 ISO 8601 格式；页面把日期直接展示给读者，也让后来修改有可见记录。8 月 7 日文章发布与修改日期不同，正好说明两个字段不是模板装饰，而是承担版本含义。

栏目表述在样本中包含“方法论”“方法论文章”“行业观察”和“平台实测”。它们与各自页面可见 chip 的主类别相符，但词汇并未完全收敛成一套最小枚举。本次没有把这种差异判为错误，因为 articleSection 本来可以描述内容所属栏目，且页面与 schema 没有互相冲突。未来若要按结构化字段聚合统计，可以再统一分类词表，避免“方法论”和“方法论文章”被当成两个栏目。

BreadcrumbList 的最后一项都使用当前文章标题和 canonical URL，前置层级也指向内容中心与相应分类。Schema.org 将 BreadcrumbList 定义为一条按顺序连接的网页链，通常以当前页面结束。本站的可见面包屑把最后一项简写为“当前文章”，而 JSON-LD 写完整标题；两者承担的可见导航和机器名称角色不同，但 URL 层级一致。本次检查要求 JSON-LD 的末项与文章实体一致，没有要求屏幕上重复长标题。

对 tests 目录中的平台审计文章，可见 chip 写作“平台实测 · 站点审计”，Article articleSection 写作“平台实测”。这属于父类别与更具体标签的关系，并非冲突。自动检查如果只做字符串完全相等，会把合理的层级表达误报为错误，因此规则只要求可见标签包含结构化主类别。

七、这项实测能证明什么，不能证明什么

它能证明，在 2026 年 8 月 12 日读取的 main 源文件与公开页面中，5 个样本的主要页面字段一致；能证明 JSON-LD 可以被标准 JSON 解析；能证明每个 URL 在无缓存请求下返回可见 h1；也能证明首次检查发现的 feed 日期失配已经在源文件层修正。

它不能证明 Google 已经抓取最新版本、接受 canonical、生成文章富结果或在 AI 功能中引用页面。Google 官方明确说明，正确的结构化数据不会保证富结果展示；抓取、索引、质量、查询相关性和产品策略仍然影响实际呈现。我们也没有 Search Console 的 URL Inspection 结果，因此不能声称“Google 已验证通过”。

它不能证明所有历史文章都一致。样本只覆盖最近 5 篇，不代表更早页面没有遗留字段。本次使用连续时间样本，目的是复核当前发布流程，而不是替代全站审计。若要评价全站，应遍历所有文章 URL，并把栏目页、旧模板和重定向纳入范围。

它也不能证明任何大模型会读取 JSON-LD。不同模型和检索系统如何使用网页标记并不统一，平台可能主要依赖可见正文、搜索索引或自己的内容处理管线。对 GEO 更稳妥的做法，是让结构化数据与读者看到的信息一致，而不是把无法验证的“模型偏好”写成效果承诺。

八、怎样把这套检查加入日常发布

第一步，在生成页面后解析所有 application/ld+json 脚本，确认至少存在 Article 与 BreadcrumbList，且 JSON 语法有效。不要只搜索字符串“Article”，因为注释、正文或错误脚本也可能包含这个词。解析后再读取类型和字段。

第二步，建立同页断言：单一 h1 等于 headline；title 使用统一站点后缀；三处 URL 相等；三处 description 相等；可见日期等于 Article 日期；Breadcrumb 末项等于当前标题与 URL。这一步在写入 main 前完成，任何一项失败都应停止发布。

第三步，建立跨文件断言：sitemap、llms 和 feed 都包含 canonical；sitemap lastmod 与 dateModified 对齐；feed updated 与 dateModified 对齐；内容中心与分类页提供自然入口。旧文章被修改时，也要进入同一组检查，不能只验证新文章。

第四步，部署后分别验证仓库与公开页面。先从 main 回读所有更新文件，确认内容与准备版本一致；再请求公开 URL，记录最终 URL、状态和 h1。出现缓存差异时，应使用独立会话或无缓存请求复核，不能因为一次旧响应立即重复改代码。

第五步，保留检查范围和局限。报告应写明样本 URL、检查日期、字段规则、失败项和修正动作。没有执行 Rich Results Test 就不要声称平台验证；没有 Search Console 数据就不要声称已索引。检查脚本的成功只能证明脚本实际覆盖的关系。

九、自动检查怎样避免误报：规则必须对应真实信息责任

自动化最危险的不是少报，而是大量没有解释力的告警。比如把可见 chip 与 articleSection 要求逐字相同，会把“平台实测 · 站点审计”和“平台实测”判成冲突；但前者是更具体的界面标签，后者是结构化主栏目，两者并没有描述不同实体。更合适的规则是确认主类别包含关系，并人工检查面包屑是否落在 tests 目录。

同样，页面可见日期只写到日，Atom feed 使用带时区的 DateTime，不能直接比较完整字符串。检查应先把两者转换到共同日期粒度，再判断是否指向同一天。否则格式不同会被误报，真正的 8 月 9 日与 8 月 7 日失配反而淹没在噪声中。可解释断言的核心，是先说明字段为何应当一致，再选择合适比较方式。

摘要也不能只做完全相等判断。本站当前选择 meta、Open Graph 与 Article description 共用一段摘要，因此可以严格比较；其他站点可能为社交平台准备不同长度，只要核心事实一致也未必错误。若团队决定允许差异，就要增加人工审核：对象、结论、范围和效果承诺是否一致，不能简单取消检查。

URL 规则则适合严格比较。canonical、og:url、mainEntityOfPage 和 Breadcrumb 当前项都在声明“这是哪一个页面”，没有必要指向不同地址。如果站点存在 AMP、打印版或语言版本，应先定义每种关系，再扩展断言；不能看到多个 URL 就随意选择一个作为通过标准。

日期修改也需要明确触发条件。修正错别字是否更新 dateModified，可以由站点制定政策；但一旦页面已经公开显示新修改日期，sitemap 与 feed 就不应继续声明旧版本。本次不是争论什么修改算重要，而是检查已确定的页面版本有没有同步到其他入口。

十、不同团队怎样使用这套方法

对完全手写 HTML 的小型站点，最实用的做法是在发布脚本中维护一份文章清单，逐页读取字段并检查索引。它不需要复杂平台，但必须在写入 main 前运行；等上线后才发现问题，容易留下短暂的半同步状态。本站目前就是这种场景，因此跨文件断言比增加更多 schema 类型更优先。

使用 CMS 的团队，页面、sitemap 和 feed 可能由同一数据库生成，手工漏改的概率更低，但模板错误会同时扩散到大量页面。此时应抽查不同内容类型和历史模板，不要只测最新一篇。发布新模板前先在少量 URL 上验证，再观察 Search Console 的结构化数据报告和抓取情况。

多语言或多地区站点还要增加语言与地区关系：html lang、inLanguage、hreflang、canonical 和可见语言是否一致；不同地区页面是否真的有价格、政策或服务范围差异。不能把本文的 13 项直接当成完整清单，因为站点架构越复杂，信息责任也越多。

新闻、商品、招聘等页面使用的结构化类型不同，Google 支持字段和资格条件也不同。方法可以复用——可见内容、结构化声明、首选 URL、日期和索引入口彼此对照——但字段不能照抄 Article。实施前应查看对应产品的官方文档，并把平台推荐字段与站点真实可提供的内容分开。

无论团队规模如何，检查记录都应能回答三个问题：检查了哪些 URL，使用了什么规则，失败后改了什么。只保存“通过”截图，没有样本与断言，下一次无法复现；只保存脚本，没有原始失败项，也无法判断规则是否真的保护了内容质量。

检查还应保留失败时的原值和修正值。例如本次明确记录 Article 的 8 月 9 日与 feed 的 8 月 7 日，而不是只写“日期异常”。具体差异能够帮助维护者定位文件、复核修正，也防止后来把正常的发布日期与修改日期差异误当成同一问题。

十一、常见误区与下一步

第一个误区是只用结构化数据测试工具看绿灯。工具通常关注支持的类型与字段，未必替你核对 feed、llms、分类页和旧文章更新链路。第二个误区是把推荐字段缺失和实际错误混为一谈。应先修复会造成错误实体、错误 URL、错误日期或不可解析的关键问题，再评估是否补充有真实内容支撑的推荐字段。

第三个误区是为了让 schema “更丰富”，加入页面不可见的评价、数据或组织关系。Google 通用指南明确要求标记代表可见内容；即使技术上能解析，隐藏夸大也不符合质量要求。第四个误区是每次更新都把 datePublished 改成当天，导致文章失去首次发布日期。正确做法是保留 datePublished，只更新 dateModified，并同步 sitemap 与 feed。

第五个误区是发现缓存旧页就立即重复提交。静态部署和边缘缓存可能短暂不同步，应先核对 main、公开源和独立会话，再判断是否真正发布失败。此前的GEOC 官网 AI 可读性整站审计更侧重 robots、Cloudflare Content Signals、sitemap 与公开访问边界；本文则把范围收窄到文章字段与跨索引版本一致性，两者可以组合成发布前后的完整检查。

下一步可以把同一规则扩展到全部历史文章，并增加内部链接目标是否存在、页面资源路径是否可访问、栏目词表是否统一等检查。但扩展时仍应保持断言可解释：每项规则都要说明保护什么信息责任，不能为了追求检查数量制造没有实际影响的告警。

资料依据

• Google Search Central：结构化数据通用指南——要求标记代表页面可见内容，并说明正确标记也不保证搜索展示。
• Google Search Central：Article 结构化数据——说明 headline、datePublished、dateModified 等文章字段与日期格式。
• Schema.org：Article——Article 类型及其可用属性定义。
• Schema.org：BreadcrumbList——说明按顺序连接页面、通常以当前页结束的面包屑列表。

2026 年 9 月 2 日，我们把这套抽样规则扩展为34 篇文章的内容索引全量一致性审计，以仓库目录为独立分母，对照内容中心、分类页、sitemap、feed 与 llms 的 URL、标题和日期；全量结果也公开了两个仅涉及引号样式的原始差异。

页面字段一致只是基础，HTML 还需要清楚表达主标题、章节、主要内容、表头和链接目的。我们随后对全部文章完成了28 篇文章的 HTML 语义结构实测，把这两层检查拆开记录。