Organization、Product、Article 和 Breadcrumb Schema 怎么选？

先判断页面主体，再选择类型

Schema.org 词汇和搜索平台支持的结构化数据用途并不完全相同。企业实施时，应先明确页面在帮助用户完成什么任务，再查看目标搜索平台当前支持的类型与字段。

结构化数据是对可见页面的机器可读说明，不是第二份宣传文案。类型选择正确、字段完整，也不保证获得富媒体搜索展示、排名或 AI 引用。

Organization：说明企业是谁

Organization 适合描述企业或品牌实体，通常放在首页或关于页。可以包括正式名称、URL、Logo、联系方式、地址和官方社交资料，具体字段按公开事实和平台指南填写。

全站可以保持一致的组织标识，但不需要在每篇文章里复制一份彼此冲突的完整公司档案。文章中的 publisher 或 author 可以引用同一组织实体。名称、Logo URL、地址和联系电话必须与页面及企业实际信息一致。

常见错误包括：使用不存在的简称、把销售邮箱写成企业法定名称、Logo 地址不可抓取、结构化数据中的地址与联系页不同，以及把未受控制的第三方页面列为官方资料。

Product：描述页面上的真实产品

Product 用于一个明确产品或可识别商品的页面。页面应公开显示产品名称、说明、品牌或制造方，以及标记中使用的其他事实。报价、库存、评价或评分等扩展信息只有在真实、当前且页面可见时才可添加。

企业 B2B 服务或复杂解决方案并不因为“想要产品展示”就自动适用 Product。若页面主体是行业方法或组合方案，更适合使用 WebPage 语义并在内容中链接具体产品。知识文章提到产品时，主体通常仍是 Article。

常见错误包括：所有文章都标记 Product、添加不可见价格、复制不相关评价、型号与页面不一致，以及产品已下线但 Offer 仍显示可购买。

Article：描述新闻和知识内容

Article 适用于新闻、博客、指南和知识文章。核心信息通常包括 headline、description、datePublished、dateModified、author、publisher、inLanguage 和 mainEntityOfPage。

日期必须反映真实发布与实质修改。作者可以是个人或组织，但页面应让读者看到相同责任信息。headline 与 H1 应保持一致或语义一致，mainEntityOfPage 指向页面 canonical。

常见错误包括：每次构建都更新 dateModified、作者只存在于 JSON-LD、结构化标题与可见标题不一致、多个 URL 声称是同一文章主页面，以及把营销落地页标记成新闻文章。

BreadcrumbList：说明网站层级

BreadcrumbList 表示用户从首页、栏目到当前页面的层级。列表项按顺序提供 position、name 和 item。可见面包屑与结构化数据应一致。

面包屑不是把所有关键词串成一条路径，也不是浏览器历史。一个文章页可以是“首页 > 新闻中心 > 文章标题”，产品页可以是“首页 > 产品 > 产品名称”。若网站没有真实中间层级，不应虚构栏目页。

常见错误包括：位置编号重复、最后一项 URL 错误、可见面包屑与 JSON-LD 不同、中文页引用英文层级，以及面包屑目标返回 404。

四种类型可以怎样组合

首页可以使用 Organization，并根据真实导航添加 BreadcrumbList 的必要性通常较低。产品页可组合 Product 与 BreadcrumbList。文章页可组合 Article 与 BreadcrumbList，并在 publisher 中引用 Organization。FAQ 若为页面可见内容，可根据当前平台规则使用 FAQPage；不要为了字段数量添加无关类型。

组合的原则是每个节点描述不同但相关的事实，并通过稳定 @id 或 URL 保持实体一致。不要创建多个名称、Logo 或产品标识互相冲突的节点。

JSON-LD、Microdata 还是 RDFa

Google 文档通常推荐 JSON-LD，因为它与页面布局分离，便于生成和维护。无论选择哪种语法，事实都必须在可见页面中存在，并保持同步。

模板化生成 JSON-LD 时，需要转义特殊字符，避免无效 JSON；日期使用明确格式；URL 使用绝对规范地址；数组字段不能混入空值。发布前应解析 JSON，并使用结构化数据测试工具检查。

发布验证清单

• 页面主体与 Schema 类型一致；
• 必填或推荐字段来自可见、当前、可核验事实；
• canonical、mainEntityOfPage、Breadcrumb URL 使用同一规范地址；
• 中英文页面各自使用正确语言、标题、作者、日期和 URL；
• JSON 可以解析，没有重复冲突实体；
• 页面返回 200，字段引用的 Logo 和目标 URL 可访问；
• 修改内容后同步更新可见页面与 JSON-LD；
• 定期复查搜索平台文档，因为支持范围可能变化。

GrowSiteX 发布流程中的 Schema

GrowSiteX 可把文章生成、内容审核、发布计划和 CMS 发布连接起来。企业可以在文章模板中固定 Article 和 Breadcrumb 字段来源，并由网站运营复核 canonical、语言、日期与作者。

产品页和 Organization 数据涉及更稳定的站点实体与商业信息，建议由产品和网站负责人维护，不应由单篇文章生成任务自行推断。当前支持方式以实际版本、目标 CMS 和实施配置为准。

参考资料

• Google Search Central：Organization 结构化数据
• Google Search Central：Product 结构化数据
• Google Search Central：Article 结构化数据
• Google Search Central：Breadcrumb 结构化数据

常见问题

一篇产品介绍文章应该用 Product 还是 Article？

看页面主体。如果它是带作者、日期和知识解释的文章，通常以 Article 为主，并链接到产品页。只有页面本身承担产品展示任务且可见事实满足要求时，才使用 Product。

Schema 字段越多越好吗？

不是。只添加与页面主体相关、真实、可见并能维护的字段。无关或无法核验的数据会增加冲突和合规风险。

结构化数据通过测试就算完成了吗？

还不够。语法通过不代表类型选择和事实正确。还要检查可见内容一致性、URL 状态、索引控制、多语言对应和后续更新机制。

SEO 表现、AI 引用、自然流量、询盘与成交会受到网站基础、市场竞争、内容质量和持续运营等因素影响，不承诺具体结果。