多數人以為網站改版只是換一次皮相，把版型換新、配色調亮、選單重新排列，交出去就大功告成。真正會讓流量在改版後前功盡棄的，往往不是這些看得見的地方，而是網址列上那串字元——改版之後，它去了哪裡。首頁換上新版型，舊網址卻原地變成一片空白，搜尋引擎多年累積下來的排名紀錄，很可能就跟著這片空白一起蒸發。
網站改版舊網址處理，講的就是舊網址消失之後該往哪裡去的一整套判斷，是該一對一轉址到新頁面，還是承認內容真的不在了、乾脆回應資源已下架。做對了，舊網址這些年累積的連結與排名可以平順接手給新網址；做錯了，等於把你過去經營的成果清空，一切重新開始累積。這篇要拆的不是「怎麼設定轉址」這種操作步驟，而是背後那套決定誰該轉去哪裡、要轉多久的邏輯。
先從改版後舊網址實際會落在哪幾種下場講起，再一路拆到轉址設定完之後還要顧的細節。
改版後，舊網址通常會落在哪幾種下場？
舊網址消失後，其實只會落在少數幾種結局，差別只在於有沒有人主動決定它的去向。每一種結局背後都對應一組特定的 HTTP 狀態碼，使用者點進去看到的畫面不一樣，搜尋引擎讀到之後的反應也不一樣。有的會把排名平順轉移過去，有的會被判定成問題頁面而慢慢淡出索引，有的則是連累積下來的紀錄都一起清空。先把這幾種結局攤開，才看得出你的改版該往哪個方向努力。
舊網址正確轉址到新版的對應頁面
這是理想狀態。伺服器回應 301 或 308，瀏覽器自動跳轉，使用者幾乎無感，就像換了個門牌卻沒發現自己走錯路。對搜尋引擎來說，這組狀態碼傳達的是明確訊號，代表內容永久搬家了，原本的網址不再是正確版本。Google 在官方文件中說明，索引系統會把 301 轉址的目標網址視為應該成為標準版本的訊號，並沿著轉址逐步把舊網址身上累積的排名訊號轉移過去。這個轉移不是瞬間發生，而是隨著爬蟲重新造訪、確認新網址內容穩定之後才逐步完成。這也是為什麼即使轉址設定完全正確，流量還是需要一段時間才會回穩，不是設定完成當下就立刻恢復原狀。
舊網址整批轉去首頁，變成一種「軟性 404」
常見的偷懶做法是，找不到對應頁面就一律導回首頁。畫面上不會跳出任何錯誤訊息，乍看之下有轉址就好，但問題在於使用者原本想找的內容跟首頁對不上，搜尋引擎讀到的也是同樣的落差。這種狀況有個專門的名字叫軟性 404，指的是伺服器回傳 200 這種代表成功的狀態碼，但頁面內容實際上等於一則錯誤訊息或一片空白。Google 的說明指出，即使狀態碼顯示成功，索引系統仍會依內容本身判斷這是一個問題頁面，可能因此把它排除在索引之外。換句話說，狀態碼騙得過瀏覽器，騙不過搜尋引擎讀內容的邏輯。
舊網址沒設定轉址，直接變成 404 錯誤頁
最單純也最傷的一種，是完全沒有人處理轉址，舊網址原地變成錯誤頁。使用者點進來，看到的是找不到頁面的畫面；搜尋引擎讀到的是資源不存在，而且沒有指向任何替代版本。MDN 對 404 的定義很單純，就是伺服器找不到請求的資源。這串代碼不像 301 那樣帶著「內容搬去哪了」的線索，對搜尋引擎而言等於這個網址的內容徹底消失，過去累積的排名訊號沒有地方可以承接，只能隨著這個網址一起被清出索引。
內容真的下架了，回應 410 而不是勉強轉址
這一種跟前三種不太一樣，因為內容本來就該消失。產品停產、活動早就結束，這時候該回應的其實是 410，而不是硬把使用者導向一個八竿子打不著的新頁面。MDN 把 410 定義為資源已經永久從伺服器上刪除、沒有轉發地址，用戶端應該移除自己儲存的快取與連結。跟 404 的差別在於明確程度。404 只是說「這裡現在找不到東西」，不排除以後會有；410 則是明確告訴搜尋引擎「這裡不會再有東西了」。這一段其實也點出一個常被忽略的判斷，轉址處理的邏輯不是凡事都要導向某個地方。判斷「這個真的不用留」同樣是舊網址處理的一部分，勉強轉到不相關的頁面，對使用者跟搜尋引擎來說都是另一種形式的落差。
轉址設定跟這幾種下場的關係先建立起來之後，還有一件更容易被低估的事。舊網址消失掉的，不只是那一串字元本身。
舊網址消失，不只是網址字串不見而已
隨便轉個址就算數，是低估了舊網址身上掛著的東西。它不是一串孤立的字元，而是這些年累積下來的資產：其他網站多年來指過來的反向連結、搜尋引擎已經建立起來的排名歷史與索引紀錄，還有使用者自己留存的入口，像是瀏覽器書籤、電子報裡的舊連結、名片與文宣品上印的網址、廣告投放的到達頁。這些東西不會因為改版而自動更新，一旦舊網址失效，等於同時切斷好幾條原本通往網站的路。
反向連結尤其容易被忽略。這些連結的價值不會因為換了新網址就自動搬家，它認的還是原本那個網址；唯一能讓你把這份價值接續下去的方法，就是讓那個網址妥善轉址到新版對應頁面。排名與索引紀錄也是同樣道理，這些紀錄是搜尋引擎花時間逐步建立起來的，不是清空重來就能立刻補回。Google 在說明網站搬遷的文件裡提到，中小型網站的排名重新穩定通常需要數週，規模更大的網站則需要更久。這段等待期不是設定出了問題，而是搜尋引擎本來就需要時間重新確認新網址值得信任。
使用者端留下的入口，又是另一個容易被漏掉的地方。書籤存的是當初那個網址，文宣品印出去之後不會自己更新，廣告到達頁一旦設錯，投放期間的每一次點擊都在把人帶去錯誤的地方。這些入口跟網站上線新版本的時程完全無關，不會因為改版就跟著同步更新。
除了搜尋引擎，現在還多了一群同樣得靠網址存續才能運作的爬蟲，也就是 AI 聊天與搜尋工具背後的抓取程式。OpenAI 在自家的爬蟲說明裡列出好幾支功能不同的機器人，例如負責抓取內容做模型訓練的 GPTBot，還有支援 ChatGPT 搜尋功能的 OAI-SearchBot。這些爬蟲同樣是透過發出網路請求去讀取頁面內容運作的程式，舊網址一旦中斷，先前被這些工具抓取、引用過的內容路徑，也會一併跟著失效。
舊網址該轉去哪裡，是怎麼決定的？
哪個舊網址該轉去哪個新網址，不是憑印象亂接就好，而是有一套可以照著走的邏輯。第一步是把舊網址整理成一份完整清單，而且不能只看網站地圖。網站地圖列的通常是還在維護的頁面，很多已經沒人管理、卻還在被搜尋引擎索引或被外部連結指到的舊網址，反而不會出現在地圖裡。Google 在網站搬遷的說明中建議，除了網站地圖，還要交叉比對伺服器日誌裡最近確實被造訪過的網址、Search Console 的連結報表，以及流量分析工具裡曾經帶進大量流量的頁面，把這幾個管道兜起來，才比較接近舊網址的完整清單。
清單整理出來之後，下一步是一對一比對到內容最接近的新頁面，而不是像前面提到的整批倒進首頁。判斷最相關的標準很單純，就是新頁面能不能回答原本這個網址想解決的問題。產品頁該轉去對應的新產品頁，文章該轉去內容最接近的新文章；找不到完全對應的頁面時，退而求其次也要選內容主題最貼近的分類頁，而不是直接放棄、丟回首頁了事。
映射表定案之後，你還有幾個地方要同步更新，不然轉址等於白做。每個新網址都要有自我參照的 canonical 標籤，指向自己而不是舊版本；網站內部的連結也要從舊網址改成新網址，不能靠轉址硬撐；網站地圖同樣要換成新版網址，讓搜尋引擎抓到的地圖跟實際轉址結果一致。
轉址鏈的層數也有邏輯上限。Google 建議轉址鏈盡量控制在 3 層以內、不超過 5 層，雖然爬蟲最多可以跟隨到 10 層，但這個上限不該被當成可以依賴的空間，畢竟每多疊一層，傳遞下去的訊號就多一分流失的風險。乾脆一開始就把每個舊網址直接指向最終版本，不要疊出 A 轉 B、B 再轉 C 這種轉址鏈。
「永久」與「暫時」轉址，搜尋引擎的反應有什麼差異？
301 跟 308 屬於永久轉址，302 跟 307 屬於暫時轉址，兩組數字的差別不只是技術規格，更重要的是它們各自在跟搜尋引擎說不同的話。MDN 對這四個狀態碼的定義很清楚，301、308 代表資源已經永久搬到新位置；302、307 則代表這只是暫時性的調整，用戶端之後的請求應該繼續使用原本的網址。308 跟 301 的差異，以及 307 跟 302 的差異，都在於前者要求後續請求方法維持不變，例如原本是 POST 就不能被轉換成 GET，不過這是技術細節，對搜尋引擎索引判斷的影響不大，真正決定索引怎麼處理的，是永久或暫時這個核心區分。
永久轉址等於明確宣告「這裡不會再變了，請把新網址當成正式版本」。Google 的說明提到，索引系統會把 301 轉址視為訊號，判斷轉址目標應該成為標準版本，並據此逐步把排名訊號轉移過去。暫時轉址傳達的訊息剛好相反，等於是在說「先別急著更新，舊網址還是主要版本」。搜尋引擎讀到 302 或 307 時，會繼續跟隨轉址讓使用者看到新頁面，但不會把這當成應該永久改用新網址的訊號，原始網址仍可能繼續留在索引裡。
改版是永久性的變動，新版網站上線之後不會再改回舊版，理論上該用的一定是永久轉址。誤用暫時轉址，是這裡最容易出的錯。如果圖方便先套用 302，想著日後再改成 301，排名訊號會一直卡在舊網址上遲遲轉不過去，而搜尋引擎在收到的訊號跟實際狀況（網站已經永久改版）對不上時，也不會主動幫忙修正這個落差。
轉址設定對了，流量卻還是掉，問題通常藏在別處
很多人以為轉址設定完成，這件事就算收工，但轉址設定正確只是條件之一。改版之後流量照樣下滑，問題常常藏在你沒特別注意的幾個技術環節，而不是轉址規則本身出錯。
第一個容易被漏掉的地方，是測試階段留下的殘留設定。網站上線前，開發環境通常會刻意擋掉搜尋引擎爬取，用的是 noindex 標籤或 robots.txt 的封鎖規則；正式上線之後，如果忘記把這些拿掉，等於是新網站自己在跟搜尋引擎說「別索引我」，轉址設定再正確也沒用，因為爬蟲根本進不去看新內容。Google 的說明裡特別提到，這是搬遷案例中常見的失誤之一。
第二個地方，是轉址目標本身寫錯，或者新網站上根本不存在那個網址。這種情況經常發生在映射表製作得太趕，把舊網址隨手接到一個猜測的新網址，結果轉過去又是一個 404，等於把原本的問題原地轉移了一次，沒有真正解決。
第三個地方，是網站地圖沒有同步更新。如果地圖裡列的還是舊網址，搜尋引擎抓到的地圖跟實際轉址結果對不上，索引更新的速度就會被拖慢。
除了這幾個技術疏漏，還有一種狀況容易被誤判成出問題，那就是改版期間本來就會有正常的過渡波動，不能一看到數字往下掉就緊張。真正異常的是斷崖式下滑，也就是短時間內大幅度、看不出回穩跡象的下跌，這種才需要立刻排查前面提到的幾個環節。要分辨兩者，可以觀察 Search Console 裡的索引涵蓋範圍報表，看舊網址的索引數量是不是在正常速度下降、新網址是不是同步在上升；也可以看搜尋查詢報表，確認新網址有沒有開始獲得曝光跟點擊。如果舊網址索引遲遲不掉、新網址又完全沒有起色，通常就代表問題出在前面三個技術環節裡的某一個。
轉址規則要留多久，才不會前功盡棄？
轉址不是設定完就能收工的一次性動作。外部連結不會因為網站改版就跟著更新。其他網站多年前指過來的反向連結、社群上流通已久的分享、還在市面上發送的印刷文宣品，這些連結認的都是舊網址，不會有人主動幫忙全部換成新版本。只要轉址規則還在，這些連結依然能把人帶到正確的新頁面；規則一旦太早拿掉，這些連結就會瞬間失效，累積多年的價值也跟著一起消失。
那要留多久才夠？Google 在說明裡給的建議很明確，轉址至少要保留一年，而且從使用者體驗的角度出發，更建議無限期保留。這個建議背後的邏輯，跟前面提到的另一件事互相呼應。網站搬遷是逐一網址處理的過程，沒有固定的爬蟲重新造訪頻率，規則拿掉得太早，很可能剛好卡在那批還沒被重新確認完成的網址上，反而把還在轉移過程中的排名訊號直接切斷。
比起精算一個差不多可以拿掉的時間點，無限期保留其實是更保守也更安全的做法。轉址規則本身佔用的資源極小，真正的成本是設定跟維護時多花的一點心力，拿掉它省下的資源相對於可能失去的連結價值，並不划算。
網址從來不是改版清單裡可以隨手帶過的小項目。它是一份需要被妥善交接的資產，交接得好，改版是流量與排名的平順接手；交接得不好，就是把過去累積的成果清空，一切從零開始。