死链检测工具改动前怎样保存原始状态：多人协作交付清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3484d5f1c1c3.html
📄
死链检测工具改动前怎样保存原始状态：多人协作交付清单
用死链检测工具跑出的结果，在改动之前必须先固定成可追溯的原始状态：把扫描配置、原始响应、报告文件和时间点一起留档，并让改动人、复核人都能拿到同一份副本。这样做的目的不是形式主义，而是让“改前是什么样”有据可查，避免改完以后争论某个链接原本是 404、超时还是被 robots.txt 拦截。
先固定扫描范围与配置
要查的是这次扫描到底覆盖了什么。进入工具的扫描设置，记录起始 URL、是否跟随站内链接、是否包含子域、是否排除特定目录、并发数与超时时间。判断结果时注意：同一批 URL 在超时 5 秒和 30 秒下可能得到不同结论，配置不同就不能直接对比两次结果。
可执行动作：把配置页截图或用 curl 抓一份站点地图清单，存为 scan-config.txt，写清扫描日期与执行人。适用条件是多人共用同一工具账号；如果每个人本地配置不同，必须各自留一份。
保存原始报告而不是只看汇总数
要查的是报告文件本身，而不是仪表盘上的“共发现 37 个死链”这类数字。导出 CSV 或 JSON 原始报告，保留每一行的完整 URL、HTTP 状态码、错误类型、发现时间、来源页面。判断结果时，如果只有汇总数，无法确认某个链接是被判定为 404 还是 DNS 解析失败，后续修复方向完全不同。
- 检查项：导出文件是否包含状态码列和来源页列。
- 检查项：文件命名是否带日期，例如
broken-links-2024-06-01.csv。 - 结果说明：缺少来源页列时，修复人无法定位链接出现在哪篇文章，返工概率明显上升。
记录改动前的页面快照
要查的是被改动页面在扫描时的实际内容。对确认要修改的页面，用浏览器保存完整网页或用 curl -I 记录响应头，重点看状态码、跳转链和 rel="canonical"。判断结果时注意：robots.txt 的抓取限制不等于可靠的索引移除，如果原始状态里有被 robots.txt 屏蔽的 URL，不能因为工具报错就断定它一定是死链。
可执行动作：对每个待改 URL 执行一次 curl -I -L，把输出追加到 before-headers.txt。适用条件是链接数量在几十条以内；数量很大时优先保存工具导出的原始报告，再抽样记录响应头。
建立改动对照表并锁定版本
要查的是“改前”和“改后”能否一一对应。建一张表，至少包含四列：原始 URL、原始状态、改动动作、改动后状态。判断结果时，如果某条记录只有“已修复”三个字，没有原始状态码，复核人无法验证修复是否真的发生。
- 把原始报告复制一份，命名为
before，只读保存，不再编辑。 - 在副本上逐条标注处理意见，例如“301 到新地址”或“删除该链接”。
- 改动完成后重新扫描，导出
after报告，与before按 URL 对齐比较。 - 把两份报告和对照表放在同一交付目录，写一份简短说明：扫描时间、工具版本、配置差异。
适用条件：多人协作时，before 文件应放在共享目录并设置只读权限，避免有人在原文件上直接改数。判断结果的标准是：任何一条链接都能从 after 反查到 before 的原始状态，且能找到对应的改动记录。
交付前的最低检查项
要查的是原始状态是否真的可还原。检查以下三项：原始报告能否独立打开、配置说明是否写明超时与排除规则、对照表是否覆盖报告中所有条目。结果说明：三项都通过，才算保存了改动前的原始状态；缺任何一项，后续出现争议时只能重新扫描，而重新扫描得到的是新状态，不是原始状态。
下一步：在下一次扫描前，先把本次的 before 报告、配置说明和对照表归档到同一目录，再开始修改页面。
