用 .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

如果是整個網域搬遷並保留 path，很多團隊會改成 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、代理或 app middleware 沒有再做一層改寫
• 路徑邏輯簡單
• ownership 清楚

為什麼一到搬站就容易失控

1. redirect 不只一層

真實專案裡，規則常常同時來自：

• .htaccess
• CMS 外掛
• Nginx / 負載平衡
• Cloudflare
• app 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. path 與 query 的邏輯開始模糊

很多團隊只測首頁，後來才發現深層頁、文件頁、活動連結或 UTM 並沒有照預期保留。

3. wildcard 看似優雅，實際上不夠

像：

/blog/* -> /articles/*

這種規則，看起來很省事。但只要出現：

• 類別合併
• 商品下架
• 某些頁面要額外例外

它就很快不夠用了。

這時你真正需要的是：

• 明確映射
• 優先順序
• 校驗
• 可審查的轉址對照表

4. 規則變更很難審計

設定檔上的 merge，不等於搬站審計紀錄。

團隊遲早會問：

• 誰改了哪條規則
• 哪些是新增的
• 哪些被刪了
• 有沒有衝突
• 出事怎麼 rollback

而 .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. 參數掉了

如果活動歸因依賴 Email、QR、廣告投放或合作連結，那 utm_ 丟掉就不只是 SEO 問題，也是報表問題。

4. redirect map 在表格裡，live 規則在伺服器裡

業務真相在表格，技術規則在設定檔，兩邊分離，盲點就會越來越多。

什麼時候該換工作流

通常符合這些條件時，就應該換：

• 要搬的是幾百到幾千條 URL
• 多個團隊或代理商一起改規則
• 需要 CSV 匯入
• 上線前一定要檢查衝突
• 一定要能清楚回滾
• 不想每改一次 redirect 就碰 origin 伺服器

這時 UrlEdge 的價值就會很明顯：

• 大量轉址管理
• 轉址規則管理
• Permanent 301 Redirects

最後一句

真正的問題不是 .htaccess 到底好不好。

真正的問題是：

你現在處理的，還只是幾條手工 server 規則，還是已經變成一個牽涉 SEO、活動、多人協作的 routing 專案？

如果是後者，那 snippet 本身就已經不是答案了。