实测 10 组问答页面 HTML：答案在正文、JSON-LD 与初始源码中是否一致？

先给结论：源码里出现过答案，不等于页面正文提供了答案

十组样本中，固定答案文字有九组出现在原始 HTML 字符串里，但只有四组进入本次规则定义的正文文本候选；三组包含 FAQPage JSON-LD，其中两组的结构化答案与预期答案一致，另一组与正文直接冲突。唯一完全不含答案文字的是“外部接口占位”样本：初始页面只有空容器和一个虚构接口地址，任何不执行请求的静态读取都得不到答案。

普通语义正文、闭合的原生 details、正文与 JSON-LD 一致、正文与 JSON-LD 冲突，这四组都能在不执行 JavaScript 的条件下提取到正文答案。这里的“能提取”只表示答案存在于未被测试规则排除的 HTML 正文节点，不表示它必然被任何搜索系统索引、被生成式模型采用，或在浏览器首屏默认展开。尤其 details 默认闭合时，用户需要展开才能看到完整答案，但答案仍在初始文档结构中。

hidden、内联 display:none、template、脚本注入和外部接口占位五组，没有通过正文候选检查；仅 JSON-LD 样本也没有可见正文答案。它们失败的原因不同：有的内容存在但被明确隐藏，有的处于惰性模板，有的只在脚本文本里，有的需要后续网络请求，还有的只向结构化数据声明答案。把这些差异都概括成“源码里有”会掩盖真正的内容交付方式。

最重要的实践判断是：面向用户的核心答案应先存在于清楚、可访问、可核验的正文中，交互和结构化数据再作为增强层。JSON-LD 不能替代正文，脚本字符串不能替代已经渲染的内容，隐藏容器也不能被当作公开回答。即便技术平台能够执行 JavaScript，减少不必要的依赖仍能降低失败面，并让内容检查更容易复现。

测试问题：我们究竟在比较哪三层内容

第一层是原始源码字面量。检查器只判断固定答案是否出现在服务器返回的 HTML 字符串中，不关心它位于段落、脚本、JSON-LD、模板还是隐藏元素。这个指标最宽松，只能证明字符出现过。九组通过并不意外，因为脚本注入样本把答案写在 JavaScript 字符串里，JSON-LD 样本也把答案放在脚本标签内。

第二层是正文文本候选。检查器解析 HTML 后，移除 script、style、template、带 hidden 属性的节点，以及内联样式明确写有 display:none 的节点，再检查剩余 body 文本是否包含完整答案。这个规则有意保持简单，目的是建立一条可以逐字复算的静态基线，而不是复制浏览器全部 CSS、无障碍树或某个搜索引擎的渲染器。

第三层是结构化答案。检查器只读取类型为 application/ld+json 的脚本，寻找 FAQPage 的 Question 与 acceptedAnswer，并把答案归一化后与固定正文答案比较。存在 JSON-LD 与内容一致是两项不同检查：脚本能被解析，不代表它描述的内容与用户看到的一样。

因此，本文不会使用模糊的“AI 可读”作为单一结果。初始源码、正文候选、结构化数据、浏览器默认可见状态、执行 JavaScript 后的 DOM、搜索平台渲染结果和模型最终回答是不同层级。此次只固定前三层中的可静态复算部分，其他层只能引用公开规范说明边界，不能由这十份离线样本直接证明。

样本与保密边界：十个页面只包含虚构产品和保留域名

测试日期为 2026 年 9 月 16 日。十组页面统一使用问题“标准版支持导出 PDF 吗？”和答案“标准版支持导出 PDF，但不包含批量导出。”产品、版本与功能均为中性虚构信息；外部接口样本使用不可解析的 invalid.example 地址，没有对任何网站发起请求。

样本不含真实品牌、客户、账号、订单、访问日志、仓库信息、发布记录或生产页面路径。我们也没有拿本站文章、内容索引、元数据或部署结果做公开样本。这样可以公开完整判读逻辑，同时避免结果反推出任何站点资产或维护方式。

每组只改变答案的承载方式，问题标题和答案文字保持不变。普通正文使用 section + h2 + p；折叠组使用闭合 details；隐藏组分别使用 hidden 和内联 display:none；模板组使用 template；三个结构化数据组分别是仅 JSON-LD、正文一致和正文冲突；脚本组把答案写入待注入字符串；接口组只保留空容器。

判读方法：五项布尔检查，没有模型主观评分

每组页面执行五项检查。其一，固定答案是否以完整字面量出现在初始 HTML；其二，排除脚本、样式、模板和明确隐藏节点后，正文文本是否仍含答案；其三，页面是否存在可解析的 FAQPage 答案；其四，JSON-LD 答案是否与固定答案逐字归一化一致；其五，在本次静态口径下，不执行 JavaScript 是否仍能取得正文答案。

空格和换行在比较前被归一化，但标点、否定词和功能范围不会被删除。因此，“标准版支持批量导出 PDF”与“标准版支持导出 PDF，但不包含批量导出”会被判断为冲突，而不是因为都包含“支持”和“PDF”就视为相同。对真实页面，语义等价可能需要人工审稿；本实验刻意采用完全相同的标准答案，避免把相似度算法混进结构测试。

检查器没有联网、没有执行脚本，也没有模拟具体模型。它使用确定性 HTML 解析与 JSON 读取，因此同样输入应得到同样结果。这个方法适合发布前拦截明显缺失和冲突，不适合推断 Google、百度、Bing 或任何聊天产品最后会不会抓取、索引、引用或展示。

结果总表：九组源码含答案，只有四组形成正文答案候选

汇总结果为：十组样本中九组在原始 HTML 字符串里出现固定答案，四组在正文候选里出现答案，三组含 FAQPage 答案，两组结构化答案与预期一致。这里不计算一个笼统“通过率”，因为没有 JSON-LD 的普通正文不应因为“不含 FAQPage”被判失败；相反，仅 JSON-LD 即使脚本内容正确，也不能替代用户可见的正文。

怎样复现这次结果：从固定输入到逐项输出

复现时先固定一个完整答案常量，再为十个样本分别生成最小 HTML 文档。除了答案承载方式，文档语言、标题、问题文本和答案标点保持一致。这样可以确保差异来自节点位置与交付方式，而不是同义改写、分词或标点归一化。外部接口样本故意不在源码中写答案，用来验证检查器不会从空容器推断不存在的内容。

解析顺序也会影响结果。检查器先保存原始字符串用于“源码含答案”判断，再生成一份用于正文检查的文档树。正文树依次删除 script、style、template、hidden 节点和内联 display:none 节点，最后合并 body 下剩余文本并移除空白。若先把整个页面转成纯文本，脚本和 JSON-LD 里的答案就会混入正文，九组都会看起来像“页面已经回答”，失去分层意义。

结构化数据单独从原始文档读取，而不是从删除脚本后的正文树读取。检查器只接受能解析为 JSON 的 FAQPage，并沿 mainEntity、acceptedAnswer、text 取出答案。若一个脚本语法错误、字段位置不同或不是 FAQPage，本次规则不会把它算作有效答案。真实发布工具需要按站点实际 schema 扩展，不能把这段最小路径当作通用 JSON-LD 解析器。

“正文与 JSON-LD 一致”采用去除空白后的精确比较。这个口径非常严格，却能可靠抓住示例中的否定词冲突。生产环境可以允许结构化答案是正文的摘要，但摘要规则必须保留数字、单位、适用对象、时间、否定和例外。任何自动相似度分数都不应直接覆盖这些高风险字段，否则一段看似九成相似的文本仍可能表达相反承诺。

结果输出保留每组五个布尔值，不把它们加权成综合分。普通正文没有 FAQPage 并不是缺陷，动态接口在必须实时查询的场景也不是错误；真正需要阻断发布的是预期状态与实际状态不一致。例如团队要求核心答案无需脚本即可读取，而检查结果却只有脚本字面量，这才构成可行动的失败。

为了避免把检查器自身当成真理，复现记录还应保存解析器版本、样本哈希、执行时间和规则说明。当规则新增对外部样式或 Shadow DOM 的支持时，应重新运行全部样本并标注口径变化。只有输入、规则和输出都可追溯，后续结果才具有可比性。

观察一：普通正文是最稳定的基线，但语义标签仍要服务阅读

普通语义正文组同时通过源码、正文候选与无脚本读取三项检查。问题由标题元素表达，答案位于紧随其后的段落中，不依赖交互、脚本或外部请求。这个结果并不证明 section、h2 和 p 会带来排名优势，只能说明内容关系在初始 HTML 中清楚存在。

实际页面不必把每个问题都做成独立 URL，也不必为了“机器喜欢”机械重复问句。短答案可以留在相关产品或政策页面，复杂问题再用独立文章完整回答。比标签名称更重要的是问题与答案相邻、标题层级合理、限定条件完整，并且链接到当前责任事实。

观察二：闭合 details 不等于答案从 HTML 消失

details 组在静态解析中保留了答案，因此正文候选检查通过。根据 MDN 对 details 元素的说明，没有 open 属性时，浏览器只显示 summary，用户展开后才看到内部内容。默认折叠改变的是交互呈现，并没有把内部节点移出初始文档。

这意味着折叠可以用于降低长问答的视觉负担，但不能成为隐藏关键限制的借口。若“不能批量导出”决定购买判断，问题摘要或首句仍应让用户知道答案有条件，而不是只显示“支持导出”再把否定条件藏在折叠末尾。移动端还要检查点击区域、键盘操作和展开后的阅读顺序。

观察三：hidden、display:none 与 template 都在源码，但用途不同

三组样本都通过“源码含答案”，却没有进入正文候选。hidden 明确表示元素当前不相关或不应呈现；内联 display:none 让元素不生成显示盒；template 则保存供脚本以后实例化的惰性片段。把它们混称为“隐藏文字”会丢失实现差异，但对本次初始正文检查而言，三者都不能证明用户已经获得答案。

MDN 的 hidden 属性文档提醒，隐藏内容不应被链接到其片段标识；而 template 文档说明其中内容不会立即渲染。若答案只有在满足用户状态后才相关，可以用隐藏或模板；若它是公开页面的核心回答，直接放进正常正文更稳妥。

测试只识别内联 display:none，没有计算外部样式表、媒体查询、透明度、视口外定位或类名级联。真实站点的可见性审计必须结合最终 CSS 与浏览器检查，不能拿这条简化规则覆盖全部前端状态。

观察四：仅 JSON-LD 的答案结构正确，内容策略仍然错误

“仅 JSON-LD”组可以解析出与预期一致的 acceptedAnswer，但正文只有“产品帮助”标题，用户看不到问题和答案。Google 的 结构化数据通用指南明确要求，不要标注读者不可见的内容，并指出结构化数据必须代表页面主要内容；正确标记也不保证任何搜索展示。

因此，JSON-LD 应描述可见页面，而不是补写正文没有提供的事实。若页面答案更新，结构化数据也要同步；若某种搜索功能已经停止展示，更不能继续把标记当作曝光承诺。结构化数据的价值在于表达一致语义，不是建立一套只有机器能看到的影子内容。

观察五：正文与 JSON-LD 冲突，比完全没有标记更难发现

冲突样本的正文写“不包含批量导出”，JSON-LD 却写“支持批量导出”。两边都能单独解析，只有做交叉比较才暴露问题。真实网站中，这类冲突常来自多个模板、不同负责人或只更新可见文案而忘记脚本。用户、搜索系统和下游工具可能取得不同版本，后续很难追溯谁才是当前事实。

自动检查可以先发现逐字差异，人工再判断是合理摘要还是事实冲突。数字、否定词、版本、地区、时间和资格尤其值得优先比对。不要用过度宽松的相似度掩盖“支持”与“不支持”这样的关键反转，也不要要求结构化答案必须复制整段长文；它至少要与正文的核心命题和限制保持一致。

观察六：脚本字符串存在，不等于初始正文存在

脚本注入组把完整答案写在 JavaScript 字符串里，所以“源码含答案”通过；解析器移除脚本后，正文只剩空容器，因此正文候选失败。Google 的 JavaScript SEO 基础文档说明，搜索处理通常经历抓取、渲染和索引，初始 HTML 不含实际内容时，需要执行 JavaScript 才能看到生成内容；预渲染或服务端输出仍是值得考虑的做法，因为并非所有机器人都能运行 JavaScript。

这不等于 JavaScript 内容一定不可索引。Google 明确会使用 Chromium 渲染，脚本执行后的正文可能被看到；但渲染需要资源、脚本可失败、接口可超时、权限和地区状态也可能改变结果。本文没有运行平台渲染，因此不能把“初始正文没有”扩大成“Google 永远看不到”。能确定的是：它比直接输出答案多了一层依赖。

观察七：外部接口占位把核心答案留在页面之外

外部接口组的初始 HTML 连答案字面量都没有，只有空容器和虚构数据地址。静态页面本身无法回答问题，后续结果完全取决于脚本是否发起请求、接口是否成功、响应是否允许访问以及渲染是否完成。用户网络较差、脚本被阻止或接口返回错误时，也可能只看到问题没有答案。

账户状态、实时库存和个性化订单必须动态获取，这种依赖有业务理由；但稳定的公开规则、功能边界和政策摘要通常可以先在 HTML 中提供，再用接口补充实时值。应把“必须动态”的数据与“只是开发方便所以动态”的内容分开治理。

从静态测试到真实发布：三层检查比一个“可读性分数”更有用

发布前第一层检查响应 HTML：标题、核心问题、直接答案和重要限定是否已经存在。第二层检查渲染后 DOM：脚本执行、组件展开、接口请求完成后，正文是否仍一致，是否出现空壳、重复或闪烁。第三层检查公开工具和平台：用浏览器、URL 检查或相应测试工具观察最终页面，但只报告工具能证明的结果。

团队可以把高风险事实设为固定断言。例如价格页必须出现币种与有效期，退款答案必须出现资格和时间窗口，产品功能必须同时说明版本与例外。断言失败就阻止发布，而不是依赖人工浏览几十个折叠项。结构化数据再与同一责任事实比较，减少双写漂移。

这套方法与品牌问答库建设方法直接衔接：前者定义问题、责任来源、限定条件和更新机制，本次测试则检查这些答案最终是否真的进入公开正文。内容正确但没有被交付，和页面能解析但事实错误，是两类不同故障，必须分别处理。

常见误判：不要从这十组样本推导平台效果

第一，不要把“源码含答案”当作“模型能回答”。脚本和 JSON-LD 也会让字符出现在源码中，但正文可能为空。第二，不要把“正文候选通过”当作“默认视觉可见”。闭合 details 的内容需要用户展开，本实验没有把折叠状态计入失败。第三，不要把“JSON-LD 一致”当作“会出现富媒体结果”；Google 不保证正确结构化数据一定展示，FAQ 富媒体结果也已停止显示。

第四，不要把“初始正文缺失”写成“所有搜索引擎都无法索引”。不同平台的渲染能力、资源限制和更新节奏不同，本实验没有联网验证。第五，不要把十个合成页面的数量包装成行业统计。它们是为了隔离变量的技术样本，不代表互联网上各种框架和组件的分布。

第六，不要为了静态检查而破坏必要交互。实时库存、登录信息和用户专属状态不能被硬编码成公开 HTML。正确目标是让稳定事实尽量直接，让动态事实有明确加载状态、失败处理和可核验来源，而不是要求所有内容永远静态。

测试边界与局限

本次检查没有执行 JavaScript，没有加载外部 CSS，没有模拟屏幕阅读器，也没有调用任何搜索或生成式模型。正文候选规则只排除了几类明确节点；它不是浏览器渲染引擎，更不是 Googlebot、百度蜘蛛或聊天产品的实现副本。结果只能说明给定静态规则下哪些文本存在、哪些被排除。

测试只比较一个固定中文答案，未覆盖多语言分词、富文本 HTML、数组式 JSON-LD、多个 FAQPage 节点、Microdata、RDFa、Shadow DOM、iframe、客户端路由或错误恢复。真实系统还应检查 HTTP 状态、canonical、robots、资源加载、移动端交互、无障碍名称和更新日期。

此外，“可见”本身有多种定义：在 DOM 中、在布局中、在首屏中、在展开后、对读屏软件可达、对登录用户可见，含义都不同。本文刻意使用“正文候选”而不是笼统的“可见内容”，避免把静态解析结果冒充完整用户体验结论。

本次结果也不能证明哪一种写法更容易被生成式系统引用。引用还取决于问题相关性、来源选择、页面质量、事实一致性、平台权限与回答上下文。若要研究模型表现，应在独立实验中固定问题集、平台版本、联网状态、地区和重复次数，并把“页面是否提供答案”与“模型是否采用答案”分别记录，不能混成一个结论，更不能承诺效果。

可直接引用的三个判断

答案出现在 HTML 字符串里，只能证明字符出现过；它是否进入正文、是否需要脚本、是否与结构化数据一致，必须分层检查。

JSON-LD 应描述用户能核验的页面事实，而不是补写一套正文没有的机器专用答案。

减少核心答案对脚本和接口的非必要依赖，不能保证引用，却能让内容交付更容易验证、复现和维护。

下一步：把静态断言接入问答内容的发布流程

先挑选价格、功能、退款、服务范围等高风险问题，为每个问题记录标准答案与关键限定。发布时检查响应 HTML 是否含有核心命题，再检查渲染后页面与 JSON-LD 是否一致；事实更新时让同一断言同步触发。这样可以把“页面看起来正常”升级为“关键答案确实存在且没有冲突”。

需要完善答案本身时，可参考价格、范围与效果限定条件指南；需要判断脚本、抓取与页面使用边界时，可继续核对 AI 搜索网页预览权限说明。技术检查只负责确认内容如何交付，事实是否正确、是否值得公开，仍需内容负责人做最后判断，并保存更新依据、责任人、复核日期和适用范围，避免日后无法追溯事实来源。