产品服务类页面通常应以 Product 或 Service 结构化数据为主，页面卖实物、软件或可下单方案时偏向 Product，页面介绍人工交付、咨询、安装或订阅服务时偏向 Service。真正影响选择的是页面主实体、用户动作和交付方式，结构化数据只能帮助机器理解页面，不能单独代表收录、引用或转化结果。
页面到底代表什么，先把主角定下来
页面主角是可独立购买的商品，Product 就更贴切；页面主角是按约定提供的服务，Service 更符合内容含义。比如一台净水器的型号、图片、规格和购买入口，应围绕 Product 组织；企业法律顾问页面若重点写服务范围、服务区域、预约方式和交付内容，则应围绕 Service 组织。
如果页面同时出现产品和服务，不要把两者硬塞成一个实体。可以让产品作为主实体，把安装、延保或上门服务作为页面中的关联内容；也可以拆成商品页与服务页，再用清楚的站内链接说明两者关系。主实体应与页面标题、首屏文案、价格说明和行动按钮保持一致。
产品页和服务页别混着标
Product 适合表达名称、品牌、型号、图片、描述、报价、库存状态以及购买条件等信息。Service 更适合表达服务名称、服务类型、服务区域、提供方、预约入口和交付范围。Schema.org 的 Product 与 Service 类型定义，可以作为组织这些信息的语义参考，但不代表搜索平台必然展示某种特殊结果。
混用类型时，机器可能难以判断用户是在买一个商品，还是在预约一项服务。尤其是“产品套餐”“解决方案”“服务包”这类名称，不能只看营销叫法，应看用户最终完成的动作：直接下单付款，偏商品；提交需求、预约人员或等待方案，偏服务。
一个页面要不要同时写两种结构化
同一页面确实包含独立商品和独立服务时，可以分别描述，但两套信息要能在页面正文中找到对应内容。若所谓服务只是商品配送、普通安装或售后说明，就不宜把它包装成与商品并列的主服务实体，否则页面语义会变得松散。
页面有多个套餐时，先区分套餐是否真的对应不同交付内容。名称、价格、包含项目和购买按钮应逐项对应；无法在页面中看见的隐藏信息，不应只写进结构化数据。涉及报价、库存或服务区域的内容变化较快，更新页面时也要同步处理结构化字段。
结构化数据写在哪一层更稳妥
结构化数据应放在与页面正文对应的位置，并让名称、描述、图片、价格、服务范围等信息与用户看到的内容保持相同含义。Product 页面可以围绕具体型号或套餐组织，Service 页面可以围绕服务项目和提供方组织，企业名称、地址和联系方式则要使用站内长期一致的写法。
不要把首页、分类页和详情页都写成同一个商品或服务实体。首页适合说明企业或业务范围，分类页适合说明品类，详情页才承载具体产品或服务。这样做的重点不是增加字段数量，而是减少同名页面之间的歧义，让抓取系统和用户都能看懂页面层级。
抓取、索引和结构化不是一回事
根据 Google Search Central《搜索抓取与索引指南》，页面能够被抓取，不等于已经进入索引；结构化数据存在，也不等于搜索结果一定展示对应样式。robots.txt、页面状态码、站内链接、sitemap 和页面本身是否可访问，都可能影响搜索系统能否处理页面。
因此，结构化数据上线后，不要把“代码通过”直接当成效果结论。AI回答是否出现页面内容、是否产生引荐点击，无法通用判断，需用自家数据验证。页面若被引用，也应区分展示、点击、表单和成交，不能把其中任一信号直接当成订单结果。
上线后怎么做一轮闭环
下面这组记录适合产品页、服务页和混合型方案页使用，重点是观察主实体是否被正确理解，以及用户是否真的完成目标动作：
- 记录页面主实体、结构化类型、更新时间、HTTP 状态和站内入口，保留发布版本的代码或导出文件。
- 查看抓取日志、索引状态和结构化数据提示，记录页面地址、发现时间、处理状态与异常位置。
- 在固定查询中记录 AI 是否提到页面、是否出现引荐点击，并把自然搜索、品牌词搜索、直接访问分开统计。
- 选定一个主转化事件，例如有效表单或订单，设置与销售周期相符的归因窗口，记录来源、落地页和成交状态。
- 完成一个完整记录周期后，比较有效线索率、订单成本或页面转化率；无法通用判断收益，需用自家数据验证，再决定修改实体、文案或入口。
如果页面可访问但没有形成有效动作，下一步不应只改字段数量，还要回看标题、服务承诺、价格说明和行动按钮是否与用户需求一致。版本记录能帮助团队区分代码改动、内容改动和渠道变化，避免把多项变化混成一个结论。