实测 12 组案例页 HTML：对象、基线、结果与限制能否形成可核验关系？

先给结果：字段大多能找到，完整关系只有 2 组通过

本次使用 12 组不关联任何真实网站、客户或项目的合成 HTML，分别改变案例对象、基线、实施动作、结果指标、时间、限制和证据链接的呈现方式。固定检查器共执行 96 项判定：对象 10 组可识别，基线、动作、结果、时间和限制各有 9 组通过，结果旁证据链接有 8 组通过；只有“完整语义基线”和“公开 details 限制”两组能把八项要求关联到同一个案例单元，完整通过率为 2/12。

这说明案例页最常见的问题不是完全没有文字，而是信息之间缺少稳定关系。页面可能同时出现客户类型、一个增长数字、一张截图和一句“结果因情况而异”，人眼可以根据版式猜测它们属于同一项目，静态解析却未必知道哪个数字是基线、哪个是结果、证据支撑哪一个指标、限制约束哪一个结论。字符存在只能证明页面里有这些词，不能证明它们构成一条可核验的证据链。

本次“通过”仅表示初始 HTML 满足公开规则，不表示 Google、百度、ChatGPT、DeepSeek、豆包或其他系统一定抓取、索引、引用或推荐。测试没有调用任何模型，也没有观察线上排名和生成式回答。它回答的是更窄的问题：当案例页已经返回给客户端时，关键事实是否以可见、可定位、可相互关联的形式存在。

案例页的机器可读性，不取决于页面里有没有“基线、结果、限制”这些词，而取决于它们能否在同一个案例边界内，围绕同一对象和同一指标形成可追踪关系。

为什么要测“关系”，而不是继续数标签

昨天发布的GEO 可核验案例页方法提出六个基本问题：对象是谁、起点是什么、做了什么、怎样测量、得到什么、哪些部分不能归因。本次实测把这套方法压缩为可以机械复算的 HTML 断言，用来检验页面结构是否真的承载了这些关系，而不是只在视觉上看起来完整。

案例与普通介绍页不同。介绍页可以独立说明产品功能、适用范围或服务流程；案例页则需要表达一次具体观察的前后关系。只要对象、时间或指标错配，结果就会失去含义。例如“准确回答率由 8/30 变为 19/30”必须同时绑定同一问题集、同一判读口径和两个观察窗口，不能把不同地区、不同入口或不同分母的数字放在一条增长叙事里。

因此，本次没有把 h2 数量、段落长度或是否存在 Article JSON-LD 作为核心结果。它们有助于页面组织，却不能替代案例事实。检查重点落在事实单元及其邻接关系：指标是否在基线或结果区内，证据是否紧邻对应结果，限制是否公开可见，前后指标名称是否能够对齐，所有部分是否处于同一个案例容器。

测试对象、环境与固定条件

测试日期为 2026 年 9 月 30 日。样本由本地脚本生成，每组都是一段独立 HTML，不请求网络，不使用真实域名、品牌、客户、后台数据或本站页面。示例证据地址使用不可解析的 example.invalid 域名，数字只服务于结构判定，不代表任何业务表现。

解析使用 Python 3.12 与 lxml 的初始 HTML 树。检查器不执行 JavaScript，不加载 CSS、图片或外部接口，也不模拟浏览器渲染后的无障碍树。隐藏判断覆盖 hidden、display:none、visibility:hidden、template、script 和 style 祖先。公开的 details 内容保留在文档树中，因此不因默认折叠而判为隐藏。

每组运行同一套八项规则，没有根据结果修改阈值，也没有删除失败样本。完整通过要求八项同时成立；任何一项失败都不能由其他项加分抵消。这样做的目的，是避免把“七项不错”误写成“证据链完整”。逐项结果和规则都在本文公开，读者可以按相同条件复算。

12 组样本怎样设计

第一组是完整基线：一个独立 article 案例容器内依次放置对象、基线、动作、结果和限制；基线与结果使用同名指标，日期由 time 元素表达，结果证据就在指标句中。它不是推荐模板的唯一写法，而是用于验证检查器能识别正确关系的控制组。

第二至第九组每次只破坏一个关键条件，包括扁平宣传段落、缺少对象、基线没有值、动作未标记、图片承载结果、日期只有普通文字、限制被隐藏、证据集中在页尾。单变量设计帮助判断失败来自哪一项，而不是让多个错误互相遮蔽。

第十组把前后信息拆进两个案例容器，模拟同一页面展示多个客户或多个阶段却没有稳定案例编号的情况。它的对象、基线、动作、结果、时间、限制和证据都能在整页找到，但检查器拒绝把两个容器拼成一条关系。第十一组将限制放入 details，验证折叠不等于隐藏。第十二组把主要内容放在 template 中并依赖脚本注入，用来界定初始 HTML 静态检查的边界。

完整结果表

表格显示，单项字段并不稀缺：十二组中有十组包含可识别对象，基线、动作、结果、时间和限制各有九组通过。真正稀缺的是把这些字段约束到同一案例的能力。完整关联只有两组通过，说明发布检查如果只搜索关键词，很容易高估页面质量。

证据链接只有八组通过，比对象、基线等字段更弱。一张案例页可能列出很多来源，但如果所有链接都集中在文末，检查器无法知道某个数据导出支撑基线、结果还是方法说明。关系型检查要求证据靠近主张，不是为了强迫一种视觉布局，而是减少“有来源但不知道支撑什么”的歧义。

观察一：扁平营销文案几乎不可复核

“我们帮助客户取得明显提升，效果很好”这一组八项全失败。问题并不在于句子短，而在于没有对象范围、指标、分母、时间和证据。即使搜索系统完整读取这句话，也只能得到一个无法独立验证的发布者判断。增加更多“显著、领先、成功”不会改变证据强度。

修复方式不是先添加结构化数据，而是把命题拆开。至少说明哪个类型的样本、实施前怎样测、上线了哪些动作、在什么窗口用同一规则复测、观察到什么，以及哪些因素仍无法排除。完成事实拆分后，再选择 section、time、表格或链接来表达；顺序反过来，就容易得到外表规范但事实空洞的页面。

观察二：对象缺失会让数字失去适用范围

第三组有基线、动作、结果、日期、限制和证据，却因为缺少案例对象只通过六项。数字本身可以解析，但读者不知道它属于哪个行业、哪个地区、哪种业务或哪一组页面。脱敏并不要求删除全部背景；完全无对象会使适用性判断和后续核验都失去锚点。

匿名案例应保留不能反推出主体的必要范围，例如“面向多个城市提供服务的消费品牌”“固定 20 个售前问题”“仅观察公开网页与两个模型入口”。不能公开的名称、域名和后台数据可以省略，行业类型和测量边界则应尽量保留。若连基本范围也无法说明，更合适的内容类型是方法复盘，而不是结果案例。

观察三：有“基线”标题，不等于存在基线

第四组的基线区写着“实施前表现较少”，但没有指标名称、数值或分母，因此基线失败。案例中的“之前不理想”“几乎没有曝光”“客户认知较低”都属于描述，不足以支撑前后变化。即使结果区给出一个精确数字，也无法算出变化，更不能判断是否采用同一口径。

可复核基线需要最少四部分：指标、数值、样本或分母、观察时间。若指标是回答准确率，还要说明什么算准确、重复运行怎样计数。若无法补回实施前记录，应明确写成“当前截面”或“上线后观察”，不要根据现有结果倒推一个看似合理的起点。

观察四：动作需要落到已经发生的改变

第五组虽然有“实施动作”区，却没有可识别的具体动作项。真实页面常把“GEO 优化、内容建设、技术改造”当作动作，这些词只能说明服务类别，不能说明哪些公开事实和页面发生了变化。读者也无法判断结果与哪一步存在机制联系。

动作应写成可核查的完成事项，例如统一产品名称与服务范围、补充价格限定条件、把关键答案移入初始 HTML、修正 canonical 或增加一手证据。还要区分已经上线、提出建议和等待执行。把方案清单全部写成已完成，会扩大项目范围，也使归因链失真。

观察五：图片可以辅助结果，不能成为唯一结果

第六组只放一张结果图，因此结果和证据同时失败。图片中的折线、数字和来源标签可能对人类读者很直观，但静态文本检查不能稳定获得其口径；即使使用 alt，也很难同时表达指标名称、数值、分母、时间和限制。截图还可能在裁剪后丢失问题、账号状态或平台入口。

更稳妥的结构是先用可见文字写出结果，再把图表作为辅助证据。结果句应紧邻数值、条件和证据链接，图片说明注明平台与日期。若截图只能证明一次模型回答，就不要把它用作“持续推荐”的证据。图片文件名、元数据和画面内容还需要脱敏，避免泄露客户或账号信息。

观察六：时间既要可读，也要能确定归属

第七组的人眼能读到两个日期，但没有 time 的 datetime，因此机器可读时间失败。这里并不是说所有日期都必须使用 time 才会被任何搜索系统理解，而是固定规则需要一种不依赖中文分词和日期格式猜测的表达。2026/8、八月初、上线一个月后和近期，都可能在不同环境中产生歧义。

日期还要放在正确阶段。基线日期属于基线，结果日期属于结果；只在页头给出发布日期，不能替代测量窗口。若案例跨越多轮迭代，应把动作上线日、观察窗口和资料截至日区分开。Article 的 datePublished 与 dateModified 描述文章版本，不是项目结果发生时间。

观察七：限制被隐藏，公开结论仍然不完整

第八组把限制区设为 hidden，静态规则因此判定失败。页面源码里存在一句“样本仅覆盖一个地区”，不等于普通读者能看到这项限定。Google 的结构化数据通用规范要求标记代表页面可见内容；同样的诚实原则也适用于案例主张：不能把强结论放在可见区，却把限制藏在不可见模板或仅供脚本处理的数据层。

第十一组则把限制放入原生 details，仍然完整通过。details 默认折叠，但用户能够展开，内容也保留在文档结构中。折叠适合承载补充方法和详细边界，关键限制仍建议在结论附近直接显示。不能用折叠组件把所有不利信息移出首屏，再声称已经充分披露。

观察八：证据链接必须知道自己支撑什么

第九组把证据放在页尾“全部资料”中，因此整页有链接，结果项却没有证据。来源集中列表便于维护，但会削弱命题与证据的局部关系。尤其页面包含多个指标时，同一报告可能只支撑访问量，不支撑模型提及；一个客户评价可能说明体验，不证明统计结果。

本次要求链接位于结果指标内部，是为了建立明确的最低关系。真实页面不必使用 data-evidence 属性，可以通过句子、脚注回链、表格行或描述性锚文本完成同样目的。关键是读者能从结论抵达对应材料，也能从材料返回它所支撑的结论。可以参考对比表限定条件与证据链接实测，检查证据是否与具体单元对齐。

观察九：整页都“有”，仍可能拼错案例

第十组在整页范围内通过对象、基线、动作、结果、时间、限制和证据七项，却因前后内容分属两个 article 案例块而关联失败。这是本次最重要的反例：字段覆盖率很高，事实链仍然可能错误。若解析器只在整页搜索数字和来源，它会把案例 A 的基线与案例 B 的结果拼在一起。

多案例页面需要稳定边界。每个案例应有独立标题、对象、标识和内部完整关系；不要在页面顶部统一列基线，底部统一列结果，再依赖视觉顺序让人猜配对。若必须做汇总，可另设总览表，但总览中的每个结论应能回到具体案例，而不是把多个客户拼成一个不存在的典型故事。

观察十：脚本注入不是错误，但静态可见性会降低

第十二组只有对象出现在初始 HTML，其余内容都放在 template 中等待脚本注入，因此只通过一项。这不证明 JavaScript 页面不会被现代搜索系统处理，也不等于 template 内文字永远不可见；它只说明不执行脚本的读取方式无法把这些内容当作当前公开案例。

如果案例的核心事实依赖接口、登录状态或交互后加载，应同时检查渲染后 DOM、接口失败状态和无脚本降级。对于对象、基线、主要结果与限制等决定结论的内容，优先放入初始 HTML 可以减少渲染资源、执行时序和客户端失败带来的不确定性。交互图表可以增强探索，不应成为唯一事实载体。

这项测试能证明什么，不能证明什么

它能证明固定输入在固定解析规则下的结果可复现，能显示某类 HTML 写法为什么通过或失败，也能帮助编辑在发布前发现字段存在但关系断裂的问题。它还说明原生 article、section、time、details 和普通链接足以表达基本案例关系，不需要发明一种“GEO 专用标签”。

它不能证明任何平台实际采用这些自定义 data 属性，不能给 HTML 写法分配排名权重，也不能预测模型是否引用案例。检查器没有验证外部证据是否真实、数字计算是否正确、客户是否授权、结论是否具有因果性。一个页面可以八项全过，却仍然包含虚假数据；结构验证永远不能替代业务事实审核。

本次也没有比较不同前端框架、服务端渲染和客户端渲染的抓取差异，没有执行 JavaScript，没有访问真实搜索产品。若要评估线上可发现性，需要另行记录响应状态、robots、canonical、渲染结果和平台报告；若要评估生成式回答，需要固定问题集、模型入口、时间与重复次数。不要把静态检查扩大成平台效果实验。

从测试结果反推案例页的实际写法

第一步是固定案例边界。一个页面只有一个案例时，用 article 包含完整正文；一个页面有多个案例时，每个案例拥有独立容器与标题。对象说明放在容器内部，匿名也要保留业务类型、市场范围和样本条件。页面级标题负责解释主题，不能代替具体案例对象。

第二步是让基线与结果共享指标名称和定义。最简单的做法，是在两处重复写出完整口径，而不是只在表头或方法区解释一次。读者截取结果段落时，仍应知道分母、条件和时间。若指标计算复杂，可链接方法说明，但结果句不能只剩一个百分比。

第三步是把动作、证据和限制放在它们约束的结论附近。动作说明“改了什么”，证据回答“凭什么这样说”，限制回答“这句话最多能说到哪里”。三者分别服务于机制、核验与边界，不能用一个模糊的“方法与说明”折叠块替代。

第四步才是同步 Article JSON-LD、Open Graph、摘要和索引。结构化数据描述文章本身，不应塞入正文没有公开的客户、评分或结果。若页面更新了实质结论，要同步 dateModified；若只是修正标点，不必把每次构建都包装成内容更新。

修复顺序：先纠正事实，再调整页面结构

测试失败后，不要直接给每个段落添加 data 属性。第一轮应回到原始材料，确认对象、基线、动作、结果和限制是否真的存在。若项目没有实施前记录，就应把文章改为阶段观察；若结果只有客户口述，就应标为体验反馈；若不同窗口采用了不同问题集，就不能计算一个前后提升。HTML 只能表达已经确认的事实，不能把缺失证据变成完整案例。

第二轮处理指标口径。为基线和结果建立同一张定义表，逐项核对指标名称、分母、去重方式、数据源、时间窗口和判读人。名称相同不代表口径相同，例如“提及率”可能按问题计，也可能按运行次数计；“访问量”可能是全部引荐，也可能只包含能识别来源参数的会话。口径无法对齐时，分别呈现两个截面，不计算增长比例。

第三轮才确定页面边界和证据位置。把一个案例的核心事实放进同一可独立理解的容器；每个结果旁放置口径、时间和对应证据；限制紧邻它所约束的结论。若多个结果共享一份报告，可以用脚注编号回链，不必重复链接，但不能只在页尾写“数据来源：内部统计”而不给出支撑范围。页面关系越清楚，编辑复核和后续更正也越容易。

最后检查渲染与降级。关闭脚本后确认核心文字仍存在，图片加载失败时确认结果句仍可读，移动端横向表格不能遮住限定条件，details 的摘要要明确告诉用户其中是方法或限制。再对照可见正文、Article JSON-LD、摘要和内容索引，避免页面结论已经更新，外部元数据仍传播旧标题或旧日期。

三个容易误判的反例

反例一是“有 JSON-LD，所以案例可读”。Article JSON-LD 可以说明标题、作者和日期，却不会自动建立业务基线与结果的关系。把客户名称、增长数字或评价只写进结构化数据，还会造成可见正文与标记不一致。结构化数据是文章元信息层，不是隐藏案例数据库。

反例二是“限制写在免责声明里，所以任何强结论都安全”。笼统的“实际效果因情况而异”没有说明哪些条件不同，也不能修复标题对普遍效果的暗示。限制应具体到样本、地区、平台、时间、无法控制的变量和不可见数据，并与对应结论放在一起。越强的结果主张，越需要清楚的适用边界。

反例三是“静态检查全部通过，所以内容真实”。本次规则只验证结构关系，不验证证据文件是否伪造、数字是否经过选择、客户是否授权或同期变量是否被遗漏。发布阻断应至少分成三层：事实真实性、披露与授权、页面一致性。静态检查只能覆盖第三层的一部分，不能替代前两层。

可直接引用的判断

案例页“有字段”只是第一层；对象、基线、动作、结果、时间、限制和证据能在同一案例内正确配对，才接近可核验。

图片可以证明某次画面曾经存在，却不能单独承担指标名称、分母、时间、证据与限制；关键结果仍应有可见文字版本。

整页找到所有信息，不代表事实关系正确；多案例页面最需要防止把不同对象的前后数据拼成一条增长叙事。

资料来源与下一步

截至 2026 年 9 月 30 日，WHATWG HTML 标准将 article 定义为文档中完整或可独立分发的组成，并提供 time 元素表达机器可读日期。本文把这些原生语义用于界定案例与时间，但不声称标准为 GEO 规定了唯一模板。

Google 的用户优先内容指南建议从 Who、How、Why 解释内容由谁创建、如何产生和为什么发布；结构化数据通用规范要求标记真实代表用户可见内容，并明确正确标记不保证特殊展示。本文据此强调公开方法与可见限制，不把标签通过写成平台效果。

美国 FTC 的推荐与用户评价指南指出，展示具体、非典型结果时，一句模糊的“结果因人而异”不足以改变读者对普遍效果的理解。本文只把它作为结果披露的参考，不替代中国或其他适用地区的法律意见。

下一步可以先按可验证命题审稿方法把案例结论拆成对象、范围、时间和证据，再用本文八项规则检查页面关系。若结果来自重复模型测试，还应单独保存问题集、入口、联网条件和运行次数，避免把一次页面结构检查误当成效果证明。