一家跨國加密貨幣新聞網站的巴西版，在完成這次涉及網域遷移的網站改版後，單日點擊數從原本每天一萬五千到兩萬五千次，一路掉到只剩兩千到四千次，拿遷移前後同一個月份對比，年減幅度將近九成。
這類網站改版後排名下降甚至暴跌的案例，乍看像是被演算法盯上，細究下來，大多數的改版失敗其實有跡可循，問題通常出在幾個具體的執行環節，不是被誰針對。轉址沒做齊、結構動太多、內容砍太兇、爬蟲被擋住，或內部連結路徑跟著斷掉，任何一個環節出錯，原本累積的排名訊號就找不到接手的地方。
接下來就照著轉址、結構、內容、爬蟲設定、內部連結這幾個最常見的出錯環節，一項一項拆開來看。先從最基本、卻也最常被做一半的轉址講起。
原因一：轉址對照表沒做，新舊網址失去對應關係
很多人以為做了轉址就沒事，但轉址對照表跟「有設 301」是兩回事。真正該做的是逐一列出每一個舊網址，一對一寫清楚要導到新網站的哪一頁，而不是用一條萬用字元規則，把整批頁面都導去新站首頁或分類頁草草交代。Google 官方文件在講網站遷移時，特別把「準備網址對應」列成獨立的一步，建議先從網站地圖、伺服器紀錄、外部連結數量高的頁面抓出優先名單，再逐一比對，這正是因為漏掉的那幾頁，常常就是帶著長尾流量或外部連結的重要頁面。
沒做齊對照表，原本累積的排名與連結權重就會找不到接手的新頁面，Google 只能判定舊網址已經消失，相關的排序訊號等於歸零重來。前面提到那個巴西版新聞網站的案例，分析報告點出的根本問題之一，就是轉址與技術遷移協定沒有完整落實，讓 Google 的檢索資源被迫分散在新舊兩個網域之間，誰都沒有真正吃到權重，這正是轉址沒做完整最典型的下場。
另一個常見疏漏是轉址類型用錯。同樣是「網址已經改了」，用 302 暫時轉址或 JavaScript 跳轉代替 301 永久轉址，傳給 Google 的訊號其實完全不同。302 等於告訴搜尋引擎「這只是暫時的，舊網址還是正主」，權重自然不會轉移過去。就算用對了 301，轉址鏈拉得太長，一路從舊網址轉兩三層才到終點，Google 官方建議連續轉址最好控制在三次以內、別超過五次，鏈拉太長等於在半路上不斷稀釋原本的訊號。
原因二：URL 結構全面重整，Google 等於要重新認識整個網站
改版最常見的心態是「反正都要動了，乾脆一次優化到位」，趁機把分類階層重新規劃、網址規則整個換掉，甚至連網域都一起換新。問題是，就算每一條轉址都設定正確，大規模的結構重整仍然等於把整張網站地圖重畫一遍，Google 得重新判斷每一頁在網站裡的位置、跟其他頁面的關聯，這個重新認識的過程需要時間，恢復期自然被拉長。
Google 官方文件給的建議剛好相反，主張遷移計畫一次只改一個項目，例如要換網域，就先只搬網域，等排名穩定下來，才進行版面設計調整，不要網域、內容、CMS、設計同時動。實務上多數改版專案卻反其道而行，把能想到的優化一次做完，這正是恢復期被拉得比預期長的主因之一。
換網域名稱又是風險最高的那一項。Search Engine Land 一篇分析文章直接點出，換網域名稱是遷移過程中「風險最高、建議盡量避免」的動作，即使轉址、內容通通都對，新網域在 Google 眼中仍是一張沒有歷史紀錄的白紙，排名需要重新累積，不會因為內容和轉址都對就自動延續下去。這篇文章也提到，一家生殖醫療服務機構在改版後有機曝光幾乎完全消失，估計損失了大約二十萬美元的營收，而這原本是可以靠事前規劃避開的損失。
遷移的執行節奏也有講究。Google 建議中小型網站原則上一次把所有網址都搬完，不要切成好幾個階段慢慢搬；規模夠大的網站才適合分區段、分批遷移，一段一段確認沒問題再往下一段推進。把這個節奏套反了，中小型網站硬要分批搬，或大型網站求快一次全上，都容易讓部分頁面在過渡期承受不必要的風險。
原因三：內容大幅刪減，新頁面回答不出原本的搜尋意圖
改版最容易被設計端的美術優先順序牽著走的，是內容大幅刪減這一項。原本一頁完整回答某個主題、把使用者可能想知道的細節都寫進去的頁面，改版後常常被換成一段精簡的行銷文案配上一張大圖，字數少了、版面確實好看很多，問題是 Google 判斷一個頁面能不能排到前面，看的是這頁有沒有完整答出使用者搜尋時想知道的答案。內容被砍掉大半，原本承接的搜尋意圖也跟著答不出來，排名自然重新被評分、往後退。
Search Engine Land 一篇談改版風險的文章直接點出，內容改寫的幅度越大，關鍵字排名的波動就越劇烈；文章舉了一個例子，一頁原本針對「狗狗訓練服務」優化的內容，改版後用詞換成偏向「寵物行為協助」，結果原本穩定的排名就跟著鬆動流失。這種變化往往不是刻意要拿掉某個關鍵字，而是換了寫手、換了版型之後，標題和字句選擇不知不覺就跟原本鎖定的主題偏了。
更容易被忽略的附帶損傷，是標題與描述在換版型、換內容管理系統時被系統預設值整批覆蓋掉，原本手動寫好、對準特定搜尋意圖的標題，一夜之間變成 CMS 自動產生的通用版本，頁面在搜尋結果裡等於失去了原本的主題訊號。Ahrefs 一份遷移指南也建議，改版後要逐一比對 canonical 標籤、標題、描述、標題階層這幾個欄位有沒有跟著跑掉，而不是等排名掉了才回頭查。
改版前該先做的功課，是找出目前流量與排名前段的頁面，把這些頁面裡「非留不可」的重點段落與關鍵字先列成清單，交給設計端當底線，精簡可以，但不能把承接搜尋意圖的內容跟著精簡掉。
原因四：測試站封鎖爬蟲的設定，上線後忘記解除
改版流程裡最戲劇化、卻也最容易被忽略的一項檢查，跟畫面好不好看完全無關，是一組看不見的技術設定。開發階段為了不讓還沒上線的測試版內容被 Google 索引、跟正式站的內容重複計算，工程端通常會在 robots.txt 加上封鎖規則，或是在頁面裡加上 noindex 標籤，告訴搜尋引擎這裡先不要收錄。這組設定在開發期是必要的保護，問題出在正式上線那一刻，它常常被忘記拿掉。
Search Engine Land 一篇談改版風險的文章直接點名，無意間封鎖 Google 爬蟲是整個改版流程裡最常被忽略、卻足以讓整個新網站從搜尋結果裡消失的疏漏。Google 官方文件也提醒，若開發階段有用 noindex 或 robots.txt 封鎖測試環境，上線前務必準備好一份「需要移除 noindex 規則」的網址清單，逐一核對解除；Ahrefs 的遷移指南同樣把「確認頁面沒有被設成 noindex」列為上線前必查項目。
這個疏漏之所以特別容易被誤判，是因為新網站上線後，畫面看起來完全正常，排版對、內容也都在，唯獨 Google 收不到收錄的訊號。經營者第一時間往往直覺聯想到「是不是被演算法盯上了」，實際上只是那組原本用來保護測試站的設定，沒有跟著上線流程一起解除。上線前把 robots.txt 的 disallow 規則、頁面裡的 noindex meta 標籤各檢查一次，是排除這類問題最直接的做法。
原因五：導覽與內部連結大幅改動，舊頁面的權重傳遞不到新頁面
很多人以為轉址設定對了，遷移就大功告成，但改版通常也會連帶把全站導覽列、頁尾、麵包屑整套重新設計過。這裡容易忽略的是，轉址處理的是網址本身還能不能找到，內部連結處理的是網站裡的頁面彼此還連不連得起來，兩件事要分開檢查，不能因為轉址都做對了就假設連結也沒事。
就算每一條轉址都正確，連結路徑跟著大搬動，等於讓原本靠內部連結傳遞權重、帶著爬蟲找到重要頁面的那條路徑一起斷掉。Search Engine Journal 一篇分析網站遷移流量下降原因的文章，就把「檢查內部連結」列為要優先確認的項目，提醒改版後常見的疏漏是舊文章裡的連結依然指向已經不存在的舊網址，訪客點下去撲空，搜尋引擎也跟著在頁面之間迷路。Ahrefs 的遷移指南也提到，麵包屑、相關文章區塊、頁尾連結，甚至主導覽選單，都可能在改版過程中被無聲無息地改掉。
Google 官方文件把這件事講得更完整，提醒遷移之後，內部連結、外部連結，連社群平台上的個人檔案連結都要逐一核對更新，而不是只顧著處理站內轉址。實務上比較有效率的做法，是用網站檢索工具把改版前後的內部連結分佈抓出來比對，一次找出所有還指向舊網址的連結，而不是等使用者回報連結失效才一個一個補。
這幾個環節攤開來看，邏輯其實很一致，轉址、結構、內容、爬蟲設定、內部連結，任何一關沒接好，原本累積的排名訊號就會斷在半路，而不是被演算法特別針對。前面提到那個掉了將近九成流量的新聞網站，後來也不是等 Google 自己想通、把排名還回來，而是逐項排查、補齊技術缺口，才在幾個月內讓流量回升——部分地區甚至翻倍、翻三倍。改版本身從來不是排名下降的原因，漏掉哪一個環節，才是。