死链检测_怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5ffe4481e738.html
📄
死链检测_怎样取得可复查的状态证据
可复查的状态证据，指任何人拿到你记录的URL、检测时间、请求方式、返回状态码和跳转链后，能独立复现同一结论。只截一张“404”图、只写一句“已检查”都不算。正确做法是：对每个待查URL发起一次可记录的HTTP请求，保存状态码、最终URL、重定向过程和响应时间，并注明检测工具、时间与时区。如果返回200，也不能直接判定为有效页面，还要看内容是否为软404或空壳页。
常见误解：状态码200就等于链接正常
很多项目把“返回200”当作死链检测的终点，这是最容易出错的地方。服务器可能对不存在的页面返回200，再显示“内容不存在”；也可能返回一个空模板、登录页或错误提示页。这类页面在状态码层面是通的，在用户体验和抓取层面却接近死链。判断时要把状态码与页面内容特征分开记录，例如标题是否包含“404”“页面不存在”、正文长度是否异常、是否跳转到首页。
另一个误解是“检测一次就够”。页面会改版、栏目会下线、外部链接会失效，所以证据必须带时间戳。没有时间的状态记录，无法判断它是当前结果还是历史结果。
用可复现的请求取得基础证据
最直接的方法是用命令行工具对单个URL发起请求，并保留完整输出。下面以curl为例，它适合小批量抽查和复核：
curl -o /dev/null -s -w "%{http_code} %{url_effective} %{time_total}\n" -L "https://example.com/page"
这条命令会输出最终状态码、最终URL和总耗时。参数-L表示跟随重定向，-o /dev/null表示丢弃响应体。执行后把输出粘贴到检测记录里，就得到了一条可复查证据。若要看完整跳转链，可改用curl -I -L查看响应头，或使用带重定向明细的检测脚本。
批量检测时，应把URL列表、检测脚本版本、执行时间、时区和输出文件一起归档。不要只保留“失败数量”这类汇总数字，因为汇总无法复查单个URL。
状态码之外还要记录哪些检查项
- 重定向链：记录每一跳的URL和状态码，确认是否出现循环跳转或跳转到无关页面。
- 最终URL：判断是否被301或302带到了首页、登录页或错误页。
- 响应时间：超时和连接失败要单独标记，不能与404混为一类。
- 页面特征：对返回200的URL，检查标题、正文长度和错误提示词，识别软404。
- robots.txt限制：记录该URL是否被robots.txt禁止抓取。被禁止抓取不等于页面已被移除，也不等于可以放心保留，它只是抓取限制，不能作为索引移除的可靠证据。
内链、外链和站点地图要分开取证
站内死链检测的对象是页面里指向本站的链接；外链检测的对象是其他站点指向你的链接。两者取证方式不同：内链可以直接从页面HTML中提取，外链需要借助第三方数据或搜索指令，且不同来源覆盖范围不同。站点地图只能说明你提交了哪些URL，不保证这些URL会被收录，也不能用来证明链接是否有效。
如果项目已有页面，改进顺序建议是：先检测导航、面包屑和正文内链，再检测站点地图中的URL，最后处理外部链接。每类结果分别建表，不要混在一张表里得出“死链总数”，否则无法定位修复责任。
怎样判断证据是否足够复查
拿一条记录问三个问题：第一，别人能否用同样的URL和请求方式得到同样状态码；第二，记录里是否有检测时间和时区；第三，返回200时是否有内容层面的判断依据。三项都满足，才算可复查证据。若只有截图，没有请求方式、时间和最终URL，遇到争议时无法复核。
对于HTTPS页面，还要注意证书错误和协议跳转。HTTPS不保证页面安全无漏洞，也不保证排名，它只说明传输层加密。检测时应把证书错误、连接超时和HTTP状态码分开记录，避免把网络问题误判为死链。
下一步，选一个你负责的页面，用上面的curl命令抽查三条内链，把状态码、最终URL、检测时间和时区写进同一张表。若发现返回200但内容是错误提示，把它标记为软404，再决定是修复链接还是设置正确的404状态码。
