死链接修复方法，怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9da650f55cb1.html
📄
死链接修复方法，怎样取得可复查的状态证据
要取得可复查的状态证据，核心是让每一次死链接处理都留下“时间、URL、请求结果、修改内容、复查结果”这五项可独立验证的记录。假设你发现文章页 /old-guide 返回 404，把它改指向 /new-guide，此时不能只凭浏览器能打开就认为修好了。你需要保存修改前的 HTTP 状态码、修改后的状态码、跳转链路，以及搜索引擎抓取工具看到的结果，才能让后续复查有据可依。
先固定证据的最小单位：一次请求的完整记录
可复查的证据不是一句“已修复”，而是一条可以被别人重新执行并得到相同结果的记录。建议每条死链接至少保存以下字段：
- 原始 URL 与发现时间，例如
/old-guide，2025-03-10 发现。 - 发现时的状态：HTTP 状态码、是否发生跳转、跳转目标。
- 处理动作：删除、301 重定向、补回页面或修改内链。
- 处理后的状态：再次请求得到的 HTTP 状态码与最终落地 URL。
- 复查时间与复查人，以及复查时使用的请求方式。
这些字段里，HTTP 状态码是最容易被误读的一项。浏览器地址栏显示正常，可能只是页面内容被前端脚本替换，实际响应仍是 404；反过来，某些 403 也可能是目标站点屏蔽了抓取工具，而不代表页面不存在。因此状态证据要区分“人看到的页面”和“程序收到的响应”。
用命令行请求留下可复核的原始响应
最直接的方式是用 curl 记录响应头。下面是一个假设示例，用来演示记录格式，不代表任何真实站点：
curl -I -L https://example.com/old-guide
执行后重点看三处：第一，首个响应是否返回 301 或 302；第二，跳转链最终落点的状态码是否为 200；第三，跳转过程中是否出现跳向另一个 404 或跳转循环。把完整输出粘贴到工单或表格里，比只写“已重定向”更可复查。
常见错误有三种。一是只看最终页面能否打开，没有记录中间跳转；二是用浏览器缓存结果当证据，实际服务器返回的状态已经变化；三是把一次请求成功当成全部修复完成，没有覆盖内链、站点地图和外部来源中的同一 URL。判断是否真正闭环，要看同一原始 URL 在不同入口下是否都指向有效目标。
区分“已定位的原因”与“可能原因”
死链接的成因不同，证据要求也不同。若已经定位为页面被删除，处理证据就是删除记录与重定向规则；若只是疑似拼写错误，证据则是修改前后的链接文本与请求结果。不要把“可能被删除”写成“已经确认删除”，也不要把一次 404 直接归因于服务器故障。
涉及抓取限制时要注意：robots.txt 的抓取限制不等于可靠的索引移除。一个 URL 在 robots.txt 中被禁止抓取，仍然可能出现在搜索结果里；站点地图也不保证收录。HTTPS 不保证安全无漏洞或排名。若死链接处理涉及这些方面，应分别核查，而不是用一条规则解释所有现象。
复查时怎么判断证据是否合格
合格的状态证据应满足三个条件。第一，可重复：另一个人用同样的 URL 和请求方式能得到相同状态码。第二，可对照：修改前后都有记录，能看出变化。第三，可定位：记录里包含具体 URL、时间和处理动作，而不是只写“已优化”。
如果复查时发现原始 URL 仍返回 404，先检查重定向规则是否生效、是否被更高优先级规则覆盖，再检查请求是否命中了缓存或 CDN 节点。不同搜索引擎对重定向和索引的处理节奏不同，支持情况须分别核查；网页搜索、平台推荐与付费广告也应分清，不能把广告落地页可访问当成自然搜索死链接已修复。
下一步，选一条你手头已知的死链接，按“原始 URL、修改前状态码、处理动作、修改后状态码、复查时间”建一行记录，再用 curl -I -L 重新请求一次，把输出附在记录后面。这样你就有了第一条可复查的状态证据，后续所有死链接都可以沿用同一格式。
