现场是这样的。索引文件由脚本按季度生成,先写索引再写子文件。四月份一次发布中断,索引里只声明了两个子文件,另外两个照常生成却没人读,三万条新文章一直停在已发现。

中间走过弯路,把「提交到 GSC 的仍是上一版索引文件」当成主因,改完现象没变。

真正麻烦的地方在于,几个原因的现象几乎一样。索引和子文件分两步生成,中间失败没有回滚;子文件命名带时间戳,索引里写的还是旧文件名;脚本没有校验索引引用的每个文件是否都返回 200。

数索引里引用了几个子文件

curl -s https://www.example.com/sitemap_index.xml | grep -c '<loc>'

接着逐个检查子文件状态

for u in $(curl -s https://www.example.com/sitemap_index.xml | grep -o '<loc>[^<]*' | cut -c6-); do curl -s -o /dev/null -w "$u %{http_code}\n" $u; done

然后对比磁盘上实际生成的文件数

ls -1 /data/sitemap/*.xml | wc -l

末了改

成

怎么算真的好了,看的是同一批现象。修复后索引引用的子文件数与磁盘一致,三万条新地址在两周内陆续被抓取,已发现的数量降到一千以内。

这里还有个坑。sitemap 索引本质是个目录,目录漏了条目,后面的文件写得再对也没人读。这类问题最好一次改到位,反复小改反而容易把原因搅混。

作者 9823189