这类问题我又碰上了一次。11 月初在 GSC 的抓取统计里看到 404 响应占 18%，翻遍当天的 nginx access.log 却一条 404 都对不上，连 URL 前缀都不认识。
第一反应是「站点做过目录改名，大量旧地址仍在 sitemap 里被反复提交」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。报表统计的是 Googlebot 抓到的 URL，源站日志只记了用户访问的域名；CDN 把 404 结果缓存后直接回给蜘蛛，请求根本没落到源站；爬虫 UA 被日志切割脚本过滤掉，404 记录落在了未归档文件里。
上来先按状态码统计蜘蛛请求的分布
awk '$9==404{print $7}' access.log | sort | uniq -c | sort -rn | head -20接着抽样一条 404 地址在两处分别复验
curl -o /dev/null -s -w '%{http_code}\n' https://www.example.com/old/list/12.html剩下的就是核对 sitemap 里是否还留着失效目录
curl -s https://www.example.com/sitemap.xml | grep -c '/old/'改完先别撤，确认这几项。同一批地址在源站日志里出现后，404 占比在一周内从 18% 压到 3% 以下，报表与日志的请求数也能对上。
补一句。GSC 抓取统计的口径是抓取次数不是独立 URL，同一个死链被反复抓会被重复计数，看占比之前先按 URL 去重。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。