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

站长工具死链怎样取得可复查的状态证据：先查什么、怎么留痕

可复查的状态证据，指的是你判断某个死链“现在返回什么状态”时，留下的可再次验证的记录：请求地址、请求时间、返回状态码、跳转终点，以及抓取时所处的环境。只截一张站长工具里的“404”列表不算证据，因为列表会变、工具口径也可能不同。下面这份清单按处理优先级排列，适合时间人手有限时先做最关键的几项。

第一步：用原始URL逐个请求，记录状态码

要查的是每条疑似死链的最终HTTP状态，而不是工具页面上的汇总数字。

• 怎么查：把死链URL复制到命令行，执行 curl -I -L -o /dev/null -w "%{http_code} %{url_effective}\n" "URL"。加 -L 是为了跟随跳转，看到终点；去掉 -L 则能看到第一跳的响应。
• 结果说明什么：返回 404 或 410 说明资源确实不可用；返回 200 说明页面仍在，工具报死链可能是抓取时点差异或跳转链问题；返回 301/302 要接着看终点是否也是错误页。
• 适用条件：单条或少量URL核查。URL数量大时改用批量脚本，但每条都要保留状态码和终点地址。

把每次请求的时间一并记下。状态码会随站点改动变化，没有时间戳的记录无法复查。

第二步：确认是不是 robots.txt 或抓取限制造成的假死链

工具显示“无法访问”不等于链接已死。抓取被限制时，工具可能把正常页面也标成异常。

• 要查什么：该URL是否被 robots.txt 的 Disallow 规则覆盖，是否需要特定 User-Agent 才能访问。
• 怎么查：打开站点根目录的 robots.txt，逐条比对该路径；再用 curl -A "指定UA" -I "URL" 换一个User-Agent请求，对比状态码是否不同。
• 结果说明什么：换UA后返回200，说明原记录是被抓取限制影响的误报；两种UA都返回404，才更接近真实死链。
• 注意：robots.txt 只能限制抓取，不能用来把已收录页面从索引中移除。需要移除索引时，应让页面返回正确的状态码，而不是靠robots屏蔽。

第三步：区分“死链”与“跳转链异常”

很多被标为死链的URL，实际是跳转链中间某一环失效，或者跳到了另一个错误页。

• 要查什么：完整跳转路径，包括每一跳的状态码和 Location 头。
• 怎么查：执行 curl -I -L --max-redirs 10 "URL"，逐行看返回的 HTTP/1.1 和 Location；也可用 curl -sIL "URL" | grep -Ei "HTTP/|location" 快速提取。
• 结果说明什么：如果中间出现 301 跳到 404，问题在跳转目标而非原始链接；如果多跳后回到自身，属于循环跳转，需要单独处理。
• 适用条件：站内做过改版、换域名或批量重定向的站点优先做这一步，它能解释大部分“工具报死链但页面看似正常”的情况。

第四步：核对站点地图与收录状态，避免误判优先级

死链是否要马上修，取决于它是否还被搜索引擎引用、是否还有外部链接指向。

• 要查什么：该URL是否出现在 sitemap 中、是否仍被索引、是否有外链指向。
• 怎么查：在 sitemap 文件里搜索该路径；用 site: 查询或搜索引擎的URL检查功能看收录状态；用外链工具或服务器日志看是否有外部来源访问。
• 结果说明什么：仍被索引且有外链的死链，返回410或做301到最相关的新页面，优先级最高；从未被收录、无外链的死链，可以排在后面处理。
• 注意：sitemap 不保证收录，提交了也不代表页面会被抓取或索引，所以它只能作为参考项，不能作为“已收录”的证据。

第五步：把证据整理成可复查的记录

证据要能被别人或未来的自己重新跑一遍。建议每条死链至少记录以下字段：

1. 原始URL和发现来源，例如站长工具报告、服务器日志或外链报告。
2. 请求时间，精确到日期和时分。
3. 请求命令或工具名称，以及是否跟随跳转。
4. 返回状态码和最终跳转地址。
5. 判断结论：真实死链、跳转异常、抓取限制误报，还是待确认。
6. 处理动作与执行日期，例如301到某URL、返回410、暂不处理。

假设某条URL在工具里显示404，你手动请求返回301并最终落到200的正常页面，那么结论应写成“跳转链正常，非死链”，而不是直接删除或改状态。这个判断依赖的是你自己请求得到的响应，而不是工具页面的标签。

时间有限时的处理顺序

先处理仍被索引、有外链、且返回404或410的URL；再处理跳转链断裂的URL；最后处理从未收录、无外链的URL。每处理一批，隔几天用同样的命令重新请求一次，确认状态码已经按预期变化。这样留下的记录才能支撑复查，也方便判断哪类问题在反复出现。