Google 新增 ShippingService 标记：跨境独立站运费政策怎么部署与验收？

先说结论：Google 新支持的 ShippingService 适合表达覆盖大多数商品的商家级运费政策，商品例外仍应放在 Offer.shippingDetails。 它不是把运费表复制成 JSON 就结束，而是要求页面可见政策、结构化数据、结账结果和 Merchant Center 信息保持一致。

ShippingService 解决的是什么问题

Google 的文档说明，ShippingService 可以描述按目的地、订单金额、重量、件数等条件变化的费用和时效，并作为 Organization.hasShippingService 的子项。Google 可能将这些信息用于商品旁边或商家知识面板中的配送展示。

如果某一商品有特殊运费，应在该商品的 Offer 下使用 OfferShippingDetails。商家级政策与商品级覆盖同时存在时，要先确定优先级，避免同一目的地出现相互矛盾的费用。

上线前先准备真实业务字段

至少整理：发货地、目的国或地区、支持与不支持配送的范围、订单金额条件、重量或件数区间、运费币种与金额、处理时间、运输时间、工作日、截单时间和季节性例外。没有真实数据的字段不要填零，也不要编造“全球包邮”。

Google 建议把标准运费政策集中在一个可访问页面，并在 Organization 下标记；不要只在不可见脚本中写一套与页面不同的规则。结构化数据基础验证可配合站内富媒体测试与 Schema Validator 分工。

部署时按五步验收

1. 选一个主要市场和一条标准线路建立最小样本；
2. 在可见运费政策页写清相同条件、费用和时效；
3. 生成 Organization、ShippingService 与 ShippingConditions；
4. 使用 Rich Results Test 检查错误，并人工核对每个条件；
5. 小范围上线后，用 URL Inspection 看 Google 获取的渲染结果，再通过 Sitemap 发现更新。

索引检查可参考Page Indexing、URL Inspection 与 Crawl Stats 分工。若站点还在使用商品 Feed，也要把网页、标记和 Feed 三套运费设置一起对账。

最常见的四类错误

• 把自然日写成工作日，导致处理和运输时间偏差；
• 没写目的地，却误把区域政策声明成全球适用；
• doesNotShip 与运费金额同时出现，语义冲突；
• 页面、Schema、结账页和 Merchant Center 更新不同步。

部署后不能以“测试工具通过”作为结束。应抽样不同目的地、金额、重量和件数，核对搜索标记与真实结账，并持续检查 Search Console 错误。工具选择时继续遵循先验证业务闭环的方法，不要为增加字段数量牺牲准确性。

常见问题

每个商品页都要放 ShippingService 吗？

Google 建议标准商家政策集中在一个页面并放在 Organization 下。只有商品例外才需要在对应 Offer 下设置商品级运费信息。

添加标记后一定会展示运费吗？

不会保证。正确结构化数据只是获得相关展示资格的一部分，Google 仍会根据抓取、索引、数据一致性和产品资格处理。

POD 或多仓站点可以用吗？

可以，但应按发货地、目的地和条件拆分真实服务。若生产地由订单动态决定，先确认能否准确表达，不要用固定时效掩盖履约差异。

核验来源

• Google Search Central：Merchant Shipping Policy structured data
• Google Search Central：Latest documentation updates

本文依据 2026 年 8 月 26 日可访问的 Google 官方文档整理。标记能力、支持属性和搜索展示可能继续变化，上线时应以最新文档与测试结果为准。