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

网站死链查询，测试环境与线上怎样对照

把测试环境和线上环境放在一起做网站死链查询，关键不是两边各跑一次工具，而是先统一“查什么”，再对比“差在哪”。测试环境里出现的死链，可能是还没上线的页面或临时资源；线上出现的死链，才是真实用户和搜索引擎会遇到的。对照的价值在于：确认哪些死链是环境差异造成的误报，哪些是上线后才暴露的真实问题。

准备阶段：先对齐两边的基础条件

对照之前，先把两边的可比性建立起来。否则查出来的差异大多来自配置不同，而不是链接本身有问题。

• 确认两边爬取的入口一致：同一个首页或同一批栏目页，避免测试环境从后台入口爬、线上从前台入口爬。
• 确认协议和域名差异：测试环境常用 http 或带端口的内网地址，线上是 https 正式域名。跨协议跳转、端口写法不同，都可能被判成异常链接。
• 确认 robots.txt 与登录态：测试环境常整体禁止抓取，或需要登录才能访问。robots.txt 限制抓取不等于页面被移除索引，但它会直接让爬虫跳过页面，导致查询结果失真。两边要么都放开被查目录，要么用同一套账号权限。
• 确认数据来源版本：测试库和线上库的栏目、文章、商品数量往往不同。先记下各自的页面总数，作为后续对比的基准。

这一步最关键的是记录“基准量”。没有基准量，后面看到测试环境 20 条死链、线上 8 条死链，无法判断是环境差异还是真实退化。

实施阶段：用同一套规则分别查询

对照要成立，查询方法必须一致。建议按下面的顺序执行：

1. 选定查询范围，例如全站，或只查导航、正文链接、图片、CSS/JS 资源中的某一类。
2. 两边使用相同的爬取深度和相同的超时设置。深度不同会漏掉层级较深的页面。
3. 分别导出死链清单，字段至少包含：来源页面、目标地址、HTTP 状态码、发现时间。
4. 把两份清单按“目标地址”归一化后做差集。归一化包括去掉测试域名、统一协议、去掉无意义的查询参数。

归一化是整件事里最关键的一步。测试环境的链接通常写成 http://test.example.com/a，线上是 https://www.example.com/a。如果不先把域名和协议替换成占位符，两份清单几乎无法逐条对应，差集结果会充满噪声。

验证阶段：逐类判断差异原因

差集出来后，不要急着修，先分类。常见的三类差异及判断方法：

• 只在测试环境出现的死链：多为测试库缺少数据、临时资源未部署、内网地址未替换。判断方法是手动访问该目标地址，看返回的是 404 还是连接失败；若线上同路径正常，基本可判定为环境差异。
• 只在线上出现的死链：优先处理。可能是上线时漏传资源、旧链接未做跳转、第三方资源失效。这类是真实影响。
• 两边都出现的死链：说明问题在源头内容或模板里，测试环境没有拦住。需要回到内容管理系统或模板层排查。

验证时注意一个常见误判：某些页面在测试环境返回 200，是因为测试服务器对未知路径做了兜底跳转，而线上返回 404。这种情况下，测试环境的“正常”是假象，应以线上状态码为准，再回头检查测试服务器的兜底配置。

维护阶段：把对照变成固定动作

一次对照只能解决当下问题。多人协作时，更需要一套稳定的交接方式，减少返工。

• 把归一化规则写成固定脚本或检查清单，谁执行都用同一套，避免各人手工替换域名导致口径不一。
• 每次上线前跑一次测试环境查询，上线后跑一次线上查询，两次结果都归档，标注日期和版本。
• 对已确认的死链建立处理记录：是加跳转、改链接，还是删除来源。避免同一问题被不同人重复上报。
• 定期复查第三方资源和图片链接，这类死链往往不随版本上线出现，而是外部变化导致。

如果团队使用站点地图辅助查询，要记住站点地图不保证收录，它只说明你希望被发现的地址，不能替代实际的状态码检查。

下一步，建议你先固定一份归一化规则，再用同一入口分别查一次测试环境和线上，把两份清单的差集作为本次交付物。这样交接时对方看到的是明确的差异列表，而不是两份各自独立的报告。