现场是这样的。sitemap 插件每小时重新生成，每次给 URL 分配新的 GUID。蜘蛛日志里同一批地址每小时被重新排队一次，真正的新文反而排在四万条旧地址后面，两天才被抓。
中间走过弯路，把「没有对已存在的地址保留原来的条目时间」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。生成逻辑用了自增序号而不是地址哈希生成 GUID；文件内容每次都变，蜘蛛认为整份 sitemap 都是新的；生成任务并发跑了两份 后一份把前一份的条目整个覆盖。
先对比两次生成的条目差异
curl -s https://www.example.com/sitemap.xml | grep -c '<loc>'随后把 GUID 改成地址的稳定哈希
guid = md5(url).hexdigest()生成前先比对内容 无变化就不重写文件
diff -q sitemap.xml.new sitemap.xml || mv sitemap.xml.new sitemap.xml末了观察蜘蛛是否恢复按优先级抓取
awk '{print $7}' access.log | grep -c sitemap恢复的判定其实很直接。改成稳定哈希并加了内容比对后，sitemap 一天最多重写两次，新文当天被发现的占比从 12% 升到 87%。
这里还有个坑。sitemap 的稳定性比更新频率重要，内容没变就别动文件，频繁重写会让整份清单的可信度下降。这类问题最好一次改到位，反复小改反而容易把原因搅混。