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

當你在經營網站的過程中，遲早會遇到需要將舊網址轉到新網址的情況。可能是因為改了文章標題、遷移了整個網域、或者單純想把 HTTP 全部導向 HTTPS。這時候，.htaccess 轉址就是你手上最快、最直接的工具。

這篇指南會從基礎概念開始，帶你搞懂 Apache 虛擬主機上的 .htaccess 轉址是怎麼運作的，301 和 302 重定向對 SEO 各有什麼影響，再到各種實用的程式碼範例和除錯方法，讓你不用再為網址搬移傷腦筋。

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

.htaccess（Hypertext Access）是 Apache 網頁伺服器預設的目錄層級設定檔。它的名稱以「.」開頭，代表在 Linux 系統中屬於隱藏檔案，所以你在 FTP 軟體裡可能第一眼看不到它。這個小檔案能做的事情比你想像的多很多：控制存取權限、自訂錯誤頁面、設定密碼保護、處理 URL 重寫與轉址，甚至壓縮傳輸內容。

大多數基於 Linux 的虛擬主機服務，像是 Bluehost、A2 Hosting 或 DreamHost，底層都跑 Apache，因此 .htaccess 對這些環境完全適用。如果你的主機用的是 Nginx（例如 Kinsta），那就得改用 nginx.conf 來達成類似效果，語法也完全不同。想知道更多主機選擇，可以參考我們的WordPress 虛擬主機推薦。如果你剛開始架站，也可以試試 DemosWP 免費建立 WordPress 測試站來練習。

對 WordPress 站長來說，.htaccess 一點也不陌生。WordPress 的固定網址（Permalink）功能、快取外掛的規則、甚至很多安全外掛，都依賴 .htaccess 來運作。只要你的主機環境支援，學會 .htaccess 轉址等於掌握了一項基礎但非常實用的伺服器管理技能。如果你剛接觸 WordPress，可以從 Bluehost 安裝 WordPress 的完整教學開始熟悉基本操作。

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

在動手寫 .htaccess 轉址規則之前，你一定要先搞清楚 301 和 302 這兩種 HTTP 狀態碼的差異。選錯了，輕則搜尋引擎抓不到正確的網頁，重則原本辛苦累積的SEO 排名權重全部流失。

301 永久轉址

301 Moved Permanently 代表「這個網頁已經永遠搬到新位置了」。搜尋引擎收到 301 回應後，會把舊網址的索引替換成新網址，同時把大部分的 PageRank 和連結權重轉移過去。Google 官方曾說明，301 轉址大約會流失極少量的排名權重，但影響非常有限。只要你是永久性的搬遷，301 就是唯一正確的選擇。

302 暫時轉址

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

301 vs 302 快速對照表

比較項目	301 永久轉址	302 暫時轉址
HTTP 狀態碼	301 Moved Permanently	302 Found / 307 Temporary
搜尋引擎處理方式	將索引替換為新網址	保留舊網址索引
PageRank 轉移	大部分轉移（約 90-95%）	不轉移
適用場景	網址永久搬遷、網域遷移、HTTP 轉 HTTPS	短期活動、A/B 測試、維護頁面
瀏覽器快取行為	會快取轉址結果	不會快取，每次都會重新檢查
對 SEO 的影響	正面，幾乎不流失排名	中性，舊網址仍保留排名

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

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

在開始寫轉址規則之前，你得先找到 .htaccess 檔案並學會安全地修改它。這一步如果做錯，整個網站可能直接掛掉，所以請務必照著下面的步驟來。

檔案位置

.htaccess 通常放在網站的根目錄底下，大多數主機的根目錄名稱是 public_html 或 www。如果你使用 Bluehost 主機，可以在 cPanel 的檔案管理員裡找到它。因為它是隱藏檔案，你需要先在檔案管理員的設定裡勾選「顯示隱藏檔案」，才能看到它。

你也可以透過 FTP 客戶端（像是 FileZilla）連線到主機，或者安裝 Filester 這類 WordPress 檔案管理外掛，直接在後台操作。

編輯前的必備動作：備份

每次修改 .htaccess 之前，一定要先備份。最簡單的做法就是把原始檔案複製一份，重新命名為 .htaccess.backup 或 .htaccess-20260530。萬一改壞了，只要把備份檔案的名稱改回 .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（包含前面的點），然後上傳到根目錄即可。你也可以參考 Gutenberg 編輯器相關教學，了解更多 WordPress 後台的操作技巧。

基礎 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 結尾。例如 /article-1.php 會被轉到 /article-1.html。反方向（html 轉 php）只要把 .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）。下面列出幾個最常用的符號，每個都附上一個小範例，幫你快速上手：

符號	意義	範例
^	匹配字串開頭	^about 匹配所有以 about 開頭的路徑
$	匹配字串結尾	.html$ 匹配所有以 .html 結尾的路徑
(.*)	匹配任意字元（0 次或多次）	^blog/(.*) 匹配 /blog/ 後的所有內容
[NC]	No Case，忽略大小寫	讓規則不區分大小寫
[L]	Last，最終一條規則	匹配後停止往下處理
[R=301]	指定 301 轉址	可以改成 R=302 做暫時轉址
[QSA]	Query String Append，保留查詢參數	確保 ?id=123 之類的參數一起帶過去
\\.	跳脫字元，匹配真正的「.」	example\\.com 匹配 example.com

有了這張速查表，再加上前面提到的 GZIP 壓縮設定技巧，你就能組合出各種複雜的伺服器規則了。

HTTP 與 HTTPS 強制轉址設定

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

HTTP 強制轉 HTTPS

在 .htaccess 中加入以下規則，就能把所有 HTTP 請求自動轉到 HTTPS：

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

這段規則的邏輯很直覺：RewriteCond %{HTTPS} off 檢查目前的連線是不是 HTTP（HTTPS 為 off），如果是，就用 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 就是一份舊網址到新網址的對照清單。通常在網站改版之前，你應該先用試算表整理出所有需要轉址的舊網址，以及它們對應的新網址。這份清單就是你建立 .htaccess 轉址規則的依據。

假設你有 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 指令：

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 萬次請求的額度。

兩種方式比較表

比較項目	.htaccess	CloudFlare
轉址執行層級	伺服器端（Apache）	DNS/CDN 層級
規則數量限制	無硬性限制（太多會影響效能）	免費 3 條，付費方案更多
設定難度	中等（需要懂語法）	低（Page Rules 圖形介面）
回應速度	稍慢（請求已到達伺服器才轉址）	更快（在邊緣節點直接轉址）
正則表達式支援	完整支援	Page Rules 有限，Workers 完整
適合場景	大量複雜規則、批次轉址	少量簡單轉址、不想碰程式碼
依賴性	需要 Apache 主機	需要使用 Cloudflare DNS

簡單說：轉址規則少的話，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 方式
操作門檻	低，圖形化介面	中高，需要懂語法
管理便利性	有完整管理介面和記錄	需要手動維護文字檔案
效能影響	略高（經過 PHP 處理）	極低（Apache 直接處理）
404 追蹤	多數外掛提供	需要額外安裝工具
大量規則處理	可能拖慢後台	幾百條規則也沒問題
伺服器相容性	適用所有 WordPress 環境	僅限 Apache 和 LiteSpeed

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

常見問題 FAQ

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

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

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

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

Nginx 伺服器能用 .htaccess 嗎？

不行。Nginx 不支援 .htaccess 檔案，它使用的是 nginx.conf 裡的 server 區塊設定。不過很多 Nginx 主機服務（例如 Kinsta）會提供自己的轉址管理工具，或者自動把你提交的 .htaccess 規則轉換成 Nginx 格式。如果你不確定自己的主機跑的是 Apache 還是 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 最佳實踐。掌握了這些基礎，你就能自信地處理任何網址遷移和轉址需求，不再擔心舊網址變成死連結而拖累網站排名。如果在操作過程中遇到任何問題，歡迎在底下留言討論。