网站死链检查：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ec25f021dbb1.html
📄
网站死链检查：改动前怎样保存原始状态
在开始网站死链检查并准备修复之前，保存原始状态的核心做法是：先完整记录当前“哪些链接是死链、它们出现在哪个页面、返回什么状态码”，再对将要改动的文件或数据库字段做一份可回滚的副本。这样做的目的不是留档好看，而是让后续每一步修改都能和原始结果对比，判断死链是减少了、转移了，还是被误伤。
观察：先固定死链清单，而不是先动手改
死链检查的第一步是采集现状。无论用爬虫工具还是服务器日志，都应导出成一份带时间标记的清单，至少包含以下字段：
- 来源页面 URL（死链出现在哪一页）
- 死链目标 URL（被指向的地址）
- HTTP 状态码，如 404、410、301、500
- 发现时间与使用的检查工具名称
这份清单就是“原始状态”的基准。如果只记下“大概有几十个死链”，改动后就无法判断某个链接是原本就坏，还是这次操作弄坏的。导出时建议保留原始格式（CSV 或表格），不要只截图，因为截图无法用于逐条比对。
判断：哪些原始状态必须保存，哪些可以省略
并非所有东西都要备份，判断标准是“改动后还能不能还原”。需要保存的通常有三类：
- 内容层：将修改的页面正文、跳转规则、内链所在模板。若是 CMS，先复制一份草稿或导出该页面内容。
- 配置层：重定向规则文件、
.htaccess、Nginx 配置、robots.txt。这些文件改动影响面大，必须先复制原文件并记录修改前的行。 - 数据层：如果死链修复涉及批量替换数据库中的链接字段，先导出相关表或至少导出受影响的行。
可以省略的是与死链无关的整站备份诉求。这里的目标是“可回滚、可对比”，不是做完整灾备。判断结果很简单：改动后如果发现某个正常链接被误改成 404，你能不能凭保存的内容把它改回去？能，就够用。
需要区分的是，robots.txt 的抓取限制不等于可靠的索引移除，它只影响爬虫抓取行为，不能替代对死链本身的处理；站点地图也不保证收录，它只是提交候选地址，不能当成死链已修复的证明。
处理：按清单逐项修改并留下对应记录
保存好原始状态后，再开始处理。推荐按“先记录、后修改、再标注”的顺序执行：
- 对每个死链决定处理方式：修复目标地址、设置 301 跳转到相关页面，或保留 410 表示内容已永久移除。
- 每改一项，在清单里新增一列“处理方式”和“处理时间”，不要覆盖原始状态列。
- 如果使用批量替换，先在小范围页面测试，确认替换规则不会误伤正常链接。
举例说明（以下为假设场景）：某页面内链指向 /old-page，返回 404。原始清单记录为“来源 /a，目标 /old-page，状态 404”。处理后把内链改为 /new-page，清单中新增“处理方式：改内链；处理后状态：200”。复查时对比两列，就能确认这次改动确实生效，而不是靠记忆判断。
适用条件是：改动范围可控、能定位到具体文件和页面。如果站点规模很大且没有版本控制，至少要对准备修改的模板和配置文件做带日期的副本，并写明副本对应的时间点。
复查：用原始清单做前后对比
修改完成后重新跑一次死链检查，把新结果与原始清单并排比较，重点看三类情况：
- 原来 404 的链接现在是否返回 200 或 301。
- 原来正常的链接是否变成了新的 404，这通常意味着改动误伤了其他地址。
- 跳转链是否形成循环或多重跳转，例如 A 跳 B、B 又跳回 A。
如果新结果里出现了原始清单中没有的死链，优先怀疑本次修改引入，而不是归因于外部变化。复查通过的标准是：原死链已按预期处理，且没有新增非预期死链。若使用 HTTPS，也要注意 HTTPS 只保证传输加密，并不保证页面无漏洞或排名提升，它和死链是否修复是两件事。
不同搜索引擎对 404、410、301 的处理节奏和支持细节需要分别核查，不能因为一个搜索引擎的表现就推断另一个。复查时以实际返回的状态码和页面可达性为准。
下一步建议：先导出当前死链清单并复制将要修改的配置文件，再开始逐项处理；处理完用同一工具复跑一次，把新旧两份清单对照确认没有新增死链。
