轉址選 301 還是 302？判斷流程與上線驗證清單

官網改版上線的第三天，行銷週報先出現異狀：搜尋曝光連續下滑，活動頁檢查清單跑出一排 404，站外還有人連進舊產品頁，接到的卻是不相干的分類頁。這是一個用來示範的建構情境，但三個現場指向同一件事：網址的對應關係斷了，新的目的地沒有接住舊的入口。

回看這類事故的紀錄，敗因很少是 301 與 302 二選一選錯。更常見的是順序顛倒：先打開工具開始設規則，商業意圖擺在後面想；真正的風險也集中在機制層，例如規則涵蓋的範圍太廣、兩條規則互相指著對方、舊網址一跳再跳，以及後台顯示已設定、舊址卻照樣回 200 的假成功。

把判斷軸縮到一條就夠用：舊網址會不會回來。不會回來，給永久語意；確定會回來，給暫時語意；回答不出來，先別動手。沿著這條軸，依序處理狀態碼、訊號工具、下架頁、實作層與驗收五個判斷，轉址就成了一份寫在 HTTP 回應裡、可以逐跳檢查的契約。

快速重點：永久退役的網址用 301 或 308，會還原的暫時狀態用 302 或 307；下架頁有相近替代內容才轉、沒有就回 404。規則優先寫在伺服器端，上線後沿舊址回應、Location、最終內容三步驗收，並同步更新內部連結與 sitemap。

先說結論：會出事的轉址，多半不是選錯 301 或 302

翻開轉址事故的檢討，模式高度重複：規則用前綴匹配，把整個資料夾一起帶走；A 轉到 B，B 又轉回 A；舊網址轉到 B，B 再轉到 C，一路接力；強制 HTTPS 的條件在 CDN 後面失準；規則明明儲存了，舊網址卻回 200。這些全部與狀態碼的選擇無關，卻每一項都足以讓流量出事。

把轉址拆到最小單位，它只有兩個動作：伺服器回應一個 3 開頭的狀態碼，並在 Location 標頭附上新網址；瀏覽器或爬蟲收到後，再對新網址發出第二次請求。使用者感覺不到中間的往返，但對搜尋系統來說，那個狀態碼是一份語意承諾：永久，或者暫時。承諾會被彈性解讀，出事的是機制，這是全文的基調。

幾個流傳很久的舊答案，先換成新的：

• 302 完全不傳遞訊號？它不是全有全無的開關，搜尋系統會綜合其他訊號解讀，但解讀的時程與結果都不可控。
• 301 一定折損權重？現行的網站搬移文件已不做此主張；過渡期的波動多半來自重新檢索與結構變動。
• 404 等於懲罰？不是。它是誠實的狀態回報，大量硬轉首頁造成的軟 404 反而更難判讀。
• 後台顯示已新增等於生效？不等於。規則可能被快取層、規則順序或語法細節吃掉，只有實際回應能作證。

↔ 左右捲動檢視完整表格

狀態碼	回應裡的承諾	實務上的角色
301	永久搬移	網址退役後的標準去向，讓搜尋系統把新網址當成正式版本。
308	永久搬移，且保留請求方法	語意同 301，對請求方法嚴格的場景使用。
302	暫時替代	會還原的暫時狀態，標準版本交給搜尋系統綜合評估。
307	暫時替代，且保留請求方法	語意同 302，對請求方法嚴格的場景使用。

五個判斷的下游都是同一個動作：沿回應逐跳驗證，直到最終頁回 200。狀態碼選對、工具選對、規則寫對，都只是紙面上的對；回應攤開來的樣子，才是搜尋系統實際收到的東西。

後續章節照著五個判斷走：先決定狀態碼，再決定該用轉址、canonical 還是 noindex 傳遞訊號，接著處理下架頁的去向，然後選擇把規則寫在哪一層，收在驗收與觀測。工具與語法都在判斷的下游，順序對了，它們才幫得上忙。開場的保養品牌情境會在各節反覆出現，示範每個判斷怎麼落地。

動手前的第一個判斷：舊網址還回得來嗎

直答版本：不會回來的網址，用 301 或 308；確定會回來的暫時狀態，用 302 或 307。對「會不會回來」沒有把握時，先別設轉址，把商業決策談完再動手，因為答案決定你送出的語意承諾，也決定搜尋系統把訊號記在哪個網址上。

Google Search Central 的官方轉址文件把 301、308、302、307 與瀏覽器端的 meta refresh、JavaScript 轉址並列比較，立場清楚：依網址變動的期限選擇對應語意，不是依權重多寡挑狀態碼。官方也說明，301 與 302 屬於標準化訊號，Google 會與其他訊號綜合決定標準網址。設規則前對照一次官方轉址文件，可以省掉不少猜測。

搜尋系統確實會觀察 302 的實際行為：一個掛了很久的暫時轉址，可能被當成永久處理。這份彈性是安全網，不是策略；判斷時程不可控，過程中訊號落在哪個網址也不透明。心裡想永久，就直接給永久語意，不要把後果交給自動校正。

用商業語言重講一次這條軸：要問的不是「技術上哪個狀態碼比較好」，而是「這個網址在公司的計畫裡，明年還存不存在」。答案在產品路線圖與行銷行事曆裡，不在伺服器設定檔裡；技術端的角色，只是把商業答案翻譯成回應。

307 與 308 帶來另一個獨立維度：請求方法的保留。經過 301 或 302，POST 請求在部分情況會被改寫成 GET；經過 307 或 308，POST 仍是 POST。暫時與永久是一個維度，方法保留是另一個維度，兩者獨立組合。一般 HTML 頁面感覺不到差別；提交表單或呼叫 API 的端點，選錯邊可能讓請求內容在轉址後失效，這類流量要實際測試，不能只看狀態碼。

保養品牌的例子在此展開（建構情境）：舊產品線的網址收整到新的分類結構，產品確定不回原網址，這是永久；週年活動頁暫時接手首頁流量，活動結束會還原，這是暫時。動手前還要盤點反向連結落在哪些舊網址上，外部連結資產跟著網址走，高價值的來源可在搬移前後主動請對方更新，完整做法參考站外 SEO 與連結經營。

重複網址問題，該用轉址、canonical 還是 noindex？

直答版本：要讓人與爬蟲實際走到新頁，用轉址；只想聲明內容正本在哪、原頁仍要留著可開，用 canonical；要讓頁面退出索引，用 noindex。三個訊號解決三種問題，效果不互相替代；noindex 與轉址疊設會互相干擾，canonical 要與轉址併用，前提是分清主從。

轉址與 canonical 的分工最容易混淆：轉址發生在回應層，伺服器直接把使用者與爬蟲送往新網址，舊網址不再是可停留的終點；canonical 是頁面裡的正本提示，原頁照常開啟、照常被檢索，只聲明標準版本落在哪個網址。一個實際把人送走，一個留下說明，兩者偶爾搭在一起用，前提是先想清楚誰做主、誰輔助，處理網址版本問題前先分清這層差異，細節參考canonical 完整解析。

與 noindex 的組合有類似陷阱：伺服器回 3xx 時，回應內容裡的 meta noindex 通常派不上用場，搜尋引擎看的是狀態碼與 Location 這一層，不會等舊頁內容。把轉址與 noindex 當雙保險同時設，訊號只會互相干擾；先決定使用者該落地在哪裡，再選訊號，noindex 的適用邊界在noindex 的正確使用可再對照。

一句話版的三者分工：轉址把訪客送到新頁，canonical 聲明正本，noindex 退出索引。把它們當同一件事輪流設，是網址版本問題愈修愈亂的常見起點。

同一個網站裡，三種訊號常常並存，而且各司其職：列印版與正式版網址用 canonical 收斂正本，季節限定的活動網址用暫時轉址接管流量，被淘汰的舊後台頁面用 noindex 退場。並存的前提是每一條都有明確的單一目的；當兩個訊號同時對一個網址說出矛盾的話，搜尋系統只能自己挑一邊相信。

下架的頁面不是全部都要救：404 有時是正確答案

直答版本：頁面下架後，有主題相近的替代頁，把舊網址 301 過去；沒有對應內容，讓它回 404 或 410，不要硬轉首頁。判斷依據是內容對應，不是 404 看起來很嚴重。

下架頁的分流只有兩條路：有主題相近的替代內容，轉向那個新頁；沒有對應內容，回傳 404 或 410。404 不是處罰，它是對「內容不存在」的誠實回報，Google 眼中 404 與 410 是同一回事，410 並不會更快把網址移出索引。更該提防的是將整批沒有替代內容的舊網址統統導去首頁：目的頁與原內容無關時，這類網址容易被判為軟 404，比誠實的 404 更難判讀，「看起來有頁面」不等於「有對應內容」。

替代頁的判斷標準也要說清楚：不是「同個網站裡挑一頁」，而是主題、意圖與內容形式都接得上。舊頁回答的問題，新頁也要能回答；訪客帶著特定需求點進來，接到的卻是完全另一件事，體驗上的斷裂與軟 404 沒有本質差別。

大量清理下架頁還會改變檢索資源的分配。一次清掉幾百頁，爬蟲的造訪模式跟著調整，問題與緩解混在一起，出了狀況很難定位。分批處理、每批觀察爬取與索引的變化，是比較穩的做法；檢索資源怎麼被分配與消耗，檢索預算的運作有完整說明。

兩個行銷情境各示範一種處理（建構情境）：促銷活動結束，活動頁轉往同類商品的列表頁，訪客接得到相近內容；商品確定停產停售，頁面回 410，讓查詢結果誠實反映狀態。兩者都沒有動首頁，因為首頁與這兩個主題都不構成對應。

四種能跳轉的機制，為什麼首選伺服器端 3xx

直答版本：伺服器端 3xx 在第一個回應就附上狀態碼與 Location，Googlebot 第一時間知道目的網址；meta refresh 與 JavaScript 跳轉要先取回頁面再執行程式，目的網址較晚才被看見，出錯的環節也比較多。這是結構差異，不是固定的速度倍數。

分析軸放在「目的網址何時被發現」：HTTP 3xx 在回應裡直接提供 Location，爬蟲讀完標頭就知道目的地；JavaScript 跳轉要先取得 HTML，轉譯執行後才知道要去哪，meta refresh 也得先拿到頁面。被導向的網址愈晚被發現，整併就愈晚開始，錯誤的藏身處也愈多。

↔ 左右捲動檢視完整表格

機制	發生層	目的網址何時可知	適用情境
HTTP 3xx 狀態碼	伺服器回應	第一個回應即附 Location	能控制伺服器回應時的首選。
PHP header 送出狀態碼	應用程式層	同樣在回應層	送出的是真狀態碼，但輸出前不能有任何內容。
meta refresh	瀏覽器，需先取得 HTML	解析頁面之後	無法控制伺服器回應時的退路。
JavaScript 跳轉	瀏覽器，需執行程式	轉譯執行之後	同為退路，設完更要用回應檢查驗證。

PHP 的 header 作法要單獨說邊界：它送出的仍是真正的狀態碼，與伺服器設定屬同一層，但呼叫之前不能輸出任何內容，連多餘的空白都會讓它失效，這個限制讓它比設定檔更容易踩雷。

分工原則照舊：能控制伺服器回應，就別把 meta refresh 或 JavaScript 跳轉當主要手段；只有在完全無法控制回應的託管環境才當退路使用，而且設完更要用回應檢查驗證。登入後的導向屬於功能需求，與公開網址的搬移是兩件事，不放在同一套判斷裡。這層選擇是技術性 SEO 的地基，整體架構的脈絡看技術性 SEO 總覽；JavaScript 與檢索的互動細節，延伸閱讀在JavaScript SEO。

迴圈與接力鏈：讓規則互相打架的兩種結構

直答版本：規則都設了、站卻打不開或流量變少，先查兩種結構事故。A 轉到 B、B 又轉回 A 的迴圈，讓網站直接卡死；A 到 B、B 再到 C 的接力鏈，讓使用者與爬蟲多繞路。兩種都只在實際請求裡現形，規則表上看不出來。

迴圈的症狀很固定：瀏覽器跳出「重新導向次數過多」的錯誤頁，網站形同停擺。成因通常是條件互蓋或兩條規則互指，有時是快取層與 CDN 把新舊規則疊出新迴圈。後台顯示規則存在救不了迴圈；設完每一條轉址，都要實際打開舊網址跑一次，讓回應說話。

迴圈還有一個容易忽略的來源：規則分層。伺服器設定、外掛、快取層各自持有一份規則，單看每一層都沒有錯，疊起來卻互指；排查時要沿回應看每一跳發生在哪一層，而不是只盯著自己最熟的那個設定畫面。

接力鏈的解法是拍平：仍被造訪或仍被引用的舊入口，直接指向最終的新網址，刪掉中途的中繼站。A 先轉 B、B 再轉 C 的結構，每多一跳就多一次往返、多一個出錯的位置；改版後新規則一層層疊在舊規則上，是接力鏈最常見的來源，整理時讓每個入口一眼看得到終點。

這兩種事故的共同教訓：規則之間會互動，單條正確不代表整體正確。只盯著單一規則、單一設定層，不足以排除跨層互指的問題，把幾個關鍵舊網址實際跑一遍，迴圈與接力都會現形；改版與換網域後主動掃一遍全站的轉址結構，成本遠低於事後救流量。迴圈至少還有瀏覽器的錯誤頁可以報信，接力鏈連提示都沒有，兩者最後都要回到逐跳回應才能定位。

換網址前的三項前置：對照表、備份、分段

直答版本：大規模換網址前，準備一份逐筆的舊網址到新網址對照表、一份可還原的備份，以及要不要分段的決定。沒有對照表，出事時連從哪裡查起都不知道。

對照表是整個專案的命根子：每一列是一個舊網址與它對應的新網址，A、B、C 各自指向各自的目的地，逐筆核對，最好雙人複查。上百個頁面靠記憶分工是靠不住的，記憶會漏、會對不上；事後流量掉了，這份表是唯一能逐條比對「預期去向」與「實際回應」的依據，也是驗收清單的原料。

對照表的欄位設計也影響可用性：舊網址、新網址、狀態碼、預期 Location、驗收結果，五個欄位就夠。驗收結果當場填，回報異常時才有共同的事實基礎；用試算表共享給團隊，比口頭回報或聊天訊息可靠。

備份是另一個前提：動任何規則前先備份、確認能還原，出錯時才有退路。WordPress 網站的完整備份與還原程序，備份與還原實作有逐步說明。

分段是第三個決定：彼此相依的網址，一批一次完成並監控，別把同一群頁面拆成長期兩半；彼此獨立的區段可以分批，但每批都要完整走完設定與驗收。新舊 sitemap 的切換時機訂在規則上線的同一刻，別讓索引來源新舊混雜，安排方式參考網站 sitemap 規劃；整套換網域流程照著WordPress 換網域步驟走一遍，比臨場拼湊穩得多。

把規則寫進伺服器：前綴匹配、TLS 終止與上線紀律

直答版本：能改伺服器設定，規則就寫在 Apache 或 Nginx，寫完先測試再上線。三個最會咬人的細節，是前綴匹配、TLS 終止位置，與免測試直接重載。

Apache 的 Redirect 指令用路徑前綴匹配，這是它低調的殺傷力：規則寫 /old，涵蓋的不只 /old 本身，還包括 /old/item 這類後續路徑，符合的部分被替換、其餘路徑接在新網址後面。想限定單一路徑，改用帶起訖錨點的 RedirectMatch；尾斜線有無、查詢參數、大小寫變體，都要在真實路徑上測過才算數。

↔ 左右捲動檢視完整表格

寫法	實際匹配範圍	後果
Redirect 指令配 /old	/old 與其下所有路徑	整個資料夾一起被轉走，範圍比預期大。
RedirectMatch 帶起訖錨點	只有完全符合的那個路徑	單頁異動的約束寫法。
尾斜線未測試	/old 與 /old/ 可能行為不同	兩種連法一種失效，驗收漏掉一邊。

編輯設定檔前的檔案存取與主機環境判別是另一層前置：FTP 與檔案管理處理怎麼拿到檔案，Apache 與 Nginx 的環境差異，虛擬主機環境比較有背景說明。

強制 HTTPS 的條件判斷（Apache 的 mod_rewrite 或 Nginx 的條件設定）是另一個重災區。經典寫法以「請求不是 HTTPS 就轉址」為條件，在 TLS 由伺服器直接處理的環境沒問題；但網站放在 CDN 或反向代理後面時，瀏覽器與 CDN 之間走 HTTPS，CDN 與來源伺服器之間可能是 HTTP，來源端看到的要求永遠「不是 HTTPS」，條件於是反覆成立，轉址迴圈就這樣繞起來。先確認鏈路在哪一層解密，再決定條件怎麼寫；HTTPS 對 SEO 的意義與升級程序，HTTPS 升級另有一篇。錯誤的 301 還可能被 CDN 快取住，修正後清快取再驗證，測試路徑也要與真實路徑一致，別用測試環境的結果替正式環境背書。

同一節最常見的批次案例是 www 與非 www 的統一：兩個版本選一個當標準，另一個永久指過去，屬於最典型的 301 用途，細節與陷阱在www 與非 www 的選擇。

上線紀律只有一句話：規則一有更動，先用實際請求驗過再部署。Apache 的 .htaccess 免重啟，但語法寫錯一個字，整個目錄就會回 500；Nginx 的流程是先跑語法檢查，通過才重新載入，失敗就回到設定檔修改，載入成功後仍要用實際網址驗證回應。這個十秒鐘的動作，擋掉的是把整站弄掛的那種事故。

還有兩個小動作能降低出事的面積：要改的檔案先複製一份留檔，改壞了有得對照；上線時間避開流量尖峰，出狀況時受影響的請求最少，也留得出回滾的緩衝。這些不算技巧，只是讓錯誤有機會只傷到最小的範圍。

WordPress 端：用 Redirection 管規則、讀 404 報表

直答版本：多數 WordPress 網站不需要碰設定檔，用 Redirection 這類外掛管理規則就好：規則存在資料庫、跟著網站搬移、有 404 日誌可查。重點是會讀報表，不是設完就走。

挑外掛的標準不是功能清單的長度，是三件事：規則可以匯入匯出，換主機或重建網站時帶得走；日誌可以導出，事後能對帳；維護活躍，升級 WordPress 時不會變成孤兒。一款用深就好，多套規則來源互相覆蓋，出錯時連來源都找不到；站上已有綜合型 SEO 外掛的話，內建轉址模組也是合理選項，依既有工具鏈取捨。安裝外掛的基礎操作看外掛安裝，Rank Math 內建模組的深度介紹在Rank Math 設定，各套件的整體比較看WordPress SEO 外掛挑選。

用萬用字元或正規表示式寫規則時，先確認規則的實際匹配範圍再儲存：一條寬鬆的規則，可能把整個路徑區段都轉到同一個目的地，造成多頁錯轉。Redirection 支援正規表示式，官方的正規表示式說明頁把語法與匹配範圍講得清楚；規則的匯入匯出與日誌相關設定集中在選項設定說明，整體功能概觀見外掛頁面。這裡的原理與 Apache 前綴匹配相通：範圍比預期大的規則，是錯轉最常見的來源。

404 報表的解讀要對準它的本質：日誌只記錄有到達工具的請求，不是主動掃描全站後的完整清單，沒被請求過的網址不會出現在裡面。看報表時把項目分成三類：有效的舊入口，補上轉址；打錯網址的外部連結，視流量決定要不要救；掃描雜訊，看過就好。請求次數高不等於一律要轉址，次數只是排序依據，對應內容存在與否才是判斷準則。

驗收三步：舊址回應、Location、最終內容

直答版本：沿回應走三步，舊網址應回 301（或 302），Location 應指向預期的新網址，最終頁應回 200 且內容正確。順手抓兩種假成功：舊址直接回 200，以及 301 串 301 的接力。

驗證以逐跳檢查為骨幹，手邊現成的工具就夠用：終端機裡對舊網址跑一次 curl -I，第一跳的狀態碼與 Location 標頭直接列出；或打開瀏覽器開發者工具的網路面板，勾選保留紀錄後重新整理，每一跳的回應會依序排開。看的三件事固定：第一步看舊網址回什麼狀態碼，第二步看 Location 實際指向哪裡，第三步開啟最終頁，確認回 200 之外內容也對。三步都過，這條轉址才算數；舊址直接回 200 是規則沒生效的假成功，一長串 301 串 301 是接力鏈的訊號，同一份逐跳紀錄裡都看得到。驗證時機有三個：設完立刻驗，改版後整批驗，有快取層的站隔一段時間再驗一次，避免被暫存的回應騙過去。

• 舊址回 200：規則沒生效，回查規則順序與語法細節，以及是否被快取層吃掉。
• 目的頁 404：轉址設對了，新網址卻不存在，等於把訪客從一個死路送去另一個死路。
• 預期 301、實際回 302：語意給錯，通常是指令或選項選錯，使用者感覺不到，搜尋系統會。
• 一長串 3xx：接力鏈現形，記下每一跳，把能合併的環節拍平。

單機回應驗完，再延伸到搜尋端視角：用網址檢查工具抽查新舊網址在 Google 眼中的狀態，送出只含新網址的sitemap，協助搜尋系統發現新結構。單一轉址的生效不需要額外的提交流程；設對了、驗過了，剩下的交給檢索週期。

整批驗收有個順序技巧：把對照表裡的舊網址依流量或外部連結排序，從最關鍵的入口開始驗，驗完的在表上標記，沒驗的維持待處理。中途被打斷，進度不會歸零，回頭接著跑就好；上百條規則的專案，進度看得到，心裡才踏實。

上線之後：Google 跟上的速度與你該看的訊號

直答版本：沒有固定時間表。搜尋系統要重新檢索、重新整合標準化訊號，規模愈大、時程愈長；你能做的是持續觀測趨勢，而不是每天催促。

Google Search Central 在官方影片裡講過 301 的處理程序，從檢索舊網址、跟隨轉址，到索引與訊號移轉的整串流程，Processing 301 redirects 這支影片把時間預期講得很白：整併需要時間，觀測以週為單位，任何號稱幾天保證完成的說法都不是官方口徑。

「301 一定折損權重」的舊說法，源自早年關於內部連結價值衰減的內部暗示，現行的網站搬移文件已不做此主張。過渡期的排名波動，多半來自重新檢索與結構變動本身，把波動全部歸因給轉址，因果邊界就畫錯了。第三方對排名因素的相關性分析（例如 Backlinko 的搜尋結果研究）可以當觀察資料，但相關不等於因果，也不能拿來推算自己網站的表現。

觀測點放在 Google Search Console 的索引狀態與搜尋表現趨勢：新網址的索引數量爬升、舊網址逐漸退場，就是整併在前進的形狀。掉勢持續不止時，先回頭查規則與目的頁的回應，再談救援；流量下滑的排查流程在流量下滑診斷，排名回升的程序在排名恢復流程。

觀測要有時間窗：以四週為一個單位看趨勢，比逐日數字有意義，搜尋表現本來就有起伏，過渡期的波動更大。趨勢向上或持平，就讓它跑；趨勢持續向下，回到規則與回應的層面找原因，數字本身不會告訴你錯在哪裡。

換網域後的舊轉址要留多久？Google 在網站搬移指南的建議寫得明白：規則盡可能長期保留，通常至少一年，若舊網址仍有造訪或外部連結，還可以為了這些使用者考慮一直留著。一年不是到期日，而是基本底線；先把還在走的舊入口顧好，維護負擔真的出現時，再依流量與連結的實況逐步收掉。

帶得走的決策清單

照一張分診單走，下次的網址異動就不再靠記憶與手感：

1. 舊網址會回來嗎？不會，給 301 或 308；確定會，給 302 或 307；不確定，先停下來把商業決策談完。
2. 頁面下架後有替代內容嗎？有，轉到主題相近的頁；沒有，回 404 或 410，不動首頁。
3. 該用哪個訊號？要實際送走訪客用轉址，只聲明正本用 canonical，要退出索引用 noindex；noindex 不與轉址疊設，canonical 與轉址併用先分清主從。
4. 規則寫在哪一層？能控制伺服器回應就用 3xx，寫完先測試再上線，CDN 環境先確認 TLS 在哪終止。
5. 怎麼驗收、上線後看什麼？沿舊址回應、Location、最終內容三步驗，搜尋端以索引與表現趨勢觀測，掉勢不止先查規則。

這份清單的用意，是讓判斷可以重複、可以交辦：五個問題的答案寫下來，就是這次網址異動的決策紀錄，團隊任何人接手，都能沿同樣的順序檢查。轉址守護的是已經累積的資產，不製造新的排名；地基顧好了，內容與連結的投入才有東西可疊。更多前車之鑑，常見 SEO 錯誤整理成另一篇可對照。

Whoops 提供網址異動的規劃與驗收顧問協助；正在評估改版，或改版後正在排查掉量，把現況整理好帶過來討論，先把對應關係接穩，再談下一步。