Schema 结构化数据
Schema 结构化数据是按 Schema.org 词表把页面事实标注成机器可读格式（通常是 JSON-LD）的做法，让程序不必从正文里猜实体和关系。
Schema 结构化数据是按 Schema.org 词表把页面事实标注成机器可读格式（通常是 JSON-LD）的做法，让程序不必从正文里猜实体和关系。
同一份信息在页面上有两种存在形式：给人看的正文，和嵌在 <script type="application/ld+json"> 里给机器看的字段。后者消除了解析歧义——“上海”是地址还是文章主题，正文里要靠语境判断，字段里 addressLocality: "上海" 没有第二种读法。
与实体识别相关的常用类型
- Organization：主体本身。
legalName、foundingDate、taxID、address这几个字段是品牌实体唯一性的关键，sameAs把多个域名和外部主页绑成同一个实体。 - FAQPage：问答对。适合承载消歧类问题。
- DefinedTerm：术语定义。
alternateName可以登记别名，让不同叫法指向同一个概念。 - BreadcrumbList：层级位置。
- Article / WebPage：内容与发布者归属。
常见失效原因
结构化数据最常见的问题不是没写，而是写了但整块失效：
- 引号未转义。答案文本里出现英文双引号直接破坏 JSON 结构，整个 JSON-LD 块被丢弃，而页面看上去完全正常。
- 多块冲突。同一实体在不同脚本块里给出不同的名称或地址。
- 与正文不符。标注里写的事实页面上找不到。
根治办法是不手写 JSON——用程序把数据序列化成 JSON-LD，转义交给序列化器处理；同一实体使用稳定的 @id，不同页面的声明保持一致。
与 llms.txt 的分工
Schema 面向抓取网页的爬虫，llms.txt 面向直接读文本的模型客户端。两者不互相替代，前者标注结构，后者提供导航。
发布后怎样检查
先用 JSON 解析检查语法，再逐项核对字段与页面正文是否一致。产品图是否能访问、服务名称是否正确、价格是否仍有效，都需要检查真实内容。JSON 能解析不代表字段满足某种搜索展示功能的要求。
随后使用目标搜索引擎提供的检测工具核对它支持的类型。Schema.org 中存在的类型，不一定对应 Google 富媒体搜索结果；即便检测通过，也不保证获得特殊展示。尤其不要添加不存在的评分、评价或客户业绩来凑齐字段。
公司官网的一个例子
公司介绍页可以描述 Organization，服务页描述 Service，文章页描述 Article，并通过稳定的 @id 关联发布者。同一实体可以在不同页面重复描述，但名称、网址和其他事实需要一致；不必把不同业务页都声明成同一篇文章。
如果产品入口或服务范围更新，应同时检查正文、FAQ 和 JSON-LD，避免机器读到旧事实。内部验收可以保存一份字段清单，记录资料来源与核对日期，而不只保留“测试通过”的截图。
参考：Google 结构化数据通用规范。需要结合官网检查实体和内容一致性，可查看 GEO 诊断。