網址轉向是站長常常需要面對的工作，尤其在重整網站結構、搬移主機或更改網域時。但 301 和 302 這兩個看似相近的轉址方式，在搜尋引擎眼中差別卻很大，處理不當會直接影響網站的搜尋排名。本篇從轉址原理開始，帶你認識外掛設定與手動語法，最後規劃一套完整的站點遷移流程。

301 與 302 轉址的關鍵差異

許多站長把轉址當成單純的技術操作，但實際上它牽動搜尋引擎如何評價你的網站。301 代表永久轉移（Permanent Redirect），告訴瀏覽器和搜尋引擎「這個頁面已經搬到新位置，以後都請去新址」；302 則是暫時轉移（Temporary Redirect），傳達的是「現在先去新頁面，但舊頁面之後可能會回來」。

從 SEO 角度看，301 會將舊頁面累積的連結權重（link equity）傳遞到新頁面，通常保留接近 100% 的權重轉移。Google 承諾轉移原頁面的排名權力、反向連結和權威度評分。302 則不同，搜尋引擎會保持為舊頁面編索引，新頁面即使內容相同也不會直接繼承排名。這就是為什麼許多網站搬遷後流量下滑——它們誤用了 302。

在實務上，301 適用於任何永久性的頁面改動：網址結構改版、頁面合併、移除重複內容等。302 則只在極少數情況下有用，比如你確實知道轉移何時會結束（例如某場活動後恢復舊址）。預設應該用 301，除非你能明確說出 302 的截止日期。

用 Redirection 外掛設定單頁與批次轉址

最直覺的方式是透過外掛，而 Redirection 是 WordPress 社群最常用的工具。安裝流程簡單：進後台→外掛→安裝新外掛，搜尋「Redirection」，啟用後進入工具選單就會看到 Redirection 面板。

首次進入會出現設定精靈，完成後進到主介面。設定頁面會顯示幾個狀態指示燈，如果全部都亮綠燈代表系統準備就緒。左側工具列提供「建立新轉址」的選項，分別對應不同需求：

單頁轉址最簡單。在「來源 URL」填入舊網址（不需要網域部分，例如 /old-post），「目標 URL」填新址（完整網域加路徑），確認類型是 301，按儲存即完成。Redirection 會自動為該頁面設置永久轉移，下次訪客來訪時會直接導向新位置。

批次轉址適合大量改版的情況。假設你把所有產品頁面路徑從 /product/ 改為 /products/，一筆一筆手動設定會很低效。Redirection 提供群組功能，先建立一個新群組（如「產品頁面遷移 2026」），再在該群組內一次設置多筆轉址規則。規則可以用正規表示式（regex）來簡化，例如 ^/product/(.*)$ 會自動配對所有 /product/ 開頭的路徑，並用 /products/$1 作為新目標，系統會自動補上後續的路徑參數。

Redirection 另一項便利功能是自動監控。當你在後台改動文章或頁面的網址（更換 slug）時，外掛會自動建立轉址規則指向新位置，省去手動設定的麻煩。監控需要在設定裡啟用「監控貼文更改」選項，之後每次改動 slug 都會產生對應的 301 轉址。

用 .htaccess 手動設定轉址

如果你習慣直接修改伺服器設定，或外掛因為某些因素無法使用，可以透過 .htaccess 檔案直接寫入轉址規則。.htaccess 是 Apache 伺服器的設定檔，位在網站根目錄，通常已經被 WordPress 佔用來管理固定網址。

最基礎的單頁轉址語法是 Redirect 301 /old-page /new-page。這行指令告訴伺服器，任何進來要求 /old-page 的請求都要永久轉向 /new-page。如果新頁面在不同網域，語法改為 Redirect 301 /old-page https://example.com/new-page，這樣跨域轉址也能正常運作。

針對目錄層級的轉址，語法稍微複雜一些。假設你想把整個 /blog/old-category/ 目錄下的內容轉移到 /news/，可以用：

RewriteEngine On
RewriteRule ^blog/old-category/(.*?)$ /news/$1 [R=301,L]

這個規則用 RewriteRule 指令，第一個參數 ^blog/old-category/(.*?)$ 是配對模式，(.*?) 會抓住後續的所有路徑；第二個參數 /news/$1 是新目標，$1 代表前面抓到的路徑片段；最後的 [R=301,L] 代表用 301 重導且這是最後一條規則（L 是 Last）。

跨網域的全域轉址（例如從舊域名遷到新域名）用 RewriteCond 搭配 RewriteRule：

RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldsite.com$ [NC]
RewriteRule ^ http://newsite.com%{REQUEST_URI} [L,R=301]

這裡 RewriteCond 條件判斷進來的請求是否指向舊域名，如果是的話 RewriteRule 就把它轉向新域名，並保留原本的路徑（%{REQUEST_URI}）。NC 旗標表示不區分大小寫。

編輯 .htaccess 有兩點須注意。第一，轉址規則要寫在 # BEGIN WordPress 註解之前，否則 WordPress 內建的網址規則會優先執行，你的自訂轉址可能失效。第二，一定要先備份原檔案，因為任何語法錯誤都可能讓整個網站無法訪問（顯示 500 錯誤）。編輯完檢查一遍語法再上傳，或用 FTP 軟體先下載、在本地編輯、再上傳，能降低出錯風險。

完整的網站遷移與轉址規劃流程

轉址管理在實務上最考驗的是「規劃」而非「技術」。一個完整的遷移專案包含準備期、上線期、驗證期三個階段。

準備期（至少提前一週）首先要盤點所有頁面。如果網站有幾百篇文章，逐一建立轉址會很耗時。此時應該用 Google Search Console 的報表匯出現有的索引頁面清單，或透過網站爬蟲工具（如 Screaming Frog）掃描全站，產出舊頁面與新頁面的對應表。最常見的策略是優先為流量最高的頁面建立轉址——通常前 20% 的頁面貢獻 80% 的流量，先讓這些頁面不掉排名最能降低損失。如果某些頁面在新結構中沒有對應位置，則轉向最相關的上層分類或首頁，而不是讓它回傳 404 錯誤。

在上線前 24 到 48 小時，降低 DNS 設定的 TTL（Time to Live）值，從預設的 24 小時降到 5 分鐘。這樣當你切換網域或主機時，新設定能在幾分鐘內生效，而不是等上一整天才被全球 DNS 伺服器更新。

上線期執行的動作取決於遷移型別。純轉址改版（例如改 slug）只需要建立轉址規則，頁面內容不動。如果涉及跨域或跨主機遷移，則要先在新主機建好網站，驗證所有功能正常，才把流量切過去。新網站完全上線後，立即批次建立轉址規則——無論用外掛還是 .htaccess，目標是讓舊 URL 盡快導向新位置，降低搜尋引擎抓到 404 的時間。

同時掃描全站內部連結，確保舊頁面之間指向彼此的連結也都更新。有些團隊會用 Go Live Update URLs 這類外掛一次性修復所有舊 URL 參照，替換成新格式。這步很關鍵，因為內部連結壞掉不但影響使用者體驗，搜尋引擎爬蟲也會面臨斷鏈，降低索引效率。

驗證期從上線後開始。第一個動作是向 Google 通知網址變更。如果只是改路徑而域名不變，在 Google Search Console 本身的設定裡通常無法直接申告，但可以提交新的 XML 網站地圖。如果整個網域都換了，Google Search Console 有「變更網址」工具，選擇新域名並提交申告，Google 會加速重新索引，通常在一週內就會把排名權重轉移到新域名。

上線後一週內逐日檢查 Search Console 的錯誤報告，確保轉址正常運作、沒有形成轉址鏈（A→B→C 這種連鎖轉址會浪費權重傳遞）。也要用 PageSpeed Insights 或 GTmetrix 檢查新網站的速度表現，因為遷移往往涉及主機切換，新主機可能更快也可能更慢，這會影響排名。如果發現新網站速度明顯變差，優先處理這個問題，否則 SEO 優化形同虛設。

最後一步是持續監控流量。完成後的前 30 天是觀察期，此時應該每天檢視 Google Analytics 的訪客數、平均工作階段時間等指標。中等規模的網站（50 到 200 頁）通常在完整轉址設定後，有機流量在一季內會回到原水準。如果三個月後流量仍未恢復，通常代表轉址規則有遺漏或設置不完整，此時應該回頭檢查 Search Console 的索引狀態，看是否有大量頁面仍未被重新索引。

許多網站遷移專案的疏漏不在技術細節，而在事前規劃和事後監控。確保轉址對應完整、檢查內部連結、向搜尋引擎主動申告，這三點做到就已經能避免絕大多數的 SEO 損失。這套流程的每一環都是讓網站流量順利過渡的關鍵。