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

死链扫描工具改动前怎样保存原始状态：先留证据再动手

使用死链扫描工具改动前保存原始状态，核心是留下三样可交付的东西：扫描配置、原始结果文件、改动前页面快照。多人协作时，判断标准不是“我记得改了什么”，而是别人能否用同一份配置复现同一批死链。只要其中一项缺失，返工和互相甩锅的概率就会明显上升。

先分清哪些状态必须保存

死链扫描工具的“原始状态”不只是那份死链列表，至少包含四层信息：

• 扫描配置：入口 URL、是否跟随重定向、并发数、超时时间、User-Agent、是否跳过 robots.txt 限制、是否包含子域。
• 原始结果：工具导出的 CSV、JSON 或日志，保留原始字段，不要先手工删行再交付。
• 页面快照：出问题页面的 HTML 或至少是链接所在片段的存档。
• 环境记录：扫描时间、执行人、工具版本、网络出口大致位置。

判断依据很简单：换一个人、换一台机器，能否用你留下的东西得出同一批死链。如果不能，说明状态没保存完整。

保存配置和结果的具体操作步骤

假设你用的是命令行或可导出配置的扫描工具，可以按下面顺序执行。这里不指定某个品牌，方法对多数工具都适用。

1. 扫描前先把配置导出或复制成独立文件，命名带日期，例如 crawl-config-2024-06-01.json。
2. 扫描完成后立即导出原始结果，不要打开表格修改，直接另存为 crawl-result-raw.csv。
3. 对确认要处理的页面，用浏览器“另存为”或抓取工具保存改动前的 HTML，命名与 URL 对应。
4. 把配置、原始结果、快照放进同一个交付目录，并写一个简短的 README 说明扫描时间和执行人。
5. 如果后续要批量改链接，先复制一份原始结果作为对照基线，改动记录写在另一个文件里。

适用条件：多人协作、需要交接、改动会影响线上页面时，这套步骤值得做。如果只是一次性本地测试、不涉及他人复核，可以只保留配置和原始结果，快照按需取舍。判断结果是：当同事能凭交付目录复现扫描并核对改动前后差异，保存就算达标。

原始结果和改动记录为什么要分开

很多人习惯在原始 CSV 上直接标注“已修复”“待确认”，这会让基线消失。一旦需要回退或核对，就无法判断某条记录是扫描时就存在，还是后来人工加的。

更稳妥的对比依据是两份文件：一份是只读的原始结果，一份是可写的改动记录。改动记录至少包含原 URL、问题类型、处理方式、处理人、处理时间。这样出现争议时，可以拿原始结果和线上现状做三方对照，而不是靠聊天记录回忆。

假设一个场景：扫描出 200 条 404，其中 30 条被判断为误报。如果误报判断只写在原始文件里，第二个人重新扫描后看到数量对不上，就会怀疑工具或配置有问题。分开保存后，误报判断作为独立记录存在，原始 200 条仍然可查，责任边界清楚。

交付前必须过的检查项

保存完不等于交付清楚，交付前逐项核对：

• 配置文件和结果文件是否同名成对，日期是否一致。
• 原始结果是否未被编辑过，能否用校验值或文件大小佐证。
• 每一条改动是否都能对应到原始结果中的某一行。
• 是否说明了哪些死链未处理，以及未处理的原因。
• 是否注明扫描范围，避免别人误以为覆盖了全站。

需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。扫描工具报出的死链是抓取层面的观察，和搜索引擎实际索引状态是两回事。交付时把扫描范围写清楚，比下“全站已清理”的结论更可靠。

多人协作下的选择与代价

保存原始状态是有成本的：多花时间导出、命名、写说明。代价换来的是可复现和可回退。如果团队规模小、改动少，可以简化快照环节；如果涉及多人并行处理同一批死链，配置、原始结果、改动记录三者缺一不可。

下一步建议：在下一次扫描开始前，先建好交付目录和命名规则，再运行死链扫描工具。这样原始状态是扫描的自然产物，而不是事后补录，交接和减少返工都会容易得多。