Schema 标记：不滥用结构化数据

有效 JSON-LD 可以通过富媒体结果测试，却仍不产生富媒体结果。这不是测试失败。结构化数据以机器可读形式描述内容；它不替代内容、不保证搜索功能，也不是排名开关。

常见错误是从“这个网站应添加哪种 schema”开始。更好的起点是：页面主要描述什么实体、访客实际能看到哪些事实，以及 Google 目前支持该内容的何种展示？

结构化数据、Schema.org 与 schema 标记

结构化数据是以机器可读格式组织的信息。Schema.org 提供实体类型和属性词汇表。Schema 标记是使用 JSON-LD、Microdata 或 RDFa 在页面上实施该词汇的方式。

Google 搜索对许多功能支持这三种格式，通常推荐 JSON-LD，因为它独立于展示 HTML 且更易维护。格式无法挽救不准确信息。格式完美的 JSON-LD Product 若声明页面没有的价格，仍违反一致性要求。

Schema 会改善排名吗？

不应将 schema 作为直接排名因素销售。结构化数据能帮助系统理解页面，并使其符合某些富媒体结果条件。更显眼展示可能在某些情况下影响点击率，但即使标记正确，Google 也不保证展示。

结果还取决于：

• 页面是否可抓取和索引。
• 内容是否符合搜索政策和功能专属政策。
• 数据是否准确、完整、及时且可见。
• 查询、设备、位置及 Google 展示选择。
• 该功能是否仍在当前文档中受支持。

富媒体结果的可用性会变化。应检查官方搜索功能库，而不是依赖旧文章或插件类型列表。

根据页面主要内容选择类型

不要给每页标记所有稍有关系的类型。识别主要实体：

• 编辑文章：Article、BlogPosting 或合适子类型。
• 可购买产品页：Product，带真实 offer、价格和库存状态。
• 实体企业地点：LocalBusiness 或准确子类型。
• 食谱：Recipe。
• 以视频为核心的页面：VideoObject。
• 组织资料：Organization。
• 层级路径：BreadcrumbList。

列出产品的分类，不会自动成为一个 Product。笔记本购买指南不应仅因讨论多个型号，就标识自身为产品。类型必须代表页面实际提供的内容。

从源数据开始，而非 JSON 字符串

可维护 schema 由与可见页面相同的来源生成：

如果模板显示数据库价格，而 JSON-LD 在 CMS 存一个手填数字，首次促销时它们就会分歧。结构化数据应是同一事实的另一种表达，而非第二个内容库。

最简 BlogPosting 示例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

这只演示结构。实施时，核实当前 Article 文档中的必需和建议属性。绝不要把示例日期、URL 或作者复制到生产环境。

@id 连接稳定实体

@id 不一定是访客单独打开的页面。它是图谱中的稳定标识，通常为带片段的绝对 URL：

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

文章的 publisher 与全站 Organization 引用同一个 @id 时，系统可将它们视为一个实体，而非名称相同的无关对象。

标识必须在渲染间稳定。不要每次请求生成随机 UUID。不要为组织及其网站等不同实体使用同一个 @id。

同页多个条目

页面可以包含多个有效结构化数据条目：

• WebPage 描述页面。
• BlogPosting 描述文章。
• BreadcrumbList 描述路径。
• Organization 或 Person 被引用为发布者或作者。
• VideoObject 描述主要嵌入视频。

对象可以独立，或在 @graph 中连接。准确关系、没有矛盾比布局更重要。视频只是无关广告时，为追求视频功能而添加 VideoObject 会歪曲页面。

无需在每个节点内重复庞大 Organization 对象。定义一个规范实体并引用其 @id，保持图谱清晰。

必需与建议属性

功能文档区分必需和建议属性。缺少必需数据会使条目不合格。建议字段可改善完整性，但前提是真实数据存在。

合理原则是更少、准确、完整的属性。不要添加：

• 没有真实评分的 aggregateRating。
• 为消除警告而编造的 priceValidUntil。
• 没有资料或编辑责任说明，却把作者写成“Admin”。
• 用通用标志作为无关内容的图片。
• 指向实体不拥有的资料的 sameAs 链接。

警告不是编造信息的命令。它说明缺少建议属性；产品团队必须判断是否有可信来源。

标记内容必须可见且一致

Google 要求结构化数据代表主要内容，禁止标记向读者隐藏的信息。风险例子包括：

• JSON-LD 写 $99，页面却写“联系我们”。
• Schema 报告 InStock，但购买被禁用。
• 标记声明五条五星评价，却没有显示。
• FAQ 答案仅存在于 JSON-LD。
• 过期职位仍保留未来的 validThrough。

“可见”不意味着每个技术属性都必须变成页面原文。URL、标识和图谱关系可以保留为元数据。价格、评分、活动详情、问题和作者等面向用户的声明，必须与体验对应。

Product schema 很快暴露数据问题

价格和库存经常变化。Product 标记应在与界面相同的请求或流水线中创建。规范以下内容：

• 货币使用合适 ISO 代码。
• 数据字段中使用不带货币符号的数字价格。
• 供货状态使用正确 schema.org URL。
• Offer 关联正确变体。
• 变体规范链接和产品 ID 保持一致。
• 评分仅汇总该产品的合法评价。

多变体产品应阅读当前产品变体文档，不要随意把颜色、价格和 SKU 合并进一个对象。如果页面不销售商品或没有真实 offer，不要为让错误消失而创建假 offer。

LocalBusiness 不能制造地点

每个地点需要真实名称、地址、电话、营业时间、服务区域和 URL。其落地页必须提供相应价值。创建 200 个近乎相同的城市页面并添加 LocalBusiness，不会创造 200 个办事处。

Schema 事实应与联系页、企业资料及内部管理数据一致。节假日营业时间变化时，从同一来源更新界面和 JSON-LD。

评价和评分是高风险滥用区域

不要标记：

• 企业为自己撰写的评价。
• 从不同产品复制的评分。
• 没有源评价的汇总分数。
• 把全公司推荐语当作每项服务的评分。
• 仅在脚本中存在的隐藏数据。

违反质量指南可能失去富媒体结果资格，并可能导致结构化数据人工处置。这不一定抹去全部网页排名，但风险不值得用一排装饰星星交换。

FAQ schema 不是每篇文章的默认选项

可见 FAQ 仍能帮助读者，但不应只因插件提供复选框就启用标记。资格和可用性会随时间、行业和政策变化。大规模推出前：

1. 确认类型仍在搜索功能库中，且适用于网站。
2. 完整阅读功能专属指南。
3. 确保每个问题和答案都在页面出现。
4. 避免在数千 URL 重复相同 FAQ。
5. 衡量结果，而非把“有效”当成功。

Schema 不应主导编辑结构。读者需要 FAQ 时才写，再判断是否有合适的受支持标记。

分三层测试

第 1 层：JSON 和 schema 语法

解析器必须能读取 JSON-LD：逗号、括号、转义和数据类型都须正确。产品名称里一个未转义引号，就能让整个数据块失效。

第 2 层：富媒体搜索结果测试

此工具检查 Google 支持的类型，并报告错误和警告。解决错误；根据可获得的真实数据评估警告。“有效”表示测试时技术上符合条件，并不保证出现。

第 3 层：生产页面与 Search Console

通过 URL 检查工具查看已部署 URL，检查实际 HTML，并监控富媒体结果报告。预发布测试无法暴露每个缓存、语言、功能开关、同意机制或实时产品数据故障。

运行 SEO 检查器抽样页面信号，使用免费 SEO 审核查找异常元数据或规范链接模式，再考虑是否应归咎于 schema。

测试不完整和恶意数据

模板在完整示例产品上常显得完美，却在边界失效：

• 没有图片。
• 零价格或未公布价格。
• 两种货币。
• 名称包含引号和换行。
• 缺少作者。
• 迁移后修改日期早于发布。
• 评价数为零。
• 产品退市。
• 英文页面收到非预期越南语组织数据。

为这些情况创建测试样例。断言 JSON 可解析、绝对 URL 使用正确语言、必需属性仅在符合条件时出现，以及核心数据不可用时省略对象。

常见实施故障

两个插件生成同一实体

主题输出 Article，SEO 插件输出 BlogPosting，评价插件又创建不同 ID 的 Product。结果包含相互矛盾的作者、图片或评分。盘点每个 application/ld+json 脚本，为每个实体指定唯一负责人。

Schema 包含预发布 URL

环境变量或缓存可能让 @id、图片和规范 URL 指向测试域名。在生产 HTML 中搜索所有意外主机名。

语言混杂

英文页面可能有英文标题，却有越南语面包屑和组织名称。定义哪些字段共享、哪些本地化；使用 inLanguage 时进行验证。

JavaScript 过晚注入标记

Google 可以渲染 JavaScript，但依赖失败或被屏蔽的客户端请求，会让数据不稳定。服务器已有事实时，在初始 HTML 渲染 JSON-LD 通常更简单可靠。

用 schema 掩盖薄弱内容

详细标记无法弥补空产品页或复制文章。结构化数据描述价值，不会创造页面没有的价值。

部署后监控

把 schema 当作发布契约：

• 用测试样例对生成器做单元测试。
• 验证主要模板或保存快照。
• 抓取预发布和生产，统计条目与错误。
• 标记覆盖突然下降时告警。
• 监控增强功能报告和人工处置。
• 记录发布日期，以比较 CTR、展示和错误。

Google 改变某类富媒体结果支持时，无需恐慌并删除所有有用 schema.org 声明。区分帮助阐明内容的实体标记，与仅为一个搜索功能维护的标记。将维护成本与实际收益比较。

发布前检查清单

• 类型是否代表主要内容？
• 当前 Google 文档是否支持该功能？
• 必需属性是否完整且来自真实数据？
• 重要声明是否对访客可见？
• URL、图片和 @id 值是否绝对、可抓取且域名正确？
• 规范链接与 mainEntityOfPage 是否指向同一战略 URL？
• 日期、价格、库存和评分是否自动更新？
• 其他插件是否创建重复对象？
• 是否通过富媒体搜索结果测试？
• 缺失数据能否使 JSON 失效？
• 是否检查生产环境和 Search Console？

结论

好的 schema 标记，是对可见内容诚实、结构化的描述。它从数据模型和来源归属开始，而非复制的 JSON-LD 片段。选择准确类型，使用稳定标识，提供真实完整属性，测试边界情况，并在发布后监控。

不要编造评分来消除警告，不要标记隐藏声明，也不要承诺一定出现富媒体结果。当界面和结构化数据由同一事实生成，schema 就成为可维护工程，而非脆弱装饰层。

参考资料：Google 搜索中心结构化数据介绍、结构化数据通用指南和 Schema.org 文档。