文章換了網址，要做 301；網站只是暫時導向另一頁，可能該用 302。但遇到表單提交、登入流程、商品下架或網站維護，事情就不只是「永久用 301、暫時用 302」這麼簡單。
SEO 轉址不是一種專屬的網站功能，而是網站在網址改變或操作流程中，告訴瀏覽器與搜尋引擎應如何前往另一個位置。選錯方式，可能讓內容對應不清楚，也可能讓表單資料遺失、訪客進錯頁，或產生反覆跳轉。
選擇轉址要先回答三個問題：原網址是否永久停用、目標頁是否承接原本需求，以及是否需要保留請求方法與資料。 本文從常見狀態碼與實作方式開始，整理各自適合的情境，不提供可直接套用所有網站的通用程式碼，也不把轉址當成排名保證。
本文是〈SEO 是什麼〉中「技術體質」這一段的延伸說明，想先看整體架構可以從那裡開始。
SEO 轉址有哪些種類？先分清楚狀態碼與實作方式
301、302、303、307、308 是 HTTP 狀態碼，不是五種網站插件
HTTP 狀態碼是伺服器回應請求時傳回的資訊。常見的轉址回應會搭配 Location，指出下一個位置；網站後台的轉址插件，則只是協助產生這些回應的工具。
比較時要把「永久或暫時」與「請求方法如何處理」分開。GET 常用來取得頁面；POST 常用來提交表單或資料。訪客閱讀文章與系統傳送表單，看似都在前往網址，但功能需求並不相同。
以下依 HTTP 規範與 Google 轉址文件整理。301／302 允許用戶端在後續請求把 POST 改為 GET；307／308 則明確要求自動轉址時保留方法。303 讓用戶端以取得資源的請求查看另一個結果，不是原樣重送 POST。
| 狀態碼 | 主要用途 | 請求方法重點 | 常見適用方向 |
|---|---|---|---|
| 301 | 永久搬移 | POST 可能改為 GET | 一般文章、服務頁永久換網址 |
| 308 | 永久搬移 | 保留方法與請求內容 | 永久搬移且需維持提交流程 |
| 302 | 暫時導向 | POST 可能改為 GET | 暫時替代的閱讀頁面 |
| 307 | 暫時導向 | 保留方法與請求內容 | 暫時更換處理位置，仍需原方法 |
| 303 | 到另一個資源查看結果 | 通常以 GET 取得結果頁；規範也允許 HEAD | 表單或操作完成後的結果頁 |
這不是完整的 HTTP 狀態碼列表，而是企業網站轉址決策中較常遇到的五種。不能只看到代碼比較新，就認為對 SEO 一定更好。
伺服器端、meta refresh 與 JavaScript：轉址在哪裡發生有何差別？
伺服器端轉址是在回應中傳回狀態碼與目標位置。meta refresh 則透過頁面標記，或對應的 Refresh 回應標頭安排導向；JavaScript 轉址依賴程式執行。
Google 建議需要永久更換搜尋結果中的網址時，盡可能採用伺服器端永久轉址。若平台無法實作，再評估其他方式，而不是把所有「瀏覽器有跳走」都當成同樣的設定。
設定可能位於主機、CDN、網站程式或內容管理系統。企業交辦時要確認實際由哪一層產生回應，避免主機與插件各有一套規則，最後互相衝突。
選擇前先問：永久還是暫時？原網址要不要恢復？
文章只是換了路徑，舊頁不再使用，屬於永久變更；服務短期改由另一頁承接，之後仍回到原頁，才有暫時導向的理由。
再問目標頁是否真的承接原需求。如果舊頁在介紹某項服務，目標卻只有企業首頁，就不能只因首頁可開啟而認為對應合理。
最後核對功能：只是讀取公開內容，還是涉及資料提交、登入與交易？永久性決定搬移意圖，方法與資料則決定功能能否正常完成，兩者都需要確認。
永久轉址怎麼選？301 與 308 適合哪些情況？
301：文章換網址、內容整併與舊頁永久停用
301 適合確定不會恢復的網址搬移，例如文章 slug 改名、服務頁路徑調整，或多篇內容已整合到能完整承接答案的新頁。
以下是情境示例：舊文章路徑 /old-guide 改為 /new-guide，內容仍是同一份指南，可以將舊入口永久導向新入口。重點是新頁完整保留需要的內容，而不只是網址看起來相近。
Google 將 301 與 308 都列為永久搬移訊號，用於支持目標頁成為主要網址；這不是設定後必然立即換網址或保留全部排名的保證。
308：永久搬移且需要保留請求方法與內容
308 同樣表示永久搬移，但自動導向時需要維持請求方法與內容。如果原請求是 POST，不應因為導向就變成只讀取頁面的 GET。
例如系統的資料提交端點永久更換位置，且新位置確實能處理原本的提交，可以由工程評估 308。這是功能情境示例，不代表所有表單換頁都要採用 308。
保留資料也帶來責任：目標必須正確、可信且具備處理能力。不能把提交請求隨意導向一般說明頁或其他網域，再假設資料會被安全接收。
301 與 308 的選擇要看功能需求，不是比較哪個更能提升排名
一般公開文章多是 GET 讀取，兩種永久轉址的主要差別未必會在閱讀時顯現。涉及提交流程，則需要核對方法、驗證、資料與系統相容性。
企業應讓工程依實際環境選擇並測試，而不是為了「308 比較新」全面更換既有規則。也不要以「301 比較有 SEO 效果」跳過功能判斷。
永久轉址可能被快取，因此發布前更要核對目標與範圍。HTTP 規範允許 301 與 308 在符合條件時被啟發式快取；錯誤規則修正後，也可能需要處理快取影響。
暫時轉址怎麼選？302 與 307 適合哪些情況？
302：短期替代頁與之後需要恢復原網址的安排
302 適合暫時改變閱讀位置、原網址之後仍要使用的安排。例如某個公開服務頁短期由另一個完整說明頁承接，且團隊已安排恢復條件。
使用暫時轉址時，不只記錄上線日期，也要記錄由誰決定取消、何時檢查，以及原頁如何恢復。沒有維護期限的「暫時設定」，很容易變成長期遺留規則。
Google 說明，暫時轉址本身不作為目標頁應成為主要網址的訊號，但目標仍可能因其他訊號被索引。因此，「302 一定不收錄」或「用了 302 就一定保住原網址」都過度簡化。
307：暫時導向且需要保留請求方法與內容
307 表示暫時改變位置，同時要求自動轉址不能改變請求方法。若暫時更換資料處理位置，又需要維持原有 POST 流程，可由工程評估。
它不是「比較完整的 302」而應無條件取代所有暫時導向。保留提交內容是否正確，仍取決於目標端點與業務流程。
驗收時要實際操作成功與失敗情境，核對新位置是否收到正確資料、有沒有重複處理，以及取消暫時規則後是否能恢復原流程。
活動期間短，不代表一定要轉址；先確認是否真的需要改變閱讀路徑
活動只辦一個月，不代表企業首頁就必須在這個月轉到活動頁。若訪客仍需要公司、服務與聯絡資訊，保留首頁並加入活動入口，可能更符合需求。
活動頁也可以有自己的固定網址，不一定需要把既有頁面導過去。活動結束後是否保留內容、更新下一期，或安排替代頁，需要依內容用途決定。
「短期」是選擇暫時轉址的一個條件，不是啟動轉址的充分理由。 先確認導向是否有必要，再選代碼。
303 轉址用在哪？表單提交後的導向與 SEO 搬頁不同
提交後以 GET 取得結果頁：303 如何支援操作流程？
表單送出後，系統可能先完成資料處理，再以 303 指向完成頁，讓瀏覽器用 GET 讀取結果。HTTP 規範將這種「處理 POST 後前往另一個結果資源」列為 303 的主要用途。
這可把提交動作與結果顯示分開，避免結果頁重新整理時只是重送原來的 POST。但它不能取代後端防重複處理、資料驗證或實際收件確認。
看到完成頁，也不等於已驗證業務端收到資料。表單驗收仍要核對提交成功、儲存或通知，以及追蹤事件是否只在預定成功條件下觸發。
303 不應代替文章或服務頁的永久搬移
文章永久換網址的目的是指出新的內容位置；303 則讓用戶端前往另一個資源查看操作結果。不能因為兩者都讓瀏覽器跳頁，就把它們互換。
Google 將 303 列在暫時轉址類別，而不是永久搬移訊號。需要永久搬移公開內容，應評估 301 或 308，而不是套用表單流程中的 303。
完成頁是否適合被索引，也要另外判斷。它的索引與存取安排，不是靠選了 303 就自動完成。
無法設定伺服器端轉址時，meta refresh 與 JavaScript 能用嗎？
meta refresh：立即與延遲導向的用途及搜尋判讀差異
meta refresh 可以在頁面載入後立即或等待一段時間再導向。Google 將零秒立即導向解讀為永久轉址，延遲導向則解讀為暫時轉址；Refresh 回應標頭也有對應方式。
因此，「等五秒讓使用者看完搬家通知」不只是視覺安排，也涉及搜尋系統如何理解導向。不能先用延遲版本，再把它當成和伺服器端永久轉址完全相同。
若平台確實無法設定伺服器端回應，可以評估這種替代方式。但仍要測試閱讀與導向結果，不因為後台有開關就直接視為完成。
JavaScript：何時才考慮，載入與渲染失敗有哪些限制？
JavaScript 可以透過 location 導向另一個網址，但依賴程式執行。Google 說明會在檢索後透過渲染處理 JavaScript；若渲染失敗，可能無法看到轉址，因此建議只有在伺服器端或 meta refresh 都無法使用時才採用。
腳本未載入、執行錯誤或導向條件不同，都可能讓訪客與搜尋引擎看到不同結果。只在自己的瀏覽器成功一次，不足以證明設定可靠。
也要區分程式路由與真正的網址搬移。網站內部畫面切換，不一定有伺服器端 3xx 回應；需要檢查實際行為，而不是只看網址列改變。
頁面放上「請前往新網址」的連結，不等於已完成可靠轉址
搬家通知與文字連結可以幫助讀者，但它要求讀者自行點擊，不會因此自動成為 HTTP 轉址。
Google 也將這類提示列為不得已的替代方式，不建議在有其他選項時依賴它告知搜尋引擎內容已搬移。
若暫時只有舊平台編輯權限，應明確記錄這是過渡安排，以及後續誰負責完成可靠的導向，不把一段通知文字當成永久轉址交付。
常見網站情境該用哪種？用需求選擇，不是一律做 301
改文章 slug、合併內容與搬網域：確認永久變更與內容對應
永久換路徑或網域，可評估伺服器端 301／308；但每個舊入口都要找到合理的新位置。內容整併時，新頁也應完整承接原本的重要答案。
Google 提醒，大量舊網址導向不相關首頁可能讓使用者困惑，也可能被視為 soft 404；合理整併到能承接內容的頁面，與一律導向首頁不同。
如果涉及整站改版，還需要舊站盤點、部署與後續監測，可以搭配 網站改版如何避免 SEO 流量流失？301 轉址與上線檢查清單。本文則聚焦轉址選擇，不重複完整改版流程。
HTTP 改 HTTPS、有無 www 與網址格式統一：選定正式主要版本
同一份內容有 HTTP／HTTPS、有無 www 或不同格式版本時，先選定正式主要網址，再由工程安排其他版本的合理永久導向。
規則要保留正確路徑，並核對參數是否有用途。不要把所有舊版本都導到首頁，也不要任意刪掉會改變頁面內容或必要追蹤的參數。
網域、憑證與主機也要能正常處理舊入口。設定轉址規則，不代表舊版本的連線問題就會自動消失。
暫時維護、服務不可用與登入導向：先確認回應及功能需求
若只是暫時把讀者引導到可用的替代說明頁，可以評估暫時轉址。但網站本身因維護或過載無法提供服務時，503 可能更符合情況；HTTP 規範也允許搭配 Retry-After 建議稍後重試。
登入導向則屬於存取與操作流程。一般頁面與資料提交的需求不同，不能為了 SEO 把所有未登入請求都永久導向登入頁，也不能未經核對就把 POST 資料導到登入位置。
需要保密的資料仍須驗證與存取控制。轉址不是授權機制，不能代替保護頁面與資料。
商品下架或內容刪除：有合理替代才評估轉址，沒有替代另看 404／410
商品暫時缺貨，可能仍值得保留產品資訊與到貨說明，不必急著導向另一個商品。永久停止銷售，也要確認是否仍有規格、支援或售後查詢需求。
確實有合理替代頁時，才評估對應轉址；若內容已移除且沒有替代，應評估 404／410，而不是硬導到分類頁或首頁。Google 的遷移文件也區分有替代內容與無替代內容的處理。
以下均為情境示例，實際選擇仍需核對內容與系統：
| 情境 | 優先判斷 | 處理方向 |
|---|---|---|
| 同一篇文章永久改 slug | 新頁是否完整承接內容 | 301／308 永久導向 |
| 多篇文章整併 | 新頁是否保留原本重要答案 | 合理對應的永久導向 |
| 暫時替代公開閱讀頁 | 原頁是否會恢復 | 302；有保留方法需求另評估 307 |
| 表單提交後顯示結果 | 是否已完成資料處理 | 評估 303，再核對收件與防重複 |
| 短期活動 | 是否真的需要改變既有入口 | 可保留原頁並新增入口，不必轉址 |
| 網站維護、暫時無法服務 | 是替代路徑還是服務故障 | 評估暫時轉址或 503，不一律跳頁 |
| 商品缺貨 | 資訊是否仍有用 | 可保留頁面並清楚說明 |
| 刪除且無合理替代 | 是否確實不再提供內容 | 評估 404／410，而非硬導首頁 |
哪些設定不是轉址？Canonical、noindex 與錯誤回應要分清楚
Canonical 表達偏好主要版本，不會自動讓訪客跳轉
Canonical 適合表達重複或相近內容中偏好的主要網址，使用者仍可能留在原頁；轉址則改變實際前往的位置。兩者不能只因都涉及主要網址，就視為同一件事。若遇到重複內容或多個網址版本，想了解處理原則，推薦搭配〈Canonical 與重複內容的處理〉一起閱讀。
Google 將轉址與 Canonical 都列為主要網址選擇的重要訊號，但仍由搜尋系統綜合判斷。若需要保留兩個可讀版本，與舊版本完全停用，應採不同安排。
noindex 管理索引；404／410 表達內容不存在，不是轉址種類
noindex 表達不希望內容被索引，不負責搬移訪客；Google 必須能取得該指示，才能處理它，若被 robots.txt 擋住，可能無法讀到。若要分清楚這幾種索引設定各自負責什麼，我們在〈robots.txt、noindex 與 Sitemap 的差異〉中有進一步說明。
404／410 是內容不存在或已移除的回應，不是指向新位置的轉址。保留可用內容、取消索引、永久搬移與移除內容，是四種不同的決策。
因此，不應用 noindex 代替網址搬移，也不需要為了避免出現任何 404，就把已刪內容全部導往不相關頁面。
不把所有舊頁導向首頁，也不只因關鍵字相近就合併頁面
兩篇文章使用相近關鍵字，未必回答同一個問題。如果頁面角色不同，強行整併可能讓讀者找不到原本需要的資訊。
確認內容是否重複、是否已有替代，以及新頁能否承接需求，再決定保留、整併或移除。轉址是執行這個決定的工具，不應反過來決定哪些內容有價值。
轉址設定後怎麼驗收？核對回應、目標與重要功能
檢查 HTTP 狀態碼、Location 與最終頁面，不只看瀏覽器有沒有跳走
瀏覽器通常直接顯示最後頁面，不容易看出中間經過哪些回應。可以使用開發者工具的網路紀錄或其他 HTTP 檢查工具，核對原網址、狀態碼、Location 與最終結果。
若採 meta refresh 或 JavaScript，原回應可能不是 3xx，需要另查實際標記或程式行為。驗收方式應與實作一致，不把所有方式都套用同一張檢查截圖。
| 驗收項目 | 需要留下的紀錄 |
|---|---|
| 原網址與需求 | 完整入口、頁面用途、永久或暫時的理由 |
| 回應與目標 | 實際狀態碼、Location 或用戶端導向設定 |
| 最終內容 | 是否可正常取得，是否承接原本需求 |
| 方法與資料 | GET／POST 等流程，以及必要資料是否正確處理 |
| 暫時安排 | 取消條件、預定檢查點與負責人 |
| 維護安排 | 規則所在系統、權限與回復方式 |
排除轉址鏈、循環、錯誤目標與請求方法造成的功能問題
避免原網址先導到中間頁，再導到最終頁的不必要鏈條；也要排除 A 導到 B、B 又導回 A 的循環。既有規則、插件、CDN 與程式可能共同造成問題。
功能測試不能只用 GET 開啟網址。表單、登入或其他提交流程，需要核對請求方法、驗證資訊、資料接收與重複處理風險，才知道選擇的狀態碼是否符合用途。
測試永久規則時也應考慮快取，區分新部署結果與瀏覽器已記住的舊導向，避免修正後仍用同一個錯誤快取下結論。
更新內部連結、Canonical 與 Sitemap，再分開觀察搜尋結果
永久搬移後，站內連結應直接使用新網址，相關 Canonical 與 Sitemap 也要支持一致的主要版本，避免新舊訊號互相矛盾。Google 的網站遷移說明亦要求核對這些項目。
技術驗收與搜尋成果要分開：回應正確、功能正常，是工作交付；搜尋系統重新處理網址、搜尋點擊與有效詢問，則需要後續觀察，不能只看到轉址成功就宣告 SEO 成果完成。
SEO 轉址不是一律做 301，而是選擇符合內容去向與功能需求的方式。 永久搬移先看 301／308，暫時安排先看 302／307，操作結果另看 303；遇到維護、內容移除或索引需求，也要知道什麼時候不該用轉址。
把變更理由、目標對應、狀態碼與驗收結果寫清楚，企業才能確認設定不只是「會跳頁」，而是真正把訪客與系統帶到正確的位置。
延伸閱讀
- 〈網站沒有被 Google 收錄怎麼辦？從 Search Console 開始排查〉：頁面沒被 Google 收錄時的排查順序