改版驗收那天，大家看的都是畫面，新官網在會議室的投影幕上打開，版型變漂亮了、手機版不再破版、載入速度也比以前順，老闆點頭說「這才像我們公司的樣子」，行銷主管把新首頁截圖丟進 LINE 群組，設計公司當天就把結案報告寄了出來。
問題通常要到幾週後才浮現。一位合作多年的客戶打電話來，語氣有點困惑：「你們是不是把那個型號的產品頁拿掉了？我用 Google 怎麼都找不到。」行銷人員自己搜一次公司名稱加型號，第一頁跳出來的是同業、是 B2B 平台、是三年前的展覽新聞稿，唯獨自家官網不在，詢問單先是少了幾張，打開 Search Console 才發現，已建立索引的頁面數從三位數掉到了兩位數。
問題常常不在網頁設計。
真正容易被漏掉的，是 SEO 遷移責任，改版專案的分工表通常會列出視覺、前端、文案與上稿，卻沒有指定誰負責盤點舊網址、建立轉址表，以及確認新網址是否成功被索引。
設計公司不會主動報這個項目，多數企業也不會想到要另外找 SEO 公司接手，於是它就消失在兩家廠商之間的縫隙裡。
為什麼網站改版是 SEO 風險較高的一段時間？
平常我們談 SEO 出問題，多半是漸進式的。內容品質慢慢被同業超車、外部連結長期沒有累積、載入速度隨著外掛越裝越多而變慢，而這些傷害會在幾個月的報表裡慢慢顯形，中間其實有很多次踩煞車的機會。
網站改版的風險不一樣，因為很多變更會同時發生，像網址、內容、頁面結構、CMS，甚至伺服器環境都可能一起改變。
如果舊網址沒有正確轉到新網址，搜尋引擎就不容易判斷兩者的關係，這可能造成排名與流量在短時間內明顯波動，也讓團隊很難確認問題究竟來自轉址、內容，還是網站技術環境。
搜尋引擎眼中的「你的網站」，本質上是一組網址加上這些網址累積的信任訊號。改版如果沒有把訊號接住，搜尋引擎就得重新理解整個網站的結構，這段重新理解的時間，就是流量容易波動的時候。
Google 官方文件對這件事的建議一直很保守。在網站遷移的一般最佳做法中，Google 建議一次只改一件事：如果你想換網域、換內容管理系統，又想換一套新的版型，就按順序分開做，先搬網域，再改版型，不要全部同時進行。
Google Search Central 的網站遷移指南建議：規劃變更時應該一項接著一項，而不是全部同時進行。（資料來源：Google Search Central，Site Moves and Migrations）
這條建議在台灣的實際專案裡不太容易被遵守。多數企業的改版是一次到位：換版型、換 CMS、重寫文案、重排網址結構，有時候連網域都順便換成新的品牌拼法。這可以理解，預算一次編、廠商一次發包，時程常被壓成上線那天一次到位。但把幾種變更疊在同一天上線，代表事後如果流量掉了，很難分辨到底是哪一項造成的。
2026 年多了一個變數：核心更新的節奏變快了
還有一件事讓改版的歸因可能會變得更困難。
根據 Search Engine Land 的報導，Google 在 2026 年 3 月 27 日推出三月核心更新，到 4 月 8 日跑完；5 月 21 日又推出五月核心更新，6 月 2 日結束，兩次核心更新之間只隔了六週。
SE Ranking 的統計就有指出，三月那次更新是他們有紀錄以來波動最劇烈的一次，前三名的網址有 79.5% 換了位置，前十名的頁面裡接近四分之一掉出前一百名。
講白一點：如果你的新官網剛好在核心更新跑動期間上線，接下來兩週的排名變化可能同時混雜「改版造成的」與「演算法造成的」兩種原因，而且不容易分開，最麻煩的是決策卡住，因為沒有人能確定該不該把改版退回去。
排程改版日期前，可以先查看 Google Search Status Dashboard，確認是否有正在進行的排名更新。 這個動作只要幾分鐘，卻能省掉後面的爭論。這也是我們在協助客戶做SEO 風險管理時，會先確認的前置條件之一。
不是所有改版的風險等級都一樣
「改版」這個詞在台灣被用得很寬鬆，從換一張首頁 banner 到整個網域搬家都叫改版，但風險差異其實很大。先分清楚自己屬於哪一種，才知道要投入多少資源保護。
| 改版類型 | 網址是否變動 | 風險等級 | 必要動作 |
|---|---|---|---|
|
只換視覺樣式，網址與內容不動 |
否 |
低 |
效能基準線對照、結構化資料驗證 |
|
換主機或搬到 CDN，網址不動 |
否 |
低至中 |
監控爬取狀態與伺服器回應碼 |
|
HTTP 轉 HTTPS |
是 |
中 |
全站 301、canonical 更新、混合內容檢查 |
|
換 CMS 導致網址結構改變
|
是 |
高 |
完整網址對應表、301、Sitemap 重建 |
|
更換網域名稱 |
是 |
最高 |
上述全部，加上 Search Console 網址變更工具 |
這張表是拿來跟廠商對預算的，當廠商說「這次只是小改版」，你可以直接對照第二欄：網址有沒有變，只要答案是「有」，這就不是小改版，而是一次遷移。
改版後流量下滑，最常見的六種死法
在協助企業檢查上線後異常時，我們看到的原因高度重複。Google 官方文件在疑難排解章節列出的常見錯誤，跟台灣現場遇到的幾乎是同一份清單。以下六種，是實務上很常見的問題。
1. 測試環境的 noindex 或 robots.txt 封鎖沒有移除
這是最常見的原因，也是最不需要技術能力就能檢查的一項，Google 在網站遷移的常見錯誤清單中，第一條就是提醒站長不要忘記移除那些只在遷移期間需要的 noindex 標記或 robots.txt 封鎖規則。
發生的原因很單純。工程師在測試站架設期間，為了避免測試內容被搜尋引擎抓到，會在全站掛上 noindex 或在 robots.txt 寫上 Disallow，這是正確的做法。問題在於上線那天，這兩行設定常常沒有被列在檢查清單裡，因為它們不影響任何一個人肉眼看得到的畫面。網站看起來完全正常，只有搜尋引擎被擋在門外。
檢查方式很簡單：在瀏覽器打開新官網任一頁面，按右鍵檢視原始碼，搜尋 noindex 這個字串。 再把網域後面加上 /robots.txt 直接開啟，看裡面有沒有 Disallow: /，這兩個動作不需要任何工具，行銷人員自己就能做，建議上線當天、隔天各做一次。
2. 大量舊網址一律轉到首頁
第二常見的錯誤來自一個看似合理的偷懶：既然舊頁面在新網站上找不到對應，那就全部轉到首頁，至少使用者不會看到 404。
Google 明確提醒：不要把大量舊網址轉向到一個不相關的單一目的地（例如新網站的首頁），這會讓使用者困惑，而且可能被系統判定為 soft 404 錯誤。（資料來源：Google Search Central，Site Moves and Migrations）
被判定為軟 404（soft 404，頁面看起來成功，系統卻當它不存在）的後果，是這些舊網址累積的信任訊號不會傳遞到首頁，而是消失。你以為自己接住了流量，實際上只是讓錯誤訊息換了個長相。
3. 轉址鏈疊了三層以上
舊網址先轉到中繼網址、中繼網址再轉到新網址，這種情況在多次改版過的網站上特別常見，因為每一次改版都留下一層轉址規則，幾年下來就疊成了樓梯。Google 建議直接轉向到最終目的地；如果做不到，轉址鏈的層數也應該壓在三層以內、最多不超過五層。過長的轉址鏈會增加使用者等待時間，也不是所有瀏覽器與代理程式都支援。
4. canonical 標籤還指向舊網址
這一項比較難察覺，因為網站表面上一切正常，轉址也做對了，但每個新頁面的 canonical 標籤還寫著測試站的網域。等於你一邊告訴 Google「請收錄這個新網址」，一邊在頁面原始碼裡寫著「其實正版在別的地方」。搜尋引擎會照著 canonical 走，結果就是新頁面較難進入索引。
5. Sitemap 還停留在舊網站
新網站上線了，Search Console 裡提交的還是舊的 sitemap.xml，裡面躺著一整份已經不存在的網址。這可能讓新網址較難被搜尋引擎及時發現，也讓你在後台看到的索引數據失真。
6. 新伺服器無法承受改版後暴增的爬取量
這一項幾乎沒有人會事先想到。Google 指出，遷移之後它會比平常更密集地爬取新網站，因為舊網址的爬取請求都會被轉導到新網站，這些流量會疊加在原本的爬取之上，所以新主機必須有足夠的運算資源來承受。
如果新主機的規格是照著日常人類流量估的，改版後那幾天可能出現大量逾時或 5xx 錯誤。搜尋引擎讀到伺服器不穩定的訊號，會主動降低爬取頻率，索引重建的時間就可能從兩週拉長到更久。
同行常見說法 vs 加乘的實戰觀察：301 與 302 的迷思
市面上流傳很久的一種說法是「302 轉址會漏掉權重，所以一定要用 301」。這句話的結論是對的，理由卻不精確，而不精確的理由會導致錯誤的除錯方向。
Google 官方的說法是：301 以及其他永久轉址不會造成 PageRank 的損失。真正該用 301 或 308 的原因，不是怕漏掉權重，而是永久轉址傳達的是「這個位置永遠改變了」，這個訊號會影響搜尋引擎選擇哪一個網址當作標準版本。用 302 的網站，問題不在權重漏光，而是搜尋引擎持續認為舊網址才是本尊，所以新網址一直排不上去。
301 與 308 等永久轉址不會造成 PageRank 損失。（資料來源：Google Search Central，Redirects and Google Search）
判斷 301 或 302 的重點，因此不只是「會不會漏權重」，而是這次變更究竟是暫時性的還是永久性的。如果誤以為是權重漏掉，可能會去買外部連結試圖補回來；如果知道是標準版本判定的問題，就會去確認轉址類型、canonical 與索引狀態是否一致。這也是為什麼技術遷移應該被列為 SEO 服務的一部分，而不是設計專案的附加項目。
改版前的功課：全站網址盤點與權重排序
所有保護動作的起點只有一件事：你必須知道舊網站上到底有哪些網址，以及哪幾個網址真正值錢。這份清單如果漏了，後面的轉址規劃再嚴謹都補不回來。
很多專案在這一步就出錯，因為他們只做了一件事：請工程師從 CMS 後台匯出頁面清單。這份清單通常不完整，因為它只包含還存在於後台的頁面。
實務上要交叉三個來源，才能還原完整的網址清單：
- 現有的xml，這裡面通常是你自己認為重要的頁面
- Search Console 的成效報表，切換到「網頁」分頁，把過去 16 個月有曝光或點擊的網址全部匯出
- 伺服器存取日誌或 GA4 的頁面路徑報表，補上那些沒有排名但仍有人直接連進來的網址
Google 的建議也是從重要網址開始盤點：查看 sitemap 裡提交過的網址、檢查伺服器日誌或分析工具中流量最高的網址，並利用 Search Console 的連結報表找出有內部與外部連結指向的頁面。
三類最常被漏掉的網址
第一類是圖片與檔案。
Google 特別提醒，網站遷移的計畫中必須包含內嵌內容的網址，包括影片、圖片、JavaScript 與 CSS 檔案，這些網址需要跟其他內容一樣被處理。台灣企業官網最常見的是產品型錄 PDF 與規格書 PDF，這些檔案往往被 B2B 買家直接收藏成書籤，也常在同業論壇被引用。改版後如果檔案路徑變了又沒有轉址，等於把一批高意圖的訪客擋在門外。
第二類是已下架但仍有排名的舊頁面。
三年前的活動頁、已停產型號的產品頁、離職員工寫的技術文章，這些頁面在後台可能早就被設為草稿，但只要 Google 還收錄著，它們就仍在替你帶來曝光。
第三類是有外部連結指向的頁面。
這類網址的價值不在它自己的流量，而在它承接了別人給的信任票。一旦改版後回傳 404，這張票就作廢了。
排序：不是每個網址都值得花同樣的時間
盤點完之後，中型企業官網通常會得到 300 到 800 個網址，逐一人工對應並不切實際。我們的做法是用三個維度排序，把資源集中在前 20%：
| 維度 | 判斷依據 | 資料來源 |
|---|---|---|
|
搜尋價值 |
過去12個月的曝光與點擊 |
Search Console 成效報表 |
|
連結價值 |
有多少外部網站連進來 |
Search Console 連結報表 |
|
商業價值 |
是否為詢問單或轉換的來源頁 |
GA4 事件與轉換路徑 |
三個維度都高的網址，值得做到一對一精準對應，而且上線後要逐一人工驗證。
三個維度都低的網址，可以用規則式的批次轉址處理，或直接回傳 410，告訴搜尋引擎這個頁面已永久移除。
新舊網址對應表怎麼建立才不會出事
網址對應表是整個改版專案最重要的一份文件，卻經常只存在於工程師的腦袋裡。我們的建議是把它做成一份所有人都能打開的試算表，並且在驗收條件裡寫明必須交付。
一份可用的對應表至少要有六個欄位：
- 舊網址：完整路徑，含協定與網域
- 新網址：完整路徑，如果沒有對應則留空
- 對應類型：一對一、多對一合併、永久移除
- 優先度：依前一節的三維度排序結果分成高中低
- 上線後驗證狀態：由誰在哪一天確認過
- 實際回應碼：上線後實測得到的 HTTP 狀態碼
最後兩欄是關鍵。沒有這兩欄，對應表只是一份計畫；有了這兩欄，它才是一份可以拿來驗收的證據。
找不到對應的頁面該怎麼辦
實際專案裡，總會有一批舊頁面在新網站上找不到合適的去處。這時候有三種正確處理方式，以及一種常見的錯誤處理方式。
第一種是「合併」。
如果新網站把原本分散的多個頁面整合成一頁，那麼把這些舊網址一起轉到新的整合頁是合理的。Google 也明確指出，若你把原本分散在多個頁面的內容整合到一個新頁面，可以把這些較舊的網址轉向到那個整合後的新頁面。
第二種是「找最相近的替代頁」。
停產的 A 型號可以轉到現行的 A2 型號產品頁，前提是內容主題確實相關，使用者點進去不會覺得答非所問。
第三種是「誠實回傳 410」。
如果這個頁面的內容真的不再存在，也沒有相近的替代品，直接告訴搜尋引擎它已永久移除，比硬轉到不相關的頁面更好。索引會乾淨地退場，不會留下 soft 404 的雜訊。
錯誤的做法只有一種：全部轉到首頁。前面已經說明過後果，這裡再提一次，是因為這個做法在台灣的改版專案中出現得很頻繁，而且通常是工期壓縮下的權宜之計。
常見狀況一：一個斜線就能造成的 404
常見狀況是這樣：產品頁的網址結構從 /product/a 改成 /products/a，單數改成複數，只差一個字母。如果上線前沒有建立對應表、也沒有設定轉址，所有舊的產品頁網址都會回傳 404。這些頁面往往是詢問單的主要來源，也是外部網站與 B2B 平台連結指向的位置。
正確的處理是為每一個舊網址設定一對一的 301，轉到對應的新網址。修正之後，重要產品頁會逐步恢復索引，但要注意一件事：流量的回補通常比詢問單快。 排名回來不代表商業結果同步回來，這一點在後面的觀察期章節會再談。
常見狀況二：合併頁面時的轉址方向
另一種常見狀況是頁面合併。一家服務業把原本三個分開的方案介紹頁 /plan-basic、/plan-pro、/plan-max 在改版時整合成一頁 /pricing，正確做法是把這三個舊網址都設定 301 轉到 /pricing，這符合 Google 對內容整合的建議。
要留意的是後續驗證。三個舊網址合併成一頁之後，這一頁在 Search Console 的曝光會吃進原本三頁的搜尋詞，看起來像是暴增，這是正常現象。真正該檢查的是：原本三頁各自排名的關鍵字，在合併頁上是否還保有位置，還是只留下了其中一頁的詞。
301 轉址的規劃原則與五個常見錯誤
轉址規則寫好之後，還有五個細節會決定它是不是真的有效。這五項在驗收時逐一測試，大概需要一個下午，卻能擋掉大部分事後的麻煩。
第一，統一使用伺服器端的永久轉址。
也就是 301 或 308。如果技術上真的無法做到伺服器端轉址，才退而使用前端方式，但這是最後手段，不是預設選項。
第二，轉址要一步到位。
不要讓舊網址先轉到中繼位址再轉到最終位址。也要特別檢查那些同時牽涉協定與網域變更的情境，例如 http 轉 https 又同時從 www 轉到非 www，很容易疊成三層。
第三，把大小寫、結尾斜線與參數納入測試。
舊網站如果對大小寫不敏感，同一個頁面可能有多種寫法被收錄；新主機如果改用區分大小寫的設定，這些變體就可能全部變成 404。
第四，轉址要留得夠久。
這一點是最多企業低估的。Google 建議盡可能長期保留轉址，一般至少一年，這段時間才足以讓所有訊號轉移到新網址，包含重新爬取以及重新指派其他網站指向舊網址的連結。從使用者的角度來說，甚至可以考慮無限期保留。
轉址應盡可能長期保留，一般至少一年。（資料來源：Google Search Central，Site Moves and Migrations）
這句話的實務含義是：如果你的合約寫著改版後三個月保固，那份保固沒有涵蓋轉址的完整生命週期。舊主機的租約、舊網域的續費、轉址規則的維護，都應該至少延續一年。這筆錢最好在編列改版預算時就一起算進去，而不是明年才發現要另外付。
第五，canonical 與轉址方向必須一致。 Google 建議每個新網址都應該有一個自我參照的 canonical 標籤；如果網站有多語系或多國版本的 hreflang 標記，也要一併更新成新網址。
上線那天：執行順序比執行內容更重要
改版上線不是一個動作，是一串有先後順序的動作，順序錯了，即使每個動作都做了，結果仍然可能是索引大量流失，Google 官方文件給出的順序很清楚，我們把它轉成台灣專案現場可以直接照做的版本。
- 移除測試期間的 noindex 標記與txt 封鎖規則
- 開啟或部署轉址規則
- 檢查新網站每個頁面的 canonical 是否指向自己的新網址
- 用網址審查工具逐一測試高優先度網址的轉址結果
- 在 Search Console 提交新的 sitemap
- 如果有更換網域或子網域，才提交網址變更要求
第一項排在最前面是有原因的。如果轉址已經生效、搜尋引擎開始大量爬取新網站，但新網站還掛著 noindex，等於在最關鍵的那幾個小時裡，主動告訴搜尋引擎這些頁面都不要收錄。
Search Console 的網址變更工具，什麼時候該用
這個工具被誤用的頻率很高，很多人以為只要改版就要提交。
Google 的說明是：只有在從一個網域或子網域搬到另一個網域或子網域時才需要這個工具，例如從 example.com 搬到 example.net。HTTP 轉 HTTPS、同一個網域下的 www 與非 www 切換、或是同網域內的路徑變更，都不需要使用它。
Google 在 2026 年 6 月 17 日更新了這份文件，補上一個過去很多人漏掉的細節。如果你要搬到新網域，必須替舊網域所有已驗證的變體都提交網址變更要求，包含子網域以及 www 與非 www 版本，即使你平常並沒有在使用這些變體，也要確保它們都已在 Search Console 完成驗證。
這項更新補上的正是一個實務落差：過去只照著文件操作的人，可能沒有被告知要替 www 或非 www 變體提交網址變更要求，導致遷移訊號不完整，拖慢排名訊號從舊網址轉移到新網域的速度。
一個實務上很好用的監控方法
Google 官方文件裡藏了一個實用做法：把舊網址的 sitemap 與新網址的 sitemap 同時提交到 Search Console，然後觀察兩份 sitemap 的索引數字此消彼長。
一開始，包含新網址的 sitemap 索引數會接近零，而舊網址的 sitemap 會有大量已索引頁面；隨著時間過去，舊網址那份的索引數會逐漸下降，新網址那份則對應上升。Search Console 可能會針對舊網址那份 sitemap 顯示轉址警告，這是正常現象，可以忽略。
這個技巧的價值在於，它把遷移進度變成一條看得見的曲線。你不再需要憑感覺判斷「應該差不多了吧」，而是可以在會議上直接指著兩條線說：舊的還剩幾頁沒轉過去。
別忘了效能基準線
改版通常伴隨版型與程式碼的整體置換，載入效能可能變好，也可能因為新版型塞了大量高解析度圖片與動畫套件而變差。改版前務必先記錄一份 Core Web Vitals 的基準數據，上線後用同一組頁面、同一個工具再測一次。 沒有基準線，你事後無法區分流量下滑是遷移問題還是效能問題。
關於網站效能與品牌質感之間該怎麼取捨，我們在品牌網站的 SEO 與 Core Web Vitals 規劃中有更完整的討論，改版前值得一併讀過。
上線後 14 天怎麼看數據
上線之後最麻煩的不是數據下滑，是不知道怎麼解讀數據下滑，有人在第三天就宣布改版失敗要求退版，有人在第三十天才發現轉址根本沒生效，兩種都造成不必要的損失。
先建立一個前情提要，Google 說明過任何重大的網站變更，都有可能在重新爬取與重新索引期間造成排名波動，中型網站通常需要數週或更久，Google 才會逐步改以新網址取代舊網址呈現，大型網站則需要更長時間，換句話說，短期波動是預期之內的正常現象，真正該監控的不是有沒有掉，而是掉的形狀對不對。
還有一個技術細節要記住：Search Console 的數據有大約兩到三天的回報延遲，你在第二天早上看到的曲線，反映的其實是上線當天的狀況。
下面這張表整理了各階段可以觀察的現象。要提醒的是，實際時間會受到網站規模、伺服器回應速度、Googlebot 抓取頻率與轉址品質影響，不能把日期當成硬性標準。
| 時間 | 該看的指標 | 可能觀察到的現象 | 警訊 |
|---|---|---|---|
|
第 0 至 1 天 |
高優先度網址的 HTTP 回應碼、robots.txt、canonical |
轉址回傳 301、新頁面可被索引 |
出現 404、直接回傳舊網址、原始碼含 noindex |
|
第 2 至 3 天 |
網址審查工具的即時測試結果、伺服器錯誤日誌 |
新網址測試結果為可索引 |
大量 5xx、爬取逾時 |
|
第 4 至 7 天 |
新網址是否開始出現曝光、舊 sitemap 索引數是否開始下降 |
曝光轉移中、排名波動 |
新網址曝光長時間為零、索引數雙邊皆降 |
|
第 8 至 14 天 |
曝光與點擊的回補幅度、索引涵蓋範圍報表 |
逐步回升，未必回到原點 |
曲線持平未回補、未知錯誤數持續累積 |
什麼情況該考慮退版
真正需要考慮退回舊版的情境其實不多，大致有三種：高優先度網址出現大量無法即時修復的 404、伺服器持續回傳 5xx 且 48 小時內解不掉、或全站 noindex 生效超過 72 小時且索引在往下掉。這幾個時數是判斷參考，不是自動退版的門檻，真正要不要退，還是得看問題影響範圍、修復速度與營收風險。發現全站 noindex 時，第一步都是立即修正，並確認是否需要暫停其他部署。
除了這些，多數狀況的正確做法是修正而非退版。退版本身也是一次遷移，會再製造一輪波動，把兩次遷移疊在同一個月，只會讓歸因變得更混亂。
一個容易被忽略的判讀原則
排名回來了，不代表遷移成功。
排名是一個容易觀察也容易誤導的指標，因為它會被季節性、被競爭對手的動作、被演算法更新一起影響，這時候真正該檢查的是三件事：
- 高優先度網址是否全部完成一對一驗證
- 舊 sitemap 中的網址是否逐步退出索引且新 sitemap 的重要網址被正常收錄
- 詢問單的來源頁分布是否恢復到改版前的結構
我認為第三項尤其重要，如果流量總數回來了，但轉換的來源頁換了一批，代表你回補的可能是低意圖流量，商業結果並沒有跟著恢復，表示流量總數與商業結果之間的落差，值得在結案報告裡單獨列一頁說明。
2026 年多出來的一層：AI 引用資產也可能在改版時斷掉
到目前為止討論的都是傳統 SEO 的遷移風險，這套邏輯從 2015 年就存在，在2026 年的改版就多了一層過去比較少被討論的風險，而且它通常不會出現在後台儀表板上。
根據 Google 在 2026 年 5 月 19 日 Google I/O 上公布的數字，AI Mode 的月活躍使用者突破 10 億，AI 摘要則達到 25 億月活躍使用者。這代表你的潛在客戶當中，有一部分不是透過藍色連結認識你，而是透過一段 AI 生成的答案認識你。
引用來源的結構也在改變中，根據 Ahrefs 對大量關鍵字搜尋結果與 AI 摘要網址的分析，來自自然搜尋前十名的引用比例，從 2025 年 7 月的 76% 掉到 2026 年 3 月的 38%，重點不是精確的百分比，而是 AI 引用已經不能再用「有沒有進前十」來代表。另一份 BrightEdge 的研究也看到，不少 AI 引用來自排名在前十名之外、甚至沒有排名的網址。
換句話說，AI 引用比較像是一組相對獨立於傳統排名的資產。它可能來自你幾年前寫的一篇技術問答頁，那個頁面在傳統排名上不起眼，卻因為結構清楚、回答精準而被引用。
為什麼改版比較容易切斷這組資產？
第一，結構化資料在改版時的存活率偏低
換 CMS 通常意味著整套 Schema 標記要重做，而它在驗收清單上的優先度往往排在最後。產品、文章、常見問題、麵包屑這幾種標記一旦消失，AI 系統辨識與引用內容的難度就會上升。
第二，AI 系統對轉址的反應可能比 Google 主索引更慢
有實務觀察指出，AI 回答模組不一定會在 301 生效後立刻換用新網址，觀察到的穩定期大約落在 15 到 30 天，這段期間被引用的來源可能是舊網址、可能是新網址，有時候兩者都不是。它提醒我們，評估改版對 AI 曝光的實際影響，最好預留一個月左右的緩衝。
第三，也是最麻煩的一點：目前沒有一個公開後台會通知你「你從 AI 摘要裡消失了」
Search Console 會告訴你索引出了問題，GA4 會告訴你流量掉了，但沒有一個標準介面會顯示你在生成式回答中的引用份額。
AI 搜尋的引用變化，目前不像傳統搜尋排名一樣有固定、公開的監控報表。若品牌很在意 AI 搜尋曝光，可以在改版前先記錄一組重要問句，改版後再用相同問句定期檢查，把它當成觀察基準，而不是一項已經標準化的指標。
改版前可以做的一個小動作
方法很簡單，只要在改版前兩到四週，挑出 20 到 30 個買家意圖明確的問句，例如「台中某某設備推薦」、「某某型號跟某某型號差在哪」。
逐一在主要的 AI 搜尋介面上跑一遍，記錄哪些網址被引用、引用了哪一段內容，改版後每週用同一組問句再跑一次，持續幾週。
這份紀錄的價值在於，它讓你在改版後有一個可以比對的參照點，而不是憑印象爭論「以前好像有被提到」。關於 AI 搜尋環境下的內容佈局邏輯，我們在AEO 和 GEO 的佈局方法中有完整說明。
責任歸屬：為什麼設計公司不一定會替你保住搜尋權重
前面所有的技術細節，都建立在一個前提上：有人負責執行。而在許多台灣企業的改版專案裡，這個人並不明確。
這不是在指責設計公司，因為網站改版的報價單通常由設計與開發項目組成：視覺稿幾頁、切版幾頁、後台功能幾項、串接幾個第三方服務。
這些項目都可以被清楚定義、清楚驗收、清楚計價，但SEO 遷移不太一樣，它沒有畫面、沒有交付物可以打開來看，而且它的工作量高度取決於舊網站的複雜程度，在報價階段很難估。
於是它常常從報價單上消失了。不是被拒絕，是從來沒有被寫進去。
三種常見的合作結構與各自的破口
| 合作結構 | 誰負責遷移 | 常見破口 |
|---|---|---|
|
設計公司一手包辦 |
通常無人明確負責 |
轉址表不存在，上線後才逐頁補救 |
|
設計公司加上 SEO 公司 |
職責界線模糊 |
兩邊都以為對方會做，網址盤點沒人啟動 |
|
企業內部行銷加外包開發 |
內部行銷 |
有意識但缺乏工具與權限，讀不到伺服器日誌 |
看懂這張表之後，你會發現解法是寫進合約。改版啟動前把三件事寫進去，風險就低一大半：指定 SEO 遷移的負責方、把網址對應表列為交付物、把「高優先度網址轉址驗證通過」列為驗收條件之一。
多編一筆 SEO 費用，到底值不值得
企業主常問：多一筆 SEO 遷移的費用，值得嗎？
我們換個角度算可能會比較清楚，假設官網每月從自然搜尋帶來的詢問單價值是十萬元，這裡用假設數字，你可以換成自己的實際級距。
改版後如果有三成流量因為遷移失誤而流失，且花了四個月才修復，這段期間的損失就是十二萬。這還沒算進舊網址失去外部連結後的長期影響，以及那段期間被同業吃掉的排名位置。
相較之下，遷移的前置盤點與上線後監控在多數 SEO 服務的方案裡屬於一次性項目，這筆 SEO 費用與潛在損失的量級並不對等。
如果你正在評估合作對象，SEO 公司怎麼選可以一併參考，尤其要留意對方是否願意在改版案中把遷移責任寫清楚。
網站改版的常見問題
1.網站改版後多久流量會恢復？
沒有固定答案，取決於網站規模與遷移品質。Google 的一般性說明是，中小型網站的多數頁面通常需要數週才能完成搬遷，大型網站則需要更長時間，速度取決於網址數量與伺服器回應速度。如果超過八週仍完全沒有回補跡象，比較像是有未被發現的技術問題，而不是需要繼續等待。
2.只是換版型、網址完全沒變，也需要做這些嗎？
不需要做網址對應與轉址，但仍需要三項檢查：測試期間的 noindex 是否已移除、結構化資料是否隨版型置換而消失、以及 Core Web Vitals 是否退步。網址沒變不代表零風險，只是風險類型不同。
3.舊網域可以在改版後就退租嗎？
不建議。轉址規則依附在舊網域上，退租等於讓所有轉址同時失效。依照 Google 的建議，轉址應至少維持一年，舊網域的續費與舊主機的租約也應該一併延續到那之後。
4.改版和內容全面重寫可以一起做嗎？
技術上可以，判斷上比較困難。網址變更與內容變更同時發生，事後不容易區分排名變化來自哪一項。如果時程允許，建議先完成遷移、確認索引穩定之後，再分批更新內容。
5.我怎麼知道廠商真的做好了遷移？
可以要求三份文件：完整的新舊網址對應表且填有實測回應碼、上線後 14 天的 Search Console 索引涵蓋範圍截圖、以及高優先度網址的逐一驗證紀錄。拿不出這三份，通常代表遷移只做了規則層面的批次處理，沒有做過驗證。
把改版當成一次遷移，而不是一次重做
改版本身沒有錯，網站本來就該隨著品牌成長而更新。
比較容易造成損失的，是把改版理解成把網站重做一次，而不是把一整套搜尋資產搬到新地址。理解一變，分工、預算、驗收都會跟著變。
如果你的改版案還在規劃階段，現在就可以做三件事：
- 確認網址結構到底會不會變
- 要求對方交出網址對應表的格式範本
- 把上線日期避開正在跑動的演算法更新
這三件事不需要技術背景，卻能擋掉大部分常見的問題。
關於本文
本文由加乘數位行銷的 Tina撰寫。文中的技術規範與時程建議，來自 Google Search Central 的官方網站遷移文件與轉址說明；核心更新時程參考 Search Engine Land 與 SE Ranking 的公開紀錄；AI 引用數據來自 Google I/O 2026 公開資訊、Ahrefs 與 BrightEdge 的研究。文中情境為常見狀況整理，非單一客戶案例。
如果你正準備啟動官網改版、更換網域或搬遷網站，又不確定現有廠商是否涵蓋 SEO 遷移這一塊，歡迎與加乘聯繫，我們可以協助盤點、驗證與上線後的索引監控。
如需轉載，請註明出處並附上原文連結。
👇【立即了解你的網站是否值得有SEO競爭力，搶佔有效關鍵字排名！】👇
