网站上线之后，你可能会遇到这些情况：换了一个新域名、修改了文章 URL 结构、合并或删除了某个栏目。这时候你就需要用到「重定向」——让访问旧地址的用户和搜索引擎自动跳转到新地址。
但如果重定向类型选错了，可能导致搜索引擎排名显著下降，甚至出现已收录的页面全部从搜索结果中消失的严重后果。
一、重定向解决的是什么问题？
重定向的核心功能：当用户或搜索引擎访问 URL A 时，服务器自动引导到 URL B。
典型的使用场景：
- 域名更换：从
old-domain.com迁移到new-domain.com。 - URL 结构调整：从
/2023/01/post-slug改为/post-slug。 - 页面删除或合并：旧产品页下线，引导用户到新产品页或相关分类页。
- HTTP 升级到 HTTPS：强制所有 HTTP 请求跳转到 HTTPS。
- www 与根域名统一：统一使用
www.example.com或example.com。
二、301 vs 302：核心区别在于「永久」还是「临时」
| 状态码 | 含义 | 搜索引擎行为 |
|---|---|---|
| 301 | 永久重定向（Moved Permanently） | 向搜索引擎明确传递永久迁移信号，通常会逐步把旧 URL 的主要信号转移到新 URL |
| 302 | 临时重定向（Found / Moved Temporarily） | 表示跳转是临时的，搜索引擎通常会更倾向保留旧 URL，并继续观察跳转状态 |
用人话理解
- 301 等于告诉搜索引擎：「这个页面已经长期迁到新地址，以后请以新地址为准。」
- 302 等于告诉搜索引擎：「这只是临时跳转，旧地址后续可能还会继续使用。」
用错 302 的后果
如果你在域名迁移、URL 变更等永久性场景用了 302，搜索引擎可能会继续保留旧 URL，并把新 URL 当成临时跳转目标来观察。这会拖慢迁移信号的传递，也可能让新页面迟迟无法稳定进入搜索结果。
三、不同场景应该怎么选？
| 场景 | 使用 | 说明 |
|---|---|---|
| 域名永久更换 | 301 | 整站永久迁移，告诉搜索引擎把所有旧 URL 的权重都给新域名 |
| URL 结构永久调整 | 301 | 逐条做 301，将旧 URL 跳到对应的新 URL |
| 页面被永久删除 | 301 跳到相关页面 或 410 Gone | 不要跳到首页！搜索引擎会把大量首页跳转视为软 404 |
| HTTP → HTTPS 全站升级 | 301 | 永久加密，这是最常见的 301 应用场景 |
| www ↔ 根域名统一 | 301 | 选择一个作为主域名，另一个 301 跳转 |
| 临时活动页、促销页 | 302 | 活动结束后页面回归，保留原 URL 的排名 |
| 网站短时维护 | 优先返回 503 Service Unavailable，必要时短期 302 到公告页 | 503 更能表达临时不可用；维护结束后及时恢复 |
| A/B 测试 | 302 | 测试版本是临时的，最终版本 URL 不变 |
四、网站改版时的 SEO 风险控制清单
假设你正在进行一次网站结构大调整——改了 URL 格式、更换了域名或迁移到新平台。以下是必须执行的步骤：
改版前
-
[ ] 导出所有现有 URL 清单
通过 Sitemap、Search Console 或数据库导出当前网站所有页面的 URL。这是重定向映射的基础数据，没有它后面无法比对。 -
[ ] 建立 URL 映射表
每一条旧 URL 对应一条新 URL。不要跳过这一步手工凭感觉配——改版涉及几百条 URL 时，一个遗漏就可能导致排名丢失。 -
[ ] 确认新 URL 结构
确保新站 URL 规则已定稿，避免上线后又改一次 URL（二次迁移对 SEO 的伤害比一次迁移大得多）。
改版上线时
-
[ ] 部署 301 重定向
在服务器层面（Nginx/Apache 配置）或应用层面（Halo 插件/代码）逐条或批量部署 301。测试每条重定向是否生效。 -
[ ] 避免重定向链
A → B → C 的多级跳转会拖慢访问速度并稀释权重传递。确保 A 直接 301 到 C，中间不经过 B。 -
[ ] 不要全部跳首页
这是最常见的致命错误——把所有旧 URL 全部 301 到新站首页。搜索引擎会把这些跳转视为「软 404」（即旧内容被认为已删除但服务器没有正确响应），权重大量流失。
改版后
-
[ ] 更新 Sitemap 并重新提交
确保 Sitemap 中是新 URL，旧 URL 已被移除。重新提交到 Google Search Console 和 Bing Webmaster Tools。 -
[ ] 使用 Search Console 的「地址更改」工具
如果你更换了域名，Google Search Console 提供「地址更改」功能，可以告知 Google 你正在进行域名迁移，加速权重转移。 -
[ ] 监控 404 和抓取错误
改版后的 1-2 周内，持续关注 Search Console 中的 404 报告，发现未重定向的旧 URL 及时补上 301。 -
[ ] 检查外部链接
使用 Search Console 的「链接」报告，查看哪些外部网站链接到了你的旧 URL。对于重要的外部链接来源，可以考虑主动联系对方更新链接。
五、Halo 站点迁移时的注意事项
URL 别名功能
Halo 支持为每篇文章设置自定义 slug（URL 别名）。如果你只是优化个别文章的 URL，不要默认假设旧 URL 会自动跳转到新 URL；改动前应先测试旧链接是否仍可访问或跳转，必要时手动配置 301。批量修改大量 slug 时，建议在 Nginx 或 CDN 层面配置明确的重定向规则。
更换域名
如果从旧域名迁移到新域名，最稳妥的方式是在 Nginx 中配置一条覆盖全站的 301 重定向规则：
server {
listen 80;
server_name old-domain.com;
return 301 https://new-domain.com$request_uri;
}
这条规则会把所有来自 old-domain.com 的请求（包括子路径）全部 301 跳转到 new-domain.com 对应的相同路径。
重定向这件事，本质就一句话：永久改动用 301，临时改动用 302，别搞混。如果你正在做网站改版或换域名，最要紧的是提前导出所有旧 URL 并做好映射表——一条一条对应到新 URL，不要把所有旧链接都跳转到首页，那是非常高风险的 SEO 做法。改版之后持续关注 Search Console 的 404 报告，发现遗漏后及时补上。
重定向的问题搞清楚了，还有个更日常的事情值得关注：每写一篇文章的时候，顺手做一些 SEO 优化。不复杂，下一篇讲。