當網站經歷改版、內容整合或臨時維護時，我們經常需要設定 URL 重定向（Redirect）。看似簡單的 301 與 302 設定，若未審慎處理，可能導致搜尋引擎權重流失、頁面無法被正確索引，甚至形成無窮迴圈，嚴重損害網站效能。本文將系統性地帶您診斷重定向問題，從選擇正確的狀態碼、追蹤複雜的重定向鏈（Chain），到找出常見錯誤與解決方案，提供一套完整的操作指南。
301、302、307、308：什麼時候該用哪一種？
選擇錯誤的重定向狀態碼是導致 SEO 問題的首要原因，其核心差異在於對搜尋引擎爬蟲傳達的「持久性」與「方法保留」語意。301 Moved Permanently 表示資源已永久移動至新位置，主要用途是永久性的網址變更，例如網站遷移、內容永久合併或修復重複內容。搜尋引擎在接收到 301 指令後，會將原網址累積的大部分連結權重（Link Equity）轉移至新網址，並逐漸以新網址取代舊網址在索引庫中的位置。相對地，302 Found 雖然也表示找到資源，但其語意是「暫時性」的，用於如臨時促銷頁面或網站維護時的暫時導引。使用 302 時，搜尋引擎會傾向保留原網址在索引中，並持續爬訪原網址，這可能造成連結權重分散或被索引的頁面並非你預期的目標頁面。錯誤的典型案例是將所有網址永久導向首頁時使用了 302，這會導致舊網址的權重無法傳遞，且首頁可能因大量不相關的重定向而被判定為低品質。
307 Temporary Redirect 與 308 Permanent Redirect 則是更為精確的版本，它們在 302 與 301 的基礎上，增加了「保留原始 HTTP 請求方法」的特性。307 要求瀏覽器或爬蟲在執行重定向時，必須使用相同的 HTTP 方法（例如 POST），這對於處理表單提交或 API 端點的暫時性變更至關重要，能避免未預期的行為。308 則是永久版本的 307，用於需要保留請求方法的永久性網址變更。簡而言之，若你的重定向涉及 POST 請求或嚴格的方法保留，應優先考慮 307/308。若僅是一般的頁面永久移動，301 仍是廣泛相容且有效的選擇；若為一般暫時導向，則使用 302。
Redirect Chain 怎麼發生的？如何用工具追蹤？
追蹤 Redirect Chain 需要借助專門工具，因為瀏覽器通常只顯示最終結果。最基礎的方法是使用命令列工具 curl -I。在終端機輸入 curl -I -L "你的原始網址"，-L 參數會要求 curl 跟隨所有重定向。輸出結果將清晰列出每一跳的 HTTP 狀態碼與目標位置，讓你一覽完整的鏈條。對於網站整體分析，Screaming Frog SEO Spider 是強大的選擇。在其爬蟲設定中啟用「Follow Redirects」後，爬取過程會自動檢測並記錄所有重定向。你可以在「Reports > Redirects > Redirect Chain」報告中查看完整的鏈條結構、每跳的狀態碼以及涉及的頁面數量，這對診斷大型網站的系統性問題非常有幫助。此外，開發者也可以使用瀏覽器內建的開發者工具（DevTools）：在 Chrome 或 Firefox 中切換到「Network」分頁，載入頁面後，點擊請求列表中的第一筆紀錄，在「Headers」標籤頁的「Initiator」或「Response Headers」部分，可以查看該請求是否由重定向觸發，並追蹤後續請求的跳轉序列。
常見 Redirect 錯誤：錯誤 destination、Soft 404、Loop
錯誤的重定向目的地（Destination）是診斷中的高風險區域。最典型的錯誤是將所有失效頁面（如 404 頁面）或不相關的舊頁面，一概重定向至網站首頁或某個熱門頁面。這種做法不僅會讓使用者感到困惑（因為他們期望看到相似的內容），也會向搜尋引擎發出矛盾的訊號，可能被視為試圖操縱排名，且原頁面的上下文關聯性與權重會在這種不相關的跳轉中大量流失。另一個嚴重錯誤是形成 Redirect Loop（重定向迴圈），即 URL A 指向 URL B，而 URL B 又指回 URL A，或形成更複雜的循環。這會導致瀏覽器顯示如「此網頁發生過多重新導向」的錯誤，使用者和搜尋引擎爬蟲均無法到達頁面，完全阻斷了訪問路徑。
Soft 404 是另一個常見的隱形殺手。當一個頁面實際上回應 404 狀態碼，但伺服器配置錯誤，或網頁內容極度空泛（例如只顯示「找不到頁面」的自訂頁面），卻回傳 200 OK 狀態碼時，就發生了 Soft 404。搜尋引擎會花費資源爬取並嘗試索引這些沒有價值的頁面。更糟的是，如果對一個 Soft 404 頁面設定了重定向，可能會將爬蟲引入無意義的內容循環。要驗證是否存在 Soft 404 或錯誤 destination，系統性的檢查至關重要。使用 Google Search Console 的「網址檢查」工具，輸入目標網址，查看 Google 爬蟲實際看到的最終網址與回應代碼。交叉比對伺服器日誌（Log Analysis）能提供更全面的視角，分析特定時間段內，哪些 URL 觸發了重定向，最終到達了哪裡，以及中間是否有異常的狀態碼。這能幫助你發現自動化工具難以偵測的、零星發生的錯誤重定向。
Redirect 與 Canonical 訊號衝突：怎麼判斷？
當一個頁面同時存在 Redirect 指令（例如伺服器端的 301）和 HTML 中的 <link rel="canonical"> 標籤時，可能產生訊號衝突。理想情況下，兩者應指向一致的目標。但實務中，衝突常發生於設定錯誤或遷移未完全時。例如，網址 A 被設定了 301 重定向至網址 B，然而網址 A 的 HTML 檔案中，canonical 標籤卻指向了網址 C。這會讓搜尋引擎爬蟲接收到矛盾的指令：HTTP 層級的 301 明確表示「A 已永久移至 B」，而 HTML 層級的 canonical 卻聲稱「A 的標準版本是 C」。
根據 Google 的文件，處理這類衝突有明確的優先順序：HTTP 狀態碼（如 301 重定向）的訊號通常會優先於 HTML 標籤中的 canonical 指令。這是因為 HTTP 回應標頭是在爬蟲讀取頁面內容之前就被接收和處理的。然而，這並不代表可以忽視 canonical 標籤的設定，因為不一致的設定會消耗爬蟲資源，並可能導致 Google 在極少數情況下做出非預期的選擇。正確的處理原則是：首先確保 HTTP 重定向的設定是正確且必要的；然後，檢查被重定向的來源頁面的 HTML（如果伺服器配置允許爬蟲在重定向前讀取它），將其中的 canonical 標籤也更新為與重定向目標一致，或者完全移除。使用 Google Search Console 的「網址檢查」工具，輸入原始來源網址，它會顯示「Google 選擇的 canonical」是哪一個網址，這能直接幫你確認 Google 最終採納了哪個訊號，是診斷此類衝突最直接的證據。
網站遷移時 Redirect 設置檢查表
網站遷移（例如更換網域、改用新網址結構）是重定向設定最複雜、影響最廣泛的場景。一個周全的檢查流程能最大限度地降低 SEO 風險。遷移前，首要任務是建立一份詳盡的「URL 對應表」，明確記錄每一個需要被重定向的舊 URL，以及它們對應的新 URL 目標。這份表格應涵蓋所有重要的內容頁面、產品頁、部落格文章和圖片資源。使用像 Screaming Frog 這樣的工具完整爬取現有網站，導出所有網址清單，是建立此表的基礎。在測試環境中，依據此表設定所有的 301 重定向，並進行初步測試。
遷移執行時，應立即上線所有 301 重定向規則。同時，密切監控伺服器日誌，觀察是否有大量非預期的 404 錯誤或重定向失敗發生。遷移後的驗證工作更為關鍵。再次使用 Screaming Frog 或類似工具爬取新網址結構，分析「Redirect Chain」報告，確保沒有產生新的、不必要的鏈條。重點檢查是否存在將大量頁面導向首頁或某個不相關頁面的模式，這通常是遷移規則設定過於粗略的跡象。利用 Google Search Console 的「變更地址」工具，可以正式通知 Google 你的網域變更。隨後，透過「網址檢查」工具和「索引涵蓋範圍」報告，交叉驗證 Google 是否已開始爬取並索引新網址，同時逐漸減少對舊網址的訪問。持續數週監控這些數據，確保遷移平穩過渡，所有權重成功轉移。
常見問題
如何快速判斷一個 URL 是否處於重定向鏈中？
最直接的方法是在終端機使用 curl -I -L "你的網址" 命令。加上 -L 參數後，它會顯示從起始網址到最終目的地之間的所有跳轉步驟和對應的 HTTP 狀態碼，讓你一目了然地看出是否存在 Chain。如果輸出中有多行 3xx 狀態碼，就表示存在重定向鏈。
如果我不小心把一個頁面設成了 Redirect Loop，該怎麼補救？
首先，使用 curl 或瀏覽器的開發者工具（Network 面板）確認迴圈的具體路徑。然後，立即登入你的網站管理後台或伺服器設定（如 .htaccess 或 Nginx 設定檔），找到並刪除或修正導致迴圈的那條重定向規則。修改後，務必清除伺服器與 CDN 的快取，並再次用 curl -I -L 驗證是否已恢復正常跳轉。同時，在 Google Search Console 中檢查網址，確認 Google 能夠正常訪問。
對於一個已經被錯誤使用 302 重定向了很長時間的頁面，我現在改成 301 會有什麼影響？
將長期錯誤的 302 改為正確的 301 是有益的修正。其主要影響是，搜尋引擎會開始將原網址的連結權重轉移至目標網址，並逐步用目標網址替換原網址在索引中的位置。這個過程需要時間，可能數週到數月。在此期間，應透過 Google Search Console 的「網址檢查」工具持續監控兩個網址的索引狀態和「Google 選擇的 canonical」是否已變更為你期望的目標網址。
Soft 404 和真正的 404 狀態碼，在處理方式上有什麼不同？
處理方式截然不同。對於真正的 404 狀態碼，你可以選擇：一、如果頁面有新的合適替代內容，則設定 301 重定向到該內容；二、如果頁面永久消失且無替代，就保持 404，允許其自然失效並從索引中移除。而對於 Soft 404（伺服器回傳 200 狀態碼但內容實為「不存在」），首要任務是修正伺服器配置，使其回傳正確的 404 或 410 狀態碼。絕不應該對 Soft 404 頁面設定重定向，因為這會將爬蟲引導至無價值的頁面，浪費資源。
網站遷移時，除了頁面，還有什麼資源需要設定重定向？
除了 HTML 頁面，你還必須考慮其他靜態資源和特殊檔案。這包括：圖片（.jpg, .png）、PDF 文件、下載檔案等。使用 Screaming Frog 爬取舊網站時，確保在設定中勾選爬取這些資源類型。在建立 URL 對應表時，也將這些資源的網址納入，並為它們設置正確的 301 重定向。忽略這些資源可能導致網站內部的圖片鏈接失效、PDF 下載中斷，或這些資源在搜尋結果中顯示為 404 錯誤，影響用戶體驗和頁面品質評分。