这类问题我又碰上了一次。sitemap 索引文件里四个子文件的 lastmod 都写着 1970-01-01T00:00:00+00:00，蜘蛛每天只抓一个子文件，新文章一周才轮到。
第一反应是「索引文件用手工模板维护，lastmod 从来没有被真正写入」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。时间戳字段是 int 类型，空值被格式化成 0 再转成日期；生成脚本取的是文件创建时间，容器里文件系统时间被重置过；子文件按时间排序，索引里顺序和实际更新时间对不上。
上来先查看索引文件里的时间字段
curl -s https://www.example.com/sitemap_index.xml | grep -o '<lastmod>[^<]*'随后按文件修改时间重新生成索引
find . -name 'sitemap_*.xml' -printf '%TFT%TH:%TM:%TS %p\n' | sort -r剩下的就是改成取子文件里最大的 lastmod
grep -o '<lastmod>[^<]*' sitemap_post.xml | sort | tail -1恢复的判定其实很直接。索引文件重新生成后时间戳回到真实日期，四个子文件在两天内被依次抓取，新文章的收录间隔缩短到一天。
索引层的 lastmod 决定蜘蛛先读哪一份，写错比不写更糟，容易让整批子文件长期排在队尾。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。