网站死链查询改动前怎样保存原始状态：先冻结链接清单再动手
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1d864e364b6b.html
📄
网站死链查询改动前怎样保存原始状态：先冻结链接清单再动手
做网站死链查询后准备修改链接前，最关键的一步是先保存一份“原始状态快照”，也就是把当前可访问的URL、返回状态码、页面内链向、跳转目标和发现时间原样记录下来，并另存为只读文件。这样后续无论批量替换、删除还是加跳转，都能对照原始清单判断哪些是误报、哪些是真实死链，也能在改错时回退。
准备阶段：先确定快照要保存哪些字段
死链查询的结果本身不是原始状态，它只是某一时刻的检测输出。保存时要固定以下字段，缺一项都会影响后续比对：
- 完整URL，保留协议、大小写、查询参数和结尾斜杠。
- HTTP状态码，以及是服务器直接返回还是经过跳转后返回。
- 跳转链，按顺序记录每一跳的地址与状态码。
- 链接所在页面，即这个链接是从哪个页面被发现的。
- 锚文本和链接类型，区分导航、正文、页脚或站内搜索。
- 检测时间与使用的工具或脚本版本。
字段确定后，把结果导出为CSV或JSON，复制一份存到改动范围之外的位置，例如本地目录或版本库，并设为只读。原始文件不要直接在导出结果上编辑，所有处理都在副本里进行。
实施阶段：改动前必须完成的冻结动作
冻结的核心是让原始快照和后续操作分离。可以按下面顺序执行：
- 对全站做一次完整死链查询，范围覆盖导航、正文、站点地图中列出的页面和常见入口页。
- 导出结果，命名为带日期的原始文件，例如
broken-links-2024-06-01-original.csv，并记录文件校验值。 - 再复制一份作为工作副本，只在副本里标注“待处理”“已确认”“忽略”。
- 如果站点使用版本控制，先提交一次当前状态，提交信息写明这是死链修改前的基线。
- 若无法使用版本控制，至少把将被修改的模板文件、重定向配置和链接映射表各备份一份。
这里最容易忽略的是：只备份了数据库或只备份了页面文件，却没有保存“链接出现在哪个页面”这层关系。死链修改往往同时涉及内容页和模板，缺了来源页面，回退时很难判断影响范围。
验证阶段：用原始快照判断改动是否正确
改动完成后，不要只看新结果，而要把新旧两份清单按URL对齐比较。判断依据可以这样分：
- 原始状态为404、410，改动后变为200或301，说明该链接已被处理。
- 原始状态为200，改动后仍为200，属于未受影响，不应被误改。
- 原始状态为跳转链中的某一跳，改动后跳转链变短或目标变化，需要确认是否符合预期。
- 原始清单里存在但新清单里消失的URL，要确认是页面被删除还是检测范围变化。
如果发现某个URL在原始快照中是200，而查询工具当时报死链，很可能是超时、反爬或临时故障造成的误报。这类情况应以原始快照中的状态码和跳转链为准，先复核再决定是否修改。
维护阶段：让原始状态可追溯而不是一次性文件
保存原始状态不是做一次就结束。每次准备批量改动前，都应按同样字段再存一份快照，并在文件名或提交信息里写清改动目的。这样当同一URL在不同时间出现不同状态时，可以判断是站点本身变化，还是检测条件变化。
需要区分的是：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。保存原始状态时，如果发现某链接被 robots.txt 屏蔽，应把它单独标记，而不是直接当作死链删除。
下一步
先打开你最近一次的死链查询结果，确认是否包含“链接所在页面”和“跳转链”两列；若没有，重新跑一次查询并导出完整字段，再开始任何链接修改。
