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

死链检查_改动前怎样保存原始状态：先留一份可回退的站点快照

做死链检查并准备改动链接、跳转或删除页面前，第一步不是打开工具，而是把“改动前的状态”完整保存下来：既包括当前线上可访问的页面与响应状态，也包括站点配置文件、重定向规则和数据库里与链接相关的记录。只有先固定原始状态，后续才能判断哪些死链是历史遗留、哪些是这次改动造成的。

假设一个场景：先备份再动手

假设你负责一个已有 200 个页面的小型内容站，准备用死链检查工具扫描后批量替换失效链接。合理顺序是：

1. 导出当前所有页面 URL 列表，保存为 urls-before.txt。
2. 对每个 URL 记录 HTTP 状态码、最终跳转地址和抓取时间。
3. 备份服务器上的重定向配置文件、robots.txt、站点地图文件。
4. 如果链接数据存在数据库，导出相关表或至少导出链接字段。
5. 给备份目录加上日期，例如 backup-2024-06-01，避免多次改动互相覆盖。

这样做的意义是：当你改完发现某个原本正常的页面变成 404，或某条跳转链被覆盖，可以对照改动前记录定位差异，而不是凭记忆猜测。

原始状态要保存哪些内容

“原始状态”不等于只保存页面 HTML。死链检查涉及的原始信息通常分三层：

• 响应层：每个 URL 的状态码、响应头中的 Location、内容类型。这是判断死链的直接依据。
• 配置层：服务器重定向规则、.htaccess、Nginx 配置、CDN 回源规则。这些文件决定链接实际去向。
• 内容层：页面内链、导航、站点地图、数据库中的链接字段。改动内链时，这一层最容易遗漏。

如果只保存了页面截图，没有保存状态码和跳转链，后续就无法区分“页面还在但跳转变了”和“页面真的没了”。

具体怎么保存：可执行步骤

用命令行抓取一份带状态码的快照，是成本较低的做法。以下命令仅为示例，需按实际环境调整：

curl -I -L -o /dev/null -s -w "%{http_code} %{url_effective}\n" https://example.com/page

把 URL 列表逐行传入，输出保存到文件，就得到改动前的状态记录。若站点较大，可用支持批量抓取的工具，但保存内容至少应包含：原始 URL、状态码、最终 URL、抓取时间。

同时备份配置文件：

• 复制重定向规则文件到独立目录，不要只依赖版本控制的历史记录。
• 导出站点地图和 robots.txt，即使它们不直接决定收录，也能反映改动前的声明状态。
• 数据库链接字段导出为 CSV，便于改动后逐条比对。

常见错误是：只备份了首页或几个重要页面，忽略分页、标签页和旧文章；或者备份后直接覆盖原文件，没有保留只读副本。正确做法是备份目录设为只读，改动在副本或新分支上进行。

怎么判断保存得够不够

可以用一个简单检查项验证：随机抽 10 个改动前记录为 200 的 URL，确认备份文件里都能查到对应状态码和最终地址。如果查不到，说明快照不完整。

另一个判断依据是回退能力。假设改动后出现异常，你能否在不解压整个站点、不重建数据库的情况下，仅恢复重定向规则就回到改动前？如果不能，说明配置层备份不到位。

需要区分的是：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此保存这些文件是为了记录改动前声明，而不是把它们当作死链状态的唯一证据。不同搜索引擎对跳转和状态码的处理需要分别核查，不能用一个平台的结果推断全部。

改动前的下一步

完成备份后，先对保存的 URL 列表跑一遍死链检查，把结果与备份状态合并成一张对照表。之后每次改动链接或跳转，都在这张表上标记变更项，这样出现问题时能直接定位到具体 URL 和具体配置，而不是重新全站扫描。