死链检查：迁移后旧地址没有等价目标时怎样处理
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /97a6d05956ef.html
📄
死链检查：迁移后旧地址没有等价目标时怎样处理
迁移后旧地址没有完全等价目标，正确做法不是统一跳到首页或栏目页，而是把每个旧地址按“最接近替代页、可保留的旧页、只能返回 410 的废弃页”三类分配处理动作，再用死链检查验证这些动作的实际响应。统一跳首页会把大量不相关旧地址压成同一个目标，既让用户找不到原内容，也让后续检查无法区分真实遗漏。
先给每个旧地址判定三种去向
拿你手里的旧地址清单，逐条打开原页面，记录它原本回答什么问题、属于哪个栏目、是否还有同类内容。判定标准可以固定为三条：
- 最接近替代页：新站存在主题相近、能满足同一意图的页面，做 301 指向它。替代页不必标题相同，但用户点进去应能解决原来的问题。
- 可保留的旧页：旧内容仍有独立价值，只是路径变了，应在新站恢复或保留该页，再让旧地址指向新路径。
- 只能废弃：内容已删除、合并或从来不该存在，且没有合理替代，返回 410 比跳到无关页更诚实。
无法立刻判定的地址先单独放一列，不要为了清空清单而随手跳首页。这一列往往就是迁移遗漏最集中的地方。
用一次小规模检查确认跳转是否真的成立
假设旧地址 /old-guide 对应内容已合并进 /new-guide，你配置了 301。动作是：用命令行请求旧地址并只看响应头，例如 curl -I https://example.com/old-guide，观察返回的状态码和 Location 值。结果若是 301 且 Location 为 /new-guide，说明这一条处理成立；若返回 200 却是旧页面残留、或 302 指向首页，则说明配置没有按预期生效，应回到上一步重新判定，而不是直接进入下一批。
这里要区分两件事：跳转配置生效，和搜索引擎完成替换。前者你能立刻验证，后者需要时间，且不同搜索引擎的处理节奏不同，须分别核查。
死链检查要覆盖跳转链和最终目标
只检查旧地址是否返回 301 还不够，要顺着跳转链走到最终地址，确认最终目标也返回 200 且内容相关。常见遗漏条件有三个：
- 旧地址跳到新地址，新地址又跳到另一个地址，形成多级跳转，中间任一环失效都会让整条链断掉。
- 最终目标是 404 或 410，但检查只看了第一跳的状态码，误以为已修复。
- 大小写、结尾斜杠、查询参数不同，导致部分旧地址实际未命中规则。
把检查结果按“旧地址 → 中间跳转 → 最终状态码 → 最终目标”记录，才能看出是哪一环需要改。若某一批旧地址的请求量或抓取量归零，不能单独证明处理正确，也可能是抓取预算转移、页面被其他规则屏蔽或统计口径变化，需要结合响应记录判断。
废弃页不要用 robots.txt 代替 410
对确认无替代的旧地址，返回 410 或 404 是明确信号。用 robots.txt 禁止抓取并不能可靠地移除已有索引，抓取限制不等于索引移除；站点地图也不保证收录。若旧地址已被索引，指望屏蔽抓取来清理，通常只会让状态更模糊。HTTPS 同样不解决这类问题，它不保证页面安全无漏洞，也不决定死链处理结果。
实际操作顺序是：先确认该页确实无替代，再让服务器对该路径返回 410，然后用死链检查确认返回的是 410 而不是被跳转规则或软 404 覆盖。若返回 200 的空页面，搜索引擎可能仍视其为有效页，这与你的处理目标相反。
把剩余无法判定的地址交给内容方而不是技术方
技术手段只能确认响应，不能判断两个页面是否等价。把“无法判定”那一列交给最熟悉原内容的人，请其标注每条旧地址应指向哪个新页或确认废弃。拿到标注后，你再批量配置跳转并复查。这样做的结果是：技术检查负责验证，内容判断负责分配，两者不混在一起，也就不会出现整站跳首页这种看似省事、实际制造新问题的处理方式。
