结构化数据：让 AI 一次读懂的页面写法

同一句话在不同语境里含义不同：「我们成立于 2019 年」里的「我们」是谁，机器并不知道。结构化数据用 schema.org 的词汇把这层关系写明：这是哪个组织、哪个页面、哪个产品，彼此怎么关联。

这也是它最容易被误解的地方。它不是给 AI 的加分项，也不存在所谓 AI 专用 schema。Google 的官方指南明确说明，生成式搜索功能没有必需的特殊结构化数据，也没有统一的最佳切块长度。

选类型的原则是页面本身是什么，就标什么。为了看起来更丰富而硬套类型，反而会制造矛盾，让系统更难判断哪个描述才是准的，也让维护成本白白增加。

下面四种是官网与文档站最常见的组合。它们的共同点是描述客观事实，而不是表达态度，因此更容易与页面正文对上，也更容易在信息变化时同步更新。类型选得越贴近页面本身，维护成本越低。

推荐用 JSON-LD，写在 script 标签里，与正文分离，便于维护。字段值必须与页面上能看到的文字一致：页面上写 299 元，结构化数据里就不能是 199；页面上没有的承诺，也不要塞进去。

同一实体在站内多处出现时，用 sameAs 指向可核验的公开档案，帮助系统把它们认成同一个对象。反过来，如果不同页面给出互相冲突的名称或价格，标注得越细，矛盾也越明显，反而不如不标。

最常见的不是括号写错，而是内容不一致。校验工具只能告诉你字段是否合法，不能告诉你这些字段是否属实。一个语法完全正确的标注，照样可以把过期价格写得很规范，而系统会把它当成最新事实。

所以验收要分两步：先跑校验工具，再人工逐字段比对页面文字与事实来源。后者更慢，但它才是决定这段标注会不会误导别人的那一步。把这两步写进发布清单，比事后回忆哪些字段核对过要可靠得多。

改完先用校验工具过一遍语法，再人工比对字段与页面文字。最后确认这些信息在原始 HTML 里就能读到，而不是等脚本执行后才注入，否则抓取阶段可能根本看不到这段标注。

如果站点同时有可见面包屑、结构化面包屑和 sitemap 层级，三者应当指向同一条路径。三处不一致时，优先修正可见的那一处，再让标注跟着它走。读者看到的是可见层级，标注只是对它的复述，不能反过来定义它。