验证死链修复是否生效,核心不是看后台“已删除”或“已替换”的提示,而是看原死链 URL 返回给爬虫和用户的 HTTP 状态码、跳转目标与页面内容是否一致。修复后应达到:原 URL 不再返回 404/410,而是返回 200 或 301 到最相关的新页面;同时该新页面可被抓取、可被索引,且内容与旧链接意图匹配。只把链接从导航里删掉,不等于修复完成。
处理死链通常有两种方案,验证方式不同。
如果旧页面只是暂时维护,应返回 503 而不是 404;如果内容永久消失且没有替代页面,返回 410 比 404 更明确。把 404 全部跳转到首页,通常不算有效修复,因为用户和搜索引擎无法从首页找到原内容对应信息。
最直接的检查是看 HTTP 响应。可以用浏览器开发者工具的 Network 面板,也可以用命令行工具。以下命令只作为示例,实际域名和路径需替换:
curl -I https://example.com/old-page
重点看三行:
HTTP/1.1 301 或 200:说明旧地址已不是死链。Location: https://example.com/new-page:说明跳转目标明确。200:说明最终落地页可访问。如果返回 302,要判断是否为临时跳转。302 不会像 301 那样稳定传递原 URL 的权重信号,长期使用应改为 301。如果出现 301 跳到 301 再到 200 的多级跳转,应尽量缩短为一跳,减少爬虫和用户等待。
状态码正确不代表修复完成。新页面还需要满足抓取和索引条件:
<meta name="robots" content="noindex">,否则它不会进入索引。可以提交站点地图辅助发现,但站点地图不保证收录。它只是告诉搜索引擎有哪些 URL 可抓,最终是否收录仍取决于页面质量、抓取预算和索引策略。
修复后应再查一遍站内入口,避免只修了旧 URL 却还有内链指向它。可以用站内搜索、爬虫工具或数据库查询找出所有引用旧 URL 的位置。检查项包括:导航、面包屑、文章正文、相关推荐、站点地图、RSS 和结构化数据中的 URL。
如果服务器日志可用,观察修复后一段时间内旧 URL 的请求状态:请求旧 URL 时是否出现 301,请求新 URL 时是否出现 200,而不是继续出现 404。日志还能暴露跳转链过长、新页面被 robots.txt 拦截或返回 5xx 等问题。不同搜索引擎的抓取和索引行为要分别核查,不要因为一个搜索引擎已更新就认为全部完成。
可以按下面清单判断修复是否通过:
常见误判包括:只删了导航链接就认为死链消失;把 404 全部 301 到首页;只检查浏览器能打开,不检查状态码;以及把 HTTPS 当成安全与排名的保证。HTTPS 不保证安全无漏洞或排名提升,它只是传输层条件之一。
下一步可以选一个已修复的旧 URL,用 curl -I 连续检查旧地址和新地址的状态码、跳转目标和最终页面,再把结果与站内链接清单对照,确认没有遗漏入口。