从日志里挖出蜘蛛天天撞的 404 死点

站改版半年了，站内链接自认清理得干干净净，蜘蛛却还在日复一日地撞 404。这些死点从哪来的？旧外链指向被删的文章、搜索引擎库里缓存的旧 URL、老 sitemap 的残留、站内漏改的某个入口——单靠人脑想，永远想不全。好消息是蜘蛛会把每一次碰壁都老老实实记在你的日志里，去日志里捞就行。

思路是三步：从蜘蛛抓取记录里筛出返回码 404 的行，按 URL 聚合计数，得到一份“蜘蛛视角的死点清单”。这份清单比站内扫描工具更有价值，因为它反映的是搜索引擎真实在尝试访问的地址，优先级天然排好了序。

# 蜘蛛撞过的 404，按 URL 去重计数
grep -E "Baiduspider|Googlebot" /var/log/nginx/access.log \
 | awk '$9 == 404 {print $7}' \
 | sort | uniq -c | sort -rn | head -30
 
# 导出完整清单备用
grep -E "Baiduspider|Googlebot" /var/log/nginx/access.log \
 | awk '$9 == 404 {print $9, $7}' \
 | sort | uniq -c | sort -rn > spider_404.txt

拿到清单后逐条归类处置，只有三种正确答案：内容搬家了的，配 301 跳到新地址，权重和访问一并转移；内容彻底没了且没有替代内容的，保持 404 或升级成 410——官方文档的说法是 404/410 会明确告诉搜索引擎这个页面不存在、不要再来抓；内容还在但地址变了入口没变的，修站内链接。最忌讳的是图省事把所有 404 统统 301 到首页，这是搜索引擎明确点名过的垃圾跳转。

# 确认彻底废弃的整目录：nginx 里直接回 410
# nginx.conf 或站点配置的 server 块里加
location ^~ /old-bbs/ {
 return 410;
}
 
# 单篇搬家：精确 301
location = /post/2023/old-article.html {
 return 301 /article/new-article.html;
}
 
# 改完验证配置并重载
nginx -t && nginx -s reload

验证闭环分两段：改配置后先用 curl 抽查状态码是否符合预期，301 的回 301、410 的回 410；然后第二天重跑开头那条统计命令，撞 404 的次数应该明显回落。持续一两周，高频死点清零，剩下零星的外链死点可以放着不管，搜索引擎会自己降频。

# curl 抽查状态码
curl -sI https://www.example.com/old-bbs/ | head -1
curl -sI https://www.example.com/post/2023/old-article.html | head -1
 
# 第二天复查：新日志里 404 计数应回落
grep -E "Baiduspider|Googlebot" /var/log/nginx/access.log \
 | awk '$9 == 404' | wc -l

还有个统计窗口的讲究：单看当天日志可能漏掉蜘蛛访问频率极低的死点，把 logrotate 切割的最近 7 天日志按顺序拼接后再跑统计，覆盖面扎实得多。改版后那种“每周才被撞一两次”的低频死点，恰恰藏在这种拼接报表里，单日数据永远看不见。

收尾说个心态问题：404 本身不可怕，官方文档明确说如果页面删了没有替代内容，404 是完全正常的状态，不用恐慌。可怕的是放着高频死点不管，让蜘蛛天天在同一个坑上撞，白耗抓取预算还拖累整站印象。日志捞清单、归类处置、curl 验证，一周就能把历史欠账清完。

相关阅读：挖出的死点要进例行清理。《SEO 自动化总清单：日、周、月、季各该跑什么》给本篇排了每周位，配合死链监控脚本，死链从发现到处理一周走完。