死链工具：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ea46fbd96c40.html
📄
死链工具：改动前怎样保存原始状态
用死链工具扫描出问题后，先别急着改。正确顺序是：在改动之前，把工具的原始输出、扫描配置和页面当时的实际状态完整留存下来，再动手修复。这样做的意义是：一旦修复后出现误判、漏判或新问题，你能拿改动前的记录做对照，判断是修复引入的，还是原本就存在。保存的对象不是工具本身，而是这一次扫描的输入、输出和当时页面的事实快照。
先分清要保存的三类原始状态
死链工具给出的结果只是结论，结论背后的依据才是需要留存的东西。可以按下面三类分开保存。
- 扫描配置：起始网址、抓取深度、是否跟随重定向、超时时间、User-Agent、是否包含子域、排除规则。同一批链接在不同配置下结果可能不同，配置丢了，结果就无法复现。
- 原始输出：工具导出的完整报告文件，包括每条链接的来源页、目标地址、HTTP 状态码、发现时间。不要只截图汇总数字，汇总数字无法还原到具体链接。
- 页面事实快照：被判定为死链的目标地址，在改动前返回什么状态、是否跳转、跳到哪里。这部分靠工具报告往往不够，需要单独记录。
改动前可以实际执行的操作步骤
假设你已经用某个死链工具跑完一轮扫描，准备开始修复。按以下顺序做，全程不改动任何线上内容。
- 把工具的完整报告导出为文件，文件名带上扫描日期和配置标识，例如
broken-links-20250115-depth3.csv。不要覆盖上一轮的文件。 - 单独记录本次扫描使用的参数，写在报告同目录的一个文本文件里。参数包括起始地址、深度、超时、是否跟随跳转。
- 对报告中每条待修复的目标地址，用命令行或浏览器开发者工具记录改动前的响应。重点记录状态码和
Location响应头（如果有跳转）。 - 如果目标地址是站内页面，另存一份该页面改动前的 HTML 源码，或至少保存正文文本。页面内容改动后，原始状态就找不回来了。
- 把以上文件放在同一个目录下，命名统一，避免和后续修复后的记录混在一起。
记录响应时可以用类似下面的方式，把结果追加到一个文本文件里：
curl -I -s https://example.com/old-page >> before-change-headers.txt
这里的 example.com 只是占位示例，实际替换成你要检查的地址。执行后文件里会留下状态行和响应头，这就是可以核对的原始依据。
怎么判断保存得够不够
一个简单的验收标准：如果换一个人拿着你保存的文件，能否在不访问原工具的情况下，复现出你当时看到的死链清单和每条链接的状态。能复现，说明保存到位；只能看到“共 37 条死链”这种数字，说明不够。
还要注意区分两类情况。工具报告某条链接是死链，可能的原因包括目标确实返回 404、目标超时、被 robots.txt 限制抓取、或工具本身解析异常。这些原因在改动前不一定能全部定位，所以保存时应如实记录“当时观察到的现象”，而不是直接写下“这条链接已失效”的结论。现象和结论要分开写，否则后续对照时会把推测当成事实。
改动后如何用这份原始状态做对照
修复完成后重新扫描一次，用同样的配置参数，导出新报告。然后逐条比对：
- 原来报 404 的地址，现在返回什么状态。如果变成 200 或 301，说明修复生效。
- 原来超时的地址，现在是否稳定返回。偶发超时和持续超时需要区分，可以多测几次。
- 有没有出现改动前不存在的新死链。这类新增项通常和本次修改直接相关，优先排查。
如果新报告里某条链接的状态和改动前一致，先别急着再改一次。回到保存的原始记录，确认当时记录的是现象还是结论，再决定下一步。需要提醒的是，robots.txt 里的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以工具报出的状态和搜索引擎实际处理结果可能并不一致，对照时以你自己保存的响应记录为准，不要用工具汇总数字直接推断收录情况。
下一步：挑一条本次扫描出的死链，按上面的步骤把它的配置、报告和响应头各存一份，跑通一次完整流程，再决定是否批量处理其余链接。
