给页面贴上机器读得懂的标签

把「这是什么」写成标准格式

结构化数据（Structured Data）是一种描述页面内容的标准格式。它用一套公共词汇表——schema.org——把信息分类标注：这是一个 Recipe（菜谱）、cookTime（烹饪时间）是 30 分钟；若有真实的汇总评分，则用 aggregateRating 对象中的 ratingValue 等属性描述。

好处是给引擎提供明确的内容线索，减少理解歧义。它是对真实内容的描述，不会让机器无条件相信你填入的事实。

推荐用 JSON-LD

结构化数据有三种写法：JSON-LD、Microdata、RDFa。Google 推荐 JSON-LD——它是一段独立的脚本，和页面正文分开，最好加、也最好维护。长这样：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "手冲咖啡入门",
  "image": "https://example.com/images/pour-over.jpg",
  "totalTime": "PT5M",
  "recipeIngredient": ["咖啡豆 15g", "热水 225ml"],
  "recipeInstructions": [
    {"@type": "HowToStep", "text": "将研磨好的咖啡放入已润湿的滤纸。"},
    {"@type": "HowToStep", "text": "按页面说明分段注入 225ml 热水，等待过滤完成。"}
  ]
}
</script>

这段代码用户看不到，是专门给机器读的。它必须和页面上真实可见的内容对得上——这一点第 4 节会重点讲。

PT5M 表示 5 分钟。上面的 example.com 图片是占位网址，不能直接上线：要替换为与菜谱相符、可抓取的真实图片，并按官方 Recipe 文档补充适用字段。代码中的步骤、时间与食材也必须在页面上有对应内容。不要为教程硬套不适合的类型。

富媒体展示，不是排名加分

选择 Google 支持的类型，满足技术、内容及政策要求后，页面才可能具备富媒体结果资格，如菜谱图片、商品价格和库存、面包屑导航。常见类型有 Recipe、Product、Event、BreadcrumbList 等；评论摘要仅适用于支持且合规的对象类型。它们可能帮助用户选择，点击率仍需实际观察。

• 它不是直接排名因素：结构化数据本身不会把你的位置往前推，它的价值在「更好的理解」和「更抢眼的展示」；
• 标对了也不保证出现：Google 明确说，即使标记完全正确，也不保证一定展示富媒体——是否展示由 Google 决定；
• 所以把它当成「争取更好外观」的机会，而不是「排名秘籍」。

只能标「页面上真有、且看得见」的东西

这是结构化数据的合规底线：标注应准确反映页面内容，供用户获得的信息应与标记一致。不要编造评价、标注页面没有的内容，或专门造空白页放标记；机器字段（如 @id）不必逐字展示。还要遵守具体类型的要求。违规可能导致失去富媒体资格；结构化数据人工处置与一般排名处置应按通知类型区分。

下面每种标记，判断可以还是不可以。点错会给提示：

点一点、填一填，检查你会了没

先选对类型，再验证标记

1. 选自己的商品、菜谱或带面包屑的页面，按 Google 支持的结构化数据列表选择匹配类型，列出必填与适用的推荐字段。没有合适类型时，不必硬加。
2. 把页面上的真实信息逐项对应到 JSON-LD；不会改代码也可先做字段表。图片用实际公开网址，评分只在确有合规评价时填写，不把示例占位内容当真实数据。
3. 在 富媒体搜索结果测试中测试代码或网址，记录检测到的类型、错误和警告；修改后重测，并核对手机页面上的可见内容。