301轉址回傳 301 Moved Permanently，代表舊網址永久換到新網址
用狀態碼檢測工具（例如 httpstatus.io）輸入舊網址，回應顯示 301 Moved Permanently，Location 標頭指向新網址，這就是永久轉址生效的樣子。301 是永久性轉址，伺服器回傳 301 並把訪客與爬蟲導向新網址，舊網址累積的權重與流量跟著轉移到新網址。Google 的站點搬移文件也寫明，301 與其他永久轉址不會造成 PageRank 損失。
301轉址的判斷條件很單純：這次變更之後，舊網址不打算再收回來用。整站換網域、把 /news-detail/what-is-seo 這類路徑搬到新的文章結構、頁面永久下架但仍有相關內容可承接，這幾種情況在對應表上都填 301。設定生效後，舊網址會慢慢從搜尋結果中淡出，接手曝光的是新網址。
永久變更才填 301，暫時維護留在另一組
網站改版期間先把流量導到維護頁，維護結束要恢復原網址，這種跳轉的舊網址並不會消失，填 301 等於把話說死。判斷方式是看這條舊網址之後還會不會繼續服務：會，就不屬於永久變更；不會，301 才是正確答案。
舊新 URL 映射與跳轉驗收表
對應表先以舊網址、新網址、備註三欄逐列建立，這是設定轉址之前的底稿；驗收時同一列再補上回傳狀態碼、跳轉層數與最終落地網址。用 Excel 或 Google Sheets 維護都可以，欄位固定下來，逐列設定與逐列核對才有共同依據。
舊網址的清單從 Search Console 的頁面報表或網站的 Sitemap 撈出來，範圍涵蓋首頁、產品頁、文章與服務頁。有外部連結或仍有搜尋流量的頁面優先處理，那些列才是轉址後真正要承接價值的地方。
三欄底稿先建好，驗收的三欄後補
備註欄記的是一次性判斷：這一列是換網域、是網址結構調整，還是頁面下架後改導向服務總覽。核對的人不必回頭翻規則檔，看備註就知道這一列當初為什麼這樣填。
最終落地網址回傳 200，這一列才算設定完成；跳轉層數的理想值是 1，填到 2 以上的列，代表中間多了一層，先確認能不能改成直接指向最終網址。
| 舊網址 | 新網址 | 轉址類型 | 回傳狀態碼 | 跳轉層數 | 最終落地網址 | 備註 |
|---|---|---|---|---|---|---|
| https://example.com/about.php | https://example.com/company.php | 301 | 301 Moved Permanently | 1 | https://example.com/company.php | 網址結構調整，頁面內容不變 |
| https://example.com/blog/123 | https://example.com/new-blog/123 | 301 | 301 Moved Permanently | 1 | https://example.com/new-blog/123 | 文章重新分類 |
| https://example.com/sale | https://example.com/maintenance | 302 | 302 Found | 1 | https://example.com/maintenance | 維護期間暫時導向，結束後撤掉規則 |
| https://example.com/old-service-page | https://example.com/services | 301 | 301 Moved Permanently | 1 | https://example.com/services | 頁面永久下架，導向服務總覽 |
302併入比較：暫時轉址也在同一組欄位裡驗收
301 永久、302 暫時；302 通常不把權重轉到新網址，適用於維護、短期活動與 A／B 測試。把 302 放進同一張表，欄位一個都不用改，轉址類型、回傳狀態碼與備註寫對，兩種類型就在同一組欄位裡並排比較。
302 的回傳狀態碼是 302 Found，瀏覽器依 Location 標頭把訪客帶到新網址。權重與排名通常留在原網址，因為搜尋引擎判斷這只是暫時跳轉，之後還會回到原本的位置。維護結束後要記得撤掉規則，否則暫時跳轉會變成長期設定。
長期掛著 302 的判讀保留彈性
Rankking 的轉址知識頁在 2023 年 8 月的更新裡記錄，John Mueller 表示轉址只要設定正確，用 301 或 302 都不影響 SEO 表現。部分來源仍主張 302 不轉移權重，兩種說法在公開資料裡並存。實務結論不變：確定永久變更就填 301，長期掛著 302 等搜尋引擎自行改判，是把結果交給沒有保證的彈性。
301 狀態碼只能由伺服器或後端送出，前端跳轉拿不到
要拿到真正的 301，設定點在伺服器或後端。Apache 在 .htaccess 用 RewriteRule 加上 R=301，Nginx 在設定檔寫 rewrite 搭配 permanent，PHP 用 header 送出 301 Moved Permanently 再帶 Location 指向新網址。平台後台與外掛也算後端設定，WordPress 可用 Redirection、Rank Math，或 Yoast SEO Premium 的 Redirect Manager，Rank Math 要先啟用 Redirections 模組。
HTML 的 meta refresh 與 JavaScript 的 window.location 不回傳 301 狀態碼，回的是 200 頁面再由頁面自己跳轉，對應表的回傳狀態碼欄就不會出現 301。Google 把 0 秒的 meta refresh 與 JavaScript location 跳轉歸類為永久轉址訊號，延遲數秒的 meta refresh 才視為暫時轉址。能從伺服器端送出就用伺服器端，做不到伺服器端或 meta refresh 時才用 JavaScript 跳轉。
平台後台只吃已失效的網址
SHOPLINE 的後台說明寫明：301 重定向只能為已失效的網址設定，/products、/cart 這類系統頁面前置詞也不支援導向系統頁面。走平台後台的舊網址先確認已經失效，還在線上、只是換結構的頁面交給伺服器規則。
介面設定的好處是不必碰程式碼，語法寫錯讓整站出錯的風險低；代價是規則散在各個介面，改版時容易漏掉一條。對應表裡每一列都要註明規則設在哪裡，這是驗收時回頭修改的依據。
轉址設好之後，用狀態碼、跳轉層數與索引狀態三處驗收
逐筆輸入舊網址，用 httpstatus.io 或 Redirect Checker 確認回傳 301 Moved Permanently，並把完整跳轉過程抄回表上的跳轉層數與最終落地網址欄。落地網址回傳 200，這一列才算過；落地到 404 或不相關的頁面，規則要重寫。
只想快速看單一網址的跳轉狀態，Redirect Path 這類瀏覽器外掛會標示 301、302、404、500 等狀態碼與 meta、JavaScript 前端跳轉，並顯示 HTTP 標頭，在瀏覽器裡順手就能確認。整站要一次掃完，Screaming Frog 的爬取報告會列出轉址鏈與 404。
Search Console 排在三處驗收的最後：用 URL 檢查確認新網址可被收錄，並提交含新網址的 sitemap，協助 Google 更快發現。索引狀態更新得慢，設定當天看不到新網址進索引屬正常，等爬蟲重跑之後再回表上更新那一列。
三處驗收看的是不同的事實
狀態碼確認規則寫對，跳轉層數確認沒有繞路，索引狀態確認搜尋引擎已經接受新網址。少看一處，就會出現規則正確、新頁面卻還沒進索引的落差。
同一次改版同時換網域又改結構，規則數量會壓垮逐列核對的人力，把 URL 對應表與跳轉驗收交給 webwork.com.tw 的技術 SEO 團隊，可以把規則位置、狀態碼與落地網址一次對齊。
轉址鏈、307／308 與其他轉址方式各自適用的情況
A 轉到 B、B 再轉到 C，多層跳轉讓爬蟲多花幾次請求才到最終網址，消耗爬取預算。Google 建議直接導向最終網址，真的需要串接時，鏈長最好在 3 跳以內、不要超過 5 跳，Googlebot 最多追 10 跳，超過就追不到最終頁。對應表上跳轉層數填 2 以上的那一列，就是把規則改成單層、直接指向最終網址的候選。
原始請求不是單純的 GET，而是表單送出或 API 呼叫，狀態碼要改用 307 或 308。這兩個碼保留原始請求方法，POST 送出後仍以 POST 到達新網址；301 與 302 有時會被瀏覽器或程式改成 GET，送出的資料可能帶不到新網址。
前端跳轉是最後手段
只能用前端、伺服器與後端都動不了的舊網址，才會落到 JavaScript 跳轉。Google 對 JavaScript 跳轉要等網頁轉譯完成才執行，轉譯失敗時 Google 可能根本看不到這個跳轉，這一列要在備註寫下原因，之後能改回伺服器端規則就改回。遮罩轉址在對應表上不該出現這一種。
舊網址下架沒有對應頁時，用相關頁或 404／410 收尾
還有相關內容可以承接，就把舊網址用 301 導向那個相關頁，讓外部連結與流量落在同一個主題上。服務頁收掉但服務總覽還在，導向服務總覽；整類內容都不再提供，才往下走。
內容已經完全無關、找不到合適目標，這一列填 404 或 410。兩者都會讓這一列離開索引，410 另外明示是刻意移除，404 則沒有說明是暫時或永久。挑一個填進類型欄，不要為了湊滿一列而硬指一個不相關的新網址，那會讓兩個不相干的主題被綁在一起。
收尾看索引狀態與落地頁
轉址跑完一輪，舊網址在搜尋結果中慢慢消失，新網址接手曝光，這是正常的替換過程。最後再掃一次全表：每一列的狀態碼、跳轉層數與落地網址都對得上，這次改版的轉址作業才算完成。