死链检查工具：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /74f9daa17ede.html
📄
死链检查工具：改动前怎样保存原始状态
用死链检查工具改动链接之前，先把“改前状态”完整留存下来：导出一份原始报告、记录扫描参数、保存当时的页面快照或响应头，并把这三样放进同一个带时间戳的文件夹。这样做的目的不是留档好看，而是让任何一次链接修改都能被对比、被回滚、被交接。多人协作时，判断“这条死链是谁改的、改前是什么样”靠的就是这份原始状态。
先观察：扫描结果本身就是最该保存的原始状态
死链检查工具输出的报告，是改动前最直接的证据。保存时不要只截图，截图会丢失可排序、可筛选的字段。优先导出结构化文件，例如 CSV 或工具自带的导出格式，保留以下字段：
- 原始 URL 与最终跳转后的 URL
- HTTP 状态码（404、410、301、302、超时等）
- 发现该链接的页面地址，即来源页
- 链接文字或所在位置（导航、正文、页脚）
- 扫描时间与扫描范围
如果工具只能在线查看，至少把结果页完整导出为 PDF 或 HTML 存档，并同时复制一份纯文本清单。判断标准很简单：换一台电脑、换一个人，能不能凭这份文件复现出“当时扫到了哪些链接、状态是什么”。做不到，就不算保存完整。
判断：哪些参数必须一起记下来，否则报告会失真
同一批链接，用不同参数扫描会得到不同结果。改动前保存原始状态时，参数和结果要绑在一起，否则复查时无法判断差异是改出来的还是扫出来的。需要记录的参数包括：
- 扫描入口：从首页爬取，还是直接导入 URL 列表
- 是否跟随跳转、是否检查外链、是否忽略 nofollow
- 并发数、超时时间、User-Agent
- 是否受 robots.txt 限制
这里有一个容易踩的坑：robots.txt 的抓取限制不等于可靠的索引移除，它只影响爬虫抓取行为。如果扫描时被 robots.txt 挡住，报告里出现的“无法访问”可能只是抓取被拒，而不是链接真的坏了。保存原始状态时把 robots.txt 当时的规则一并留存，复查时才能区分这两种情况。
处理：按“一个文件夹一次改动”的方式落地
多人协作最容易返工的地方，是几个人各自改链接、各自留记录，最后对不上。建议用固定结构存放，命名带日期：
2025-06-01_deadlink-before/
report.csv：工具导出的原始报告，不改动、不删列。params.txt：上面列出的扫描参数，逐条写清。snapshot/：关键来源页的存档，可用浏览器“另存为”或存档服务保存。headers.txt：对争议链接单独跑一次请求，记录状态码与响应头，例如用curl -I抓取。notes.md：写明本次要改哪些链接、由谁改、预期改成什么。
动手改之前，先复制一份 report.csv 命名为 report-after.csv 的空白模板，改动后再导出填进去。这样对比时是同一套字段、同一套参数，差异只来自链接本身。
复查：用对比而不是凭记忆确认改动结果
改完后重新扫描一次，用相同参数，把新报告与原始报告按“来源页 + 原始 URL”做比对。需要确认三类结果：
- 原本 404 的链接，现在返回 200 或正确的 301，且跳转目标与预期一致。
- 没有误伤正常链接，即原本 200 的链接没有变成 4xx 或 5xx。
- 新增的跳转没有形成链条或循环，例如 A→B→C 这种多级跳转。
如果改动涉及站点地图或页面结构，注意站点地图不保证收录，它只是提交线索。死链修好之后收录是否恢复，取决于搜索引擎各自的处理，需要分别核查，不能因为提交了站点地图就认为问题已解决。同理，把站点迁到 HTTPS 也不保证安全无漏洞或排名提升，它只是排查中的一个变量。
假设某次扫描发现 30 条 404，其中 12 条来自同一批旧文章。改动前的原始状态应能回答：这 12 条分别出现在哪些页面、当时状态码是否一致、是否都在 robots.txt 允许范围内。如果连这些都无法回答，说明保存的只是一份结果清单，而不是可交接的原始状态。
下一步
现在就打开你正在用的死链检查工具，对当前站点跑一次完整扫描，按上面的文件夹结构把报告、参数、快照和备注存好，再开始改链接。之后每次改动都沿用同一套命名和字段，复查时直接对比两份报告即可。
