选择 Schema 类型，不能按“咖啡茶饮行业”这个标签去套模板，而要根据每个页面的真实内容与核心意图来判断。品牌官网首页用 Organization，商品销售页用 Product，培训、租赁、团购服务页用 Service，行业文章用 Article，页面有真实可见的问答才用 FAQPage，全站加 BreadcrumbList 统一导航层级。先确定页面主实体，再决定标记类型，字段必须在页面实际展示，这套顺序才是稳定获得解析的基础。
先识别主实体，而不是堆类型
不少咖啡茶饮网站的常见做法，是把 Product、FAQ、Event、Review 一次性铺满首页和所有落地页，期望“多标记多命中”。实际结果是搜索引擎无法判断页面主实体，标记之间相互冲突，轻则全部不展示，重则被认定为垃圾结构化数据，影响页面本身的可信度。
识别主实体不需要复杂的分析方法，只需要回答三个问题：
- 这个页面的主体是什么？是品牌、某款商品、某项服务、一篇文章，还是导航层级？
- 页面是否完整展示了该实体应具备的关键事实？品牌页要有 logo 与介绍，商品页要有价格与图片，服务页要有服务范围与联系方式。
- 用户在这个页面最可能完成的动作是什么？购买、咨询、阅读，还是到店？
一个页面只对应一个主实体。首页的主实体是品牌，就用 Organization；某款咖啡豆详情页的主实体是商品，就用 Product；咖啡培训服务页的主实体是服务，就用 Service。多个实体在同一页面并存，等于没有主实体。
一个典型反面场景：门店页同时卖咖啡豆、开展培训，于是把 Product、Service、LocalBusiness、Event 全部标上。价格、地址、时间混杂在同一段 JSON-LD 里，看似覆盖全面，实则四种实体互相干扰，最终任何富媒体结果都展示不出来。止损做法是拆页——商品走商品页，培训单独建服务页，门店地址只保留在门店页。
六种类型的判断边界
| 类型 | 适用咖啡茶饮页面 | 关键字段 | 不适用场景 |
|---|---|---|---|
| Organization | 官网首页、品牌介绍页、关于页 | name、logo、sameAs、contactPoint | 产品详情页、门店页 |
| Product | 咖啡豆、挂耳、器具等有明确 SKU 的销售页 | name、image、offers.price、availability | 培训、租赁、团购等无形服务 |
| Service | 咖啡培训、企业团购、空间租赁、烘焙代工 | serviceType、provider、areaServed、offer | 实物商品销售页 |
| Article | 行业观察、咖啡知识、门店探店等原创内容 | headline、datePublished、dateModified、author | 列表页、分类页、摘要区块 |
| FAQPage | 页面真实呈现了问答对 | mainEntity（Question/Answer） | 没有任何问答内容的营销页 |
| BreadcrumbList | 全站导航层级 | itemListElement（name、url） | 无层级关系的单页站 |
判断规则只有一个：页面完整体现了该实体的关键事实，才具备使用对应类型的资格。商品页没有明确价格，Product 的 offers 字段就无从谈起；服务页只是笼统介绍“提供培训”，没有课程名称、时长或费用信息，Service 标记的价值也很有限。
FAQPage 有一个现实约束：Google 目前只为权威的政府和医疗健康类网站展示 FAQ 富媒体结果，商业站点的 FAQ 标记通常无法获得富媒体展示。但这类结构化数据的价值不仅在于富媒体结果——真实可见的问答对会以清晰的实体关系被搜索引擎和 AI 模型引用，尤其在 GEO 场景下，这部分价值不容忽视。
字段必须真实且页面可见
Google 开发者文档明确要求，结构化数据必须描述页面上可见的真实内容，不能添加用户看不到的信息，否则可能被判定为垃圾内容。这一条直接决定了哪些字段能写、哪些字段不能写：
- 价格：产品页标注“价格请咨询客服”，就不要写 offers.price。写一个固定价格却与页面文案矛盾，属于误导标记。
- 评分：页面没有展示真实评论，不要写 aggregateRating。虚构高分一旦被识别，可能触发 Search Console 评分警告，甚至影响整站信任度。
- 营业时间：标记的营业时间必须与页面正文、地图信息完全一致，否则本地搜索会展示错误信息，损伤线下转化。
- 作者与时间：Article 的 author、datePublished、dateModified 必须是页面真实呈现的信息。为了“显得新鲜”而修改日期，与页面可见事实相悖，属于典型的违规标记。
Schema.org 标准本身也为不同类型定义了属性边界。Product 的 offers 用于表达价格与库存，Service 的 serviceType 用于明确服务项目。标记时严格使用标准字段，不创建自有的扩展属性去覆盖其他实体。
部署后必须验证，不只是贴代码
JSON-LD 语法正确，不代表能被正确解析。部署后需要执行三组验证：
- Rich Results Test（search.google.com/test/rich-results）：输入页面 URL，查看哪些类型被识别、哪些字段报错。这是 Google 维度的第一道检查。
- Schema Markup Validator（validator.schema.org）：检查 JSON-LD 语法与实体图谱是否正确，尤其适合排查多实体嵌套的复杂结构。
- 大模型可读性验证：将渲染后的页面文本复制进主流 AI 工具，提问“这家店的营业时间”“这款咖啡豆的价格”，看能否得到准确答案。这一步直接关系到 GEO 效果——结构化数据的目标不仅是搜索引擎富媒体结果，更是让大模型在引用时获得准确事实。天行GEO在研究页持续记录结构化数据影响 AI 检索与引用的验证方法。
此外，Search Console 的网址检查工具可以看到 Google 实际识别了页面上的哪些结构化数据；国内站点则应在对应站长平台的工具中检查解析情况。
改内容就要改标记
Schema 不是部署完就一劳永逸的静态代码。产品上下架、价格调整、FAQ 更新、营业时间变更、页面改版，任何一次内容变化都可能让已有标记失配。
| 触发事件 | 需同步标记 | 验证动作 |
|---|---|---|
| 产品下架 | 删除 Product 标记，或改为 availability=OutOfStock | Rich Results Test 与 Search Console 错误检查 |
| 价格调整 | 更新 offers.price 与页面展示价 | 确认两者一致 |
| FAQ 增删 | 同步新增或删除 Question-Answer 对 | 确认问答仍是页面可见内容 |
| 营业时间变更 | 更新 LocalBusiness 与正文时间 | 与地图信息交叉核对 |
| 页面改版 | 检查新页面是否仍适配原 Schema | 重新运行验证工具 |
执行节奏上，每次发布或编辑页面后检查对应页面，每季度抽查首页、Top 10 落地页和服务页，并持续关注 Search Console 的结构化数据报告。能长期维护的标记，比一次性堆砌大量标记更有价值。
Q&A
有独立门店、真实地址、电话和完整营业时间，且页面完整展示这些信息的门店页，应该使用 LocalBusiness，具体子类型可参考 Schema.org 定义的 CafeOrCoffeeShop。但品牌官网首页、没有线下门店的纯电商站，或只是文案中提及“线下门店”的页面，不应该使用。
门店页可以同时组合 LocalBusiness、FAQPage、BreadcrumbList，但地址与联系方式只标记在该门店页，不要全站重复。标记时营业时间和电话必须与页面正文、第三方地图完全一致，这是本地搜索和 AI 引用时最容易出错的字段。
如果有多个门店，每个门店应持有独立页面和独立标记，避免用同一段 JSON-LD 描述多家店址。门店页同时关联品牌 Organization，形成清晰的实体关系：品牌拥有门店，门店提供商品与服务。这套结构既利于搜索引擎识别，也便于大模型在回答“附近有哪些门店”这类问题时提取准确信息。
需要快速完成咖啡茶饮全站的结构化数据审计与部署，可参考服务方案中的实施路径。