網站改版最容易讓排名掉下來的原因，往往不是設計或內容變差，而是轉址沒做對：網址變了卻沒設永久轉址、內部連結還連著舊網址、或改版後才發現漏掉某個曾經帶流量的頁面。以下用我們自己在 noise-and-signal.com 實際做過的轉址與下架經驗，整理出改版前、中、後三階段該做的具體步驟。
改版前：盤點與規劃
第一步：盤點現有網址與索引狀態。 改版前要先知道自己有哪些網址正在被索引、哪些正在帶流量，才知道改版後要保護誰。做法是匯出目前的 sitemap.xml，並對照 Search Console 的涵蓋範圍報表——我們自己上線初期（GSC 資料範圍 2026-09-14~09-19）就發現 sitemap 列了 114 個網址，Google 卻只認識 51 頁，這種落差如果在改版前沒先盤點清楚，改版後很容易被誤判成「內容全部消失了」。
第二步：列出新舊網址對照表。 每一個會變動網址的頁面，都要有明確的「舊網址 → 新網址」一對一對照，不要用「反正首頁還在就好」這種模糊心態帶過。如果某個頁面確定要下架且沒有對應的新頁面，也要決定它該導去哪個最相關的既有頁面，而不是放著讓它變成 404。
第三步：決定轉址方式並實作在對的層級。 永久性的網址變更要用永久轉址（HTTP 301，或框架層級的等效設定），讓搜尋引擎把舊網址的排名訊號傳遞到新網址；暫時性的情境才用 302/307。我們自己實際的做法是在 next.config.ts 裡設定轉址規則，把停用的 /opensource 路由與 /insights/rag-vs-fine-tuning（含其變體網址）都用 308 永久轉址導到 /insights，而不是任其變成 404 或依賴使用者自己找到新內容。
改版中：同步更新，不要留半套
第四步：sitemap.xml 只放新網址，移除舊網址。 如果 sitemap 裡還留著已經轉址或下架的舊網址，等於持續引導爬蟲去確認一個「已經不存在」的頁面，浪費爬蟲預算。改版上線的同時，sitemap 也要跟著換成新版本。
第五步：內部連結全部指向新網址，不要只靠轉址硬撐。 轉址可以保留排名訊號，但如果網站內部（選單、頁尾、文章互連結）還大量連到舊網址，每次點擊都多一次轉址跳轉，也會讓爬蟲花更多預算在追蹤轉址鏈，而不是直接爬到真正的內容。改版時建議連同內部連結一起檢查更新，不要事後才補。
第六步：hreflang 與 canonical 要跟著改版同步，不要新舊版混用不同代碼。 我們自己在 2026-09-16 的稽核中就發現過 hreflang 代碼不一致的狀況——頁內 0 用的是 zh-Hant，但 sitemap 與 HTTP Link header 卻用 zh-TW，三處訊號互相矛盾，後續才統一修正。改版是最容易讓這類代碼「新舊並存」的時間點，值得特別留意。
第七步：檢查語系自動偵測的轉址規則，不要讓它蓋掉改版後的 canonical 頁。 像 next-intl 這類框架預設會依 Accept-Language 標頭把使用者 307 轉址到對應語系；Googlebot 通常不送這個標頭，但 ChatGPT-User、部分瀏覽器型抓取工具與 Lighthouse 會送，導致你改版後的 zh-TW canonical 頁對它們「等於不存在」。改版時如果連動調整了語系路由邏輯，這一項一定要重新測一次。
第八步：llms.txt／llms-full.txt 同步改版後的架構描述，不要留著舊版說明。 如果你的網站有提供給 AI 爬蟲讀取的摘要檔案，改版後的頁面結構、服務項目一旦跟檔案內容對不上，AI 引擎讀到的就是過時資訊。我們自己的 /llms.txt 與 /llms-full.txt 就是每次新增或下架內容時都要同步更新的檔案，改版時也要排進更新清單，不能只更新網頁本身。
改版後：監測與收斂
第九步：改版上線後立刻用 Search Console 的網址檢查工具，逐一送出重要頁面要求重新檢索。 同時可以搭配 IndexNow 批次提交給支援的引擎（Bing、Yandex），但要記得 Google 明確不支援 IndexNow，不要誤以為送了 IndexNow 就等於通知了 Google。我們自己的批次提交腳本累計送出 406 個網址，Bing Webmaster 那邊也確認 sitemap 內 112 個網址、0 錯誤 0 警告，2026 年 9 月 19 日提交、隔天就檢索成功。
補充：不要期待 Bing 等次要引擎馬上有數據。 我們自己上線初期，Bing Webmaster Tools 同期的總點擊與總曝光都是 0（新站資料處理中），但 sitemap 狀態已經是「1 個已知、112 個網址、0 錯誤 0 警告」，且提交隔天就檢索成功——代表 sitemap 已被正常讀取，新站的成效資料需要時間才會出現，不要因為看不到點擊數字就誤判轉址失敗。
第十步：改版後密切追蹤 Search Console 的涵蓋範圍變化，抓出異常堆積。 特別留意「已檢索尚未索引」與「已找到尚未索引」這兩類數字有沒有在改版後暴增——我們自己上線初期就是 30 頁已建立索引、21 頁未建立索引（其中 3 頁驗證失敗、18 頁已找到尚未索引），這種落差如果在改版後持續擴大而不是縮小，通常代表轉址或內部連結哪裡沒接好。
第十一步：同時比對不同分析工具的數字，不要只看單一來源就下結論。 GSC 看的是 Google 自然搜尋，實際訪客行為則要看網站分析工具；兩邊數字對不上，通常代表流量來源本來就不是 Google 搜尋，不是排名掉了。我們自己就觀察過這種落差：2026 年 9 月 22 日抓取的 Vercel Analytics（最近 7 天）顯示 /cases 案例頁有 25 位訪客，但這頁在 Google 的曝光是 0；同期全站來源除了 google.com，也有不少來自 l.threads.com 等社群平台——也就是說，這頁的訪客不是從 Google 自然搜尋進來的。改版後如果只盯著 GSC 一項數字，很容易誤判某個頁面「排名掉了」，其實它本來就不是靠搜尋帶流量的頁面。
第十二步：多頁談同一主題時，用 canonical 或內部連結收斂成單一主要來源，而不是任由多頁互相競爭。 改版常會讓新舊內容並存，挑一頁當主要來源、其餘頁面連過去，比每頁各自優化、互相搶同一組關鍵字更穩。
第十三步：確認新內容真的部署上線，而不是只在本機完成。 這聽起來理所當然，但「寫完」和「上線」是兩個不同的檢查點，不能假設寫完就等於使用者看得到。改版流程建議在最後一步加上「用無痕視窗直接開啟正式網域確認」這個動作，而不是只看本機或預覽環境。
另外要提醒一件事：以上十三個步驟解決的是「轉址與技術訊號」層級的問題，不代表改版完就等於品牌權威提升。我們自己 2026-09-16 的稽核裡，技術基礎拿到 86 分，但品牌權威訊號只有 5 分——這兩者是不同層次的問題，改版能保住排名，但站外沒人討論你的問題，還是要靠內容與站外曝光慢慢累積。
下一步
網站改版最怕的不是設計改了使用者不習慣，而是排名訊號因為轉址沒做對而歸零、卻要等好幾週才發現。如果你正在規劃改版，建議把這十三步驟當作檢查清單跑過一輪，也可以搭配我們的《官網上線前 SEO/GEO 檢查清單》一起使用。如果想討論你的改版專案該怎麼規劃轉址與監測步驟，歡迎參考我們的網站服務，或直接聯絡我們。