網站搬家與改版的 SEO 風險：301 轉址完整指南

先講結論：網站搬家與改版的風險取決於網址、內容、內部連結、渲染與伺服器是否同時改動，不是每次換版型都會把既有訊號歸零。要降低風險，核心是完整網址盤點、對應到最相近新頁的永久轉址，以及上線後持續監控抓取、索引與流量。

網站改版為何可能影響搜尋流量

想像一個畫面：你花了三年，一篇一篇把網站內容養到 Google 首頁，每個月穩定進帳幾萬次自然搜尋流量。某天設計團隊提案改版，新版型確實好看、轉換率測試也漂亮，於是你在某個週末按下上線。禮拜一早上打開後台，自然流量明顯下滑。

這是示意情境，不代表每次改版都會流失流量。應先拆分變更範圍，避免同時更換網域、CMS 與版型，讓影響較容易查核。

Google 會根據抓取與渲染取得的內容，以及網址、連結和其他訊號處理索引與排名。改版不一定改 URL；若保持內容與網址穩定，就不能描述成所有舊頁消失、信任從零開始。

網址變更後，Google 需要重新抓取並處理轉址與標準網址訊號，因此可能有波動。行動優先索引僅表示 Google 主要以行動版內容建立索引，不代表搬遷會因行動版而自動增加排名風險；真正要確認的是新舊頁內容對應、永久轉址、行動版內容一致與伺服器穩定（見 Google Search Central Blog 對行動優先索引的說明，2023 年 10 月）。

換句話說，網站搬家等同於把一家實體店面連夜搬到新地址：招牌內容沒變，但老主顧手裡的導航紀錄、Google 地標、外部推薦連結全還指向舊門市。沒把這些「路標」一條條更新到新地址，你在顧客眼裡就像憑空消失。

網站搬家、改版到底動到了什麼？Google 眼中的四種「搬家」

「搬家」可能只換主機，也可能同時改網域、路徑、CMS 或內容。以下四種情境有不同驗證重點，不能只按名稱排列固定風險高低。

只換主機而保持網址與內容不變，通常比改網域或重做架構的變數少，但仍要管理 DNS、停機、伺服器錯誤、速度、SSL、robots.txt 與索引設定。可依 WordPress 搬家到新主機的流程先測試再切換，不能預設 SEO 不受影響。

換平台若同時調整 網站架構、內容與導覽，應逐項比較。刪除頁面前檢查搜尋流量、轉換、外部連結及用途；不是每個舊頁都必須保留，也不能只因流量少就一律刪除。

風險取決於實際變更和執行品質。只換主機也可能因存取錯誤造成重大影響；保留 URL 與內容的改版則未必需要大規模訊號轉移。依差異列驗收項目，比固定排風險等級更實用。

流量蒸發的四條水管：索引、轉址、權重、體驗訊號

我用一個比喻來解釋整個機制。把你的 SEO 流量想像成家裡的水龍頭，水從水庫一路經過四條水管才會流出來。改版的時候，這四條水管任何一條破裂，水就會從那裡漏掉，你看到水龍頭出水量變小，卻未必知道是哪條管子在漏。

第一條水管：索引

水庫的水要進到你家，前提是水管有接到水庫。對應到 SEO，就是你的頁面有沒有被 Google 收錄進索引庫。改版最常見的災難，是舊網址大量回傳 404（找不到頁面），Google 把這些網址從索引移除，而新網址又還沒被收錄，於是出現一個「舊的消失了、新的還沒進來」的真空期。

Google Search Console 的網頁索引報表、網址檢查工具 可查看索引原因與抽查 URL，但有處理延遲，不能作為上線初期唯一監控。應搭配日誌與 HTTP 測試，分清預期轉址／刪除和意外錯誤。

第二條水管：轉址

永久搬遷應使用 301 或 308，讓 Google 把它視為強烈的標準網址訊號；302 或 307 適合真正的暫時變動，不應用來表達永久搬家。不要再用「301 僅傳大部分 PageRank」的舊百分比說法，Google 的官方說明是永久轉址不會造成 PageRank 流失。

關於轉址的完整設定邏輯，可以看 SEO 網址優化指南。舊網址應盡量對應到內容最相近的新網址，轉址鏈則壓到最少；原因是鏈條會增加延遲、抓取與維護成本，不是每一跳都固定損耗一部分權重。

第三條水管：權重

除了轉址，還要更新內部連結並確認重要 反向連結 的舊 URL 仍有有效去處。導覽有助於發現與理解頁面，但不能把這些項目當成計算完整排名轉移的公式。

不要把 nofollow 當成可精確分配排名分數的工具。重要頁面應有清楚、可爬取的 內部連結；付費或不受信任等連結則依情境使用適當屬性。

第四條水管：體驗訊號

新版型若塞入更多圖片、JavaScript 與第三方追蹤碼，可能讓網頁速度與操作體驗退化。Core Web Vitals 會用於排名系統，但僅是有限訊號；跳出率也不能直接當成 Google 排名因素。仍應同時檢查實際使用者體驗、轉換與抓取狀態。

更麻煩的是，新版型如果大量改用 JavaScript 來渲染內容，還會牽涉到 JavaScript SEO 的問題：Google 爬蟲能不能正確讀到 JS 渲染出來的內容？讀不到，等於這些內容在 Google 眼裡根本不存在。這條水管最容易在改版後被忽略，因為肉眼看新網站一切正常，僅有 Google 看到的是一片空白。

整件事的樞紐：那份逐頁的 URL 對應清單

URL 映射能支援轉址、連結與索引驗證，但不能取代效能、渲染、追蹤與存取測試。

複雜搬遷應建立逐頁或明確規則的舊新 URL 對照，保留驗證結果。若只是換網域且路徑不變，合理的通配轉址也可行，但仍要檢查例外、參數及資源網址。

這份清單要長什麼樣？至少要有這幾欄：

• 舊網址：完整的 URL，包含協定與路徑。
• 新網址或處理方式：有相關替代內容時列出目的 URL；永久移除且無替代時註明 404／410，不要全部轉到首頁。
• 對應關係：通常一對一，整併可多對一。舊文拆成多篇時，一次 HTTP 轉址仍只能指向一個目的 URL，應選主要承接頁再提供其他連結。
• 舊頁的流量與排名：標出哪些是高價值頁面，這些頁面的轉址必須最優先、最謹慎處理。
• 轉址類型：301 或是其他。
• 驗證狀態：上線後是否確認轉址生效、新頁是否被收錄。

舊網址清單不能僅靠單一來源。用 Screaming Frog 爬站，再合併 Sitemap、分析與 Search Console 的高價值頁面、伺服器日誌及反向連結資料。Search Console 不提供完整「所有已收錄網址」匯出，因此任何來源都不能保證零遺漏。

映射表是轉址、索引抽查與內部連結更新的依據；另需驗證效能、渲染、權限及追蹤，才能涵蓋 URL 對照以外的變更。

六個最容易在會議桌上被否決、卻最致命的決策

以下決策都應先評估搜尋與使用者影響。它們不一定造成流量下跌，但略過規劃和測試可能增加可避免的問題。

決策一：「轉址先用 302，以防萬一要改回來」

如果搬遷確定是永久的，就直接使用 301 或 308；302 或 307 留給真正的暫時情境。Google 仍會處理暫時轉址，但它不是永久搬遷的明確標準網址訊號，因此不該用「先 302 再看看」表達已確定的改址。

正確做法：舊網址到新網址，一開始就用 301。要保留彈性的話，靠的是版本控制與備份，用狀態碼來打模糊仗僅會壞事。

決策二：「舊網站那些沒人流量的頁面，順手清掉比較乾淨」

刪除前比較各頁的 長尾搜尋流量、轉換、外部連結與實際用途。流量少可能反映季節性或特定需求，不能假設合計固定占全站一半，也不能只看單一指標決定。

正確做法：刪除前先看 Search Console、分析資料與外部連結。若有主題相近的新頁，使用 301；若內容確實移除且沒有合理替代，應回傳 404 或 410。把所有刪除頁一律導向首頁，反而可能被視為 soft 404。

決策三：「網址改成中文比較好記」

改中文 URL 或重新命名路徑都屬於網址變更。Google 可處理中文網址，風險在於不必要的大量改址，以及編碼、連結和轉址實作，不是中文本身比較差。先評估需求，盡量保留穩定 URL；延伸見 中文網址、網址組成結構、網址路徑。

決策四：「舊的 sitemap 先不要管，新版上線再說」

XML Sitemap 協助發現新 URL，但不是唯一途徑。上線時準備新版並檢查回應與 canonical；舊清單有失效 URL 不代表 Google 會對整站套用固定可信度扣分。

上線時提交新 sitemap；舊 sitemap 可在遷移期間保留以監控舊 URL 的處理狀態，不必立即刪除。永久轉址至少保留一年，仍有舊連結使用時能長期維持更好。規劃見 網站 Sitemap 入門指南。

決策五：「www 跟 non-www 反正都一樣，新版直接拿掉 www」

www 與非 www 在技術上是兩個不同的網址。如果你改版時順手把 www 拿掉，卻沒有做兩者之間的統一轉址，就會產生重複內容的問題：同一份內容出現在兩個網址上，Google 不知道該把權重算給誰。www 與 non-www 的差異不僅在美觀，更在於你必須擇一、並且用 301 與 canonical 標籤明確告訴 Google 你的標準版本是哪一個。

決策六：「上線當天再找 SEO 進來看」

SEO 檢查越早納入規劃，越容易在開發前確認 URL、內容與驗收要求。上線後仍能修正，但可能增加返工與風險，不宜切換當天才第一次盤點。

指定負責 URL、內容、索引和監控的窗口，讓相關變更有明確驗收依據。流程可按團隊規模安排，不必把每個細節都變成額外簽核。

上線前 24 小時：SEO 紅線檢查表

以下清單可作為上線前的最後複核，但盤點與測試應提前進行。標題中的 24 小時是工作安排範例，不是 Google 規定，也不是所有網站都足夠的準備時間。

1. 轉址清單全數驗證：永久搬遷項目應回 301 或 308 並到達正確新頁；刻意移除且無替代頁的網址可以回 404 或 410。不要把所有非 301 狀態一律視為錯誤。
2. canonical 標籤設定正確：每一頁的 canonical 都指向自己的標準網址，沒有指向舊網址、沒有循環指向。多語系或重複內容頁面要特別留意 canonical 設定。
3. robots.txt 沒有誤封：確認新版 robots.txt 沒有把重要頁面或 CSS、JS 擋掉。Google 需要能完整渲染頁面才能正確評估。這部分的原理見 robots.txt 介紹。要特別小心 robots.txt 與 noindex 不能混用的陷阱：用 robots.txt 封鎖的頁面，Google 還是可能用外部連結發現它並收錄它的標題。
4. 索引與權限分開檢查：預期索引的頁面不能誤帶 noindex；公開但不想搜尋顯示的頁面可用 noindex。後台和敏感資料使用登入及權限保護。參考 noindex 的原理、不被索引的方法。
5. 結構化資料重新驗證：把仍適用且與畫面內容一致的 結構化資料搬到新版，再用驗證工具檢查。不要原封不動複製舊錯誤；Google 已於 2026 年 5 月停止顯示 FAQ 複合式搜尋結果。
6. hreflang 多語系標記：如果是多語系網站，hreflang 設定必須重新核對，每一個語言版本的指向都要雙向正確。從子網域、子目錄到獨立網域的整體規劃，也可以對照多語言網站架構的行動方案再檢查一次。
7. 內部連結全站檢查：用爬蟲工具檢查新版有沒有大量斷裂的內部連結。內部連結是網站架構的神經網絡，斷了等於癱瘓。
8. 先做效能測試：測試環境可做 Lighthouse 等實驗室測試並實測互動。PSI 的 CrUX 資料涵蓋過去 28 天，測試站通常無足夠樣本，不能宣稱已驗證正式站 INP。指標背景見 INP 與 FID 的差異。
9. 備妥新版 XML Sitemap：產出一份乾淨、僅包含新版有效頁面的 sitemap，準備在上線第一時間提交。
10. 保存基準資料：匯出有代表性的歷史搜尋、分析與伺服器資料，考慮季節性及追蹤變更；只看前一天不足以定義正常範圍。
11. 比對新舊站：在受保護的測試環境檢查 URL 映射、正文、標題、canonical、索引指令和資源。意圖刪除的頁面記錄 404／410，不要求每個舊 URL 都有新頁，也不宣稱能攔下固定比例事故。

上線前先確認已知問題已處理，並備妥回復方案和監控。檢查能降低可避免的錯誤，但 Google 重新處理有自己的節奏，準備充分也不能保證零搜尋波動。

上線後 72 小時：你在看 dashboard，還是在看對的指標？

上線後頭幾天要密集檢查伺服器錯誤、轉址、robots、noindex、canonical 與分析追蹤。Search Console 報表有處理延遲，不適合當 72 小時內唯一的即時監控；應搭配伺服器日誌、爬蟲抽查、監控告警與 GA 即時資料。

頭 72 小時，我會輪流看這幾個東西：

第一項：網頁索引報表的錯誤數量

Google Search Console 的索引報表有延遲且非完整逐頁清單。把 404 與轉址範例對照映射表，再實測回應；預期刪除的 404 不算故障，數量相符也不能證明全部轉址正確。

第二項：用網址檢查工具逐一抽驗高價值頁面

挑高價值頁及不同模板、路由的代表頁抽查，數量依規模決定。即時測試成功不等於已索引；比較索引版本、抓取時間與回應，不假設固定 20–30 頁涵蓋多數價值。

第三項：sitemap 提交與處理狀態

確認新版 sitemap 已經提交、而且 Google 開始處理。Sitemap 的狀態欄會顯示「已發現的網址數量」，如果這個數字跟你預期的差很多，代表 sitemap 裡可能有大量無效網址、或者有大量頁面沒被寫進去。

第四項：區分「正常波動」與「真正的損害」

沒有通用的「三天掉三成」故障判準。重要頁出現意外 404、noindex、錯誤轉址或伺服器故障時應立即修正；流量變化則比較需求、季節性、追蹤與搜尋更新，不以固定比例判定原因。

排名變化可能影響點擊，但 CTR 也受查詢、品牌、裝置及搜尋版面影響。第三方平均曲線不能預測特定網站損失，應以 GSC 查詢與頁面資料判讀，不把第十名之後的流量一律忽略。

流量已經崩了？一張分層搶救流程圖

網站流量下滑時，可先用排名下滑診斷流程檢查搜尋層問題；若所有管道都下降，則參考網站流量下滑診斷比較追蹤、技術、需求與來源變化。除錯時宜先處理影響面大且可驗證的項目，每次保留變更日期，避免同時修改過多變數。

第一層：先確認有沒有大面積的 404

在 GSC、爬蟲與伺服器日誌檢查 404。若舊網址有合理替代頁，就補永久轉址；若內容確實移除且無替代頁，404 或 410 是正確狀態，不要硬導向不相關頁面。

第二層：確認轉址型態是不是寫成了 302

如果 404 不多但流量仍下降，檢查永久搬遷是否誤用 302 或 307。僅把確定永久的項目改成 301 或 308；真正暫時的轉址應維持原語意。

第三層：確認有沒有誤掛 noindex 或 robots 封鎖

檢查重要頁面的原始碼，看有沒有被誤植 noindex meta 標籤、或被 robots.txt 封鎖。改版過程中，開發環境的 noindex 標記常常被「忘了拿掉」一起帶到正式上線版本，這會讓整批頁面直接從索引消失。相關排查邏輯見 Google 網頁收錄查詢。

第四層：確認 sitemap 有沒有更新並提交

提交新版 sitemap，並用網址檢查工具對重要頁面按「要求建立索引」，主動提示 Google 重新檢索。

第五層：確認內部連結結構沒有崩塌

重要頁應有清楚的站內導覽；缺少連結會增加發現和理解的困難，但 Google 仍可能從 sitemap、外部連結或既有 URL 發現，不能一概說完全找不到。

第六層：確認 Core Web Vitals 沒有退化

若未發現索引或轉址錯誤，再比較效能、內容、需求及搜尋更新。CWV 退化值得改善，但不能僅憑 LCP 或 INP 變差就認定為排名下降的唯一原因。

第七層：回頭照顧外部反向連結

當網址改變，指向舊網址的外部連結會經過 301 到新頁。永久轉址是正常的訊號整合方式，不必假設存在固定折扣期；仍可優先請重要來源直接更新連結，因為這能減少跳轉並改善使用者體驗。

更新外部連結時，優先考慮內容相關、有人使用且可聯絡的來源。第三方分數可作線索，媒體、政府或教育網域本身不保證每條連結更有價值；無法更新者可由正常永久轉址承接。

換網域後，舊 URL 仍要提供正確轉址，並非全面作廢。維持舊網域、主機與憑證；符合條件的整站網域或子網域搬遷，驗證新舊 GSC 資源後可用 Change of Address。HTTP→HTTPS、www／non-www 或站內路徑調整則不用此工具。

搶救的重點不是「一次做完所有事」，而是「按影響面大小依序處理」。一個大面積的 404 問題，修起來的效果遠大於你去微調十個頁面的標題。先止血，再收尾。

WordPress 站的搬家：多數台灣網站的共同處境

WordPress 搬遷還需確認固定網址、SEO 外掛資料和主題輸出。下列是要測試的變更，不能只憑外掛或主題名稱判定必然有問題。

地雷一：固定網址結構變更

WordPress 的固定網址（permalink）決定了每一篇文章的網址長相。很多改版會順手把固定網址從某種結構換成另一種，例如從日期結構換成文章名結構。這個動作會讓全站每一篇文章的網址都改變，等於一次要把幾百、幾千個舊網址全部轉址。如果你沒有那份逐頁 URL 對應清單，這會是一場災難。WordPress 的固定網址設計原則可以對照 WordPress SEO 必做設定。

地雷二：外掛衝突導致 SEO 設定遺失

更換 SEO 外掛或匯入不完整時，部分 metadata、canonical、sitemap 或索引設定可能遺失或改變，不代表全部一定歸零。先備份，再比較實際 HTML 輸出。

先在測試環境備份並依新外掛官方流程匯入，確認支援的資料。切換後由單一主要 SEO 外掛輸出標記，避免同時啟用造成重複 canonical 或 Schema；抽查正常再依回復方案處理舊外掛。

地雷三：換主題導致版面結構變動

換主題不僅換外觀，還會改變頁面的 HTML 結構、標題層級、麵包屑、側邊欄連結。這些都會影響 Google 對頁面的理解。新主題如果用不同的頁面產生器（如 Elementor、Divi），還可能引入大量影響效能的程式碼，拖垮 Core Web Vitals。

地雷四：測試站的 noindex 沒拿掉

WordPress 的索引阻擋設定不能保護私人測試站。上線時確認預期索引頁已移除 noindex；測試站用登入或存取控制。Google 需重新抓取才處理指示，不是按開關就立即移除或恢復。可搭配 WordPress 自架站全攻略。

行動清單：照著做，把大工程拆成可控的小步驟

讀到這裡，你應該已經理解：網站搬家本身不可怕，可怕的是沒有計畫地搬家。我把整篇文章濃縮成一份你可以今天就開始執行的行動清單。把它想成把一場大工程，逐步拆解成一串可控的小步驟。

1. 階段一：盤點現況。合併爬站、CMS、sitemap、GSC、分析、日誌及外部連結資料；各來源可能不完整，依規模安排工時。
2. 階段二：建立映射。列出保留、搬移、合併和刪除項目，包含圖片與下載檔，標明目的 URL 或狀態碼。
3. 階段三：測試與回復準備。驗證轉址、內容、索引、權限、連結及效能，處理重要問題並備妥回復方案，再安排上線。
4. 上線日：精準切換。依自己的流量資料選低風險時段，並確保工程、內容與監控人員在線；不必假設週末深夜一定最好。同步提交新版 sitemap、處理舊 sitemap，並抽驗高價值頁面。
5. 上線初期：密集監控。結合 HTTP 測試、伺服器告警、分析與 GSC；有延遲的 GSC 報表不能作唯一即時訊號。
6. 後續：持續驗證。重新處理依規模與抓取速度而異，沒有一至四週的完成保證。轉址至少保留一年，避免不必要的同時大改。

改版應預留設計、工程、驗證與監控資源。規劃可降低可避免的錯誤，但不能保證沒有搜尋波動，也不代表改版一定清空成果。整體觀念見 SEO 的本質。

是否達成改版目標，應比較可用性、轉換、索引與搜尋表現，記錄同期內容和需求變化。流量持平不證明每個設定都正確，下降也不能只歸因為搬遷。

想進一步把整體 SEO 體質打穩，你可以從 SEO 自學先講結論 建立完整觀念，或參考 E-E-A-T 指南 了解 Google 如何評估一個網站的可信度。如果你正在考慮要不要為了改版而找外部顧問，挑選網頁設計公司 與 網站維護成本解析 可以幫你釐清投入的合理性。搬家是風險，但若工程化地拆解它，它就僅是一次有點緊張的搬家，稱不上災難。