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

如何检查网站死链_改版或迁移时应核对什么

改版或迁移时检查死链，核心是核对“旧地址是否还能到达正确的新内容”。假设你把一个产品页从 /old-product 迁到 /new-product，如果旧地址直接返回 404，又没有跳转，那么用户和搜索引擎沿着旧链接进来时就会撞上死链。正确做法是：先列出迁移前后所有 URL 的对应关系，再逐条验证状态码和跳转终点，最后处理站内入口和站点地图。

先建立旧 URL 与新 URL 的对照表

不要等改版上线后再凭记忆补跳转。迁移前应导出旧站可访问的 URL 清单，来源可以包括：站点地图、站内链接抓取结果、 analytics 中的落地页报告、以及服务器访问日志。然后为每个旧 URL 指定一个目标：要么对应到新 URL，要么明确删除并返回 410。

常见错误是只处理首页和栏目页，漏掉分页、带参数的筛选页、旧图片和附件。这些地址同样可能被外部引用。若旧 URL 没有合适的新内容，不要全部跳到首页，因为那会让用户和搜索引擎无法判断对应关系，通常视为软 404 处理。

用状态码判断死链，而不是只看页面能否打开

检查时重点看 HTTP 状态码，而不是浏览器里“看起来正常”。可以用命令行逐个请求：

curl -I https://example.com/old-product

结果判断：

• 301 或 308：永久跳转，适合迁移后旧地址指向新地址。
• 302 或 307：临时跳转，迁移场景一般不应长期使用。
• 404：未找到，说明旧地址没有对应内容，属于死链。
• 410：已删除，表示内容确定不再提供，比 404 更明确。
• 200：正常返回，但还要确认返回的是不是预期的新页面，而不是错误地返回了首页。

批量检查时，可把 URL 清单交给爬虫工具或写脚本循环请求，记录状态码和最终跳转地址。注意跟随跳转后要看最终 URL，避免出现“旧地址跳到另一个旧地址，最后仍然 404”的跳转链。

核对站内链接、站点地图和 canonical

死链不只来自外部，站内入口同样会制造死链。改版后应检查：

• 导航、面包屑、正文内链是否还指向旧地址；
• 站点地图是否只包含可返回 200 的新 URL；
• 页面的 canonical 是否指向自身或正确的新地址，而不是已失效的旧地址；
• 旧地址的跳转目标是否与 canonical 一致。

需要分清：站点地图不保证收录，它只是帮助发现 URL；robots.txt 的抓取限制也不等于可靠的索引移除。若旧页面已被索引，仅靠 robots.txt 禁止抓取，未必能让它从搜索结果中消失。robots.txt 应谨慎使用，不要用禁止抓取来掩盖本应做 301 的迁移地址。

一个可执行的检查顺序

1. 导出旧 URL 清单，标注每个地址的目标新 URL 或删除决定。
2. 用 curl -I 或爬虫批量请求旧 URL，记录状态码和最终地址。
3. 筛出 404、410、302 以及跳到首页的 URL，逐条修正为 301 到最相关的新页面。
4. 重新抓取站内链接，确认没有链接指向已失效地址。
5. 更新站点地图，只保留返回 200 的 URL，并提交给对应搜索引擎。
6. 上线后再次抽查旧 URL，确认跳转终点正确、没有跳转链和循环。

如果使用 HTTPS，也要分别核查 HTTP 到 HTTPS、旧域名到新域名的跳转是否叠加正确。HTTPS 本身不保证安全无漏洞或排名，它只解决传输加密问题，不能替代死链检查。

适用条件与判断结果

这套方法适用于域名更换、目录结构调整、CMS 替换、页面批量下线等场景。判断标准很简单：旧 URL 请求后，用户应到达与旧内容最相关的新页面；若内容确实不存在，应返回 404 或 410，而不是返回 200 的空页面或一律跳首页。第一次接触时，先完成“旧 URL 清单 + 状态码抽查”这两步，就能定位大部分迁移死链。

下一步：从服务器日志或站点地图导出旧 URL 清单，先抽查 20 条最常被访问的旧地址，记录状态码与跳转终点，再决定哪些需要补 301、哪些应保留 404。