结构化数据是描述页面和实体的机器可读标记。Schema.org 提供 Vocabulary；Google 当前的 搜索 文件决定某个类型是否具备 Google Rich Result 资格。准确 Markup 可以提升清晰度和资格，但不保证排名或展示。
只标记页面上看得到、仍然有效而且可验证的事实，并使用足够完成目的的最小模型。不要因为 Generator 有某个字段，就创造 Review、Rating、Price、Author、Location、Product 或关系。
分清五个经常混用的名词
| 名词 | 意思 | 不代表 |
|---|---|---|
| Structured Data | 使用标准格式表达的机器可读资料 | 某一种 Vocabulary 或搜索外观 |
| Schema.org | 共用的 Type 与 Property Vocabulary | 所有类型都受 Google 支持 |
| Schema Markup | 在网页使用该 Vocabulary，常见格式是 JSON-LD | 保证 Rich Result 或排名 |
| Rich Result | Google 为当前支持功能提供的增强结果 | 所有 SERP Feature 或 Knowledge Panel |
| 搜索 Appearance | Google 呈现或报告某种结果的方式 | 永久不变；功能可以停止或调整 |
结构化数据能做什么，也不能保证什么
Google 会把结构化数据当作理解页面的明确线索，并用它判断页面是否具备当前支持功能的资格。不过 Google 仍可选择普通文字结果；外观也可能因为 Query、地区、Device 和 搜索 Product 而不同。
Google 没有承诺 Markup 本身会提高排名、点击、信任或 AI Answer 引用。当前 AI 优化指南仍然指向正常 SEO 基础，而不是某个特殊的 AI Schema。
| 可以帮助 | 不能保证 |
|---|---|
| 说明页面、实体与关系 | 没有证据的声明会被相信 |
| 取得当前支持功能的资格 | 功能一定展示 |
| 让机器可读事实保持一致 | 更高自然排名 |
| 表达产品、文章或活动属性 | 流量、销售或 AI 引用 |
| 通过 Enhancement Report 监控 | Google 会处理不支持的 Schema.org 类型 |
选择类型前，先建立资料来源层级
判断 Google 搜索 行为时，以最新 Google 搜索 Central 文件和 搜索 Gallery 为准。Schema.org 用来确认 Vocabulary；Generator、Plugin 与第三方文章只是实施辅助，不是最终资格规则。
Rich Result 支持会改变。即使第三方文章刚发布，也可能在 Google 关闭某个功能后变得过时。
| 要判断的事 | 主要资料来源 | 原因 |
|---|---|---|
| Google 现在是否支持这种外观？ | Google 搜索 Gallery 与对应功能指南 | 说明当前资格与政策 |
| Type/Property 是否属于 Schema.org？ | Schema.org 定义与 Validator | 确认 Vocabulary 合法性 |
| Google 要求或建议哪些字段？ | 当前 Google 功能文件 | Google 资格不等于 Schema.org 有效 |
| CMS 如何产生 Markup？ | CMS/Plugin 文件与实际 Source | 属于实施行为 |
| Production 是否仍然准确？ | 可见页面、JSON-LD、Log 与 Search Console | Live Evidence 比设定画面可靠 |
功能会改变：2026 年 FAQ 案例
Google 已在 2026 年 5 月 7 日停止显示 FAQ Rich Result，并于 6 月移除对应文件。FAQ 内容仍然可以帮助用户，FAQPage 也仍是 Schema.org 类型，但它已经不再符合 Google FAQ Rich Result 资格。
其他功能停止或改变时也用同一原则：保留有用的可见内容，移除过时的展示承诺和监控，再判断 Markup 是否仍有明确的非 Google 使用者。不要因为装饰消失，就删除真正有用的 FAQ。
- 先查看 Google 搜索 文件更新记录。
- 确认当前 搜索 Gallery 与功能指南。
- 把内容价值与 Rich Result 资格分开。
- 移除已停止的 Report 与展示承诺。
- 只有知道谁会使用时，才保留非 Google Markup。
- 一起更新 Template、内部文件和 QA Case。
- 在成效报告记录变更日期。
根据页面的主要用途选择类型
从用户真正看到的页面开始。选择一个具体、真实的主要类型；只有关系清楚时才增加次要实体。Node 更多不代表 SEO 更好。
| 页面用途 | 实用模型 | 重要限制 |
|---|---|---|
| 个人品牌 首页/关于我们 | Person；真实公司为主体时才用 Organization | 保持一个稳定身份，不要创造两个无关 Publisher |
| 公司 首页/关于我们 | Organization 或具体 Subtype | Google 建议放 首页 或 关于我们，不是每页重复 |
| 博客/新闻文章 | 篇文章、博客Posting 或 News篇文章 | 真实作者、日期、Headline 与代表图片 |
| 网站层级 | BreadcrumbList | 表达正常用户路径和最终 URL |
| 实体地点 | 具体 LocalBusiness Subtype | Address、Hours 与 Phone 必须可见准确 |
| 销售产品 | Product 加 Offer/Merchant Property | 单一产品或 Variant，价格与库存要同步 |
| Software Landing Page | 符合要求时用 SoftwareApplication | 不要把一个 App 的 Rating 复用给其他产品 |
| Service Page | Service 可以说明页面含义 | Google 没有承诺专属 Service Rich Result |
| FAQ 内容 | 先提供可见 HTML；有明确用途才选择 Schema.org Markup | 2026 年 5 月起没有 Google FAQ Rich Result |
选择最容易保持准确的格式
Google 支持 JSON-LD、Microdata 与 RDFa，并通常建议 JSON-LD，因为嵌套资料较清楚，也更适合 Template 维护。不过真正合适的格式，是系统可以准确生成并持续测试的格式。
JSON-LD 可以放在 <head> 或 <body>。它与可见 HTML 分开很方便，却也更容易在没有共同 Source of Truth 时悄悄失去同步。
| 格式 | 优点 | 运营风险 |
|---|---|---|
| JSON-LD | 易读、可嵌套、适合 Template | 可能与可见内容静默漂移 |
| Microdata | Property 靠近可见 Element | 复杂 Markup 较难重构和审核 |
| RDFa | 灵活的 Linked-data Attribute | 多数交付团队较不熟悉 |
| JavaScript 注入 JSON-LD | 可以使用动态 Route Data | 依赖 Rendering，快速变化事实可能延迟 |
建立一个连贯的实体模型
使用 Absolute Public URL。稳定 @id 可作为重复实体的实用 Identifier，但不能取代真实页面、品牌、作者或公司。@graph 只是整理方式，不是 SEO 要求。
文章连接真实 Author 与 Publisher，Breadcrumb 连接最终 Route URL，Product 连接真实 Offer。sameAs 只使用真正代表同一个人或机构的官方 Profile。
- 每个公开实体只有一个首选 HTTPS URL。
- Name、URL 与 Identifier 在 Template 之间稳定。
- 使用当前、可抓取的 Logo 或代表图片。
- 有 Author Profile 时连接真实 URL。
- sameAs 只放已验证的官方 Profile。
- 联系 与 Address 只在准确、相关时使用。
- Breadcrumb 与实体 URL 符合 Canonical Route。
- Production 不出现 Test、Staging 或 Placeholder Identifier。
为每个字段指定 Source of Truth
每个 Property 都要有负责人和上游字段。尽量从同一份记录生成可见内容和 JSON-LD；如果一个值无法稳定收集，就省略，不要猜测。
Ecommerce 的 Price 与 Availability 变化快，需要额外控制。Google 警告，动态产生 Product Markup 可能让 Shopping Crawl 较不频繁也较不稳定；价格与库存流程可以优先考虑 Initial HTML 和 Merchant Center Feed。
| Property | Source of Truth | 上线规则 |
|---|---|---|
| headline/name | 已发布页面记录 | 符合页面可见主题 |
| author | 已验证 Author Profile | 每位可见作者分别列出 |
| datePublished | 首次发布记录 | 外观修改不能重设 |
| dateModified | 有意义的编辑更新 | 使用 ISO 8601，需要时可见 |
| image/logo | 已批准 Media Library | 相关、可抓取、仍有效 |
| price/availability | Commerce System | 页面、JSON-LD 和 Feed 相同 |
| rating/reviewCount | 已验证 User Review System | 不能手填、捏造或选择性计算 |
| URL/Canonical/Breadcrumb | Routing Configuration | 只使用最终 Production URL |
按 Template 映射，避免全站 Boilerplate
| Template | 核心关系 | QA Sample |
|---|---|---|
| 篇文章 | 篇文章 → Author Person/Organization → Publisher | Headline、所有作者、真实日期、图片 |
| 首页page/关于我们 | WebPage → 主要 Person 或 Organization | Name、URL、Logo、sameAs、联系 |
| Breadcrumb | BreadcrumbList → 有顺序的 ListItem | 可见层级与可访问 URL |
| Location | LocalBusiness Subtype → Address/Hours | 一个真实地点与准确营业状态 |
| Product | Product → 符合资格时连接 Offer/Review/Rating | 单一 Product/Variant 与当前商业事实 |
| Profile Page | ProfilePage → mainEntity Person/Organization | 由网站拥有并且身份可见 |
| Software App | SoftwareApplication → OS/Category/Offer 或 Rating | 符合要求的真实 App 资料 |
| Service | WebPage → 描述性 Service Entity | 不承诺 Service Rich Result |
验证是多层流程，不是一个绿色勾
Schema.org Validator 检查 Vocabulary 与 Extraction；Google Rich Results Test 检查当前支持功能的技术资格；URL Inspection 检查 Google Live Render。没有一个工具可以确认商业事实、Ownership，或保证结果一定展示。
先修复会阻止资格的 Critical Error。对于 Warning，回到当前功能文件和真实资料判断；不要为了清除 Warning 而捏造 推荐阅读 Field。
| 层级 | 工具或证据 | 回答的问题 | 不能证明 |
|---|---|---|---|
| JSON Syntax | Parser 或 Build Test | JSON 能否解析？ | Schema Vocabulary |
| Vocabulary | Schema.org Validator | Type/Property 是否被识别？ | Google Rich Result 支持 |
| Google Eligibility | Rich Results Test | 支持功能的技术字段是否完整？ | 展示或事实真实性 |
| Rendered Delivery | URL Inspection 与 Rendered HTML | Google 能否取得最终 Markup？ | 索引或排名 |
| Content Parity | 可见页面对照 JSON-LD | 声明是否一致？ | 单靠它无法证明所有政策合规 |
| Production Health | Enhancement Report 与抽样 URL | Template 是否持续有效？ | 商业结果 |
质量政策比语法有效更重要
Google 要求 Markup 可见、最新、代表页面主要内容、在需要时属于原创，而且不能误导。技术上有效的 Block 仍可能失去 Rich Result 资格，甚至收到 Structured Data Manual Action。
Google 说明这类 Manual Action 会取消 Rich Result 资格，而不是改变普通网页排名。应修复不准确或欺骗性的根本问题，并在适用时通过 Search Console Manual Actions 流程处理。
| 风险 | 失败原因 | 正确处理 |
|---|---|---|
| 隐藏或无关的 Markup 内容 | 不代表页面可见主题 | 显示事实或移除 Property |
| 虚假 Product、Author 或 Location | 身份误导 | 只使用已验证真实实体 |
| 过时 Event、Price 或 Availability | 时效资料错误 | 立即同步或移除 |
| 空白 Holder Page 的 Markup | 页面没有有用内容 | 把 Markup 放在它实际描述的页面 |
| 只标记部分可见评价 | 选择性且误导 | 一致标记完整可见评价集 |
| 错误 Primary Type | 页面重点不清楚 | 选择最具体的真实类型 |
评价与评分需要独立证据门槛
有 Testimonial 不代表可以加入五星。Review 与 aggregateRating 必须符合当前支持类型规则，清楚说明受评价对象，来自真实用户，并与页面上看得到的评价资料一致。
对于 LocalBusiness 与 Organization，如果受评价实体在自己控制的网站展示评价，即使通过第三方 Widget，Google 也不会显示 Self-serving Review Snippet。虚假评价被禁止；因利益或奖励取得的评价必须显著披露。
- 确认受评价 Type 目前仍符合 Google 资格。
- 清楚而且只定义一次受评价对象。
- 验证每个 Review 与 Rating 来源。
- 在页面显示被 Markup 代表的评价资料。
- Average 与 Count 来自同一完整 Dataset。
- 任何奖励或利益关系都显著披露。
- 排除员工、测试与虚构顾客身份。
- 指定负责更正与删除的 Owner。
谨慎使用 JavaScript 与 GTM
Google 可以处理由 JavaScript 或 Google Tag Manager 注入、并出现在 Rendered DOM 的 JSON-LD。这不代表 Client Injection 对核心身份或快速变化资料一定最安全。
Google 建议让 GTM Variable 从页面读取资料，而不是在 Container 重复维护。Server 或 Build Output 通常更容易与内容一起 Version；实施动态 Markup 前可参考JavaScript SEO 指南。
| 方法 | 适合情况 | 主要控制 |
|---|---|---|
| Server/Build Generation | 身份、篇文章、稳定 Route Data | 页面和 JSON-LD 使用同一记录 |
| CMS/Plugin | 插件明确支持的 Template | 关闭重复输出并检查 Source |
| GTM Injection | 受控过渡方案 | Page-derived Variable、版本与 Render Test |
| Custom Client JavaScript | 真正的动态资料 | Rendered Test 与 API Fallback |
统一多语言、重复页与 Canonical
每个语言 URL 的 Markup 都要符合当前可见翻译、该语言 Canonical 与 Breadcrumb。Person 或 Organization 身份可以保持稳定，而 Name、Description 与 Page URL 按语言本地化。
Google 建议等效 Duplicate Page 也提供同样结构化数据，不是只放在 Canonical Page。结合Canonical 与跳转指南统一 Hreflang、Sitemap 与 Internal Link。
- 本地化 Headline、Description 与 Breadcrumb。
- 每个语言 URL 的 Canonical 自洽。
- Hreflang 指向真正等效页面。
- Person/Organization Identity 保持稳定。
- Price、Currency、Date 与 Availability 符合市场。
- 被标记图片能够抓取。
- Production 没有未翻译 Placeholder。
按 Template 分阶段上线
把 Structured Data 当作 Production Code。先选择一个仍获支持、具业务价值的 Template 和一小组代表 URL；不要把未经审核的 Generator 一次部署到数千页。
- 定义目的和 Google 当前支持功能。
- 阅读该功能文件与 General Guidelines。
- 盘点可见事实、资料来源和 Owner。
- 选择最小而准确的模型与格式。
- 把每个 Property 映射到 Source Field。
- 从共同资料生成页面与 JSON-LD。
- 验证 Syntax 与 Schema.org Vocabulary。
- 运行 Rich Results Test。
- 比较可见内容、Raw HTML 与 Rendered Production Output。
- 部署小样本并检查 Live URL。
- 样本通过后才扩大到全部 Template。
- 监控 Enhancement、Manual Actions 与功能变化。
诚实衡量资格与搜索影响
把 Structured Data 当作上线与资格变更，不要称为保证排名的实验。Search Console 可以显示 Enhancement 有效性与部分 搜索 Appearance Filter，但可用 Report 会因类型而异。
记录部署日期，比较符合资格的 Page/Query Cohort，并观察 Impression、Click、CTR 与有效询盘。结果外观可能变化而排名不变；Seasonality、Query Mix 与其他 Release 都会限制因果结论。
| Metric | 回答的问题 | 限制 |
|---|---|---|
| Valid/Invalid Item | Template 是否产生合资格 Markup？ | 有效不等于展示 |
| 已索引的合资格 URL | Google 是否处理目标页面？ | 有效页面不一定索引 |
| 搜索 Appearance Impression | 支持外观是否曾展示？ | Filter 依赖具体功能 |
| Page/Query CTR | 外观与相关性是否改善点击？ | 排名和 Query Mix 也可能改变 |
| Lead/Revenue | 这批 Traffic 是否产生价值？ | 取决于 Analytics 质量 |
| 人工抽样 | 可见事实是否仍符合 Markup？ | 抽样可能漏掉 Edge Case |
维护功能与 Template Registry
Rich Result 支持、Property 规则和 Search Console Report 都会改变。为每个自动生成的类型指定 Owner 与 Last-reviewed Date，并留意 Google 搜索 文件更新。
把结构化数据检查加入SEO 审核流程。CMS Migration、Redesign、Routing、Author/Logo、Review Provider、Commerce System 或语言改变后，都要重新验证。
| Registry 字段 | 例子 |
|---|---|
| Template | 博客 篇文章 |
| Primary Type | 博客Posting |
| Google Feature/Status | 篇文章——在审核日期仍获支持 |
| Generator/Owner | Build Module——Engineering |
| Source Fields | Title、Author、Dates、Image、Publisher |
| Sample URLs | 新旧、翻译版与 Edge Case |
| Last Reviewed | 日期 + Google 文件链接 |
| Monitoring | Build Test、RRT Sample、Search Console |
常见结构化数据迷思
- “Schema.org 验证通过就保证 Google Rich Result。”
- “Schema Markup 是直接排名因素。”
- “每页都应该加入所有可能类型。”
- “2026 年 FAQ Markup 仍会产生 Google FAQ Result。”
- “有 Testimonial 就能加入五星 Organization Markup。”
- “Rich Results Test 绿色代表每项声明都是真的。”
- “即使没有资料，也要填满 推荐阅读 Field。”
- “Plugin 设定画面代表 Production Output 正确。”
- “JavaScript 注入永远等同 Initial HTML。”
- “Schema 本身是进入 AI Answer 的特殊捷径。”
常见问题
Structured Data 和 Schema Markup 有什么不同？
Structured Data 是更广的概念；Schema Markup 通常指网页使用 Schema.org Vocabulary，常见格式是 JSON-LD。
结构化数据会提高 Google 排名吗？
Google 可以用它理解内容并启用支持的外观，但没有承诺单靠 Markup 提高排名。
Schema 验证通过就保证 Rich Result 吗？
不会。类型必须是 Google 当前支持的功能、符合技术与质量规则，而且 Google 仍会决定某次搜索是否适合展示。
每个页面都需要 JSON-LD 吗？
只有当准确 Markup 有明确用途、可靠 Source of Truth 与负责人时才加入。没有稳定资料的更多 Node 只会增加风险。
FAQPage 还会产生 Google FAQ Rich Result 吗？
不会。Google 在 2026 年 5 月 7 日停止展示 FAQ Rich Result，并于 6 月移除文件。FAQ 可继续服务用户，但不要承诺已经停止的装饰。
个人品牌可以同时使用 Person 和 Organization 吗？
应表达真实主要实体与关系。真实公司可以发布个人 Profile；个人经营者不应只为了增加 Node 而创造一个不存在的机构。
可以为 Testimonial 加五星 Markup 吗？
不能自动这样做。Rating 必须对应合资格类型、来自真实资料并在页面显示；Self-serving LocalBusiness 或 Organization Review Snippet 不符合资格。
Rich Results Test 的 Warning 是失败吗？
Critical Error 可能阻止资格。Warning 常指 推荐阅读 Field；只有真实存在且有帮助时才补充。
GTM 可以生成 JSON-LD 吗？
可以，但应从页面读取 Value、避免重复 Markup，并测试 Rendered Production URL。稳定的 Server 或 Build Output 通常更容易治理。
多久审核一次结构化数据？
Template、URL、内容字段、Commerce、Review Source、语言或 Google 功能改变后都要复测，并定期抽查代表 URL。
官方参考资料
- Google 搜索 Central: structured data introduction
- Google 搜索 Central: general structured data guidelines
- Google 搜索 Central: supported structured data gallery
- Google 搜索 Central: documentation updates
- Google 搜索 Central: 篇文章 structured data
- Google 搜索 Central: Organization structured data
- Google 搜索 Central: Breadcrumb structured data
- Google 搜索 Central: Product structured data
- Google 搜索 Central: LocalBusiness structured data
- Google 搜索 Central: Review snippet guidelines
- Google 搜索 Central: ProfilePage structured data
- Google 搜索 Central: JavaScript-generated structured data
- Google 搜索 Central: AI features optimization guide
- Schema.org: Markup Validator
- Ahrefs: Schema markup implementation guide
- Semrush: Schema markup implementation guide
分享 Page Template、资料来源与现有 JSON-LD。Jack 可以映射准确实体、移除不受支持或高风险的声明，并建立上线与监控清单。
Google 排名如何演变：从 PageRank 到现代搜索系统2026年9月2日
Google AI 内容与 SEO：什么被允许、什么是垃圾内容，以及怎样安全发布2026年9月2日
Google Florida Update 2003：事实、理论与 SEO 教训2026年9月2日