使用 .htaccess 實現 Redirect 301/302 重定向轉址規則

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

.htaccess 是 Apache 主機上最直接的轉址工具，一行 Redirect 301 就能把舊網址搬到新位置，同時保留 SEO 排名權重。

這篇教學涵蓋 301 與 302 的差異、基礎 Redirect 與進階 RewriteRule 語法、HTTP 強制轉 HTTPS、查詢參數轉址、Cloudflare 轉址比較，以及 WordPress 外掛替代方案。每段都附上可直接複製的程式碼範例和除錯方法。

.htaccess 是什麼？為什麼需要用它做轉址？

.htaccess（Hypertext Access）是 Apache 網頁伺服器的目錄層級設定檔。檔名以「.」開頭，在 Linux 系統中屬於隱藏檔案，FTP 軟體預設不會顯示。這個檔案可以控制存取權限、自訂錯誤頁面、設定密碼保護、處理 URL 重寫與轉址，以及壓縮傳輸內容。

大多數基於 Linux 的虛擬主機，像是 Bluehost、A2 Hosting 或 DreamHost，底層都跑 Apache，所以 .htaccess 完全適用。如果你的主機用的是 Nginx（例如 Kinsta），就必須改用 nginx.conf，語法完全不同。想了解不同主機的差異，可以參考我們整理的WordPress 虛擬主機推薦。

WordPress 的固定網址（Permalink）功能、快取外掛的規則、以及很多安全外掛，都依賴 .htaccess 運作。只要主機環境支援，學會 .htaccess 轉址就等於掌握了一項基礎但實用的伺服器管理技能。剛接觸 WordPress 的讀者，可以從Bluehost 安裝 WordPress 的完整教學開始熟悉基本操作。

301 與 302 重定向有什麼不同？SEO 影響一次搞懂

寫 .htaccess 轉址規則之前，必須先搞清楚 301 和 302 這兩種 HTTP 狀態碼的差異。選錯了，搜尋引擎可能抓不到正確的網頁，原本累積的SEO 排名權重也可能流失。

301 永久轉址

301 Moved Permanently 表示「這個網頁已經永久搬到新位置」。搜尋引擎收到 301 回應後，會把舊網址的索引替換成新網址，同時把大部分的 PageRank 和連結權重轉移過去。Google 官方已確認 301 轉址不再稀釋 PageRank，權重轉移效果等同於一般連結。只要是永久性的搬遷，301 就是唯一正確的選擇。

302 暫時轉址

302 Found（或 307 Temporary Redirect）表示「這個網頁暫時搬到別的地方，之後還會回來」。搜尋引擎收到 302 後，會繼續保留舊網址的索引，不會把權重轉移到新網址。適用於短期活動頁面導流、A/B 測試或伺服器維護期間的暫時導向。

301 vs 302 快速對照表

如果你想更深入了解 301 和 302 對 SEO 排名的具體影響，可以參考這篇關於 301 與 302 Redirect 差異與 SEO 影響的詳細說明。也可以搭配結構化資料測試工具確認轉址是否被搜尋引擎正確辨識。

.htaccess 檔案在哪裡？如何建立與編輯？

寫轉址規則之前，先找到 .htaccess 並學會安全修改它。這一步做錯，整個網站可能直接無法存取。

檔案位置

.htaccess 通常放在網站根目錄，大多數主機的根目錄名稱是 public_html 或 www。因為它是隱藏檔案，需要在檔案管理員的設定裡勾選「顯示隱藏檔案」才看得到。你也可以透過 FTP 客戶端（例如 FileZilla）連線，或安裝 Filester 這類 WordPress 檔案管理外掛，直接在後台操作。

編輯前的必備動作：備份

每次修改 .htaccess 之前，一定要先備份。把原始檔案複製一份，重新命名為 .htaccess.backup 或 .htaccess-20260531。改壞了只要把備份檔名改回 .htaccess 就能馬上恢復。

WordPress 的 .htaccess 預設內容

WordPress 安裝完成後，根目錄的 .htaccess 通常長這樣：

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# BEGIN WordPress 和 # END WordPress 之間的內容是 WordPress 自動管理的，不要在這段區域內插入轉址規則。自訂規則放在 # BEGIN WordPress 之前，或 # END WordPress 之後。

如果完全找不到 .htaccess，用純文字編輯器（Notepad++、VS Code 都可以）建立一個空白檔案，檔名就打 .htaccess（包含前面的點），然後上傳到根目錄即可。

基礎 Redirect 指令：單頁、整站與子目錄轉址

.htaccess 轉址有兩大類指令：Redirect 系列（簡單直接）和 RewriteRule 系列（功能強大但語法複雜）。先從簡單的 Redirect 開始。

單頁面 301 轉址

把一個舊頁面轉到新頁面，只需一行：

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

Redirect 301 後面接舊頁面的相對路徑，再接新頁面的完整網址。例如原本的網址是 /2024-old-post.html，搬到 /new-post/：

Redirect 301 /2024-old-post.html https://example.com/new-post/

整個網站/網域 301 轉址

把整個舊網域的所有流量導向新網域：

Redirect 301 / https://newsite.com/

這會把舊網域的所有頁面（包含首頁和子頁面）全部導向 https://newsite.com/ 的首頁。如果你希望子頁面的路徑也一起保留（例如 /about/ 轉到 newsite.com/about/），要改用後面的 RewriteRule 方式。如果你正在規劃選擇網域名稱的策略，這個技巧遲早用得上。

網站轉址至子目錄

把根目錄的所有內容移到 /blog/ 子目錄：

Redirect 301 / https://example.com/blog/

所有訪客都會被導到 /blog/ 子目錄。這在重新組織網站架構時很實用，例如從單純的部落格轉型成企業官網加部落格的組合。

子目錄轉址至新網站

只把某個子目錄的內容搬到全新網站：

Redirect 301 /old-folder https://newsite.com/

這條規則只影響 /old-folder/ 及其底下的頁面，其他路徑完全不會受影響。適合把某個產品線的內容拆分到獨立網站。如果你有自訂網域的需求，可以參考Blogger 自訂網域設定教學，裡面也有相關的 DNS 設定知識。

檔案副檔名批次轉換

如果你把整個網站從 PHP 改成靜態 HTML，不想一頁一頁寫 Redirect，可以用 RedirectMatch 搭配正則表達式一次搞定：

RedirectMatch 301 (.*)\\.php$ $1.html

這會把所有 .php 結尾的網址自動轉成 .html 結尾。反方向只要把 .php 和 .html 對調即可。

RewriteRule 重寫規則進階應用

Redirect 指令有個限制：不會自動保留原始網址的路徑結構。如果你需要更精細的控制，例如把舊網域的所有頁面連同路徑一起轉到新網域，就要用 RewriteRule。這是 WordPress 主機環境中最常被用到的進階語法。

RewriteEngine 與 RewriteCond 基礎

所有 RewriteRule 相關指令都必須在啟用重寫引擎之後才能使用：

RewriteEngine On

這一行是必要的開頭，放在所有 RewriteRule 和 RewriteCond 之前。三個核心概念：

• RewriteEngine On：啟用 URL 重寫功能
• RewriteCond：設定條件（如果…才執行），可以有多條，全部滿足才觸發後面的 RewriteRule
• RewriteRule：定義轉址規則（把 A 轉成 B）

舊網域完整轉址至新網域（保留路徑）

這是最常見的進階需求：整個網站從舊網域搬到新網域，每個頁面的路徑都能對應轉過去。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite\\.com$ [NC]
RewriteRule (.*) https://newsite.com/$1 [R=301,L]

RewriteCond %{HTTP_HOST} 檢查訪客請求的是不是舊網域，[NC] 代表不分大小寫。RewriteRule (.*) 用正則表達式匹配所有路徑，然後接到新網域後面。[R=301] 指定 301 轉址，[L] 代表這是最終一條規則（Last），執行完就停止。

例如訪客連到 oldsite.com/about/contact/，會自動轉到 newsite.com/about/contact/，路徑完全保留。

non-www 轉 www 統一網址

搜尋引擎會把 example.com 和 www.example.com 視為兩個不同的網址。不統一的話，等於製造重複內容問題，影響 SEO 表現。下面把所有 non-www 流量導向 www 版本：

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

反過來，統一用 non-www（把 www 轉成 non-www），把條件和目標對調：

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

不管選哪一種，重點是全站統一，不要有的頁面帶 www、有的不帶。

正則表達式速查表

RewriteRule 的威力來自正則表達式（Regex）。以下是 .htaccess 轉址中最常用的符號：

有了這張速查表，再搭配GZIP 壓縮設定技巧，就能組合出各種複雜的伺服器規則。

HTTP 與 HTTPS 強制轉址設定

Google 從 2018 年起就把 HTTPS 列為排名因素，Chrome 瀏覽器也會在 HTTP 網頁上顯示「不安全」標記。不管從 SEO 角度還是使用者信任度來看，強制全站 HTTPS 都是必須做的。設定完成後，可以用 Security Header Scanner 順便檢查網站的安全標頭是否到位。

HTTP 強制轉 HTTPS

在 .htaccess 中加入以下規則：

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTPS} off 檢查連線是不是 HTTP，如果是，就用 RewriteRule 把協定從 http 換成 https，同時保留原本的網域和路徑。

重要：套用這條規則之前，先確認網站已經正確安裝 SSL 憑證。否則轉址過去後，訪客會看到憑證錯誤的警告畫面，反而更糟。如果你用 Kinsta 這類優質主機服務，他們通常提供一鍵強制 HTTPS 的功能，不需要自己改 .htaccess。也可以透過 Cloudflare 的 Always Use HTTPS 功能來達成同樣效果。設定 HTTPS 的同時，別忘了搭配 Cloudflare Turnstile 來強化網站的驗證碼防護。

HTTPS 轉 HTTP（除錯用途）

極少數情況下需要暫時把 HTTPS 導回 HTTP，通常是在排查 SSL 設定問題時：

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

這不是長期做法。排除完問題後，記得馬上改回 HTTP 轉 HTTPS 的規則。

查詢參數（Query String）轉址技巧

很多舊式網站的網址結構是動態的，例如 index.php?id=10 或 product.php?category=5&item=123。這種帶查詢參數的網址對 SEO 不友善，把動態網址轉成乾淨的靜態網址是SEO 優化的重要一步。

查詢參數轉目錄結構

把 index.php?id=1024 轉成 /1024/ 這種目錄格式：

RewriteEngine On
RewriteCond %{QUERY_STRING} ^id=([0-9]+)$
RewriteRule ^index\\.php$ /%1/? [R=301,L]

RewriteCond %{QUERY_STRING} 抓出網址中問號後面的參數，^id=([0-9]+)$ 用正則表達式匹配 id=數字 的格式，括號裡的數字存在 %1 變數中。RewriteRule 把 index.php 轉成 /數字/，結尾的 ? 把原本的查詢參數清掉，避免新網址又帶上 ?id=1024。

帶參數轉址至子目錄

如果參數值要變成某個特定資料夾下的子目錄（例如 /blog/）：

RewriteEngine On
RewriteCond %{QUERY_STRING} ^id=([0-9]+)$
RewriteRule ^index\\.php$ /blog/%1/? [R=301,L]

這樣 index.php?id=1024 就會轉到 /blog/1024/，適合把舊系統的動態頁面遷移到 WordPress 固定網址結構。如果你剛好需要購買網域並設定轉址，可以搭配這些技巧一起完成。

批次轉址與 Redirect Map 建立

網站大規模改版時，動輒需要處理幾十甚至幾百條網址對應關係。這時需要系統化地建立 Redirect Map（轉址地圖），再把規則寫進 .htaccess。

什麼是 Redirect Map？

Redirect Map 就是一份舊網址到新網址的對照清單。在網站改版之前，先用試算表整理所有需要轉址的舊網址和對應的新網址。假設有 50 條轉址規則，在 .htaccess 裡逐一列出即可：

Redirect 301 /old-page-1 https://example.com/new-page-1
Redirect 301 /old-page-2 https://example.com/new-page-2
Redirect 301 /old-page-3 https://example.com/new-page-3
...（以此類推）

避免 Redirect Chain（轉址鏈）

Redirect Chain 是指 A 轉到 B、B 又轉到 C 這種多層轉址。每一層都會消耗 crawl budget（爬取預算），也會輕微稀釋 link juice。Google 官方建議避免兩次以上的連續轉址，最好讓每個舊網址都直接轉到最終目標。

例如舊網址已經做了 A → B 的 301 轉址，後來 B 又改了網址要轉到 C，正確做法是把 A 的轉址規則直接改成 A → C，而不是放任它變成 A → B → C。養成定期檢查轉址鏈的習慣，就像用 TLD-List 查詢最便宜網域一樣，是站長的基本功。

WordPress 遷移時的批次轉址策略

從舊網域整個遷移到新網域時，先用 RewriteRule 處理整域轉址（前面提到的保留路徑方式），再針對路徑有變動的個別頁面額外寫 Redirect 301 規則。大部分頁面一條 RewriteRule 就搞定，只有少數路徑不同的頁面需要額外處理。

進行遷移時，可以先用 Hosting Checker 確認新主機的環境配置。如果你考慮更換主機商，Hostinger 提供了很友善的一鍵遷移工具，也可以用 EasyEngine 簡化 WordPress 的部署流程。

.htaccess 轉址常見錯誤與除錯方法

寫 .htaccess 轉址規則時，差一個空格、漏一個反斜線，都可能讓整個網站出現 500 Internal Server Error。以下是幾個最常踩的坑和對應解法。

500 Internal Server Error

打開網站就看到 500 錯誤頁面，十之八九是 .htaccess 裡有語法問題。常見原因包括：

• 拼字錯誤：把 RewriteEngine 打成 RewriteEngien
• 缺少空格：Redirect301 少了空格，應該是 Redirect 301
• 使用了主機不支援的模組（例如 mod_rewrite 沒有啟用）
• 正則表達式寫錯導致無窮迴圈

排除方法：把剛加的那幾行規則前面加上 # 號註解掉，重新整理頁面。如果網站恢復正常，表示問題出在被註解的那幾行。逐行取消註解，直到找到肇事的那一行。

Redirect Loop（轉址迴圈）

瀏覽器顯示 ERR_TOO_MANY_REDIRECTS 就是轉址迴圈的症狀。意思是 A 轉到 B、B 又轉回 A，瀏覽器來回跳轉幾次後放棄。最常見的場景是同時設了 HTTP 轉 HTTPS 和 HTTPS 轉 HTTP，或者 non-www 轉 www 但又設了反向規則。

解決方法是檢查 .htaccess 規則有沒有互相矛盾。在瀏覽器開發者工具的 Network 面板中，觀察每個請求的 HTTP 狀態碼和 Location 標頭，看是哪兩條規則在打架。如果是502 Bad Gateway 或 503 Service Unavailable 等其他錯誤造成的，問題可能不在 .htaccess 本身。

快取干擾轉址測試

改了 .htaccess 但瀏覽器看起來完全沒變，通常是快取在作怪。需要同時清除三層快取：

• 瀏覽器快取：用無痕模式或清除瀏覽器快取
• WordPress 快取：清除快取外掛的快取
• CDN 快取：如果用了 Cloudflare 或其他 CDN，也要清除它們的快取

用 curl 指令測試轉址

最快確認轉址是否正確的方法，在終端機執行：

curl -I https://example.com/old-page

這會回傳 HTTP 標頭資訊，可以看到狀態碼是不是 301 或 302，以及 Location 標頭指向哪裡。如果沒有終端機環境，也可以用 GiftofSpeed 這類線上工具測試。

Cloudflare 轉址 vs .htaccess 轉址：哪個適合你？

除了在 .htaccess 寫規則，也可以透過 Cloudflare 在 DNS 層級做轉址。兩種方式各有優缺點，適合不同場景。如果你還沒用過 Cloudflare，它的免費 Email Routing 功能也很值得一試。

Cloudflare Page Rules 與 Forwarding URL

在 Cloudflare 控制面板建立 Page Rules，設定 Forwarding URL 來實現轉址。操作不需要碰程式碼，只要填入匹配的 URL 模式和目標網址。如果你已經在用 Cloudflare 做 DNS 服務，這是很方便的附加功能。

但免費方案只提供 3 條規則，Plus 方案有 5 條、Business 方案有 20 條、Enterprise 不限。轉址需求超過免費額度的話，.htaccess 仍然是更實際的選擇。

Cloudflare Workers 進階轉址

Cloudflare Workers 允許寫 JavaScript 腳本處理每個請求，包含執行複雜的條件判斷和轉址邏輯。這比 .htaccess 的 RewriteRule 靈活得多，但需要程式開發能力。免費方案每天有 10 萬次請求額度。

兩種方式比較表

簡單說：轉址規則少的話，Cloudflare 省事又快速；規則多或需要複雜邏輯的話，.htaccess 才是正解。也可以參考 Cloudflare Speed Test 來評估網站使用 Cloudflare 後的速度表現。

WordPress 轉址外掛替代方案

如果覺得直接改 .htaccess 太硬核，WordPress 有幾個好用的轉址外掛可以代替。這些外掛提供圖形化管理介面，讓你在不碰程式碼的情況下管理所有轉址規則。

Redirection 外掛（免費）

Redirection 是 WordPress 上最受歡迎的免費轉址管理外掛，安裝量超過 200 萬。支援 301、302、307 等多種轉址類型，可以自動偵測文章網址變更並建立對應的轉址規則，還能追蹤 404 錯誤並匯出完整的轉址記錄。對大多數站長來說，裝了這個就夠用。

Rank Math SEO 內建轉址

如果你已經在使用 Rank Math SEO 外掛，免費版就內建了轉址管理功能。在後台的 Redirections 頁面新增和管理轉址規則，不需要額外安裝其他外掛。搭配 Disable Comments 等管理外掛，能讓後台更加精簡。

外掛 vs .htaccess 比較

只有幾條到十幾條轉址規則，用外掛比較輕鬆。需要處理幾十條以上的規則，或追求極致效能表現，.htaccess 仍然是最佳選擇。尤其是搭配高效能 WordPress 主題和優質主機時，每一分效能都很重要。剛開始接觸 WordPress 的讀者，可以先從挑選適合的主題開始，再研究轉址的進階設定。

三個下一步

1. 備份現有的 .htaccess 檔案：在修改任何規則之前，先複製一份備份。判斷標準是備份檔名包含日期（例如 .htaccess-20260531），方便日後追蹤。預期結果是改壞了也能在一分鐘內恢復。
2. 用 curl 指令驗證轉址：修改完 .htaccess 後，在終端機執行 curl -I 你的舊網址，確認 HTTP 狀態碼是 301 或 302，Location 標頭指向正確的新網址。判斷標準是狀態碼和目標網址都符合預期。預期結果是轉址正確無誤地運作。
3. 提交 Google Search Console 重新索引：轉址設定完成後，到 Google Search Console 的 URL 檢查工具，主動請求 Google 重新爬取變更的網址。判斷標準是 Google 已收到索引請求。預期結果是幾天到幾週內搜尋結果更新為新網址。

常見問題 FAQ

.htaccess 轉址設定後多久生效？

.htaccess 的修改是即時生效的，不需要重啟伺服器。瀏覽器訪問時，Apache 會即時讀取 .htaccess 並執行。不過搜尋引擎要重新爬取並更新索引，可能需要幾天到幾週的時間。你可以用 Google Search Console 的 URL 檢查工具，主動請求 Google 重新爬取特定的網址，加快更新速度。在等待期間，可以用前述的 curl 指令確認轉址是否正常運作。

修改 .htaccess 會導致網站掛掉嗎？

會。只要語法有錯，整個網站就會出現 500 Internal Server Error。這就是為什麼每次修改前都必須備份。如果你用的是 Bluehost 或 SiteGround 等主流主機，可以在 cPanel 的檔案管理員裡快速復原備份檔案。

Nginx 伺服器能用 .htaccess 嗎？

不行。Nginx 不支援 .htaccess 檔案，它使用 nginx.conf 裡的 server 區塊設定。不過很多 Nginx 主機服務（例如 Kinsta）會提供自己的轉址管理工具，或者自動把提交的 .htaccess 規則轉換成 Nginx 格式。你也可以參考 DNS Flag Day 的相關資訊，了解 DNS 設定對網站的影響。

如何檢查轉址是否正確設定？

最簡單的方法是在終端機執行 curl -I 你的舊網址，查看 HTTP 狀態碼是否為 301 或 302，以及 Location 標頭是否指向正確的新網址。如果不熟悉終端機操作，也可以用瀏覽器開發者工具（F12，Network 面板）來測試，或者用 Facebook 分享偵錯工具確認 Open Graph 標籤在轉址後是否正常抓取。

一個 .htaccess 可以放多少條轉址規則？

理論上沒有硬性上限，但實務上建議不要超過幾百條。每一條規則 Apache 都要在處理請求時逐一檢查，規則越多，伺服器回應就越慢。如果有上千條轉址需求，建議改用資料庫搭配 RewriteMap 的方式，或者使用 WordPress 的轉址外掛來管理。對於大量規則的場景，使用 Cloudways 這類提供進階伺服器設定的主機會更方便。

301 轉址會影響網站載入速度嗎？

單次 301 轉址的效能影響微乎其微，通常只增加幾毫秒的延遲。但如果存在 Redirect Chain（A → B → C），每多一層就多一次 HTTP 請求，累積起來就會被使用者感受到。如果你用的是 FastComet 這類內建 CDN 的主機，轉址效能的影響會更小。

如何復原錯誤的轉址設定？

用之前備份的 .htaccess 檔案覆蓋掉當前版本即可。如果沒有備份，另一個方法是把 .htaccess 裡新增的規則全部刪除或註解掉（前面加 # 號），只保留 WordPress 的預設規則。好的主機服務通常提供自動備份和一鍵復原功能，可以參考我們的 HostPapa 主機評價或SiteGround 主機評價，選擇提供完善備份機制的主機商。

.htaccess 轉址雖然看起來只是一些簡單的文字指令，背後涉及 Apache 伺服器的重寫引擎、正則表達式、HTTP 狀態碼和 SEO 最佳實踐。掌握了這些基礎，就能自信地處理任何網址遷移和轉址需求，不再擔心舊網址變成死連結而拖累網站排名。如果在操作過程中遇到問題，歡迎在底下留言討論。