301 轉址是什麼？搞懂永久重新導向的設定方式與常見錯誤

什麼是 301 轉址？為什麼它不等於「換網址」

301 轉址（301 Redirect）是 HTTP 協定中代表「永久重新導向」的 301 狀態碼，伺服器用它告訴瀏覽器與搜尋引擎：這個網址已經永久搬到另一個位置。當舊網址確定不再使用時，這是把檢索與排名訊號轉移到新網址最常用的機制。同樣屬於永久重新導向的還有 308，差別在於 308 不允許用戶端把原本的請求方法改寫成 GET，Google 對兩者的處理方式相同。

HTTP 301 狀態碼的技術定義

在 HTTP 協定裡，301 是伺服器回傳的狀態碼，搭配 Location 表頭指出新網址。瀏覽器收到 301 後會自動跳轉，搜尋引擎爬蟲則把這個回應解讀為「資源已永久移動」，進而將舊網址的索引與訊號處理指向新位置。這與 200（正常）或 404（不存在）的本質不同：301 明確攜帶「往哪裡去」的指令，而不是單純告知頁面是否存在。

301 與「換網址」的語意差異

「換網址」是商業動機，例如公司改名、合併兩個網站、或把專案從舊網域搬走；「轉址」則是達成這個動機的技術手段。兩者不對等：你可以換網址卻不用 301（例如直接放新版內容、放棄舊排名），也可以用 301 處理單頁刪除而非整站換網址。只有在舊網址確定永久停用、且新網址承接相同內容時，301 才是正確選擇，否則只是徒增搜尋引擎的判斷成本。

瀏覽器與搜尋引擎如何處理 301

瀏覽器會把 301 回應快取起來，下次使用者直接輸入舊網址時直接跳轉，書籤也會逐漸更新。搜尋引擎則需要重新爬抓舊網址、確認 301 穩定存在、再把舊網址的收錄與訊號合併到新網址，這個過程不是即時的，可能耗費數天到數週。舊網址若仍持續復用，301 會讓它從索引消失，因此確認舊網址不再有價值前不該貿然設置。301 轉址是爬取與索引技術叢集的一環，更完整的背景可參考爬取與索引指南。

301 與 302 的核心差異：永久與暫時該如何選

301 與 302的核心差異在於「永久」與「暫時」的語意，這決定了搜尋引擎是否把舊網址的檢索與排名訊號轉移到新網址。舊網址確定退休就用 301，短期維修或 A/B 測試就用 302，選錯會直接影響收錄歸屬。

比較項目	301 永久轉址	302 暫時轉址
語意	資源已永久移至新網址	資源暫時移至新網址
標準網址訊號	Google 視為強訊號，改以新網址為標準網址	Google 視為弱訊號，舊網址常繼續留在索引
快取與處理	瀏覽器與內容傳遞網路（CDN）較長期快取轉向	通常不長期快取，每次重新確認
使用時機	舊網址確定永久停用	短期維修、A/B 測試、暫時活動

對搜尋引擎來說，301 是語意最清楚的永久轉向訊號。Google 的爬蟲說明把 301 列為「強訊號」、302 列為「弱訊號」，指的是索引管道要不要把轉址目標當成標準網址（canonical）來處理，這也是為什麼遷移與改版幾乎都建議用 301。302 的問題在於它告訴搜尋引擎「只是暫時去一下」，索引管道不會據此改以新網址為標準網址，因此舊網址往往繼續留在索引裡；如果一個其實是永久的變動被設成 302，新網址可能遲遲拿不到該有的排名，等發現時已經錯失時機。

判斷的依據不是「我打算改多久」，而是「舊網址之後還要不要」。只要舊網址確定不再回來、且新網址承接相同內容，就用 301；若是維修期間暫時把流量導到公告頁、或是對同一群使用者做短期 A/B 測試，才用 302。快取層面也有差別：301 會被瀏覽器與內容傳遞網路較長期記住，302 則傾向每次重新確認，這會影響使用者再次造訪舊網址時的跳轉行為。若舊網址只是內容相近但都保留，應改用 canonical 標記（canonical tag）而非 301。

永久與暫時的語意差異

永久與暫時的區分不在時間長短，而在舊網址是否還有存在價值。舊網址確定廢除就是永久，用 301；舊網址只是暫時不能服務就是暫時，用 302，兩者不能互換。

權重傳遞機制的差異

301 讓搜尋引擎把舊網址的連結權重（link equity）與排名訊號合併到新網址；302 因為只是弱訊號，索引管道不會改以新網址為標準網址，舊網址往往繼續留在索引裡，新網址得自己重新累積。這也是為什麼永久變動誤用 302 是最大的損失來源，新網址遲遲接手不了舊網址累積的價值。

快取與搜尋引擎處理速度的差異

瀏覽器對 301 的快取較長，使用者第二次造訪舊網址會直接跳轉；搜尋引擎處理 301 的索引切換需要重新爬抓與確認，不是設完立刻生效。302 因為語意是暫時，搜尋引擎與瀏覽器都傾向保守處理，反而讓舊網址更慢退出索引，這對想快速切換的專案並不利。

哪些情境該用 301 轉址：決策清單

該用 301 的情境是舊網址確定永久停用、且新網址承接相同內容的時候；最常見包含整站換網域、HTTP 升級 HTTPS、網址結構改版、合併重複或過時頁面。只要舊網址還要保留，就該考慮 canonical 標記而非 301。

下面四類情境都成立於同一個前提：舊網址的內容由新網址完整承接，且舊網址之後不再使用。若新網址內容大幅縮水，301 雖然技術上能設，但搜尋引擎可能因為內容不對等而無法順利轉移訊號，這時候該先補內容再轉。另外，短期活動頁不該設 301，活動結束後流量會無處可去，這種情況活動結束直接下線即可，不需要永久轉向。

1. 整站換網域：公司改名、品牌合併、或把舊網域流量全部移到新網域，舊網域確定停用。
2. HTTP 升級 HTTPS：網站從 http:// 搬到 https://，這是同一內容的安全層升級，應用 301。
3. 網址結構改版：把 /product.php?id=1 改成 /product/1，舊路徑永久停用，需逐一 301。
4. 合併重複或過時頁面：多個內容重複的頁面擇一為主，其餘 301 到主頁；但僅在內容確實重複時成立，否則用 canonical 標記。

合併頁面這一項最常被誤用。只有當多個頁面內容高度重複、且你決定只保留其中一個時，才把其餘頁 301 到主頁；若頁面各自有獨特價值，應該保留並用 canonical 標記建議搜尋引擎偏好哪一個，而不是強制轉址消滅內容。決策的關鍵永遠是「舊網址是否還值得存在」，值得存在就別轉，不值得才用 301 讓它退休。

整站換網域

整站換網域是最標準的 301 使用場景，舊網域所有網址逐一對應到新網域同等網址，並在搜尋引擎完成索引切換前持續保留舊主機，避免 301 突然失效。

HTTP 升級 HTTPS

HTTP 升級 HTTPS 屬於同一網站的安全層變更，所有 http:// 網址都應 301 到對應的 https:// 網址，這也是搜尋引擎明文建議的做法，能保全原有收錄與訊號。

網址結構改版

網址結構改版發生在重寫路由規則時，舊路徑永久失效，必須用規則把每個舊網址對應到新網址，避免產生大量 404。關於網址設計的原則可參考網址結構指南。

合併重複或過時頁面

合併重複或過時頁面時，只把真正重複且要廢除的頁面 301 到主頁；若頁面仍有獨立價值，改用 canonical 標記而非轉址，才能同時保留內容與集中訊號。

301 轉址會流失 SEO 權重嗎？誤解與證據

301 轉址本身不會吃掉 SEO 權重，Google 會把連結權重與檢索訊號指向新網址；所謂「掉權重」多半來自內容砍半、轉址鏈過長或 canonical 衝突，而不是 301 這個動作。

PageRank 與 link equity 如何傳遞

在 Google 的運作裡，連結權重（link equity）會沿著 301 從舊網址流向新網址，舊網址累積的外部連結價值因此被保留。PageRank 做為排名訊號的一環，也會跟著轉移。前提是新網址內容要對等、轉址要直接（不經過鏈式跳轉），這樣訊號才能完整傳遞，不會在半路被稀釋。

「掉權重」迷思的常見來源

實務上看到排名下滑，常見原因不是 301 偷走權重，而是遷移時砍掉了一半內容、把舊網址設成鏈式轉址稀釋訊號、或舊網址同時放了 canonical 造成訊號衝突。另一個來源是舊網址其實還在搜尋結果裡、新網址遲遲沒被收錄，讓人誤以為權重消失。MDN 的 301 說明指出，搜尋引擎會把指向原網址的連結歸給轉址目標，並把排名傳遞到新網址；Google 的爬蟲說明則把 301 列為要求改處理新網址的強訊號。權重傳遞是預期行為，不需要把短期波動解讀成永久損失，也不要期待設完當天排名就完全不動。

Apache 與 .htaccess 的 301 轉址設定

Apache 環境中，.htaccess（Apache 設定檔）用 Redirect 或 RewriteRule 在請求層攔截舊網址並回傳 301，是最直接的單頁與整站轉址做法。每條規則都要確認路徑正確，否則會誤傷其他網址。

單頁轉址語法

把單一舊網址轉到新網址，用 Redirect 指令最簡單。下方這行表示：當有人造訪 /old-page，伺服器回 301 並跳到 /new-page，你只要把路徑換成自己的網址即可。

Redirect 301 /old-page /new-page

這段在做的是比對網址路徑後回傳 301 狀態碼；何時該改路徑：當你的舊網址命名改變、但內容搬到新路徑時使用，不影響其他網址。

整站網域轉址語法

整站從舊網域搬到新網域，要用 RewriteEngine 配合 RewriteCond 比對主機名稱。下方規則意思是：只要來訪的是舊網域，就把所有請求 301 到新網域的同等路徑。

RewriteEngine On

RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]

RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

這段在做的是先開啟重寫引擎、再用條件比對舊網域、最後把任意路徑導向新網域；何時該改路徑：當整個網站換網域、且希望深層網址也跟著對應時使用。規則裡的 [L] 代表這是最後一條，避免後續規則再次改寫。

萬用字元與正規表達式

萬用字元適合批次處理規律的舊網址，但正規表達式寫得太寬會誤傷其他路徑。下方範例把 /category/ 開頭的舊網址全部導向新分類頁。

RewriteRule ^category/(.*)$ /new-category/$1 [R=301,L]

這段在做的是捕捉 category 之後的任意內容並對應到新路徑；何時該改路徑：當你重命名了某個路由前綴、且底下所有網址都要跟著搬家時使用。正規表達式過寬的失敗模式是連不該轉的網址也被吃掉，設定後務必用工具抽驗深層網址，確認沒有誤傷。

Nginx 與 WordPress 的 301 轉址實作

非 Apache 環境下，Nginx 用 return 301 或 rewrite 指令處理轉址，WordPress 則用 Redirection 外掛在資料庫層記錄規則。兩者都能達成 301，但設定位置與失敗模式不同。

Nginx return / rewrite 指令

Nginx 的 return 指令語意最清楚、效能也最好，優先用 return 而非 rewrite。下方範例把舊網址永久轉到新網址。

location = /old-page { return 301 https://example.com/new-page; }

這段在做的是精確比對 /old-page 後直接回 301；何時該改路徑：單頁轉址且不需要正規比對時使用。若是整站換網域，可在 server 區塊用 if 比對 host 後 return 301，但要注意 if 在 Nginx 裡有使用限制，複雜規則建議用 map 或獨立 server 區塊處理，避免邊界條件出錯。

WordPress Redirection 外掛設定

WordPress 網站若沒有伺服器層權限，可用 Redirection 外掛在資料庫層記錄轉址規則。後台新增一條「來源網址對應目標網址、選擇 301」的規則即可，外掛會在每次請求時檢查是否命中。

失敗模式在於外掛規則與伺服器層規則同時存在會造成雙重轉址（double redirect），讓網址跳兩次才到終點，既浪費爬取預算（crawl budget）也可能觸發轉址鏈問題。若伺服器已設 301，就不要在 WordPress 再設一層；反之若用外掛，就確認伺服器沒有重複規則，兩層來源只能留一個。

轉址鏈與檢查：避免 301 設定失敗

轉址鏈（A 轉 B、B 再轉 C）會讓每次跳轉都消耗爬取預算並稀釋訊號，任何超過一層的轉址都應壓平為直接 A 轉 C。檢查深層網址比只看首頁重要。

轉址鏈為什麼有害

轉址鏈的危害在於每多一層跳轉，瀏覽器與爬蟲就要多發一次請求、多等一次回應。對搜尋引擎來說，鏈式轉址會浪費爬取預算，也可能因為中間某一環不穩定而讓訊號在傳遞過程中被稀釋。舊網站經過多次改版後，常見 A 轉 B 轉 C 的堆疊，正確做法是把 A 直接設成 301 到 C，跳過中間已經不存在的 B，讓路徑最短。Google 說明其爬蟲預設最多追蹤 10 次轉址跳轉，但那是會放棄的上限而不是可以用滿的額度，實務上仍應壓平成一層直達。

Redirect Path 與 Link Redirect Trace 的使用時機

Redirect Path 與 Link Redirect Trace 是用來檢查舊網址經過幾層跳轉的瀏覽器擴充功能，適合在遷移後抽驗深層網址。只靠瀏覽器看得到首頁正確跳轉，不代表深層網址也沒問題，這時就要用工具追蹤完整路徑。

使用時機是遷移上線後、以及日常稽核時：隨機抽樣舊網域的深層網址，確認它們都一層直達新網址、且最終狀態碼是 301 而非 200 或 302。若發現鏈式跳轉，回到伺服器設定把源頭直接對準終點，不要讓舊規則一層層接力。

HTTPS 遷移與整站換網域的 301 策略

HTTPS 遷移與換網域都應用 301 保全檢索訊號，並按照備份、設轉址、更新 sitemap、提交 Google Search Console 網址變更的順序執行。內容對等才轉，否則先補內容。

整站遷移檢查清單

整站遷移的順序決定了流量能不能平穩接續。下方步驟是實務上最少遺漏的做法，每一步都影響搜尋引擎何時完成索引切換。

1. 備份：完整備份舊站檔案與資料庫，任何設定錯誤都有回復點。
2. 設 301：在伺服器層把每個舊網址對應到新網址，確認深層也一層直達。
3. 更新 sitemap：產生新網址的 sitemap 並移除舊網址，提交給搜尋引擎。
4. 提交網址變更：換網域時，在新舊網域都驗證 Google Search Console 資產（需同一個 Google 帳戶、且為網域層級資產），再用網址變更工具告知對應關係。若這次只是 http 升級 https，Google 明確說明不要使用這個工具，照一般遷移流程做即可。

過程中最常犯的錯是只轉首頁、忘記深層網址，或是轉址設完卻沒更新內部連結與 sitemap，讓爬蟲抓到一半又遇到斷點。另外 sitemap 的更新細節可參考sitemap SEO 指南。整站改版與遷移的風險清單已經在網站改版 SEO 風險一文整理，轉址只是其中一環，內容對等與內鏈同步同樣關鍵。

舊網域保留與停用時機

舊網域的伺服器與 301 規則必須持續保留，直到搜尋引擎完成索引切換、且舊網址不再帶入明顯流量。過早關閉舊主機會讓 301 失效、流量瞬間斷崖。Google 對換網域的建議是轉址至少保留 180 天，若舊網址仍有來自搜尋的流量就再延長，並用 Google Search Console 觀察舊網址的曝光是否歸零後再停用，不要搶快關機。

301 轉址的常見錯誤與失敗模式

最常見的 301 失敗模式是用 302 處理永久變動、內部連結與 sitemap 未同步、以及重複規則造成迴圈，這些都會讓爬蟲收錄凍結甚至流量歸零。重大改動前務必備份與分階段驗證。

下面列出的錯誤，每一項的觸發條件都不複雜，但發生時後果很直接。把不該轉的頁面全轉到首頁，會讓爬蟲以為整站內容都變成首頁、深層內容全部掉收錄；規則衝突造成迴圈，則讓爬蟲在舊網址之間無限跳轉、最後放棄抓取。這些都不是 301 機制本身的問題，而是設定時的邊界沒守住，需要在上線前逐條檢查。

• 用 302 處理永久變動：舊網址其實已經退休，卻設成暫時轉址，導致新網址拿不到權重、舊網址繼續佔收錄。
• 內部連結未更新：頁面內還指向舊網址，使用者與爬蟲繞一圈才到新網址，形成不必要的跳轉。
• 規則衝突造成迴圈：兩條規則互相指向，舊網址 A 轉 B、B 又轉 A，爬蟲陷入迴圈、收錄凍結。
• 忘記更新 sitemap：sitemap 仍列出舊網址，搜尋引擎持續回訪已轉址的網址，浪費爬取預算。
• 轉址鏈過長：A 轉 B 轉 C，多層跳轉稀釋訊號並拖慢深層網址抓取。

風險聲明：301 設定錯誤可能導致流量歸零，特別是規則衝突造成的迴圈、或把全站頁面誤轉到首頁。重大改動前請先完整備份、用分階段方式先在測試環境驗證、並用 redirect checker 抽驗深層網址，確認最終狀態碼是 301 且一層直達，再正式上線，不要把整站賭在一次設定上。

用 302 處理永久變動

用 302 處理永久變動是最常見的錯誤，因為設定時以為「先暫時轉著」沒差；但搜尋引擎會因此保留舊網址、不把訊號轉給新網址，等發現時新站已經錯失排名時機，回補成本遠高於一開始就用對。

內部連結與 sitemap 未同步

內部連結與 sitemap 未同步，會讓網站內部仍大量指向舊網址，使用者體驗與爬取效率都受損。轉址設完後，應該把內部連結與 sitemap 一併改成新網址，讓抓取路徑最短，也避免搜尋引擎一直被導回舊網址。

重複或衝突的轉址規則

重複或衝突的轉址規則會讓伺服器不知道該聽哪一條，嚴重時形成迴圈。設定後應該用工具逐一抽驗，確認每個舊網址只有一條明確的 301 終點，沒有互相指涉或是多條規則搶同一個來源。

如何驗證 301 轉址是否生效：工具與解讀

驗證 301 是否生效，要同時檢查 HTTP 狀態碼、用 redirect checker 工具確認深層網址、並在 Google Search Console 觀察收錄切換，三者缺一不可。只看首頁會漏掉深層網址的錯誤。

驗證方法	檢查重點	判讀條件
狀態碼與標頭	舊網址回傳的 HTTP 狀態	301 才是正確；200 代表沒轉，302 代表設錯成暫時
redirect checker 工具	深層網址經過幾層跳轉	應一層直達新網址，且不應出現鏈式跳轉
Google Search Console	舊網址曝光是否下降、新網址是否接手	舊網址曝光歸零、新網址收錄穩定代表切換完成
爬蟲日誌	伺服器端記錄的爬抓路徑	爬蟲直接命中新網址、不再反覆訪問舊網址

狀態碼檢查是最基礎的一層：用瀏覽器開發者工具或線上 redirect checker 輸入舊網址，若回傳 200 表示根本沒轉、若回傳 302 表示你設成了暫時轉址，只有 301 才是對的。但狀態碼正確不代表深層網址也都對，這就是為什麼需要逐層抽驗。Google Search Console 的角色則是觀察「結果」：舊網址的曝光與點擊是否隨著時間下降、新網址是否接手這些流量，這需要數週才會顯現，不是設完當天就能在報表看到。

搜尋引擎處理 301 需要重新爬抓與索引更新，不是即時動作，所以驗證也不能只看當下。建議上線後每週用 Google Search Console 觀察一次，搭配 redirect checker 隨機抽樣舊網域的深層網址，直到舊網址曝光歸零、新網址收錄穩定，才代表這次轉址真正生效。相關的收錄觀察細節可以參考Google Search Console 使用指南。

狀態碼與標頭檢查

狀態碼與標頭檢查是第一步，直接看舊網址回傳的是 301、302 還是 200。只有 301 代表永久轉址設對了，其餘兩者都要回頭改設定，不能只看瀏覽器畫面有沒有跳轉。

Google Search Console 收錄切換觀察

Google Search Console 收錄切換觀察看的是結果面：舊網址曝光是否下降、新網址是否接手流量。這項觀察需要數週，是確認轉址被搜尋引擎接受的關鍵證據，也是判斷能否停用舊主機的依據。

301 轉址與 AK 的 technical SEO 服務

當你面對整站遷移、網址結構重組、或轉址後流量異常時，這已經屬於 technical SEO 診斷範圍，建議交給專人處理而非自行試錯。判斷標準在於問題是否已經超出單一設定、牽動整站收錄。

何時該找 technical SEO 顧問

該找 technical SEO 顧問的條件很具體：你即將做整站換網域或 HTTPS 大規模遷移、網址結構要重組、或者設完 301 後流量異常下滑卻找不到原因。這些情況的風險是流量歸零，自行試錯的成本往往高於一次完整診斷。若只是單頁轉址、且你熟悉伺服器設定，本頁的語法就足以自己處理，不需要外接人力。

相關服務與診斷資源

AK SEO Labs 的technical SEO 服務涵蓋遷移規劃、轉址規則稽核、與流量異常診斷，適合需要有人負責執行與驗證的團隊。遇到具體技術卡點，也可以從SEO 稽核清單開始自我檢查，先釐清是轉址、內容還是內鏈的問題，再決定要不要進一步求助。

常見問題 FAQ

301 轉址生效後，舊網址還需要保留嗎？

舊網址的伺服器與 301 規則必須持續保留，直到搜尋引擎完成索引切換且舊網址不再帶入流量；過早關閉舊主機會讓 301 失效、流量斷崖。Google 對換網域的建議是至少保留 180 天，舊網址若仍有來自搜尋的流量就再延長，並用 Google Search Console 觀察舊網址曝光是否歸零。

一個網址可以同時設 301 與 canonical 嗎？

不建議。301 是伺服器層永久轉向，canonical 標記是索引層建議，兩者同時存在會讓訊號衝突。若舊網址已確定退休就用 301；若只是內容相近但都保留，用 canonical 即可。兩者的邊界可參考 canonical 標記指南。

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

單層 301 的額外延遲極小，只是一次額外的 HTTP 往返；但轉址鏈（A 轉 B 轉 C）會疊加延遲並浪費爬取預算。失敗模式是鏈過長會拖慢深層網址抓取，所以轉址應壓平為一層直達。

更換網域後，Google Search Console 要怎麼處理？

在新舊網域都驗證資產（同一個 Google 帳戶、網域層級），使用網址變更工具提交 301 對應，並更新 sitemap 與內部連結。條件是內容對等才提交，否則先補內容。工具的訊號轉移會持續 180 天，轉址也應至少保留這麼久，不是當天生效。單純的 http 升級 https 則不適用這個工具。

301 轉址設錯會導致流量歸零嗎？

會。規則衝突造成迴圈、或把不該轉的頁面全轉到首頁，會讓爬蟲無法收錄、流量驟降。重大改動前先備份、分階段、用 redirect checker 驗證深層網址，才是把風險壓低的做法。