所有文章
· URLCheck

什么是 301 重定向？301 vs 302 完全指南

详细解释 HTTP 301 和 302 重定向的区别、使用场景、SEO 影响，以及如何使用 URLCheck 工具检查重定向链。

HTTP 重定向 SEO

301 重定向（Moved Permanently）是 HTTP 协议中最常用的重定向状态码之一。当服务器返回 301 状态码时，表示请求的资源已被永久移动到新的 URL。

301 vs 302：关键区别

特性301302
含义永久移动临时移动
SEO 权重传递给新 URL保留在旧 URL
缓存倾向通常可长期缓存是否缓存取决于响应头
使用场景域名迁移、URL 结构变更A/B 测试、临时维护

浏览器和搜索引擎是否缓存跳转还会受到缓存响应头影响。长期存在的 302 也可能被搜索引擎按永久迁移处理，因此状态码应始终准确表达业务意图。

301、302、307、308 应该怎么选？

HTTP 不只有 301 和 302。307 与 308 的关键价值，是明确要求客户端在跳转后保留原请求方法和请求体。

状态码迁移语义方法处理典型用途
301永久历史客户端可能把 POST 改成 GET普通网页永久迁移
302临时历史客户端可能把 POST 改成 GET临时活动、维护页
307临时必须保留方法和请求体API 临时迁移
308永久必须保留方法和请求体API 或上传接口永久迁移

对于普通 GET 页面，301 与 308 的用户体验通常接近；对于登录、支付、上传和 API 请求，方法是否保留可能直接影响业务正确性。不要在没有验证的情况下，把 POST 接口随意重定向到另一个地址。

响应还可以通过缓存头控制客户端与 CDN 的行为：

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-path/
Cache-Control: public, max-age=86400

永久重定向缓存时间不宜在上线第一天就设得过长。迁移初期保留较短 TTL，确认规则稳定后再延长，可以降低错误配置难以回滚的风险。

何时使用 301？

  • 网站从 HTTP 迁移到 HTTPS
  • 更改域名
  • 合并重复页面
  • 修改 URL 结构

一次完整的网站迁移流程

1. 建立旧 URL 到新 URL 的映射

不要只写一个“全部跳首页”的兜底规则。应从 sitemap、访问日志、搜索落地页、外部链接和数据库中收集旧地址，为每个重要页面找到语义最接近的新页面。

映射表至少包含：

  • 旧 URL 与新 URL
  • 迁移原因
  • 预期状态码
  • 页面负责人
  • 上线批次
  • 验证状态
  • 是否存在外部链接或高流量

2. 让规则尽量靠近入口

协议和主域名统一通常适合在 CDN 或最外层反向代理完成；业务路径迁移则更适合在应用或明确的路由表中维护。多层系统都配置同一类规则，很容易形成重复跳转。

3. 更新站内信号

重定向只是兼容旧入口，站内系统不应继续依赖它。同步更新：

  • 导航、正文和组件内链
  • canonical 与 hreflang
  • XML sitemap 与 RSS
  • 广告落地页和邮件模板
  • API 文档、SDK 与 Webhook 地址
  • 前端资源、图片和结构化数据 URL

4. 分批发布并保留回滚能力

先发布低风险路径，观察 3xx、404、5xx 和转化指标，再迁移核心页面。规则应版本化，并能够快速恢复到上一份映射。

5. 长期保留重要重定向

搜索引擎、书签、历史邮件和外部网站不会同时更新。只保留几周通常不够。重要旧地址应长期维护，并定期检查目标是否仍然存在。

常见配置错误

  • 把所有废弃页面都跳转到首页，而不是最相关的新页面
  • 形成“旧地址 → 中间地址 → 最终地址”的多级跳转链
  • HTTP、HTTPS、www 与非 www 规则不一致
  • 跳转目标返回 404、5xx，或者再次进入循环

每增加一跳都会增加延迟和失败风险。站内链接与 canonical 标签也应直接指向最终 URL。

配置示例

以下 Nginx 示例把单个旧路径直接迁移到新路径：

location = /old-guide {
    return 301 https://example.com/new-guide/;
}

协议与主域名统一可以单独放在入口 server 中：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

需要避免的写法是让通用正则同时匹配重定向后的目标，或者在 CDN 与源站分别执行“添加 www”和“删除 www”的相反规则。

框架层配置也应遵循同样原则：条件清晰、目标唯一、不会再次命中自身，并为规则准备自动化测试。

如何检查重定向

使用 URLCheck 工具，您可以：

  1. 输入任意 URL
  2. 查看完整的重定向链
  3. 确认每一步的状态码
  4. 对比不同身份（浏览器/爬虫）下的重定向行为

使用 URLsCheck 检查 URL，可以一次查看每一跳、响应耗时、最终地址和追踪参数。

如何验证迁移是否成功？

单条测试无法覆盖真实站点。建议同时执行：

  1. 全量映射测试：旧 URL 是否返回预期 301/308；
  2. 最终状态测试：目标是否直接返回 200；
  3. 链路长度测试：是否出现第二跳；
  4. 内容一致性测试：新页面是否承接相同主题与用户任务；
  5. 身份对比测试：浏览器、移动端和爬虫是否一致；
  6. 参数测试：必要查询参数是否保留，追踪参数是否被正确处理；
  7. 地区测试：不同边缘节点是否加载了同一版本规则。

上线后重点监控：

  • 旧路径请求量是否按预期下降；
  • 404 与软 404 是否上升；
  • 平均重定向跳数与耗时；
  • 新 URL 的抓取、索引和自然流量变化；
  • 登录、下单、表单等关键转化是否异常；
  • CDN 缓存中是否仍存在错误的永久跳转。

若 404 明显增加，优先检查映射遗漏；若大量 URL 出现两跳以上，通常说明协议、域名和路径规则分散在不同层级。

常见问题

301 会保留 SEO 权重吗？

相关且正确配置的 301 通常会把排名信号整合到目标页面。目标内容应与原页面匹配，同时避免过长跳转链，并长期保留迁移规则。

什么时候应该使用 302？

当活动、测试或维护结束后仍要恢复原 URL 时使用 302。若迁移是长期的，应使用 301 或 308 等永久重定向。

301 会把查询参数自动带到新地址吗？

不会由状态码自动保证。是否保留参数取决于 Location 的生成方式。应分别测试无参数、单参数、多参数、编码字符和敏感参数，避免全部丢失或重复追加。

301 和 canonical 可以互相替代吗？

不能。301 是客户端导航与资源迁移机制，canonical 是页面向搜索引擎提供的规范化信号。能重定向的重复 URL 优先使用重定向；必须同时访问的相似页面再根据业务使用 canonical。

所有文章
URLsCheck