从页面和受支持的功能开始
不要一开始就添加所有听起来和你业务相关的 schema.org 类型。schema.org 是一个广泛的共享词汇表，而 Google 的 Search Gallery 文档列出了其支持的丰富结果功能及其所需属性。产品、活动或文章页在没有标记的情况下首先应该是有用的。
对于每个模板，确定其主要主题和可见的辅助事实，然后阅读 Google 针对该匹配功能的现行指南。Product、Recipe、Article、Breadcrumb、Event、Organization、LocalBusiness 和 Video 是示例。仅有词汇类型并不会自动生成 Google 功能；是否有资格取决于该功能所要求的属性。
将页面上主要可见的条目作为主要的标记对象。
使用 Google 的指南了解功能行为，并使用 schema.org 作为词汇参考。
以可见页面为事实来源
标记必须代表页面的主要内容，而不是隐藏、无关或误导性的材料。如果标记中写着某位表演者出现，页面就需要描述该表演者；如果标注了聚合评分，访客需要能看到该评分。这样可以防止模板渐渐变成误导性的摘要。
将页面文本和标记都构建自相同的经核准记录。产品 feed、事件系统或 CMS 可以同时提供两者，但在发布前需要审查这些值。不要把价格、库存状态、日期或评论总数复制到仅用于标记且可能被遗忘的字段。当可见信息发生变化时，应更新或移除相应标记。
确保名称、日期、价格、可用性和评分与页面保持一致。
切勿用猜测或过时的值填写属性。
将 JSON-LD 用作可维护的数据层
JSON-LD 是一种基于 JSON 的链数据格式，放置在 HTML 文档中。Google 支持 JSON-LD、Microdata 和 RDFa，并表示 JSON-LD 通常在大规模实施和维护时最容易。它与可见标记的分离可以使嵌套信息的建模更简单。
为每个实际项目使用一个清晰的数据对象，指定适当的 schema.org 类型和准确的支持属性。为每个模板记录功能指南、源字段、必需字段的行为以及负责人。也要检查渲染后的输出：插件或组件可能会添加重复或冲突的标记。
选择团队能够持续维护的格式。
当源数据缺失时，不要编造必需的值。
验证代码与可访问的页面
验证回答两个问题。首先，标记是否足够完整以支持某项功能？Rich Results Test 接受粘贴的代码或公开可访问的 URL，并报告可以由结构化数据生成的丰富结果。应为每个模板测试具有代表性的示例，而不是只测试那种异常完整的页面。
其次，Google 能否访问已发布的页面和资源？不要用 robots.txt、noindex 或访问控制阻止带标记的页面。检查相关的图片 URL。测试并非质量保证：可见内容或政策问题仍可能阻止展示。
先测试代码，然后再测试可公开访问的实时 URL。
当工具添加标记时，比对渲染页面、源代码和测试结果。
潜在展示并不等同于最终一定会展示。
像面向用户的模板变更一样发布它
结构化数据通常依赖于模板、feeds 和发布规则。一次重新设计、库存集成变更、本地化更新或组件移除都可能破坏大量项目。在用于规范标签、标题和图片的预发布审查中加入代表性的标记检查。记录模板、页面示例、源字段和发布日期。
当模板发出错误的标记时，修正共享的源或模板，验证一小部分样本，部署最小范围的安全变更，并重新测试受影响的 URL。如果修复产生意外行为，按照常规回滚流程处理。目标是基于证据修复降级的网页能力，而不是触发停机警报。
检查代表性页面集合，而不是单个 URL。
在后续修复前记录变更和标记组件。
维护、测量并接受展示的限制
部署后，使用相关的 Search Console 丰富结果报告调查问题并确认修复。报告是抽样而非完整清单，计数指的是条目而非页面。必要时检查具体 URL。
谨慎测量。Google 建议在 Search Console 中对稳定且有足够流量的页面，进行数月的前后对比。记录发布日期和其他页面变更。正确的标记只使页面获得资格；搜索展现由 Google 决定。
在 CMS、模板、feed、策略或内容模型更改后重新检查。
避免在其他主要页面变更存在差异的情况下进行比较。