如何检查网站死链，怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e67d8e9e005f.html
📄
如何检查网站死链，怎样取得可复查的状态证据
要取得可复查的状态证据，核心是让每一次死链判断都能被第三方按相同步骤复现：记录完整URL、请求时间、HTTP状态码、重定向链和最终落地页，并保留原始响应头或截图。只凭浏览器显示“404”不够，因为缓存、登录状态、地区差异和前端渲染都可能改变结果。下面是一份可执行清单，每项都说明查什么、怎么查、结果说明什么。
检查前先固定测试条件
在开始抓取或点击之前，先记录测试环境，否则后续结果无法对比。需要固定的条件包括：使用的设备与网络、是否登录、User-Agent、请求时间、是否跟随重定向。可以用命令行工具保存原始响应，例如：
curl -I -L -A "Mozilla/5.0" https://example.com/page
结果说明：如果返回200，说明该请求路径当前可访问；如果返回301或302，要记录Location头指向哪里；如果返回404或410，说明服务器明确表示资源不存在。注意，curl默认不执行JavaScript，若页面内容由前端渲染，状态码正常但正文可能为空，这时需要换用能执行JS的检查方式。
逐项记录死链证据
对每个疑似死链，至少保存以下字段，才能称为可复查：
- 完整URL：包含协议、域名、路径和查询参数，不要只写“某个页面”。
- 请求时间：精确到分钟，便于判断是否与服务器变更或缓存过期有关。
- HTTP状态码：如200、301、404、410、500，区分“页面不存在”和“服务器临时错误”。
- 重定向链：记录每一跳的地址和状态码，判断是否出现循环或过长跳转。
- 最终落地页：用户实际看到的页面，确认是否跳到了首页或无关内容。
- 原始响应头：保存
curl -I输出或浏览器开发者工具Network面板的截图。
结果说明：如果状态码是404且没有重定向，可以判定为死链；如果是500，只能说明服务器当时出错，需要稍后复测，不能直接当作永久死链；如果是301但最终落地页与原文无关，属于“软404”或错误重定向，也应记录为问题。
用站点地图和站内链接交叉验证
单点检查容易漏掉隐藏入口。可以导出站点地图中的URL列表，再与站内链接抓取结果对比。检查项包括：站点地图里列出的页面是否全部返回200；站内导航、正文和页脚中的链接是否指向已失效地址；是否有页面只被站点地图引用而没有任何内部链接。结果说明：站点地图不保证收录，也不保证页面可访问，它只是候选清单；如果站点地图中的URL返回404，说明提交的地址本身已经失效，需要先修正来源。
区分robots.txt限制与真实死链
如果抓取工具报告某URL被阻止，先查看robots.txt是否禁止了对应路径。可以用：
curl https://example.com/robots.txt
结果说明：被robots.txt禁止抓取，不等于该页面不存在，也不等于它已从索引移除；它只是告诉爬虫不要抓取。要判断真实状态，仍需用允许的User-Agent或直接请求确认HTTP状态码。反过来，一个页面返回200但被robots.txt阻止，也不能当作可正常收录的证据。不同搜索引擎对robots.txt和索引移除的支持方式不同，需要分别核查。
复测与证据归档
死链可能由临时故障、CDN缓存、服务器重启或发布失误造成。建议在首次发现后间隔一段时间复测一次，并保存两次结果。若两次都返回404，可判定为稳定死链；若一次404一次200，说明状态不稳定，需要检查缓存、负载均衡或发布流程。归档时按“URL—时间—状态码—重定向—最终页—工具输出”整理成表格，任何人按同样命令都能得到相同结果，这才算可复查的状态证据。
下一步：选一个你怀疑的URL，用curl -I -L保存响应头，再与浏览器开发者工具中的Network记录对比；如果两者状态码不一致，优先排查缓存、登录状态和User-Agent差异。
