网站死链检查_怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cc3f52d83935.html
📄
网站死链检查_怎样取得可复查的状态证据
要取得可复查的状态证据，核心是让每一次死链判断都能被第三方重新执行：记录请求的完整URL、请求时间、HTTP状态码、重定向链和最终落地页地址。只截一张“404页面”的图不算证据，因为它无法证明这个状态是稳定返回的，也无法证明检查时用的是哪个URL。
从一个假设例子看证据链怎么搭
假设某站点有一批旧文章链接，运营人员怀疑其中一部分已经失效。第一次接触这个问题时，不要急着全站扫描，先选10条链接做小样本，把过程固定下来。
- 把这10条URL原样写进一个文本文件，一行一条，不做任何改写。
- 对每条URL发一次请求，记录返回的状态码。命令行可用
curl -I只看响应头，速度快，适合批量初筛。 - 对返回301或302的URL，继续跟踪跳转，直到拿到最终状态码和最终URL。
- 把结果整理成表格：原始URL、状态码、跳转次数、最终URL、检查时间。
常见错误有三个。一是只记录“打不开”，不记录状态码，导致无法区分404、500和超时；二是遇到跳转就停下，把301当成正常，忽略了跳转终点可能仍是404；三是用浏览器打开看一眼就下结论，浏览器会缓存、会执行JavaScript、会显示自定义错误页，看到的和服务器实际返回的未必一致。
可复查的证据需要包含哪些字段
一份能被别人复核的记录，至少要有下面这些字段。缺少任何一项，复查时都可能得出不同结论。
- 原始URL：完整地址，包含协议、主机名、路径和查询参数，查询参数会影响返回结果。
- 请求方法与时间：GET还是HEAD，以及具体到分钟的检查时间。服务器内容会变，时间决定了证据的有效期。
- 状态码：首位数字决定大类，4xx是客户端错误，5xx是服务端错误，两者处理方向不同。
- 重定向链：每一跳的地址和状态码，用于判断是否存在跳转环或跳转过长。
- 最终URL与最终状态码：这才是用户和搜索引擎实际到达的位置。
把这些字段存成CSV或表格文件，比存在聊天记录里可靠得多。复查者拿到同一份清单，在相近时间重跑一遍，结果应当基本一致；如果差异很大，说明站点状态不稳定，需要先排查服务器，而不是急着改链接。
区分“可能原因”和“已经定位的原因”
检查中出现异常时，一项现象往往有多种解释，不要看到404就断定页面被删除。
- 返回404：可能是页面确实被删除，也可能是URL拼写错误，还可能是服务器配置把某些路径统一指向了404。
- 返回403：可能是权限设置拦截，也可能是防护策略误判了检查工具的请求特征。
- 返回超时：可能是目标服务器响应慢，也可能是本地网络或中间节点的问题，需要换网络环境复测。
- 返回200但内容是错误页：部分站点用200状态码返回“页面不存在”的提示，这种情况靠状态码判断不出来，需要比对页面标题或正文特征。
只有通过重复请求、更换网络、对比响应内容之后仍然一致的现象，才能写成“已经定位的原因”。在此之前，记录里应写明“疑似原因”并附上判断依据。
几个容易混淆的判断依据
做死链检查时，常有人把下面几件事当成等价证据，实际上它们说明的问题不同。
- robots.txt 的抓取限制不等于可靠的索引移除。 它只是请求爬虫不要抓取某路径，页面仍可能因为外部链接被收录，也不能用来证明某个URL已经失效。
- 站点地图不保证收录。 把URL写进站点地图只表示你希望被发现，不能作为该页面可访问的证据。
- HTTPS 不保证安全无漏洞或排名。 证书有效只说明传输层加密生效，与链接是否失效无关。
- 不同搜索引擎支持情况须分别核查。 一个URL在某个搜索引擎的结果里消失，不代表它在其他搜索引擎里也已失效，反之亦然。
因此，状态证据应当以服务器实际返回的响应为准，而不是以某个平台的结果页或工具面板为准。工具可以作为批量初筛手段，但关键URL仍要回到原始请求去核对。
下一步怎么做
先建一个只包含20到50条URL的小清单，用固定字段记录一轮完整结果，确认这套记录方式你和同事都能读懂、都能重跑。等这个小样本的复查结果稳定之后，再扩大到全站扫描，并把每次检查结果按日期归档，这样后续对比才有基线。
