现场是这样的。sitemap 里的 lastmod 输出成 2026-11-09T09:30:00+08:00，百度站长平台提示日期异常，部分条目被跳过，Google 那边却读得好好的。
中间走过弯路，把「部分条目用了未来时间，被抓取端判为无效」当成主因，改完现象没变。
原因不止一个，得分开看。W3C 规范要求带时区偏移，但百度对带偏移的写法解析不稳定；服务器时区设成了 PRC，PHP 输出的时间比 UTC 快八小时；lastmod 精确到秒，同一批文章时间戳完全相同。
上来先抽查 sitemap 里的时间格式
curl -s https://www.example.com/sitemap-1.xml | grep -o '<lastmod>[^<]*' | head -5然后统一改成 UTC 时间
date_default_timezone_set('UTC');再往下输出符合规范的完整时间
echo gmdate('c', get_post_modified_time('U', true, $post_id));复查平台里是否还报日期异常
curl -s https://www.example.com/sitemap-1.xml | grep -c 'lastmod'怎么算真的好了，看的是同一批现象。sitemap 里的时间统一为 UTC 且不再有未来时间，百度平台的日期异常提示消失，被跳过的条目恢复正常读取。
时区差八小时在大站点上很容易变成未来时间，改时间格式前先把服务器和 PHP 的时区对齐，能省掉一半的诡异提示。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。