网站死链：测试环境与线上怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /102a491754c7.html
📄
网站死链：测试环境与线上怎样对照
把测试环境和线上环境对照检查网站死链，核心是让两边用同一套URL清单、同一套抓取规则和同一套判定标准，再比较返回状态码、跳转链和页面内链接的差异。测试环境发现死链不等于线上有死链，线上发现死链也不一定能在测试环境复现，只有把两边差异归因清楚，才能决定在哪一侧修复、修复后如何验证。
先统一两边要检查的URL范围
测试环境和线上环境的域名、目录结构、参数规则往往不同，直接拿测试环境的地址去线上抓取会得到大量误报。对照前先确定一份基准URL清单，来源可以包括：线上可访问页面的站内链接、站点地图中列出的地址、以及历史访问日志中出现过的路径。测试环境则用对应的路径映射，例如线上/product/123对应测试环境/product/123，只替换域名部分。
要查的是：两边清单的URL数量和路径是否一一对应。怎么查：把两份清单按去掉域名后的路径排序，用表格做差集。结果说明：差集里的URL如果只在一边存在，先判断是环境差异还是真实遗漏，不能直接当成死链。
用相同状态码规则抓取两边
状态码是判断死链最直接的依据，但测试环境和线上可能因为鉴权、防火墙、跳转配置不同而返回不同结果。抓取时两边使用相同的请求头、相同的超时时间和相同的跳转跟随设置。
- 要查什么：每个URL返回的HTTP状态码。
- 怎么查：用命令行工具或爬虫对两份清单分别请求，记录状态码和最终跳转地址。例如
curl -I -L可以查看响应头和跳转链。 - 结果说明什么：两边都是200，说明该路径正常；一边404一边200，说明差异来自环境配置或内容缺失；两边都301到同一个新地址，属于正常跳转；两边都404，才是需要优先处理的死链。
注意robots.txt的抓取限制只影响爬虫是否允许访问，不等于页面已被索引移除，也不能用来判断死链是否存在。测试环境如果整体禁止抓取，需要改用直接请求的方式检查状态码，而不是依赖爬虫结果。
对照页面内链和跳转链的差异
死链不只出现在独立URL上，也常出现在页面内部的链接里。测试环境和线上可能引用不同的资源地址、不同的跳转目标，导致同一页面在两边的链接健康度不同。
- 要查什么：每个页面内所有
<a>标签的href目标。 - 怎么查：分别抓取两边页面，提取链接目标，去掉域名后比对。重点看测试环境是否误用了测试域名、线上是否残留了已下线的旧路径。
- 结果说明什么：如果测试页面链接指向测试域名而线上指向正式域名，属于环境差异，不算死链；如果两边都指向一个已返回404的地址，说明链接本身需要更新。
跳转链也要对照：线上为了兼容旧地址可能配置了301，测试环境没有配置，于是测试环境显示404而线上正常。这种情况要在测试环境补齐跳转规则，而不是去修改线上。
区分环境差异和真实死链
对照的目的不是让两边完全一样，而是找出哪些差异会导致用户或搜索引擎遇到死链。可以用下面的检查项逐条判断：
- 测试环境返回404、线上返回200：通常是测试环境缺少内容或路由配置，优先修测试环境。
- 测试环境返回200、线上返回404：说明线上存在真实死链，需要修复线上链接或补跳转。
- 两边返回不同跳转目标：检查哪一边的目标是可访问的，以可访问且符合当前URL规则的一侧为准。
- 两边都返回404：确认为死链，按影响范围决定是恢复页面、设置跳转还是移除链接。
站点地图中列出的地址不保证被收录，也不能作为判断死链是否已解决的唯一依据。HTTPS同样不保证页面安全无漏洞，也不代表链接一定有效。判断死链仍以实际请求返回的状态码和跳转结果为准。
修复后的验证步骤
确定修复方案后，先在测试环境执行修改，再用同一份URL清单重新抓取测试环境，确认目标URL返回200或预期的301。然后把修改同步到线上，用相同清单再抓取一次线上，比较修复前后的状态码变化。如果线上使用CDN或缓存，需要确认缓存刷新后再验证，否则可能仍返回旧结果。不同搜索引擎对跳转和索引的处理方式不同，需要分别用各搜索引擎的抓取工具核查，不能因为一个渠道正常就认为全部正常。
下一步：从线上访问日志或站点地图导出最近一批URL，按本文清单在测试环境和线上各抓取一次，把状态码不一致的路径单独列出来，逐条判断是环境差异还是真实死链，再决定修复位置。
