为什么要关注 301 和 302
网站改版、栏目迁移、域名更换、HTTP 跳 HTTPS 时，经常需要做跳转。很多站长知道要“做重定向”，但不一定分得清 301 和 302 的区别。两者看起来都是把用户从旧地址带到新地址，实际传递给浏览器、搜索引擎和缓存系统的含义并不一样。
如果把临时跳转写成永久跳转，后续改回去可能会遇到缓存残留、收录信号转移不符合预期等问题；如果该永久迁移却一直用临时跳转，搜索引擎也可能迟迟不把新地址当作主地址。因此，重定向不是随手写一条规则就结束，而是要先判断迁移是否长期有效。
301：告诉外界地址已经永久搬家
301 Moved Permanently 表示资源已经永久移动到新的 URL。对搜索引擎来说，它通常意味着旧地址的主要信号应逐步转移到新地址；对浏览器和中间缓存来说，301 也更容易被长期记住。适合使用 301 的场景包括域名长期更换、固定链接结构永久调整、全站 HTTP 强制跳转到 HTTPS、旧栏目合并到新栏目等。
做 301 前要特别谨慎：先确认新地址长期可用，页面主题与旧页面高度相关，再批量上线规则。不要把大量旧页面全部跳到首页，也不要为了省事把不存在的内容跳到无关栏目，这样既影响用户体验，也不利于搜索引擎理解网站结构。
302：表示只是临时换个入口
302 Found 更适合临时场景，比如短期活动页切换、灰度发布、A/B 测试、登录后跳转、地区或语言临时分流等。它的核心语义是：旧地址仍然有效，只是当前请求暂时先去另一个地址。
如果只是春节活动页、限时维护页、临时导流，就不要轻易使用 301。临时跳转结束后，旧地址还要继续承担原来的内容入口，使用 302 可以减少搜索引擎把主地址永久改掉的风险。
Nginx 中常见写法
在 Nginx 中，永久跳转常用 return 301 https://example.com$request_uri;，临时跳转可以使用 return 302 https://example.com/new-path;。如果是整站 HTTPS 跳转，通常放在 80 端口的 server 块里；如果只是某个路径迁移，则可以针对具体 location 写规则。
需要注意的是，rewrite 也能实现跳转，但简单场景优先使用 return，语义更直观，执行路径也更清晰。上线前可以用 curl -I 查看响应头，确认状态码是 301 还是 302，Location 是否指向预期地址，避免把测试域名或临时地址写进生产配置。
SEO 与缓存的常见坑
301 最容易踩的坑是浏览器缓存。你在测试时一旦访问过错误的 301，浏览器可能会继续记住旧规则，即使服务器已经改正，本地仍然自动跳走。排查时可以换无痕窗口、清理站点缓存，或直接用 curl 验证服务器真实响应。
另一个坑是跳转链过长。比如 A 跳 B、B 跳 C、C 再跳 D，用户等待时间变长，搜索引擎抓取效率也会下降。理想做法是旧地址尽量一步跳到最终地址，减少中间环节。使用 CDN 时，还要同时检查源站规则和 CDN 边缘规则，避免两边互相跳转造成循环。
迁移前后的检查清单
正式迁移前，先列出旧 URL 与新 URL 的对应表，按页面主题一一匹配；迁移后，抽样检查核心页面状态码、Location、页面内容和 canonical 标签。站点规模较大时，可以分批上线，先观察日志里的 404、跳转次数和搜索引擎抓取情况。
如果业务站点运行在云服务器上，重定向调整前最好保留配置备份，并安排低峰时段发布。像 速维云云服务器 这类环境，通常可以结合 Nginx 配置备份、快照和访问日志一起排查，出现异常时更容易快速回滚。
怎么选择才稳妥
简单判断：长期搬家用 301，短期导流用 302；影响搜索收录和品牌主入口的变更，要先测试再批量上线；涉及登录、实验、临时活动的跳转，不要随便永久化。状态码本身不复杂，难点在于你是否清楚这次跳转代表“永久迁移”还是“临时安排”。
重定向规则写好后，不要只在浏览器里看“能不能打开”，还要检查响应头、跳转链、缓存表现和日志反馈。只有这些都确认正常，301 和 302 才能真正帮助网站平稳迁移，而不是制造新的访问故障。
