用 .htaccess 做 301 跳转，为什么网站迁移时容易失控

很多人搜 .htaccess 301 redirect，最初只是想解决一个很具体的问题：

• 旧网址跳到新网址
• HTTP 统一到 HTTPS
• 旧域名永久迁到新域名

少量规则时，.htaccess 的确还能用。但问题在于，很多团队会把这种“能写几条规则就先顶着”的方式，一路用到整站迁移。

更实际的判断通常是：

• 少量、稳定、规则清楚的 301，.htaccess 还能撑住
• 换域名、改品牌、重构站点、大批量 URL 迁移，.htaccess 很快就会变成运维风险源

如果你现在就在做迁移，建议把 网站迁移跳转检查清单 也一起打开。本文只聚焦在其中一个高频入口：用 .htaccess 做 301 跳转时，为什么规模一大就容易出事。

最基础的写法

单条永久跳转，Apache 常见写法像这样：

Redirect 301 /old-page https://www.example.com/new-page

如果是整域名搬迁并保留路径，很多团队会改写成 mod_rewrite：

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$
RewriteRule ^(.*)$ https://www.new-domain.com/$1 [R=301,L]

这解决的是语法问题，不是迁移问题。真正要问的是：

[!TIP] 你现在到底是在维护几条 redirect 规则，还是已经在维护一个需要校验、归属、回滚能力的迁移工作流？

.htaccess 还能成立的前提

通常只有在这些条件下，它才比较安全：

• 规则数量不多
• Apache 是唯一的 redirect 层
• CDN、代理、应用 middleware 没有再做一层改写
• 路径逻辑简单
• ownership 清楚

为什么一到迁移就容易失控

1. redirect 层不止一层

真实项目里，规则常常同时来自：

• .htaccess
• CMS 插件
• Nginx / 负载均衡
• Cloudflare
• 应用 middleware

于是一个表面上简单的迁移，很容易变成：

http://old-domain.com/product-a
  -> https://old-domain.com/product-a
  -> https://www.old-domain.com/product-a
  -> https://www.new-domain.com/shop/product-a

它也许还能打开，但作为迁移方案已经不干净了。

2. 路径和参数逻辑开始模糊

很多团队只测首页，后来才发现深路径、文档页、广告链接、UTM 参数并没有按预期保留。

3. wildcard 听起来优雅，实际不够

像：

/blog/* -> /articles/*

这种规则，看上去很省事。但只要出现：

• 分类合并
• 商品下线
• 某些页面需要例外处理

它马上就不够用了。

这时你真正需要的是：

• 明确映射
• 优先级
• 校验
• 可审核的跳转映射表

4. 规则改动很难审计

配置文件上的 merge，不等于迁移审计记录。

团队迟早会问：

• 谁改了哪条规则
• 哪些是新加的
• 哪些被删了
• 有没有冲突
• 出问题怎么回滚

而 .htaccess 自己并不擅长回答这些问题。

迁移里最常见的几类错误

1. host、HTTPS、最终目标被拆成多跳

差的写法：

http://old-domain.com/docs/api
  -> https://old-domain.com/docs/api
  -> https://www.old-domain.com/docs/api
  -> https://www.new-domain.com/docs/api

更好的写法：

http://old-domain.com/docs/api
  -> https://www.new-domain.com/docs/api

2. 首页能打开，真正重要的 URL 不行

首页正常，不代表：

• 产品页
• 博客文章
• docs
• 搜索引擎里已经收录的老 URL

都正常。

3. 参数丢了

如果活动归因依赖邮件、二维码、投放广告或合作链接，那 utm_ 丢掉就不只是 SEO 问题，也是报表问题。

4. 真正的 redirect map 在表格里，live 规则在服务器里

业务真相在表格，技术规则在配置文件，两边分离，盲点就会越来越大。

什么时候该换工作流

通常满足这些条件时，就应该考虑换：

• 迁移的是几百到几千条 URL
• 多个团队或代理商一起改规则
• 需要 CSV 导入
• 上线前必须校验冲突
• 必须能清楚回滚
• 不想每改一次跳转都碰 origin 服务器

这时 UrlEdge 的价值就出来了：

• 批量跳转管理
• 跳转规则管理
• Permanent 301 Redirects

最后一句

真正的问题不是 .htaccess 到底好不好。

真正的问题是：

你现在处理的，还是几条手工 server 规则，还是一个已经牵涉 SEO、活动、多个团队协作的 routing 项目？

如果是后者，那 snippet 本身已经不是答案了。