404 not found，怎样形成可复用检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc75029a2bfe.html
📄
404 not found，怎样形成可复用检查清单
把 404 not found 做成可复用检查清单，核心不是记下所有报错页面，而是固定一套“先判断影响、再分类原因、最后决定动作”的顺序。时间和人手有限时，先处理被站内链接或站点地图指向、且返回 404 的地址；再处理有外部链接指向的 404；最后才清理无入口、无外链的孤立地址。下面用一个假设例子展开。
假设例子：一次上线后的 404 排查
假设某站点改版，把 /old-guide 改为 /guides/new-guide，但导航、旧文章正文和站点地图里仍保留旧地址。上线后，访问 /old-guide 返回 404 not found。此时不要先批量重定向所有 404，而应按清单逐项判断：
- 确认状态码：用浏览器开发者工具或命令行查看响应，确认是 404，而不是 403、410 或 500。不同状态码对应不同处理方式。
- 找入口：检查站内链接、导航、站点地图、外部链接是否仍指向该地址。有入口的 404 优先处理。
- 定动作：如果新页面与原内容高度对应，做 301 重定向到新地址；如果内容已彻底删除且无替代，可返回 410；如果只是暂时不可用，考虑 503，而不是直接 404。
- 改入口：重定向只能兜底，站内链接和站点地图中的旧地址应同步改为新地址，避免长期依赖跳转。
- 记录与复查：把处理过的地址、动作、日期写入清单，过一段时间再抽查，确认没有再次出现 404。
常见错误是：看到 404 就全部 301 到首页。这会让用户和搜索引擎无法判断原内容去向，也可能被视作软 404。另一个错误是只改页面链接，却忘了站点地图；站点地图不保证收录，但保留大量 404 地址会浪费抓取预算，也不利于后续核查。
可复用清单的固定字段
要让清单可复用，每条记录至少包含以下字段，而不是只写“已处理”：
地址：出现 404 not found 的完整路径。发现来源：站内链接、站点地图、外部链接、日志或手动访问。入口数量：有多少页面或链接指向它，用于排优先级。原因分类：页面被删、地址变更、拼写错误、参数错误、服务器配置错误。动作：301、410、503、修复链接、保留观察。复查日期：用于后续抽查，避免处理完就遗忘。
如果时间和人手有限，可以按“有站内入口且有外部链接 → 有站内入口 → 只有外部链接 → 无入口无外链”的顺序处理。前两类通常最值得先做，因为它们既影响用户，也可能影响搜索引擎对站点结构的判断。
判断时容易混淆的几组关系
robots.txt 的抓取限制不等于可靠的索引移除。也就是说，即使 robots.txt 禁止抓取某个地址，该地址仍可能因外部链接或历史记录出现在搜索结果中；要移除索引，应使用对应的移除工具或返回合适的状态码，并分别核查不同搜索引擎的支持情况。
HTTPS 不保证安全无漏洞或排名。它只表示连接加密，与 404 处理没有直接替代关系。遇到 404 时，不要因为站点是 HTTPS 就跳过状态码和入口检查。
站点地图不保证收录。把新地址写进站点地图，只是提供发现线索，不代表搜索引擎一定抓取或收录。404 清单应把站点地图当作“入口来源”之一，而不是“已处理”的证明。
执行与复查：让清单真正可复用
假设你每周只有一小时处理这类问题，可以这样安排：先用站点爬取工具或服务器日志导出 404 地址；按入口数量排序；只处理前 20 条；每条填写上述字段；处理完后把旧地址加入监控列表。下一周先复查上周处理过的地址，再处理新一批。这样清单不会越积越乱，也能看出哪些 404 是反复出现的。
复查时重点看三项：原 404 是否已返回 301、410 或其他预期状态；站内链接和站点地图是否已更新；是否有新的 404 从同一批旧地址产生。如果同一路径反复出现，说明入口没有改干净，应回到来源处修复，而不是反复重定向。
下一步，你可以先选一个近期改版或频繁报 404 的栏目，按上面的字段建一张表，只填 10 条记录，跑完一轮“确认状态码—找入口—定动作—改入口—复查”。跑通后再扩展到全站，比一上来整理所有 404 更实际。
