404错误修复：检查前需要准备哪些信息？先收集这五类证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7dbb6eb457f4.html
📄
404错误修复：检查前需要准备哪些信息？先收集这五类证据
在动手修改服务器、CMS或跳转规则之前，先把与404相关的五类信息收集齐：可复现的URL样本、HTTP状态码与响应头、服务器与CDN日志、页面来源与内链关系、以及站点当前的跳转与robots配置。缺少这些信息，修复往往只能靠猜，容易把“单个链接写错”误判成“整站路由故障”。
第一类：可复现的URL样本与访问方式
先准备至少3到5个出现404的完整URL，包含协议、域名、路径和查询参数，例如https://example.com/old-page?id=12。同时记录访问方式：直接输入地址、从站内链接点击、从外部链接进入，还是从搜索结果进入。
- 记录浏览器、设备类型和是否登录，排除个性化内容导致的差异。
- 记录访问时间与时区，便于和日志时间对齐。
- 如果只有部分用户遇到，记录对方网络环境或地区。
判断结果：如果同一URL在不同入口表现不同，问题可能出在链接本身或跳转链路；如果所有入口都返回404，才更可能是资源确实不存在或路由规则未覆盖。
第二类：HTTP状态码与响应头
用浏览器开发者工具的Network面板或命令行工具查看实际返回的状态码。重点区分404、410、301、302和软404（页面显示“未找到”但状态码为200）。
需要记录：
- 状态码具体数值。
- 响应头中的
Location字段，确认跳转目标。 X-Robots-Tag是否存在，以及内容。- 服务器返回的
Server或CDN标识，便于判断请求经过哪一层。
判断结果：301表示永久跳转，302表示临时跳转，410表示资源已永久移除。若状态码是200但页面内容为错误提示，属于软404，需要单独处理，不能只改文案。
第三类：服务器、CDN与CMS日志
日志能回答“谁在什么时候请求了什么，以及服务器如何回应”。准备以下字段：请求时间、客户端IP、请求方法、完整路径、状态码、User-Agent、Referer。
适用条件：如果站点使用CDN或反向代理，需要同时拿到边缘节点日志和源站日志，否则可能只看到其中一层的404。CMS日志则用于确认页面是否曾被创建、修改或删除。
检查项：
- 同一路径在日志中是否稳定返回404，还是间歇出现。
- Referer是否指向站内某个已改版的栏目页。
- 请求是否来自爬虫，User-Agent是否可识别。
判断结果：若404集中在某个目录或某次发布之后，优先检查该次发布的路由或重写规则；若分散且Referer多样，更可能是旧链接未做跳转。
第四类：页面来源、内链与站点地图
确认这个URL原本是否存在、由谁引用。检查站内导航、文章正文、侧栏、页脚和站点地图中是否仍有指向该地址的链接。站点地图只用于提交候选URL，不保证收录，也不能替代跳转修复。
需要准备的证据：
- 该URL在站点地图中的记录，以及最后修改时间。
- 站内引用该URL的页面清单。
- 外部来源，例如合作方、社交媒体或历史邮件中的链接。
判断结果：如果内链仍指向旧地址，应先修正内链，再决定是否保留跳转。若只有外部链接指向旧地址，跳转规则通常是更合适的处理方式。
第五类：跳转规则、robots.txt与索引状态
在修改之前，先导出当前的跳转配置、重写规则和robots.txt内容。需要留意：robots.txt的抓取限制不等于可靠的索引移除；它只控制抓取，不控制已收录页面从结果中消失。若希望旧页面不再出现，应结合410或301等状态码处理，并分别核查不同搜索引擎的支持情况。
可执行的准备步骤：
- 保存一份当前跳转规则和robots.txt的副本，标注导出时间。
- 列出计划保留、跳转和删除的URL，形成对照表。
- 确认跳转目标页返回200，且内容与原页面主题相关。
- 修复后再次抓取样本URL，确认状态码和跳转链路符合预期。
验收信号：样本URL返回预期的301或410，跳转目标可正常访问，站内不再出现指向404地址的链接，日志中该路径的404数量在后续观察周期内下降。若状态码仍为404，说明规则未生效或请求未经过预期层，需要回到日志和配置继续定位。
下一步：把上述五类信息整理成一张对照表，按“URL—状态码—来源—日志证据—处理动作”逐行填写，再决定是修正链接、添加跳转还是保留404。
