URL重定向，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e1e8370f3c41.html
📄
URL重定向，改版或迁移时应核对什么
改版或迁移时核对URL重定向，核心是确认三件事：旧URL是否都指向了内容最接近的新URL、重定向类型是否适合当前场景、以及重定向链路是否干净且可被正常抓取。只做一张跳转表并不够，必须逐项验证状态码、目标页面和链路层数，否则流量和收录可能一起丢失。
先看现象：重定向出错时有哪些可观察信号
改版上线后，如果出现以下现象，应优先怀疑重定向配置而非内容质量：
- 旧链接在浏览器中跳到首页或无关栏目，而不是对应的新页面。
- 搜索结果里旧URL长期不消失，或点开后落到404。
- 同一旧URL连续跳转多次才到终点，链路超过一跳。
- 部分旧URL返回200但内容已变，实际是软404，没有真正跳转。
- 带参数的旧URL跳转后参数丢失，导致统计或功能异常。
这些现象只能说明“可能有问题”，不能直接断定原因。例如旧URL跳到首页，可能是映射表缺失，也可能是规则优先级写错，还可能是服务器默认404页面被设成了首页。需要进一步收集证据才能定位。
判断依据：核对重定向时的四个关键检查项
第一，状态码是否正确。永久迁移用301，临时调整用302。301表示旧地址永久让位给新地址，适合改版、换域名、目录结构调整；302表示临时，不适合长期迁移，否则新地址可能迟迟不被当作规范地址。判断方法：用命令行工具查看响应头中的状态码，而不是只看浏览器是否跳转成功。
第二，目标URL是否一一对应。重定向应尽量做到旧页面指向内容最接近的新页面，而不是全部指向首页。全部指向首页会造成大量旧页面失去原有主题信号，用户也需要二次寻找。检查方法：抽样比对旧URL与新URL的标题、正文主题是否一致。
第三，链路是否只有一跳。理想情况是旧URL直接301到最终新URL。如果出现A→B→C的多跳，会拖慢响应，也增加抓取成本。检查方法：对旧URL请求一次，观察最终落地地址；若中间还有跳转，应把规则改为直接指向终点。
第四，是否可被抓取。重定向页面如果被robots.txt限制抓取，抓取工具无法读取跳转指令，旧URL的更新可能被延迟。注意：robots.txt的抓取限制不等于可靠的索引移除，它只控制抓取，不控制已有索引的替换。检查方法：确认重定向路径未被robots.txt屏蔽，并查看站点地图是否只收录最终URL，而不是旧URL。站点地图不保证收录，但提交错误URL会浪费抓取预算。
处理步骤：按顺序执行可落地的核对流程
- 导出旧URL清单。从日志、站点地图、内链和已有索引中收集旧地址，形成待核对列表。
- 建立映射表。为每个旧URL指定一个内容最接近的新URL；确实没有对应内容的，明确返回410或保留说明页，不要硬跳到首页。
- 配置规则并区分类型。永久迁移用301，临时活动用302；同一路径避免同时存在多条冲突规则。
- 逐条验证响应。用命令行请求旧URL，确认状态码、目标地址和跳转层数。例如：
curl -I https://example.com/old-page，观察返回的HTTP/1.1 301和Location字段。这是假设示例，实际域名和路径按你的站点替换。 - 检查内链与站点地图。把站内指向旧URL的链接改为新URL，站点地图只保留最终地址。
- 复查抓取与索引。上线后持续观察旧URL是否逐渐被替换，新URL是否被正常抓取。不同搜索引擎的处理节奏不同，不能保证固定见效时间，需要分别核查。
复查与边界：哪些情况不能只靠重定向解决
重定向解决的是地址变更问题，不解决内容质量问题，也不保证排名或收录。如果新页面内容与旧页面主题差异过大，即使301正确，原有信号也可能无法延续。HTTPS也不保证安全无漏洞或排名提升，它只是传输层加密，与重定向核对是两件事。
另外，如果旧URL本身数量巨大且无对应内容，应评估是否值得全部重定向，还是让部分页面自然失效。判断条件是：该旧URL是否仍有外部链接或用户访问需求。有，就映射到最接近的新内容；没有，就不必强行跳转。
下一步：从旧URL清单中抽取访问量最高的20条，逐条执行上述命令行检查，记录状态码、目标地址和跳转层数，先修掉多跳和指向首页这两类问题。
