網站改版 SEO 搬遷分三個階段處理：改版前建立舊 URL、流量、排名及轉換基準線；上線日按 URL mapping 啟用直接 301 轉址、更新 canonical、robots.txt 及 XML Sitemap；上線後用 Google Search Console（GSC）、GA4 及伺服器日誌持續監察。
301 Redirect 向 Google 和訪客說明頁面永久搬到新位置，但不能保證排名完全不變。每個舊 URL 都要指向最相關的新頁面；找不到合理替代頁面時，應考慮真實 404 或 410，不要把所有舊頁面一律轉向首頁。
新網站看起來更快、更靚，但上線後自然流量和表單查詢突然下跌，這是網站改版後最常見的擔憂。改版不只改設計，可能同時改動 URL 結構、CMS、內容、伺服器、DNS、追蹤代碼及索引設定。只要其中一個環節出問題，Googlebot 就可能無法正常抓取新頁面，GA4 就可能中斷記錄查詢資料。
本文提供改版前、上線日及上線後三階段清單，並附一個可複製的舊 URL 至新 URL 對照表欄位。這份清單可以降低可避免的技術風險，但不能保證排名、流量或轉換一定維持不變，因為搜尋結果受多種訊號影響，包括內容相關性、抓取效率及市場因素。
網站改版 SEO 搬遷是甚麼？先分清你正在改變甚麼
「SEO migration」（網站搬遷 SEO）泛指任何會影響 URL、伺服器行為、索引設定或追蹤資料的網站變更。然而，不同類型的改版所需要的 SEO 處理工作差異很大。
根據 Google Search Central 官方文件，網站搬遷的關鍵問題是：URL 有沒有改變？只換主機但 URL 完全不變，屬基礎設施變更，不應自動套用完整的網域搬遷流程。只有更換網域或子網域時，才應評估在 GSC 使用 Change of Address 工具。
| 變更類型 | URL 是否改變 | 需否 301 | 需否 Change of Address | 主要風險 |
|---|---|---|---|---|
| 只換主機（URL 不變） | 否 | 否 | 否 | DNS、SSL、伺服器配置錯誤 |
| HTTP 升級至 HTTPS | 是（協定改變） | 是 | 否 | canonical 及混合內容 |
| 改 URL 路徑結構 | 是 | 是 | 否 | 舊 URL 斷鏈、索引流失 |
| 轉換 CMS（URL 不變） | 不一定 | 視乎 URL 是否改變 | 否 | Rendering、canonical 設定 |
| 更換網域 | 是 | 是 | 是（可選） | 索引訊號轉移時間 |
| 多語言架構搬遷 | 是 | 是 | 視乎網域情況 | hreflang、x-default 設定 |
先完成這個分類，再決定需要哪些 SEO 處理步驟，避免把簡單的主機遷移過度複雜化，或把真正的網域搬遷低估處理。
為甚麼網站改版會影響排名、索引與自然流量？
網站改版涉及多個依賴關係。舊 URL 失效後，Googlebot 無法找到頁面；301 轉址鏈過長（超過 3 至 5 個 hop）會拖慢爬蟲處理；canonical 指向錯誤會令 Google 選錯代表 URL；robots.txt 或 noindex 若誤封重要頁面，搜尋結果就不會顯示該頁面。
以下是改版最常見的五個 SEO 風險點：
- 舊 URL 失效，301 未啟用：反向連結、書籤及已索引頁面即時斷鏈。
- canonical 仍指向舊 URL：Google 可能繼續選擇舊網址為代表頁面。
- robots.txt 或 noindex 誤封：上線後仍以 staging 設定阻擋 Googlebot。
- XML Sitemap 未更新：Google 需要更長時間發現新 URL。
- GA4 追蹤中斷：Measurement ID、GTM 容器或事件觸發器沒有在新 CMS 模板中重新驗證，導致查詢資料出現假性下跌。
根據 Google 官方說明，搬遷期間可能出現暫時排名波動，處理速度取決於網站規模、伺服器速度及 URL 數量，沒有固定的恢復時間表。因此，上線後的監察與上線前的準備同等重要。
改版前：建立 SEO 基準線與舊 URL 清單
上線前沒有基準線，上線後就無法判斷流量下跌是 SEO 問題、追蹤問題，還是季節性波動。改版前需要整理以下資料：
技術資料：
- XML Sitemap 全部 URL export
- CMS URL 完整匯出（包括 slug、類型、發布狀態）
- 伺服器 access log（確認實際被 Googlebot 抓取的 URL）
- robots.txt 及現有 canonical 設定截圖
- 現有 404、301 及重定向鏈報告
流量與排名資料：
- GSC Performance Report（最近 12 個月曝光、點擊、CTR、平均位置）
- GSC Page Indexing Report（現有索引頁面數量）
- GA4 Landing Pages Report（有機流量前 50 頁）
- 主要關鍵字排名基準（含品牌及非品牌查詢）
- 反向連結報告（指向哪些舊 URL）
轉換資料：
- GA4 轉換事件（表單提交、WhatsApp 點擊、電話點擊）
- 各 landing page 的轉換率基準
- 主要查詢來源及有效查詢量
如需在 GA4 及 GSC 中驗證 WhatsApp 和表單事件追蹤設定，可參考 GA4 追蹤 WhatsApp、電話與表單查詢 的設定方式，確保改版前已有完整的轉換基準。
哪些舊 URL 必須列入清單？
重要 URL 不只來自 XML Sitemap，更要從多個來源交叉核對：
- 高自然流量頁面：GA4 Landing Pages 報告中有機流量前 50 名。
- 高排名頁面：GSC Performance 中 CTR 或平均位置較好的頁面，即使流量不高亦要保留。
- 有外部連結的頁面：反向連結指向的 URL，斷鏈後連結訊號無法轉移。
- 有轉換的頁面：有表單提交、WhatsApp、電話或下載記錄的 landing pages。
- 非 HTML 資源：PDF、圖片、影片及下載檔案，若有搜尋曝光或反向連結，同樣需要納入搬遷計劃。Google 官方文件明確指出這些資源應一併處理。
URL 取捨表：保留、合併、301 或 404/410
每個舊 URL 都要做出明確決定，不能留空白：
| 情況 | 處理方式 |
|---|---|
| 新網站有完全對應的新 URL | 保留，直接 301 至新 URL |
| 兩個舊頁面內容合併為一個新頁面 | 兩個舊 URL 均 301 至合併後的新 URL |
| 舊頁面在新網站沒有對應，但內容仍有需求 | 建立新頁面後再 301，或暫時返回 404 |
| 舊頁面已永久移除，內容不再存在 | 返回 410（確認已刪除）或 404 |
| 找不到合理替代頁面，強行轉至首頁 | 不建議，可能被視為 soft 404 |
只有在首頁確實是合理替代頁面時，才考慮轉至首頁。Google 官方文件指出，大量不相關的首頁轉址可能造成使用者困惑，並影響索引判斷。
如何製作舊 URL 至新 URL 的 redirect mapping 對照表？
URL redirect mapping 是整個改版 SEO 最關鍵的交付物，目的是讓每個有搜尋或商業價值的舊 URL 都有明確的歸宿。以下是建議的對照表欄位範本（可直接複製至試算表使用）：
| 舊 URL | 新 URL | 頁面意圖 | 動作 | 預期狀態碼 | 最終 URL | 301 測試結果 | canonical 結果 | Sitemap 狀態 | 負責人 | 驗證日期 |
|---|---|---|---|---|---|---|---|---|---|---|
| /services/old-design | /services/website-design | 服務介紹 | 301 | 301 → 200 | /services/website-design | 待測試 | 待確認 | 已加入 | 開發 | - |
| /about-old | /about | 品牌介紹 | 301 | 301 → 200 | /about | 待測試 | 待確認 | 已加入 | 開發 | - |
| /old-blog-post | (無對應) | 過時內容 | 410 | 410 | - | 待測試 | 不適用 | 未加入 | SEO | - |
以上為假設範例（fictional example），欄位設計供參考，實際數字及 URL 以你的網站為準。
建議以實際 GSC、GA4 及反向連結報告的流量和連結數據排序，優先人工核對高價值頁面。
301 轉址應否一對一對應？
直接答案：有相同或合併後的相關新頁面時，優先一對一直接轉址。沒有合理替代頁面時，不要強行轉至不相關首頁。
四個執行規則：
- 優先直接轉址：舊 URL 直接指向最終新 URL，避免 redirect chain（轉址鏈）。根據 Google 官方文件，redirect chain 應保持很短，理想上不多於 3 個 hop，少於 5 個。
- 用 301 或 308 作永久轉址：301 和 308 均表示永久搬移；不要用 302 代替永久轉址，302 是暫時轉址訊號，不建議作 migration 用途。
- 避免 redirect loop：轉址迴圈（A 轉到 B，B 轉回 A）會令 Googlebot 放棄抓取，需在 staging 階段測試排除。
- 誠實面對限制：301 是 Google 理解永久搬移的訊號，不是排名或流量保證；內容品質、相關性及其他訊號仍會影響最終排名。
上線前：測試 staging、canonical、robots.txt 與 XML Sitemap
上線前的技術 QA 是防止最常見失誤的最後防線。按以下五類逐一確認：
爬蟲存取（Crawl）：
- Staging 環境已設 noindex 或 robots.txt 阻擋，防止測試內容被索引。
- Production 上線前已解除 staging 阻擋，這是最常被忽略的失誤。
- robots.txt 沒有誤封重要服務頁、博客或轉換頁面。根據 Google 說明，robots.txt 控制爬蟲存取，不等於移除索引，需要真正移除索引時應使用 noindex 或移除頁面。
索引訊號（Index）：
- 每個主要頁面的 canonical 標籤指向新 URL（完整 HTTPS 版本）。根據 Google canonicalization 文件，canonical 是提示，不是絕對指令，但正確設定有助減少歧義。
- 新 XML Sitemap 只列出希望出現在搜尋結果的完整 canonical URL，不包含 noindex、重定向或錯誤頁面。提交 Sitemap 是向 Google 提供 URL 發現提示，不等於收錄保證。
內容完整性（Content）：
- 所有 H1、Title Tag、Meta Description 在新 CMS 中正確渲染。
- 內部連結已更新至新 URL，不再指向舊路徑。
- 圖片、PDF 及重要媒體資源的 URL 已納入 mapping 並可正常存取。
結構化資料（Schema）：
- BlogPosting 或 Article schema 已更新 URL、發布日期及作者資料。
- BreadcrumbList schema 反映新 URL 結構。
轉換與追蹤（Conversion）：
- 表單、WhatsApp 及電話連結在新模板中可正常點擊。
- GA4 Measurement ID 及 GTM 容器已正確安裝並在 staging 測試通過。
多語言網站要同步檢查 hreflang 與 x-default 嗎？
如果你的網站有繁體中文、英文或簡體中文版本（各自有不同 URL），改版時需要同步處理 hreflang 及 x-default。
核對要點如下：每個語言版本的 hreflang 必須雙向對應（A 指向 B，B 也要指向 A）；canonical 應指向同語言版本的代表 URL；x-default 應指向真實存在的 fallback 頁面，不能只是標籤設定。完整設定方法可參考 多語言網站 SEO 與 hreflang 設定。
注意：並非每個香港網站都需要 zh-Hant-HK、en-HK 或 x-default，以實際 URL 架構和市場目標為準。
上線日：301、DNS、SSL、CMS 與轉換追蹤檢查表
上線日按以下順序執行，減少因時序錯誤造成的漏網：
- 備份：備份舊網站資料庫、mapping 試算表、robots.txt、Sitemap 及 GSC 報告截圖。
- DNS 及 SSL：確認 DNS 已指向正確主機，SSL/TLS 憑證覆蓋主網域及必要子網域；用瀏覽器及在線 SSL 檢查工具確認憑證有效。
- HTTP 狀態：確認首頁、主要服務頁及主要 landing page 返回 HTTP 200。
- 啟用 301 轉址：按 mapping 對照表逐批啟用，確認直接指向最終新 URL，沒有 redirect chain 或 redirect loop。
- 索引設定複查：確認 canonical、robots.txt、noindex 及 hreflang 均反映新 URL。
- 提交新 XML Sitemap：在 GSC 中提交新 Sitemap，並確認 Sitemap 只列可索引的新 URL。
- 驗證追蹤：確認 GA4 Measurement ID 正確連接；用 GTM Preview 及 GA4 DebugView 測試表單提交、WhatsApp 點擊及電話點擊事件。營收增長諮詢服務可協助整合 GA4、GTM 及查詢追蹤設定。
- GSC 驗證：確認新舊網站資源均在 GSC 中以同一 Google 帳戶驗證。若屬網域或子網域搬遷，才評估使用 Change of Address 工具。
上線後立即測試至少一個由自然搜尋進入的 landing page，並完整走過一次表單或 WhatsApp 查詢流程，確認轉換記錄出現在 GA4。
上線後：如何用 Search Console、GA4 與 SEO KPI 監察搬遷？
搬遷後的監察應按時間分層，不要只看單一指標，也不要把初期波動直接判定為 SEO 失敗。
| 時間 | 觀察重點 |
|---|---|
| 0 至 24 小時 | HTTP 狀態（200/301/404）、DNS 及 SSL 穩定性、robots.txt、GA4 實時數據、表單及 WhatsApp 測試 |
| 第 2 至 7 日 | GSC URL Inspection、Page Indexing Report、Sitemap 處理狀態、404 新增量、伺服器錯誤 |
| 第 14 日 | 曝光、點擊、CTR、平均排名（新舊 URL 對比）、品牌查詢及非品牌查詢對比 |
| 第 30 日 | 自然流量、轉換事件、有效查詢量、新增 404、redirect chain 及 GA4 轉換品質 |
| 第 60 至 90 日 | 索引覆蓋趨勢、外部連結更新、非品牌排名、assisted conversions 及內容差異分析 |
根據 Google 官方文件，GSC 可按查詢、頁面、國家及其他維度檢查曝光和點擊，Sitemaps 及 Page Indexing 報告也可用來監察搬遷進度。值得注意的是，Googlebot 完成一次完整的新舊 URL 抓取需要時間，沒有固定的爬蟲頻率，大型網站可能需要數週或更長時間。
同時監察技術 SEO KPI 和商業 KPI：曝光、點擊、CTR、平均位置、自然工作階段、表單提交、WhatsApp 點擊、電話點擊及有效查詢。只有流量下跌而轉換未下跌，可能是追蹤問題；只有排名波動而索引正常，可能是內容相關性需要調整。
如需在 GSC 及 GA4 設定技術 SEO 監察及 技術 SEO、GEO 及 AIO 優化服務，搬遷後的持續優化與改版前的規劃同等重要。
網站搬遷後排名下跌，先查甚麼？
按以下優先順序診斷，找到根本原因前不要急於改動多個變數：
- 新網站是否可正常存取？首頁及主要頁面返回 HTTP 200 還是有錯誤？
- robots.txt、noindex 或登入保護是否誤封了重要頁面？
- 301 轉址是否正確指向最終 URL？有沒有 redirect chain 或 redirect loop？
- 新頁面的 canonical 是否已更新至新 URL？
- XML Sitemap 是否列出可索引的新 URL，並已在 GSC 提交？
- 重要頁面的 H1、Title Tag、正文內容是否在改版時被刪除或大幅更改？
- DNS、SSL 或伺服器是否有不穩定情況，導致 Googlebot 間歇性無法存取？
- GA4 或 GSC 追蹤是否中斷？避免把數據故障誤判為真實流量故障。
根據 GSC URL Inspection 工具說明，URL Inspection 可查看索引狀態、canonical、抓取結果及渲染內容，提出重新索引要求不代表 Google 會立即收錄。
甚麼時候應找專業團隊處理網站搬遷 SEO？
不是所有改版都需要外部支援，但以下情況風險較高，建議尋求具備香港網頁設計服務及技術 SEO 能力的團隊協助：
適合尋求專業支援的情況：
- 網站有大量 URL（超過 200 頁）或複雜 URL 結構。
- 同時更換網域、CMS、內容及 URL 架構，問題難以個別歸因。
- 有多語言版本需要同步更新 hreflang、canonical 及 Sitemap。
- 電商網站有大量產品及分類頁面，搜尋意圖複雜。
- 內部沒有同時懂開發和 SEO 的負責人。
- 現有網站有穩定自然流量或高價值查詢，流量中斷影響查詢及收入。
LetsGetWeb 官方服務頁面列出網站設計、技術 SEO、GEO、AIO、Search Console 監察、Schema 及營收追蹤等服務方向。品牌服務內容以 LetsGetWeb 官方頁面及個別專案確認為準。
本文由 LetsGetWeb 撰寫，品牌服務內容以官方頁面及個別專案確認為準。品牌方案及功能資料於 2026 年 9 月查核，發布前請重新核對官方頁面。
甚麼情況下不適合立即做完整 SEO 搬遷？
以下情況應先完成規劃，再開始搬遷：
- 尚未確定新網站的 URL 架構，沒有清楚的頁面對應關係。
- 沒有指定 URL mapping 的負責人，各頁面的取捨無人確認。
- 舊網站尚未備份，一旦出問題無法回滾。
- 現有網站幾乎沒有自然流量或轉換基準線，沒有可比較的改版前數據。
- 同時改動太多變因（設計、內容、URL、CMS 及網域），出問題後無法精確診斷。
誠實的建議：只換主機而 URL、CMS 及內容完全不變時，可能只需基礎設施和監察清單，不需要完整的網域搬遷 SEO 服務。
網站改版 SEO FAQ
1. 網站改版一定會影響 SEO 嗎？ 只要 URL、內容、內部連結、索引設定或伺服器行為改變，就需要做 SEO QA。只換主機而所有設定不變，SEO 影響通常很小。
2. 網站改版一定要做 301 轉址嗎？ 只有舊 URL 永久搬到新 URL 時，才需要啟用 301 Redirect。URL 沒有改變時，不應無緣無故新增 301。
3. 301 轉址可以保證排名不跌嗎？ 不可以。301 是永久搬移的訊號，不是排名保證。根據 Google Redirects 文件，內容相關性、抓取效率及其他訊號仍會影響排名。
4. 舊頁面全部 301 到首頁可以嗎？ 不建議。只有在首頁確實是合理替代頁面時才考慮，否則應指向最相關的新頁面，或返回適當的 404/410 狀態。
5. 網站搬遷後需要在 Search Console 使用 Change of Address 嗎？ 只在更換網域或子網域時評估使用。根據 GSC 官方說明，單純改 URL 路徑、HTTP 升級至 HTTPS 或換主機，不需要使用 Change of Address。
6. 網站搬遷後應否重新提交 XML Sitemap？ 應提交只包含新網站可索引 canonical URL 的 Sitemap，並在 GSC 查看處理狀態。Google 官方 Sitemap 文件指出，提交 Sitemap 是提示，不等於保證收錄。
7. robots.txt 可以阻止舊頁面被 Google 收錄嗎？ 不能作為完整的索引移除工具。需要真正移除頁面索引時，應使用 noindex、密碼保護或移除頁面。Google robots.txt 文件有詳細說明。
8. 網站搬遷後幾耐才知道排名有沒有受影響？ 沒有適用所有網站的固定時間。建議由 24 小時技術 QA、第 14 日索引和流量檢查，以及第 30 至 90 日趨勢共同判斷。
9. 換 CMS 會不會令網站排名下跌？ 換 CMS 本身不是必然原因。若同時改變 URL、內容、canonical、內部連結或頁面速度，SEO 風險會相應增加。
10. GA4 在網站改版後為甚麼沒有查詢數據？ 常見原因包括 GA4 Measurement ID、GTM 容器、事件觸發器、表單、WhatsApp 或電話連結沒有在新模板中重新驗證，必須用 GTM Preview 及 DebugView 實際測試確認。
最後決策：用三階段清單確認網站可以安全上線
改版前、上線日及上線後這三個階段，各有不能跳過的交付物：
- 改版前已完成：URL inventory、SEO 基準線（GSC、GA4、排名）、URL 取捨決定、redirect mapping 對照表、轉換基準及媒體資源清單。
- 上線日已驗證：DNS、SSL、HTTP 狀態、301 轉址、canonical、robots.txt、新 XML Sitemap 提交、GSC 資源驗證、GA4 Measurement ID、GTM 事件及完整轉換 journey 測試。
- 上線後有監察：24 小時技術錯誤處理，第 14 日索引和 404 檢查，第 30 日流量和轉換對比，第 60 至 90 日趨勢分析和外部連結更新。
如果你的網站有既有自然流量、複雜 URL 結構或多語言版本，先完成這份清單，再決定由內部團隊處理，或向 LetsGetWeb 預約網站 SEO 搬遷諮詢，取得網站設計、技術 SEO 及轉換追蹤的整合支援。