舊文章網址最後能開啟，不代表中間沒有繞路。瀏覽器可能先從舊路徑轉到過渡頁，再轉到新文章；地址列只留下最後一個網址，兩次跳轉就被藏起來了。
排查重新導向串時，先保留每一步的 URL、狀態碼與 Location，確認哪一步還有必要。這篇用兩段 HTTP 回應示範怎麼追，不處理 canonical 的選擇，也不要求一開始修改正式主機規則。
先看第一個回應，不自動追到底
在開發者工具的 Network 勾選保留記錄，再輸入舊網址。找到第一個文件請求，檢視 Status 與 Response Headers 的 Location。接著找 Location 指向的下一個請求，重複到最後頁面。
例如舊路徑 /old-guide 回301，Location 是 /middle-guide；middle-guide 再回302，Location 是 /final-guide；final-guide 才回200。訪客要讀最後的文章，瀏覽器先做了兩次轉向。
/old-guide → 301 Location: /middle-guide
/middle-guide → 302 Location: /final-guide
/final-guide → 200Location 可以是相對地址，不能只把字串貼在另一個網域上猜。按上一個回應的 URL 解析，再核對實際下一個請求。遇到跨網域、http轉https或尾斜線變更，也各自算一步，別把它們合併成「瀏覽器自己修好了」。
用 curl 儲存每一步
在 Windows 終端機可明確使用 curl.exe，避免叫到不同工具的同名指令。先用不帶 -L 的請求檢視第一個回應；-o NUL 不輸出正文，-D - 把標頭寫到畫面：
curl.exe -sS -D - -o NUL "https://example.com/old-guide"Linux 或 macOS 把 NUL 換成 /dev/null。這裡仍是 GET，不是 HEAD；有些網站對 HEAD 的處理不同，拿 HEAD 的結果代替訪客實際GET可能漏掉差異。對需要登入或特殊 Cookie 的路徑，先按自己的權限處理，不要把登入憑證貼到公開紀錄。
確認目標可信後，再加 -L 跟隨重導，用 --max-redirs 5 限制這次追蹤的轉址數量：
curl.exe -sS -L --max-redirs 5 -D - -o NUL "https://example.com/old-guide"5只是這次檢查的上限，並非網站應該容許五次轉址。若工具報達到上限，儲存已看到的標頭，回頭找是否形成循環或還有更多跳轉。不要為了讓指令完成，把上限無限拉高。
判斷過渡頁是否還有用途
先看 middle-guide 為什麼存在。若它只是上次搬文章留下的暫存路徑，而 final-guide 已經是長期目標，就可在測試環境把 old-guide 直接導向 final-guide。若中間步驟負責語言、登入或權限判斷，就不能只憑「多一跳」刪掉。
這個例子的301表示舊路徑永久搬移，302表示過渡路徑暫時轉向。正式規則應依實際用途選狀態碼，不要因為文章用了301，就把登入或臨時活動入口全部改成永久轉址。已有快取的永久轉址，也可能讓你改完後仍看到舊結果。
若只是兩個地址互相轉回來，畫出完整循環：A到B、B又到A。儲存觸發條件，例如是否帶尾斜線、https、登入狀態或查詢參數。這比只寫「重導太多」更能讓維護者找到衝突規則。
修完用同一個起點再追一次
修改前儲存舊規則與原始標頭，選一個對應文章入口試做。修正後從同一個舊網址重新開始，理想上直接到正確目標，最後的內容也必須是那一篇文章。若最後回200但進到首頁、登入頁或錯誤提示，不能當作文章轉址已正確。
同時檢視查詢參數是否按用途保留。例如下載入口的檔案識別碼、搜尋條件與語言選擇，不能一律丟掉，也不能把敏感參數轉送到不相干網域。要保留哪些參數，由具體功能決定，先寫成清楚規則再實作。
替網域或目錄安排重導時，列出幾種代表入口：首頁、分類、文章與媒體。不要直接把整批404轉到首頁；先確認每個舊地址有對應內容。改動只限本次規則，發現其他入口受影響時，回復這次變更，再重新核對匹配條件。
看到什麼，還不能推成什麼
curl看到的是HTTP回應。若HTTP文件回200後才由 JavaScript 或 meta refresh 改頁，這套標頭追蹤不會把它列成HTTP Location跳轉。此時配合瀏覽器的 Network、頁面原始碼與執行過程，分清是伺服器轉向還是前端導頁。
瀏覽器的記錄也可能受快取、Service Worker或HTTPS安全策略影響。看到一筆「內部重新導向」時，核對回應來源與標頭，不要直接認定是網站伺服器送的301。用乾淨測試環境比較，可以縮小範圍，但不需要為排查而關閉正式安全設定。
減少多餘轉址後，應重新量測訪客實際載入流程；只數少了一個回應，不能換算成固定省多少毫秒。搜尋引擎是否重抓、是否更新結果也另有自己的處理時間。本文能確認的是網址鏈與內容對應，沒有承諾搜尋成效。
需要決定舊頁究竟保留還是轉走，可另看canonical和301的選擇；WordPress文章本身404，則先看固定連結404排查，不要把不同問題都塞進重導規則。
整理成一張路徑清單，再交給維護者
每個入口記一行：起點、每次回應、最終URL與最終內容。若只有其中一條出問題，先標出它與正常路徑的差異，例如舊域名、多一層目錄、某個查詢參數或少了一個尾斜線。修正應能解釋這個差異，而不是先把所有規則停用。
同一張清單也記錄使用GET、是否登入及瀏覽器是否沿用快取。網站的登入流程可能需要Cookie；命令列沒帶Cookie卻轉到登入頁，是不同的請求條件。不要用公開訪客請求的結果推論會員頁壞了，也不要把私人Cookie放進截圖或貼到討論區。
若多個地方都會做重導，例如CDN、主機設定與WordPress外掛，先請負責人核對哪一層產生每個Location。標頭可提供線索，但不一定足以識別真正規則。沒有設定權限時，將完整追蹤記錄交給維護者即可，不必自己再新增一條相反的規則碰運氣。
重導目標固定後，站內連結也應指向真正要讀的地址。文章搬家卻繼續在導覽或相關文章放舊路徑，訪客每次都會再走一遍轉址；修正連結要儲存來源清單，逐一核對內容對應，不要用相似標題猜目標。
長期存在的舊分享網址仍可以保留合理轉址。目標是讓每條有用途的舊入口到達對應內容，不是追求全站絕對沒有任何301。沒有必要的過渡點能減少，就在確認功能後直達；負責權限或語言判斷的步驟，則保留它的邊界。
最後再輸入一條不存在的地址。它應按照網站原本的錯誤處理回應，不要因為這次改規則，把所有未知路徑都偽裝成某篇文章。驗證後儲存修改前後的追蹤結果，哪天網址再變動，才有具體依據判斷新增了哪一跳。
評論0