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

网站死链检测：改版或迁移时应核对什么

改版或迁移时，网站死链检测要核对的不只是“有没有 404”，而是旧地址是否被正确替换、重定向链是否干净、站内链接与站点地图是否同步更新。常见误解是：只要新页面能打开，旧链接失效无所谓。实际上，旧地址若直接返回 404 或跳到无关页面，用户和搜索引擎都会丢失原有路径，协作交付时也容易互相甩锅。正确做法是先锁定旧 URL 清单，再逐条确认去向，最后用工具和抽查复核。

先核对旧 URL 清单是否完整

改版前应导出旧站可访问页面的地址列表，来源可以包括：

• 旧站站点地图中的 URL；
• 服务器访问日志里近期有流量的路径；
• 站内导航、文章正文、按钮等内部链接；
• 已知的外部合作链接或广告落地页。

多人协作时，这份清单要指定唯一负责人维护，避免设计、开发、运营各拿一份不同版本。核对结果是：清单缺项越多，迁移后出现死链的概率越高。适用条件是改版范围涉及路径变化；如果只是换模板、URL 完全不变，重点转为检查新页面是否仍返回 200。

重定向要核对目标与层级

旧地址迁移到新地址，常用 301 重定向。需要核对的是：

1. 旧 URL 是否直接跳到最终新 URL，而不是先跳中间页再跳一次；
2. 重定向目标是否与旧页面主题一致，不能全部指向首页；
3. 是否形成循环跳转，例如 A 跳 B、B 又跳回 A；
4. 是否出现重定向链过长，导致加载变慢或抓取失败。

若旧页面已无对应内容，返回 404 或 410 比强行跳首页更合适。这里没有统一答案，判断依据是用户意图：旧页面讲的是某产品，跳到同类新产品页可以接受；跳到首页则通常算错配。检查时可用浏览器开发者工具查看网络请求状态码，或使用支持批量检查的爬虫工具。注意，robots.txt 的抓取限制不等于可靠的索引移除，若旧地址被 robots 禁止抓取，搜索引擎可能无法看到你的重定向。

站内链接与站点地图要同步更新

改版后常见死链不是来自外部，而是来自站内：导航、面包屑、文章推荐、页脚等仍指向旧地址。核对项包括：

• 全站导航和页脚链接是否已换新；
• 文章正文中的内链是否仍可访问；
• 新站点地图是否只包含可访问的最终 URL；
• 站点地图中的地址是否与页面实际返回状态一致。

站点地图不保证收录，它只是帮助发现 URL。若站点地图里混入 404 或重定向地址，会降低协作交付质量。多人协作时，建议在合并代码前跑一次全站爬取，把非 200 状态码的 URL 导出为待办清单，分配给对应负责人。

交付前做一次可复现的抽查

工具报告不能替代人工抽查。可以按以下步骤执行：

1. 从旧 URL 清单中随机抽取 20 至 50 条，覆盖栏目页、详情页、图片和下载文件；
2. 逐条访问，记录最终状态码和最终地址；
3. 对重定向条目，确认目标页面标题与旧页面主题一致；
4. 把异常项按“已定位原因”和“可能原因”分开记录，例如“已定位：目标 URL 拼写错误”与“可能原因：服务器规则未生效”。

判断结果是：若抽查中异常比例较高，应回到全量清单重新核对；若仅个别异常，可单独修复后复测。适用条件是时间有限、无法全量人工验证的迁移项目。注意，HTTPS 不保证安全无漏洞或排名，它只说明传输层加密，与死链是否修复无关。

把核对结果写成可交接的清单

为了减少返工，交付物应包含：旧 URL、新 URL、状态码、重定向类型、负责人、复核结果。若某条旧地址暂时没有对应新页面，明确标记为“保留 404”或“待补内容”，不要留空。下一步可以选一个旧栏目做小范围试跑：导出该栏目 URL，逐条核对重定向和站内链接，确认流程顺畅后再推广到全站。