死链测试工具：测试环境与线上怎样对照？先统一口径再比对结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d912efda26e8.html
📄
死链测试工具：测试环境与线上怎样对照？先统一口径再比对结果
测试环境与线上的死链结果对不上，通常不是工具本身出错，而是两边抓取的入口、链接范围和响应状态不在同一口径。正确做法是：先固定一套可复现的抓取规则，再分别跑测试环境和线上，最后按“同一URL、同一状态、同一来源页”逐条比对，而不是直接比较两份报告的总数。
先确认两边到底在测什么
死链测试工具给出的结果，取决于它从哪里开始抓、跟不跟随跳转、是否带登录态、是否执行页面脚本。测试环境常带基础认证、内网域名、未发布的草稿页面，线上则可能有CDN、WAF或重定向规则。两边条件不同，结果自然不同。
对照前先列出四项：起始URL、抓取深度、是否渲染JavaScript、请求头与Cookie。四项中任何一项不同，都应视为两套独立测试，而不是同一测试的两个副本。
用同一份URL清单做对照
比总数意义不大，比同一批URL的状态才有意义。可以先把线上已收录或已上线的URL导出成清单，再让工具分别请求测试环境和线上地址。
例如线上地址是 https://example.com/a，测试环境是 https://test.example.com/a，就按路径一一对应替换域名后请求。假设测试环境某条返回404、线上返回200，说明该页面在测试环境缺失，属于环境差异；若两边都返回404，才是真正需要修的死链。这里的状态码只是示例，实际以工具返回为准。
- 两边都404：优先修，属于真实死链。
- 测试404、线上200：测试环境数据或路由缺失，不影响线上，但要补测试数据。
- 测试200、线上404：上线遗漏或配置差异，风险最高，需立即核对发布流程。
- 两边都301/302：检查跳转目标是否也有效，避免跳转链末端仍是死链。
区分“可能原因”与“已经定位的原因”
看到两边结果不同，不要直接断言是工具问题。可能原因包括：测试环境未同步线上数据、robots.txt 在测试环境禁止抓取、线上有重定向而测试没有、CDN缓存了旧状态、页面依赖接口在测试环境返回错误。已经定位的原因，必须能通过一次复现说明：同一URL、同一请求头，在两边得到不同状态码，并排除缓存与登录态影响。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，它只影响爬虫抓取行为，不能代替删除页面或返回410。站点地图也不保证收录，HTTPS 不保证安全无漏洞或排名。这些规则在不同搜索引擎的支持情况须分别核查，对照死链时同样不能把“工具没报错”当成“线上一定没问题”。
处理与复查步骤
- 固定抓取配置：相同起始URL、深度、User-Agent、是否渲染脚本、超时时间。
- 分别导出两份结果，字段至少保留来源页、目标URL、状态码、跳转链。
- 按路径对齐，标记“仅测试异常”“仅线上异常”“两边异常”三类。
- 仅线上异常优先处理；仅测试异常检查环境数据与权限；两边异常进入修复队列。
- 修复后只复查受影响URL，并再次用同一配置跑一遍，确认状态码变化符合预期。
复查时要看跳转链是否收敛到200，而不是只看首个响应。若某条链接从404变成301但目标仍是404，问题并未解决。
把对照结果变成可执行的检查项
每次发布前，用同一份URL清单在测试环境跑一次，记录与线上的差异；发布后再对线上跑一次，确认没有新增404或异常跳转。差异清单本身就是发布检查项，比单看死链总数更能定位问题。下一步，先固定抓取配置并导出两边同一批URL的状态，再按上面的分类处理。
