AI把「已停产」的SKU当在售推荐，我查了三天发现是availability字段的时区坑

上周三下午，客服转来一个投诉截图：客户问AI「XX型号还有货吗」，AI回答「在售，可直接下单」，但这款型号我们两个月前就停产清仓了。我第一反应是AI抓了旧页面，结果拉日志一看，抓取时间戳是三天前的，页面内容也是新的。那问题就出在结构化数据上了。

我先把产品页的Product schema拉出来逐字段对。availability写的是InStock，但实际库存系统里这个SKU的status是discontinued。这里就是第一个坑：我们前端模板是统一渲染InStock的，后端停产标记只改了库存接口，没同步到schema输出层。

但真正让我盯了三天的是另一个细节。我按SKU维度把最近90天的dateModified和availability变更记录拉了个时间线，发现停产那天凌晨2点库存接口已经返回discontinued，但页面schema里的dateModified到当天上午10点才更新——中间有8个小时，AI抓到的页面结构是「旧dateModified+新availability」，它大概率判定这个状态变更不可信，直接沿用了缓存里的InStock。

我做了个对照实验：手动把dateModified和availability的变更时间戳对齐到同一分钟，再触发重新抓取，48小时后那条问句的AI回答改成了「该型号已停产」。差异很明确——时间字段和状态字段的变更必须原子化，否则AI对状态变更的采信率会掉。

顺带还发现一个时区问题：我们的dateModified输出的是UTC时间，但priceValidUntil用的是本地时区+08:00，两个字段混用格式，AI解析时对priceValidUntil的过期判断偏了一天。这个坑更隐蔽，因为页面肉眼看不出来。

现在我的处理方案是：

1. schema输出层加一道校验，availability变更时强制同步刷新dateModified，偏差超过5分钟就打日志告警；
2. 所有时间字段统一ISO 8601带时区偏移，禁止裸日期；
3. 停产SKU的页面不直接下架，改成availability: Discontinued并保留页面，让AI能读到明确状态而不是404。

这套改完跑了三周，同类误报从每周11条降到2条。

想请教下做电商GEO的：你们availability和dateModified的变更同步是放在哪一层做的？是模板层统一输出，还是走单独的schema服务？我们目前是在模板层做，但多SKU批量变更时还是会漏，想看看有没有更稳的架构。