404 not found改版或迁移时应核对什么：先抓取、再比对、后验收
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3c3a13a214dd.html
📄
404 not found改版或迁移时应核对什么：先抓取、再比对、后验收
改版或迁移时核对 404 not found，核心不是看页面是否“长得像原来”，而是确认三件事：旧 URL 是否仍返回 404、404 是否被错误地当成正常跳转、以及本该保留的页面是否被误删或误改路径。只有先拿到状态码、响应头和跳转链路的证据，才能判断问题出在服务器、CDN、应用路由还是链接本身。
先确认 404 是真实状态码，而不是软 404
很多迁移事故里，页面显示“404 not found”，但服务器实际返回的是 200 OK，这叫软 404。它对用户和搜索引擎都不友好，因为抓取工具会把它当作正常页面处理。核对时要用命令行或浏览器开发者工具查看响应头，而不是只看页面文字。
- 检查
HTTP/1.1或HTTP/2状态行是否真的是404。 - 检查响应头里是否有
Content-Type: text/html，避免把图片、JS 或接口的 404 混在一起判断。 - 如果站点用了单页应用，确认服务端是否对未知路径统一返回
200再由前端渲染 404 页面。
适用条件：任何改版、换域名、换目录结构、换 CMS 或换 CDN 后都适用。判断结果：若状态码为 200 而页面内容是 404，应优先修服务端路由或 CDN 回源规则，而不是只改页面文案。
把旧 URL 清单和当前响应逐条比对
迁移前应有一份旧站 URL 清单，来源可以是站点地图、日志、内链抓取结果或历史备份。迁移后逐条请求这些 URL，记录状态码、最终 URL 和跳转次数。不要只抽几个首页或栏目页，因为 404 往往集中在深层文章、分页、标签页和附件页。
- 导出旧 URL，去掉参数和重复项，保留路径部分。
- 用脚本或抓取工具批量请求，输出状态码和
Location头。 - 把结果分成四类：正常 200、301/302 跳转、404、其他错误。
- 对 404 项确认是“本来就不该存在”还是“迁移遗漏”。
假设一个旧站有 /old-guide/，迁移后新地址是 /guide/。如果请求旧地址返回 404，而新地址正常，说明缺少重定向；如果旧地址返回 301 到新地址，则说明跳转已配置。这里的关键不是跳转数量，而是最终落地页是否与旧内容主题一致。
检查重定向链和跳转终点
404 not found 有时不是直接出现，而是跳转链断在中间。例如旧 URL 跳到中间页，中间页再跳到新 URL，但中间页被删除，最终返回 404。核对时要看完整跳转链，而不是只看第一次响应。
- 确认跳转是否超过两跳，过长链路会增加失败概率。
- 确认跳转终点是否仍返回 200，且内容与旧页面相关。
- 确认是否把大量旧 URL 统一跳到首页，这种做法对用户和抓取都不理想。
- 确认
Location头里的地址是否使用了正确协议和域名。
适用条件：换域名、换目录、合并栏目、下线旧产品时尤其需要。判断结果：若跳转终点是首页或无关栏目，应改为最接近的对应页面；若链路中断，应补上缺失的中间跳转或直接改为一步跳转。
区分 robots.txt、站点地图和索引移除的作用
robots.txt 的抓取限制不等于可靠的索引移除。即使 robots.txt 禁止抓取，已经收录的 URL 仍可能出现在搜索结果中。站点地图也不保证收录，它只是帮助发现 URL。迁移时不要把“提交站点地图”当成解决 404 的唯一手段。
- 若页面已删除且无替代内容，应返回真实 404 或 410，而不是用 robots.txt 掩盖。
- 若页面有替代内容，应配置 301 跳转，并确保目标页可抓取、可索引。
- 若页面只是暂时下线，考虑 503 而非 404，但需确认维护周期和服务器配置。
- 不同搜索引擎对 404、410、软 404 的处理方式需分别核查，不能假设完全一致。
验收信号与下一步
验收时看四个信号：旧 URL 清单中应有跳转的条目不再返回 404；真实 404 页面返回 404 状态码而非 200；跳转链不超过两跳且终点内容相关；站点地图和内部链接不再指向已删除地址。若这些信号不满足，先修服务端状态码和跳转规则，再重新抓取比对。
下一步可以选一批旧 URL，用命令行请求响应头，记录状态码和跳转终点，形成一份可复查的迁移核对表。
