網站遷移 SEO 怎麼做：301、對映表與上線排查清單（2026）

網站遷移最怕的，不是上線當天報錯，而是上線當天看起來沒事，過幾天流量開始往下掉。再去查，發現問題不是一個，是一串。舊 URL 沒有一對一跳轉，開發環境的 noindex 沒撤，canonical 還指著舊地址，圖片和 PDF 丟了一批，站內連結還在跑老路徑。到這一步，排查就很費勁了。

Google 近年的遷移文件其實講得很清楚。site move with URL changes 講的是 URL 變化時該怎麼遷。changing your hosting 講的是隻換基礎設施、不改使用者可見 URL 的情況。兩類事情不能混著處理。混了，後面就很難判斷風險到底來自哪一段。

這篇文章不講空話，只按實際專案順序來。先分清遷移型別，再做 old-to-new 對映，再查重定向、資源、結構訊號、Search Console 和上線監控。你會發現，網站遷移 SEO 說到底本質是個專案管理活，不是靠某一個技巧。

先說清楚為什麼遷移這麼容易出事——一組資料能讓你重視起來：

參考：谷歌官方網站遷移文件

第一步：先分清你做的是哪一類遷移

很多團隊一張嘴就是“網站改版”。但對 SEO 來說，改版不是一個詞，而是幾類完全不同的事情。Google 把它分得很清楚，核心就在於使用者可見 URL 有沒有變。

如果使用者可見 URL 變化了，就別把它當成單純的“換伺服器”。如果 URL 沒變，也不要為了圖省事去配一堆沒必要的遷移動作。先把專案歸類，這一步能幫你少走很多彎路。

第二步：一次儘量只改一類變數

網站遷移一失敗，常見場景都很像。團隊想“一步到位”，於是域名換了、路徑改了、模板換了、內容重寫了、圖片重新傳了、還順便接了新的分析程式碼。結果上線後掉了，你根本沒法判斷是哪一步拖了後腿。

Google 的站點遷移文件 明確建議遷移前先把新站準備好並充分測試。放到執行上，更穩的理解就是：一次儘量少動變數。能拆成兩次做，就別壓成一次做。

比如，換域名和換設計不要綁在同一天。換 CMS 時，如果能先保住原有 URL 規則，就先保住。內容重寫，如果不是必須，也最好放到遷移穩定之後。遷移專案裡最值錢的不是“改得多”，而是“問題能定位”。

第三步：先找高價值 URL，再補全全量 URL

很多人做遷移，第一反應是把全站 URL 匯出來。匯出當然要做，但先後順序不對。更穩的順序是：先找最不能掉的那批頁面，再去補完整列表。因為專案資源有限，測試視窗有限，優先順序一定要分。

高價值 URL 通常來自四塊資料：Search Console 的點選和展示、分析工具裡的落地頁和轉化、外鏈工具裡的高權重落點、伺服器日誌裡的高頻抓取 URL。把這幾塊合在一起看，優先順序就出來了。

如果你們站已經在做資料歸因和日誌分析，那遷移前最好順手把這兩篇一起過一遍：SEO 資料分析清單 和 伺服器日誌分析指南。遷移不是單靠開發解決，資料側也得先站好位。

第四步：old URL 到 new URL 的對映表，才是遷移底盤

URL 變化型遷移裡，最關鍵的檔案不是設計稿，也不是上線排期，而是對映表。Google 在 How to move a site 裡寫得很直接，要先準備當前 URL 和對應新 URL 的對映，再開始配置重定向。

對映表不是一列舊地址、一列新地址這麼簡單。它至少還要告訴團隊三件事：是否真的存在對應頁、該做永久重定向還是乾脆返回 404/410、這個 URL 是不是高優先順序測試物件。沒有這些欄位，對映表後面很難執行。

這裡最忌諱的，是把大量舊頁面一把梭到首頁，或者統一跳到某個“相關分類頁”。Google 文件 明確提醒過，不相關的重定向容易被系統當成 soft 404。真正穩的做法，還是一對一到最相關的新頁。

第五步：301 和 308 是主方案，但重點不只是狀態碼

很多討論網站遷移的人，最後只剩一句“記得做 301”。這句話不算錯，但太粗了。Redirects and Google Search 講得更完整：如果是永久遷移，優先用服務端永久重定向，也就是 301 或 308。重點是服務端、永久、直達。

真正影響遷移質量的，不只是程式碼寫成 301 還是 308，而是下面這幾件事有沒有做對：

1. 舊 URL 是否直接跳到最終新 URL，而不是 A 到 B 再到 C。
2. 跳轉目標是否和舊頁面主題高度相關。
3. 移動端、桌面端、帶引數 URL 是否都按預期處理。
4. 平臺內建規則和伺服器層規則有沒有互相打架。

Google 現在對多跳 redirect 的容忍度比早些年高，但官方仍建議儘量直接到最終地址。不是因為系統完全認不出來，而是因為多一跳，抓取和使用者訪問都多一層損耗。

第六步：不要只遷正文，資原始檔和結構訊號也得一起遷

很多網站遷移掉量，不是因為文章沒遷過去，而是因為“看起來是配角”的東西丟了。圖片路徑沒跟過去，PDF 下載地址失效，JS 和 CSS 資源換路徑後被遮蔽，canonical 還是舊站地址，hreflang 還是舊 URL。頁面表面活著，底層訊號已經斷了。

Google 的遷移文件 明確提到，images、videos、downloads、JavaScript、CSS 這些嵌入資源也應納入遷移計劃。不是可選項，是必查項。

這一塊和 技術 SEO 指南、Schema 指南 是一脈相承的。遷移不是隻搬文字，而是把整張頁面的搜尋訊號一起搬過去。

第七步：上線前先查開發環境遺留問題

遷移專案裡最冤的一種損失，就是內容、重定向、資源都做得差不多了，結果上線後被一個開發期設定卡住。最常見的就是 noindex 忘撤、robots.txt 把關鍵目錄擋住、防火牆把 Googlebot 攔了、密碼牆沒關。

changing your hosting 和 URL 遷移文件都在提醒同一件事：新環境必須讓 Googlebot 正常訪問。尤其是換主機或 CDN 的專案，遷移成功與否，往往不是“程式碼能不能跑”，而是“Google 能不能順利抓”。

如果你們還牽涉 DNS 切換，Google 文件建議提前把 TTL 調低，再做切換。這樣傳播更快，回滾也更靈活。這個動作看起來偏運維，但對遷移視窗很關鍵。

第八步：Search Console 要在遷移前就準備好

很多團隊上線後才想起 Search Console。其實這一步應該提前。舊站和新站相關 property，要先驗證好。域名遷移專案尤其如此，因為後面還可能會用到 Change of Address。

遷移當天和遷移後，Search Console 主要看四塊：新 sitemap 是否成功讀取、索引狀態是否開始轉移、是否出現大量 Not Found 或 soft 404、URL Inspection 抽查關鍵頁時看到的 canonical 和抓取狀態是否正常。對於少量關鍵頁，URL Inspection 請求重新抓取 可以用；但大規模遷移，官方仍建議優先靠 sitemap 讓 Google 發現大量新 URL。

如果是換域名，Search Console 裡還要確認舊 property 和新 property 都在可用狀態。這樣後面無論是驗證遷移進度，還是提交 Change of Address，都不會被卡住。

第九步：上線後不要只盯排名，要看 old/new 兩邊的資料流

遷移後短期波動很常見。真正不該做的，是隻看幾個關鍵詞今天漲了還是跌了。遷移專案的判斷方式，應該更像看漏斗。舊 URL 的流量有沒有往下走，新 URL 的流量有沒有接起來，舊站抓取有沒有逐步減少，新站抓取有沒有起來，錯誤報告是不是集中在少數模板問題上。

Google 在 site move 文件 裡也說得很現實，網站遷移後會有波動，大站恢復時間會更長。所以，遷移後第一週到前幾周，重點不是追排名截圖，而是查鏈路有沒有斷。

如果你們本身就有日誌側能力，建議把舊站和新站日誌一起看。Googlebot 還在抓哪些舊地址，哪些新地址一直沒進抓取佇列，這些都比“某個詞今天第幾名”更有診斷價值。

第十步：重定向別急著關，內部連結要儘快改直達

很多人把 301 當成終點。其實 301 更像緩衝帶。Google 建議 舊地址的重定向儘量至少保留一年。從使用者體驗和歷史連結角度，能保留更久通常更穩。

但另一邊，站內連結不能長期依賴 301 過日子。導航、正文內鏈、麵包屑、HTML sitemap、圖片引用、下載連結、結構化資料裡的 URL，都應該儘快改成新地址。否則站內一直在給爬蟲和使用者製造多一跳。

這件事和 錨文字最佳化指南、內鏈最佳化指南 直接相關。遷移穩定之後，第二批該做的不是“繼續改版”，而是把內部路徑徹底理順。

三種最常見遷移場景，實際該怎麼處理

1. 只換主機或 CDN，URL 不變

重點不在重定向，而在 DNS、訪問性、快取、日誌和 Googlebot 能否順利抓到新基礎設施。上線後要同時看新舊環境的流量和抓取。

2. 換 CMS 或改 URL 結構，域名不變

重點在對映表、301/308 直達、模板保留主內容、靜態資源不丟、站內連結同步改新。大部分掉量事故，都出在這類專案。

3. 換域名

這是風險最高的一類。除了全站對映和永久重定向，還要準備 Search Console property、必要時使用 Change of Address，並長期保留舊域名上的跳轉。

企業站網站遷移 SEO 清單

1. 先定義遷移型別，不要把 hosting move 和 URL move 混為一談。
2. 拆分變數，能分兩次做就別一次全改。
3. 先識別高價值 URL，再補全全量 URL。
4. 建立可執行的 old-to-new 對映表，並標明 301/308、404/410。
5. 抽查重定向是否直達最終目標，避免鏈式跳轉。
6. 遷移圖片、PDF、JS、CSS、canonical、hreflang 和結構化資料。
7. 撤掉開發環境的 noindex、robots block、密碼牆和誤傷防火牆規則。
8. 提前準備 Search Console property 和 sitemap。
9. 上線後同步看 old/new 流量、抓取、索引和錯誤報告。
10. 重定向保留至少一年，並儘快把內部連結全部改直達。

常見問題 FAQ

網站遷移後短期掉排名，正常嗎？

正常。遷移後出現波動很常見。關鍵不是有沒有波動，而是新舊 URL 的替換、抓取和索引轉移是不是在正常推進。

所有舊頁面都能跳到首頁嗎？

不應該。沒有高度相關性的統一跳首頁，容易被當成 soft 404。更合適的做法是一對一跳到最相關的新頁面；沒有對應內容，就返回合理的 404 或 410。

遷移後要不要每個頁面都手動請求收錄？

不用。少量關鍵頁可以用 URL Inspection 請求重新抓取，大量 URL 還是更該靠 sitemap。Google 官方就是這麼建議的。

只是換伺服器，不改 URL，還需要做 301 嗎？

不需要。只換 hosting 的專案，重點是訪問性、DNS、快取和抓取切換，不是重定向。

301 要保留多久？

至少一年更穩。對老外鏈多、歷史頁面多的網站，保留更久通常更安全。

網站遷移 SEO 不是“上線前配幾個 301”這麼簡單。它更像一條鏈。舊地址、對映表、重定向、資原始檔、結構訊號、Search Console、站內連結、上線監控，這幾段只要斷一段，過去積累的搜尋訊號就會漏。把鏈條接順，遷移才穩。