死链检查方法：测试环境与线上怎样对照

📍 WDQWDWQD987AAAAA:216.73.217.115
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4dd16009e092.html
📄

死链检查方法：测试环境与线上怎样对照

测试环境和线上环境的死链检查结果通常不会完全一致，因为两者的URL结构、抓取范围、访问控制和服务响应都可能不同。正确做法是：先在测试环境用限定范围的爬虫跑一遍，把结果按“仅测试环境出现”和“两处都出现”分类，再对线上做抽样验证。不要直接把测试环境的死链清单当成线上修复清单，也不要指望一次全站爬取就能覆盖所有入口。

两个环境的结果为什么会对不上

死链检查的核心是让爬虫沿着链接访问并记录返回状态。测试环境与线上的差异主要来自四个方面：

因此，对照的目的不是追求两边结果相同，而是判断某个死链是“代码或模板问题”还是“环境配置问题”。前者两边都会出现，后者只在一边出现。

对照检查项：逐条比对才有结论

建议对每个疑似的死链记录以下字段，再横向比较：

  1. 完整请求 URL：包括协议、主机、路径、查询参数，不要只记路径。
  2. HTTP 状态码：区分 404、410、301、302、403、401、5xx。301/302 不是死链，但要看最终落点是否有效。
  3. 来源页面：这个链接从哪个页面被发现，是导航、正文还是站点地图。
  4. 链接类型：<a> 普通链接、图片 <img> 的 src、脚本请求、还是重定向链中的一环。
  5. 是否需要登录：测试环境被拦截的请求，先放行再复测。

判断规则可以简化为：两边都返回 404，且来源页面相同，基本可判定为模板或内容里的真实死链；只在测试环境 404、线上 200，多半是数据差异或路径前缀问题；只在线上 404、测试环境 200，优先怀疑线上重定向、缓存或发布遗漏。

具体操作步骤：先测试后线上，再抽样核对

下面是一套可直接执行的对照流程，假设你使用任意一种站点爬取工具（命令行或图形界面均可）。

  1. 测试环境限定范围爬取：只爬测试域名，设置并发数低一些，关闭“跟随外部链接”。如果站点需要登录，先配置好会话或 Cookie。爬完后导出状态码非 200 的 URL 列表。
  2. 过滤误报：删掉因登录跳转产生的 401/403，删掉测试环境特有的临时路径。剩下的是“测试环境疑似死链”。
  3. 线上抽样验证：不要立刻全站爬线上。先取测试清单里的 URL，把主机名替换成线上域名，逐个请求，记录状态码。这一步可以用 curl -I 或浏览器开发者工具完成。
  4. 反向抽查：再从线上随机抽一批页面，用同样工具爬取，看是否存在测试环境没暴露的死链。反向抽查能发现只在线上生效的重定向或已删除内容。
  5. 分类归档：把结果分成“两边都死”“仅测试死”“仅线上死”三类，分别交给开发、运维或内容编辑处理。

适用条件：这套流程适合有独立测试域名的站点。如果测试和线上共用同一套内容管理系统、只是数据库不同，重点放在数据差异上；如果测试环境根本无法被外部爬虫访问，就先在本地用渲染后的 HTML 做链接提取，再拿提取出的 URL 去线上验证。

几个容易踩的判断误区

robots.txt 限制抓取不等于链接已移除。测试环境如果禁止爬虫，你看到的“无法访问”是抓取限制，不是死链。要单独确认该 URL 是否真的返回 404。反过来，把死链加进 robots.txt 也不能替代修复，它只是阻止抓取，不改变链接本身失效的事实。

站点地图不保证收录，也不能当死链清单。站点地图里列出的 URL 仍可能 404，爬虫是否抓取由各搜索引擎自行决定。对照时可以把站点地图当作链接来源之一，但不能假设里面的地址都有效。

HTTPS 不代表安全或排名，也不影响死链判断。协议从 HTTP 换成 HTTPS 后，旧链接如果没有正确 301，才会产生死链。检查时要把协议变化单独列出来看。

不同搜索引擎和平台对同一状态码的处理不同。404 和 410 在索引移除上的表现需要分别到各搜索引擎的站长平台核查，不要用一套结论套用所有平台。付费广告的落地页死链检查逻辑与自然搜索也不同，应分开处理。

下一步：先确定你的测试环境能否被爬虫正常访问。如果不能，就从线上抓取结果反推模板中的链接规则，再回到测试环境做定点验证，而不是强行全站对照。

图1 图2
nginx