sitemap 里 3 万条 URL 全是 404 怎么回溯生成逻辑

事情本身不复杂，线索都在日志里。GSC 的 sitemap 报告里 3 万条已提交 URL 全部返回 404，抽查几条是 /archives/2024/05/ 这类早删掉的栏目，站点实际只有两千篇文章，sitemap 却列出了八万条。

第一反应是「分页参数被当成路径写进 URL，拼出来的地址本来就不存在」，验证下来不成立。

这类报错背后常见的原因有几处，逐个排除就行。生成脚本直接读 wp_posts 全表，没过滤 post_status 和 post_type。另一种情况是多站点共用同一份生成逻辑，把别的站点的 ID 拼进了当前域名。

不容易想到的是，数据库里遗留的修订版本被当成正文页一起输出。

先统计 404 的占比和路径特征

curl -s https://www.example.com/sitemap.xml | grep -o '<loc>[^<]*' | awk -F/ '{print $4}' | sort | uniq -c

随后核对数据库里这些 ID 的真实状态

SELECT ID,post_status,post_type FROM wp_posts WHERE ID IN (101,102,103);

给生成查询补上状态和类型过滤

SELECT ID FROM wp_posts WHERE post_status='publish' AND post_type='post';

剩下的就是重新生成后逐条 HEAD 抽查

while read u; do curl -o /dev/null -s -w '%{http_code} ' $u; done < urls.txt | tr ' ' '\n' | sort | uniq -c

恢复的判定其实很直接。新 sitemap 只剩两千余条，抽查 404 比例为 0，重新提交后无法读取的条目从报告里消失。

补一句。sitemap 条数远大于站点真实页面，是最直接的异常信号，先看数量再逐条看内容。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。