打开独立站，产品页好好的，价格和图片也都在；转到商品后台，这个条目却已经到期。两边并不一定互相矛盾。网页仍能访问，说明网站保留着页面；商品系统是否继续使用这一条提交数据，还取决于它自己的状态。

这个问题适用于已经使用 Google Merchant Center 的卖家，不是所有外贸网站都会遇到。Google 的 ProductAttributes 文档区分了提交时指定的到期日与实际到期日，并提醒实际日期可能更早。因此，排查时不能只翻网站，也不能只看当初发送的字段。

你提交的日期，不等于最终采用的日期

文档中的 expirationDate 表示提交时指定的商品到期时间，实际到期时间则由状态信息中的 googleExpirationDate 表示。官方说明，如果指定日期过于遥远，实际日期可能提前。

这并不意味着遇到展示下降就能认定是到期问题。先确认后台是否真的显示到期，再讨论日期。商品不展示也可能有其他原因，单看搜索结果中暂时找不到它，无法定位到某一个字段。

对接人员排查时，应把同一个商品条目的提交值与实际状态放在一起。尤其要确认比较的是同一目标市场、语言和商品身份，不要拿另一个相似条目的正常状态解释当前问题。看到接口发出成功，只能说明请求完成到某一步，不能替代后续处理结果。

不要把三个时间混成一个

产品资料何时更新、优惠何时结束、商品条目何时到期，可能发生在不同日期。营销人员关心促销周期，网站人员关心页面维护，数据对接人员关心条目状态。如果只留一个“更新时间”，每个人都可能以为对方已经处理。

排查时先找近期实际发送的商品记录，再看处理后的状态和提示。若页面仍在售，确认商品数据是否按原计划继续维护；若产品已经退出销售，则要检查页面是否还把旧条件当作当前承诺。不能为了恢复展示就把已经失效的报价继续送出。

日期还应带上清楚的时区含义。团队在中国看到的自然日，与系统接受的时间戳不一定处于同一时刻。涉及临界时间的差异时，先把它们换到同一时区再比较，避免把几小时差别误判成整天的异常。

修正数据之前，先确认销售意图

一种常见冲动是把日期改得很远，或者换个商品编号重新提交。这既不能说明原条目为何到期，也可能掩盖维护任务已经中断。更有用的顺序是先确认该商品是否仍打算销售，再修正真正失效的数据或同步环节，随后查看处理结果。

如果只是暂时没有现货，应该据实际情况表达供货状态，而不是用到期替代所有停售情形。现货与生产能力的区别讨论的是供货承诺；到期排查解决的则是商品数据本身还能使用多久。把这两件事拆开，客服和技术人员才不会各自回答不同的问题。

恢复后也不要只截一张网站页面作为完成证据。应确认目标商品的实际状态已经改变，再查看适用展示渠道中的表现。公开网页的修改时间不需要为了这次排查而刷新；让页面看起来更新，并不会自动修复商品条目的有效期。

参考来源

Google for Developers：Merchant API ProductAttributes，文档更新于2026年9月4日。