永久重定向方法，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /778e621db130.html
📄
永久重定向方法，改版或迁移时应核对什么
改版或迁移时，永久重定向方法要核对的核心是：旧地址是否用 301 或 308 指向最合适的新地址，并且这条链路能长期稳定工作。多人协作时，不要只看“跳转成功”，而要把旧 URL 清单、映射关系、响应头、内链与站点地图一起交付和复查。
准备阶段：先锁定旧地址清单和映射规则
先导出旧站可被访问的 URL，而不是只拿栏目页交差。清单至少覆盖：已收录页面、有外链的页面、站点地图中的页面、站内搜索或筛选参数页。然后逐条决定去向：内容等价则一对一跳到新页；内容合并则跳到最相关的新页；确实下线的页面，才考虑跳到上级栏目或返回 410。
映射表建议包含四列：旧 URL、新 URL、重定向类型、负责人。多人协作时，这张表就是交付物，能减少“我以为你改了”的返工。需要特别核对的是，旧地址是否被误跳到首页。大量页面统一跳首页，用户和搜索引擎都难以判断替代关系。
实施阶段：确认状态码和跳转链路
永久重定向应使用 301 或 308。两者都表示资源永久迁移，差别在于 308 会保留请求方法，301 在部分客户端可能把 POST 改为 GET。普通内容页迁移通常用 301；涉及表单提交或 API 端点时，要单独确认 308 是否更合适。
实施时要检查三件事：
- 旧地址返回的是重定向状态码，而不是 200 的“跳转页”或 JavaScript 跳转。
- 跳转目标返回 200，且内容与旧页主题一致。
- 不出现 A 跳 B、B 跳 C 的长链，也不出现循环跳转。
如果服务器配置里写了规则，可以用命令行抽查响应头。例如：
curl -I https://example.com/old-page
看到 HTTP/1.1 301 或 308，以及 Location: 指向预期的新地址，才算这条规则按预期生效。若看到 302、307 或 200，就要回到配置中核对，而不是直接交付。
验证阶段：把抽检变成可复现的检查项
不要只点开几个页面看“能跳”。至少按下面顺序验证：
- 从映射表中随机抽取旧 URL，检查状态码、目标地址和最终页面标题。
- 检查站内链接是否已经指向新地址，避免用户多点一次才到目标页。
- 检查站点地图是否只包含新地址，旧地址不应继续出现在地图中。
- 检查 robots.txt 是否误封了需要抓取的旧路径或新路径。抓取限制不等于可靠的索引移除，别把 robots.txt 当成迁移工具。
- 检查 HTTPS 跳转与永久重定向是否叠加成多余链路，例如 HTTP 旧页先跳 HTTPS 旧页，再跳新页。
验证结果要记录：旧 URL、实际状态码、实际 Location、最终 URL、是否通过。这样交接时，下一位同事不用重新猜。
维护阶段：迁移后继续观察和修正
重定向上线后，仍要定期抽查旧地址是否失效、目标页是否被再次改版、服务器规则是否被后续发布覆盖。尤其多人协作时，主题上线、栏目调整、CDN 或反向代理变更，都可能让原有规则失效。
判断是否要保留某条重定向，可以看两个条件：旧地址是否仍有外部链接或用户访问；新地址是否仍是该内容的最佳替代。若目标页再次迁移，应把重定向更新到最终地址，而不是继续叠加中间跳转。HTTPS 能加密传输，但不保证站点没有漏洞，也不保证排名，所以安全与 SEO 问题要分别检查。
下一步：把旧 URL 清单、映射表、实际响应头和验证记录合并成一份迁移核对表，指定一人负责上线后复查，另一人负责抽查结果，确认无长链、无循环、无错误目标后再宣布迁移完成。
