跨境商品的 SEO/GEO 问题，往往不是“少了一个 Schema”，而是同一件商品在五个出口里变成了五个版本：ERP 说有货，商品页显示售罄；Merchant Center 是美元，页面首屏是欧元；feed 把蓝色款标成红色；退货页写 30 天，渠道后台写 14 天。正确做法是把 PIM、ERP 或商品库设为事实源，让官网、feed、Product/ProductGroup 和协议数据从同一个标准化对象派生，并每天检查漂移。
一、为什么“字段都有”仍然会失败
搜索平台和 AI 商品发现系统接收的不是一张静态宣传海报，而是一组持续变化的事实：商品是谁、当前卖多少钱、哪个市场能买、哪个变体有货、多久送达、能否退货。
如果这些事实分别由运营、开发、投放和客服手工维护，字段越多，冲突概率越高。一个完整商品页即使带有 Product JSON-LD，只要可见价格、结账价格和 feed 价格不同，结构化数据就失去验证价值。机器也许能读懂每个字段，却无法判断哪个才是真实版本。
因此第一条原则不是“尽可能多填字段”，而是：
每个可变事实只能有一个权威来源；其他出口只负责转换格式，不负责重新发明数值。
二、先定义标准商品对象
成熟的商品对象至少分成四组。
1. 身份字段
- 商品主 ID：长期稳定，不因标题、URL 或价格变化而改变。
- 变体 ID：每个可购买组合唯一。
- 品牌、GTIN、MPN：有真实值时填写；没有时保持缺省，不能编造。
- 父子关系：同一商品组的尺码、颜色、容量等变体共享一个组标识。
2. 展示字段
- 标题：品类、关键属性、型号或适用对象清楚可辨。
- 描述：写明材料、尺寸、兼容性、使用限制和包装内容。
- 落地页：直接打开对应市场、语言和可购买变体。
- 图片：主图与变体图要能对应具体颜色、款式或规格。
3. 交易字段
- 价格与币种；
- 库存与可售状态；
- 商品状态，如新品、翻新或二手；
- 目标市场；
- 促销价格及其生效时间；
- 最小订单量或不可直接购买的限制。
4. 履约与政策字段
- 可配送国家或地区；
- 运费、免邮门槛与预计时效；
- 退货窗口、退货成本和例外条件；
- 客服联系方式；
- 税费或关税的展示口径。
这四组字段共同决定商品是否“可核验”。只优化标题和描述，不解决库存、履约与政策冲突，仍然只是内容优化。
三、最小 feed 字段只是起点
OpenAI 当前的 ACP 商品文件规范沿用了成熟商品 feed 的核心形态。最小骨架包括：
| 字段 | 作用 | 常见跨境错误 |
|---|---|---|
| id | 稳定识别商品或变体 | 每次导出重新编号 |
| title | 帮助理解商品是什么 | 只有内部款号或营销口号 |
| description | 描述属性、适用与限制 | 与页面规格冲突 |
| link | 指向可核验落地页 | 所有市场都指向首页 |
| image_link | 提供代表图片 | 图片与所选变体不一致 |
| availability | 表示当前可售状态 | 只按总仓库存，不按市场 |
| price | 价格与币种 | 页面、feed、结账币种不同 |
| brand | 确认品牌归属 | 卖家名、制造商名混用 |
“最小字段能通过解析”和“商品资料足以参与准确比较”不是同一个标准。尺寸、材质、颜色、GTIN、运费、退货、促销和适用市场等信息，要根据类目与接入规范继续补齐。
如果团队已经维护 Google Merchant Center feed，不应再从零建立一套逻辑完全独立的“AI feed”。先把成熟字段映射成中间商品对象，再为 ACP、网站和其他渠道生成各自格式，维护成本更低。
四、ProductGroup 与 Product：父级聚合，变体可购买
Google 的产品变体结构使用 ProductGroup 描述一组共同商品属性，用 Product 描述具体可购买变体。工程上可以把它理解为：
- ProductGroup：同一款鞋、同一型号灯具或同一系列水杯；
- Product：黑色 42 码、3000K 12W、500ml 蓝色等具体组合。
每个可选择变体至少要解决五件事：
- 拥有稳定 SKU 或变体 ID。
- 页面状态能表达当前选择，最好有可复制、可抓取的独立 URL。
- 主图随变体切换，并能直接访问。
- 价格与库存对应当前变体，而不是父商品的模糊区间。
- 结构化数据里的变体属性和可见页面一致。
如果所有颜色和尺码共用一个 URL，抓取器打开页面时无法稳定复现某个变体，用户分享链接也会丢失选择。Google 对变体 URL 的建议并不要求你为每个组合写一篇重复页面，而是要求状态可被唯一标识。
对只有询价、没有公开价格的 B2B 产品，不要为了获得 Merchant Listing 资格虚构 Offer、价格或库存。这类页面可以清楚表达产品实体、规格、制造能力与询盘条件，但“可直接购买”的结构化声明只能出现在真实可购买页面。
五、多币种与多市场：一个 URL 必须有一个明确主版本
Google 对不同币种建议使用独立 URL。原因很实际：如果同一个 URL 根据 IP、Cookie 或前端状态瞬间换成不同价格，抓取器、用户和验证工具可能看到三个不同版本。
更稳妥的路由示例是：
| 市场版本 | URL | 页面主币种 | canonical |
|---|---|---|---|
| 美国英语 | /en-us/products/model-a | USD | 指向自身 |
| 英国英语 | /en-gb/products/model-a | GBP | 指向自身 |
| 德国德语 | /de-de/products/model-a | EUR | 指向自身 |
如果两个页面只是币种不同、语言相同，也不要用 canonical 把目标市场版本全部并回一个全球页面，然后又用 hreflang 声明它们是独立版本。canonical 表达“首选索引副本”，hreflang 表达“面向不同语言或地区的等价版本”；两者不能互相否定。
多语言路由的完整验收方法见《外贸多语言站技术验收：hreflang、canonical、x-default 与 Sitemap 如何不打架》。
六、运费与退货不能只藏在结账页
跨境购买决策里，“商品多少钱”通常不是最终到手成本。运费、税费、到货时间和退货成本会直接改变用户是否愿意购买，也会影响平台判断商品是否适用于特定地区。
至少要做到：
- 商品页或清晰链接的政策页说明可配送地区；
- 预计时效带有适用国家、仓库或配送方式；
- 免邮门槛说明币种和市场；
- 退货窗口、退货运费承担方与例外品类明确；
- Merchant Center、feed 与网站采用相同政策版本；
- 商品级例外通过真实字段覆盖全局政策，而不是靠客服口头说明。
Google 当前 UCP 准备指南要求 Merchant Center 配置退货政策和客户支持信息；退货政策还可以通过标签限定到部分商品，或在产品级提供覆盖信息。这说明政策不是网站页脚里的装饰文案，而是商品交易对象的一部分。
七、建立“新鲜度预算”
不同字段允许的延迟不同。不要用“每天全量更新一次”作为所有数据的统一答案。
| 字段 | 建议更新节奏 | 超时后的处理 |
|---|---|---|
| 库存、可售状态 | 分钟级或事件驱动 | 过期时宁可标为未知或不可售 |
| 价格、促销 | 事件驱动并保留生效时间 | 禁止展示已过期优惠 |
| 标题、描述、图片 | 发布变更时 | 记录版本并重建各渠道输出 |
| 运费、退货、市场资格 | 政策变更时立即同步 | 阻止不符合政策的商品继续发布 |
| 品牌、GTIN、MPN | 低频但要审计 | 禁止为填满字段而猜测 |
对采用“每日全量 + 日内增量”的系统，日内更新必须可重放、可去重。一次 API 失败不能永久漏掉价格变化；下一次全量文件也必须能把状态收敛回事实源。
八、用漂移检测代替人工抽查
一个可执行的每日检查可分五步：
- 从商品事实源抽取每个市场的代表 SKU。
- 获取公开页面首次 HTML，并解析可见标题、价格、币种、库存和当前变体。
- 解析 Product/ProductGroup JSON-LD。
- 读取最近一次输出的渠道 feed 或 API 快照。
- 对 ID、URL、价格、库存、图片、变体和政策版本做逐字段比较。
告警要带上事实源值、冲突出口、发现时间和严重级别，但不要在日志里写支付凭证、客户身份或私密订单数据。
可以按影响分级：
- P0：结账价与公开价冲突、缺货仍可购买、错误市场仍可售；
- P1：变体图片或属性错配、运费与退货政策冲突；
- P2：描述、标题或非交易属性更新延迟。
九、上线前的 12 项验收
- [ ] 商品与变体 ID 稳定且唯一。
- [ ] 落地页返回 200，不要求登录。
- [ ] 重要商品信息存在于首次 HTML。
- [ ] 每个市场 URL 有自引用 canonical。
- [ ] 语言与地区版本的 hreflang 互相回链。
- [ ] 可见商品、ProductGroup、Product 与 feed 使用同一 ID 映射。
- [ ] 价格包含明确币种，并与结账一致。
- [ ] 库存对应市场与变体。
- [ ] 变体 URL、图片与所选属性一致。
- [ ] 运费、退货与客服信息可公开核对。
- [ ] Sitemap 只包含可索引的规范 URL。
- [ ] 漂移监控覆盖页面、结构化数据、feed 和事实源。
这份检查表解决的是数据送达和一致性。至于商品是否出现在 ChatGPT 或 Google AI 体验里，还需要另行记录准入、展示与流量证据。《ChatGPT 商品发现接入指南》给出了这条分层边界。
十、三个常见问题
Product JSON-LD 可以代替 Merchant Center 或 ACP feed 吗？
不能。结构化数据、Merchant Center feed 与 ACP feed 是不同入口。它们可以从同一商品对象生成，相互帮助核验，但不能把一个入口的接收状态当成另一个入口已经完成。
商品页上只显示价格区间，可以吗？
如果用户还没有选择变体，父商品可以展示真实区间；选择具体变体后，页面、结构化数据和结账应落到该变体的确切价格与库存。不要用最低价代表所有变体。
工厂产品没有公开价格，要不要加假的 Offer？
不要。应清楚展示规格、应用、MOQ、询价流程和可验证资料；没有真实可购买报价时，不应虚构价格、库存或零售 Offer。
边界声明
本文提供的是商品数据一致性与技术资格方案，不保证富结果、收录、AI 展示、推荐、流量或订单。平台字段、资格和协议仍会更新，实施时应按目标市场和类目复核最新官方规范。
资料来源
本文字段与实现边界来自 OpenAI ACP 商品 feed 规范，以及 Google Search Central 的 Product、ProductGroup、Merchant Listing、国际站 canonical 指南和 Google Merchant Center/UCP 实施文档。工程分层与检查清单由妙蛙 GEO 研究团队整理。