404错误排查 - 检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7b7e38cbfa7.html
📄
404错误排查 - 检查前需要准备哪些信息
开始排查404错误前，至少要准备好四类信息：出错的完整URL、用户实际点击的来源页面、服务器返回的状态码与响应头、以及该URL过去是否存在过。缺少任何一项，都容易把“链接写错”“页面被删”“服务器配置异常”“爬虫仍访问旧地址”混为一谈。准备信息的目的不是立刻修好，而是先让现象可复现、可对比。
先记录出错的完整URL和访问方式
不要只记“首页报404”或“某个栏目打不开”。需要完整记录协议、域名、路径、查询参数，例如 https://example.com/old-page?id=12。同时记录访问方式：是浏览器直接输入、从站内链接点击、从外部链接进入，还是搜索引擎结果页跳转。不同入口对应不同排查方向。若同一路径带参数时正常、不带参数时404，问题可能出在重写规则或路由匹配，而不是页面被删除。
收集来源页面和链接上下文
来源页面能说明链接是谁写的、是否写错。检查项包括：
- 来源页面的完整URL，以及链接在页面中的位置，如导航、正文、页脚。
- 链接的原始
href值，确认是否缺少斜杠、大小写不一致或多了空格。 - 该链接是站内链接还是外部链接。站内链接可由自己修改，外部链接只能通过跳转或联系对方处理。
- 如果是搜索结果进入后404，记录搜索词和结果标题，用于判断旧URL是否仍被索引。
这一步的判断结果是：如果只有某一个来源页面的链接404，优先修链接；如果多个来源都指向同一URL且都404，优先查该URL本身的状态。
获取服务器响应头和状态码
浏览器页面显示404，不等于服务器一定返回404。有些站点会把错误页返回成200，也有些服务器对不存在路径返回403或500。用命令行查看响应头更可靠，例如：
curl -I https://example.com/old-page
重点看第一行状态码和 Location 响应头。若返回301或302，说明存在跳转，问题可能在跳转目标；若返回404，说明服务器明确认为资源不存在；若返回200但内容是错误页，属于软404，需要单独处理。适用条件是你能在本地或服务器环境执行命令；若不能，至少用浏览器开发者工具的Network面板查看状态码。注意，HTTPS只表示传输加密，不代表页面一定存在或没有配置问题。
确认该URL过去是否存在及如何消失
判断404的性质，需要知道这个地址是“从未存在”还是“曾经存在”。可核对的信息包括：
- 站点地图或历史备份中是否出现过该URL。站点地图里有记录，只能说明曾经提交过，不保证现在仍应存在或被收录。
- 内容管理系统里是否还能找到对应文章、产品页或分类页，包括回收站和修订版本。
- 服务器访问日志中该URL此前的状态码，是200、301还是404。日志能区分“一直404”和“最近才404”。
- 是否有人最近修改过固定链接、目录结构、路由规则或删除过内容。
如果确认页面曾经存在且仍有访问价值，处理方向是恢复内容或设置301跳转到最相关的新页面；如果页面从未存在，只需修正链接或让服务器正常返回404。
检查robots.txt与索引相关记录
robots.txt的抓取限制不等于可靠的索引移除。一个URL被robots.txt禁止抓取后，仍可能出现在搜索结果中，因为搜索引擎可能在不抓取的情况下保留旧记录。排查时要记录：robots.txt中是否有针对该路径的Disallow规则、该URL是否提交过移除请求、是否有noindex标签。若页面需要被访问却返回404，不要用robots.txt来“修复”，它解决不了资源不存在的问题。不同搜索引擎对移除请求和抓取规则的支持情况须分别核查，不能用一个平台的结果推断另一个平台。
整理成可复查的记录再动手
把上述信息写成一行一条的记录，格式可以是：URL、状态码、来源、过去是否存在、已做处理、复查日期。处理后再用同一命令或同一入口访问一次，确认状态码变化是否符合预期。若设置了301，检查跳转目标是否返回200且内容相关；若修正了链接，确认来源页面已更新。复查时如果状态码仍是404，说明处理未生效或缓存未更新，需要回到响应头和服务器配置继续定位，而不是重复修改同一处。
下一步：选一个具体出错的URL，按“完整URL—来源—响应头—历史记录”四项各填一条，再决定是修链接、恢复内容还是设置跳转。
