站长工具死链：怎样验证修复后的响应
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7c64ff91f5d8.html
📄
站长工具死链：怎样验证修复后的响应
修复死链后，验证的核心不是“页面能打开”，而是确认原死链 URL 返回的状态码符合预期，并且该 URL 不再出现在站长工具的抓取错误列表中。具体做法：用站长工具或命令行对原 URL 发起请求，检查 HTTP 状态码是否为 200（内容恢复）或 301/302（已跳转到有效页面），同时确认返回内容与目标一致，而不是一个软 404 或错误页。
准备：先记录原死链的准确 URL 和期望结果
验证前必须有一份清单，否则无法判断修复是否生效。清单至少包含四项：原死链 URL、发现来源（站长工具的抓取错误、外链报告或日志）、修复方式、期望状态码。
- 内容已恢复：期望 200，且页面内容与原主题一致。
- 永久跳转：期望 301，指向最相关的有效页面。
- 临时跳转：期望 302，仅用于短期调整，不适合长期替代。
- 彻底移除：期望 404 或 410，前提是确认该 URL 无搜索价值、无外链。
注意，robots.txt 的抓取限制不等于可靠的索引移除。把死链 URL 写进 robots.txt 只能阻止抓取，不能保证它从索引中消失，也不能作为修复死链的验证依据。
实施：用请求工具逐条核对状态码与跳转链
最直接的验证方式是直接请求原 URL，观察响应。可以用站长工具自带的 URL 检测功能，也可以用命令行工具。以 curl 为例，假设要检查 https://example.com/old-page：
curl -I -L https://example.com/old-page
关键看两点：一是最终状态码，二是跳转链是否只有一跳。如果出现多跳跳转（A→B→C），应尽量改成 A→C，减少传递损耗和超时风险。如果返回 200 但页面显示“内容不存在”，这是软 404，需要按真实 404 处理，不能算修复完成。
批量验证时，可以只提取状态码，逐条对比清单：
curl -o /dev/null -s -w "%{http_code} %{url_effective}\n" -L https://example.com/old-page
这一步的适用条件是：你能直接访问这些 URL，且服务器没有对检测工具做特殊拦截。如果返回 403 或 503，先排查是否被防火墙或频率限制挡住，再判断修复本身是否有效。
验证：区分“已经定位的原因”与“可能原因”
请求结果异常时，不要直接断定是修复失败。同一现象可能有多种解释：
- 返回 404：可能是跳转规则未生效，也可能是请求打到了旧服务器或缓存节点。
- 返回 301 但落到无关页面：跳转目标配置错误，而非跳转机制失效。
- 返回 200 但内容为空：可能是模板渲染问题，也可能是软 404。
- 返回 5xx：通常是服务端错误，与死链修复本身无关，需要先恢复服务。
判断方法是：先用带 -L 的请求看完整跳转链，再单独请求跳转目标，确认目标页本身返回 200 且内容正确。两步都通过，才能认定这条死链修复有效。
维护：在站长工具中复查抓取错误的变化
直接请求通过后，还要回到站长工具的抓取错误或索引报告里复查。不同搜索引擎的站长工具支持情况须分别核查：Google Search Console、Bing 网站管理员工具等对错误状态的更新节奏不同，有的需要重新抓取后才会刷新。
可以执行的步骤：
- 在站长工具中对已修复的 URL 提交重新抓取（如果该功能可用）。
- 等待一段时间后，查看该 URL 是否仍显示为错误。
- 若仍显示错误，点开详情确认它记录的是最近一次抓取结果，还是历史快照。
- 对确认修复的 URL 做标记，避免重复处理。
站点地图不保证收录，把修复后的 URL 放进 sitemap 只是提供发现线索，不能替代状态码验证。HTTPS 也不保证页面安全无漏洞或排名提升，它只解决传输加密问题，与死链是否修复无关。
时间有限时，优先验证哪一类
人手有限时，按影响排序：先验证有外链指向的死链，再验证有搜索流量的死链，最后处理无外链、无流量的孤立死链。判断依据是站长工具中的外链报告和页面流量数据。对第一类，修复后必须逐条请求确认状态码；对最后一类，可以批量抽查，确认跳转规则整体生效即可。
下一步：从站长工具导出当前抓取错误列表，按外链数量排序，取前 20 条建立验证清单，逐条执行上面的请求检查并记录状态码。
