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

死链接：改动前怎样保存原始状态

改动前保存原始状态，核心是留下三份可回看的资料：改动前的链接清单、页面当时的响应状态、以及改动操作记录。只截图不够，因为截图无法批量比对；只记在脑子里更不行，因为死链接处理往往要跨天甚至跨人。正确做法是把“现状”固化成文件，再动任何链接、重定向或页面内容。

先确定要保住的原始状态包含什么

针对死链接，原始状态至少包含四类信息，缺一项后面就可能说不清问题从哪来：

• 链接清单：站内所有指向目标页面的链接，包括导航、正文、侧栏、页脚、站点地图中的链接。导出为 CSV，保留来源页 URL、链接文字、目标 URL 三列。
• 响应状态：每个目标 URL 改动前的 HTTP 状态码，如 200、301、404、410。用爬虫工具或命令行逐条记录，不要只记“能打开”或“打不开”。
• 页面快照：对即将改动的页面保存 HTML 源码和渲染后截图。源码用于比对链接位置，截图用于确认视觉呈现。
• 操作记录：谁在什么时间改了什么。哪怕只有你一个人操作，也要写下来，因为排查时无法凭记忆还原顺序。

如果目标页面本身要删除或改地址，还要额外保存它原来的 canonical 标签、robots 元标签和重定向规则。这些信息决定了后续能否正确恢复或替换。

用一条命令保存可核对的链接状态

假设你已有一份 URL 列表文件 urls.txt，每行一个地址。改动前执行下面的命令，把状态码和最终地址存下来：

while read u; do curl -o /dev/null -s -w "%{http_code} %{url_effective}\n" "$u"; done < urls.txt > before-status.txt

这条命令逐条请求并输出状态码与最终 URL。适用条件是你能在本地或服务器上运行 curl，且目标站点允许正常访问。判断结果时注意：输出 200 表示当时可访问，301 或 302 表示当时已有跳转，404 或 410 表示当时已不可用。如果输出为空或连接失败，说明请求本身没完成，不能当作“页面正常”。

把 before-status.txt 和 urls.txt 一起存档，并标注保存时间。之后任何改动都可以用同样命令生成 after-status.txt，逐行对比差异。

保存页面源码和链接位置

状态码只说明目标地址是否可达，不说明链接出现在哪里。改动前还需要保存来源页的 HTML，并标出死链接所在位置。

1. 用浏览器“查看网页源代码”或爬虫工具导出页面 HTML，文件名带上页面路径和日期。
2. 在源码中搜索目标 URL，记录它出现在第几行、属于导航还是正文、是否带 nofollow 或 target 属性。
3. 如果链接由 JavaScript 动态插入，源码中可能搜不到。此时用开发者工具的元素面板确认最终生成的 <a> 标签，并保存渲染后的 DOM 快照。
4. 对关键页面截图，确保截图包含链接可见区域和浏览器地址栏。

这样做的目的是：改动后如果发现某个位置漏改或改错，可以对照原始源码逐处还原，而不是靠印象重新找。

改动前必须确认的三项检查

保存完资料后，动手前再核对三项，避免把“保存”变成“已经改过”：

• 文件是否可读：打开保存的 CSV 和状态文件，确认没有乱码、没有空行、行数与 URL 数量一致。
• 时间是否记录：在文件名或文件首行写明保存日期和时间，精确到分钟。多个版本时按时间排序，不要用“最终版”“新版”这类无法排序的名字。
• 责任是否明确：如果多人协作，在操作记录中写明谁负责保存、谁负责改动、谁负责验收。验收人应独立于改动人，至少能对照原始文件检查。

这三项检查的适用条件是：改动会影响线上可访问链接，或改动后需要向他人说明原因。如果只是本地测试且不涉及线上，可以适当简化，但仍建议保留 URL 列表和状态输出。

从交付结果倒推需要留下的证据

假设最终要交付的是“死链接已修复且未引入新问题”这个结果，那么改动前保存的原始状态就要能支撑三件事：证明修复前确实存在死链接、证明修复只改了目标链接、证明修复后状态符合预期。因此，原始状态文件应至少保留到验收完成之后，而不是改完就删。

下一步：先列出你准备改动的所有 URL，生成 urls.txt，执行上面的 curl 命令保存 before-status.txt，再导出对应页面的 HTML 和截图。完成这些之后，再开始改链接或加跳转。