curl -sS -D - -o /dev/null "$OLD_URL"

跟隨重新導向，查看沿途回應標頭

curl -sS -L -D - -o /dev/null "$OLD_URL"

輸出最終狀態與最終網址，便於登記結果

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

驗收紀錄應同時保存首次回應、目標網址、最終回應及頁面內容。永久遷移的規則類型，應由技術負責人按實際部署環境確認，不能只用瀏覽器「似乎跳過去了」作結論。

把不必要的連續重新導向、跳回舊網址、導向測試網域、目標頁面不存在等情況列為阻擋上線的項目。特別注意不要只檢查首頁規則，而漏掉文章和產品詳細頁。

## 五、頁面內容與 canonical 如何一起驗收？

網址能夠開啟，只是最低要求。建議從每種頁面範本抽取代表頁，核對標題、主標題、正文、圖片替代文字、內部連結和諮詢按鈕是否完整，避免匯入後只剩頁面框架。

canonical 可作為標準網址檢查項目，但不要把它當作處理所有遷移問題的替代方案。驗收時記錄頁面宣告的標準網址，並確認它與專案確定的正式頁面一致；尤其要排查仍指向舊網域、預覽網域或不相關頁面的情況。

多語言網站應額外核對語言版本之間的對應關係。中文版產品頁不應因為批次取代而連結到英文首頁；語言切換、頁尾連結與正文推薦連結都要實際點擊測試。

同時比較遷移前後的核心資訊。價格條件、服務範圍、案例依據與聯絡方式不能在範本替換時被無意刪除。對於業務人員仰賴的頁面，建議讓業務負責人參與驗收，而不只由開發人員檢查技術回應。

## 六、網站地圖要檢查什麼？先與正式頁面清單核對

建議先整理「計畫公開並供搜尋引擎發現的正式頁面清單」，再與生成的網站地圖對照。不要把「已經生成一個 XML 檔案」當成檢查完成。

重點檢查以下事項：

- 地圖中的網址是否屬於正式網域和正式環境。
- 遷移後的新路徑是否已按計畫列入。
- 已刪除、仍在重新導向或尚未準備公開的網址是否混入。
- 地圖列出的頁面，是否與頁面宣告的標準網址一致。
- 多語言目錄、文章分頁或產品分類是否存在整類遺漏。
- 更新地圖和重新發布的負責人是否明確。

地圖項目數量變化時，應追問變化來自哪裡：是內容有計畫地合併，還是匯入遺漏、篩選條件錯誤？建議保存遷移前後的檔案副本，以便逐項比較。

網站地圖只是遷移驗收的一部分。提交作業完成後，仍要檢查具體頁面的存取、內容和後續狀態，不能據此承諾索引收錄、排名或流量結果。

## 七、Search Console 上線前後分別要檢查什麼？

![七、Search Console 上線前後分別要檢查什麼？](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)


上線前，先確認團隊能存取相關網站資源，負責人員的權限不會隨舊供應商退出而遺失。記錄遷移前的重要到達網頁、查詢字詞、點擊和曝光表現，並保存觀察日期，作為後續比較的起點。

上線後，建議按以下順序檢查和登記：

1. **資源與權限**：目前查看的是否為本次遷移涉及的網站，負責人是否仍有存取權限。
2. **代表性網址**：檢查關鍵頁面的檢索、索引狀態及標準網址資訊，區分歷史紀錄與後續變化。
3. **網站地圖**：核對提交對象、處理狀態及相關提示，遇到異常再回到實際檔案排查。
4. **頁面問題**：按目錄和範本整理異常，不要只盯著總量。
5. **成效表現**：結合舊頁面與對應新頁面比較查詢、點擊和曝光，不只比較首頁。

如果同時更換網域，應另外確認網址變更相關流程是否適用於自己的遷移情況，不要把同網域更換建站工具與跨網域遷移混為一談。

發現問題時，把頁面網址、看到的提示、觀察時間和複測結果放進同一張工單。不要僅憑某一次螢幕截圖就刪除頁面或反覆修改規則。

## 八、上線當天如何安排驗收與回復？

建議把上線劃分為準備、切換、複測和觀察階段。準備階段凍結重要內容變更，備份頁面資料與設定，確認舊站必要的存取能力仍可保留。

切換後先測試關鍵業務流程：從舊入口進入、閱讀產品說明、提交表單、接收通知、業務跟進。SEO 檢查與潛在客戶檢查應同步進行，避免頁面可存取但諮詢無人收到。

阻擋上線的條件應提前約定，例如關鍵產品頁無法存取、大批舊入口沒有預定去向、正式頁面仍受測試環境限制，或諮詢流程失效。出現這些情況時，由負責人決定修復還是回復，而不是邊上線邊爭論標準。

回復也應有操作說明：誰能執行、需要還原哪些設定、如何確認還原成功。不要在遷移當天才發現舊站已經刪除，或原供應商帳戶權限已經失效。

## 九、遷移後表現變化，怎樣排查才不亂？

建議先排查可重複出現的技術和內容問題，再討論更廣泛的搜尋表現。順序可以是：頁面能否存取、舊入口去向是否正確、內容是否完整、內部連結是否更新，以及網站地圖與頁面宣告是否一致。

比較資料時，應把同一業務頁面的舊網址與新網址放在一起看。如果只看新網址的歷史紀錄，容易忽略遷移前的資料；如果只看全站總量，又可能掩蓋一個重要目錄的損失。

還應記錄同期的廣告變化、內容刪改、季節性活動和統計設定調整，避免把所有變化都歸因於更換平台。建議每輪只修復一組明確問題，並登記複測結果，減少多項變更疊加後無法判斷原因的情況。

沒有統一適用於所有網站的恢復期限。遷移驗收可以設定內部複查節奏，但不宜把這個節奏包裝成搜尋引擎的處理承諾。

## 十、選擇 AI 建站平台時，要怎樣詢問遷移能力？

生成頁面和承接舊站是兩項不同的驗收工作。[we0 官網](https://we0.ai/zh)介紹了以自然語言描述需求、多 Agent 建置、視覺化調整與網域部署流程。企業可以據此評估建站方式，但仍應單獨要求示範舊路徑保留、重新導向設定及遷移後的測試方法，不能直接推定這些事項會自動完成。

作為另一類產品參考，[Readdy 官網](https://readdy.ai/zh)介紹了程式碼匯出、網域託管以及 SEO、GEO 相關工具。採購時應進一步詢問：匯出後由誰維護部署設定，路徑規則由誰管理，異常由誰排查。功能名稱不能代替專案責任書。

[阿里雲開發者社群的萬小智介紹文章](https://developer.aliyun.com/article/1773673)涉及對話式建站與部署流程，但頁面註明內容由使用者貢獻。它適合協助團隊理解建站情境，不宜被當作廠商對本專案遷移交付範圍的承諾。

建議讓候選平台或實施方拿一小組真實舊頁面做示範，再決定採購和上線計畫。示範應涵蓋不同範本與異常情況，而不只是生成一個新首頁。

## 常見問題

### 不更換網域，只更換建站平台，也需要遷移清單嗎？

需要。建議核對路徑、正文、頁面宣告、內部連結和諮詢流程是否保持一致。網域未變，並不意味著所有部署結果都會自動符合原方案。

### 能不能把全部舊頁面都導向首頁？

不建議將它作為預設方案。應先判斷每個舊頁面是否有相關的新頁面承接；沒有替代內容時，也要明確記錄處理方式，而不是用首頁掩蓋缺失。

### 提交網站地圖後就算遷移完成了嗎？

不算。還應完成舊入口測試、關鍵頁面檢查和業務流程驗收，並持續記錄 Search Console 中的狀態變化。提交動作不能代替實際存取測試。

## 相關工具

- **URL 對照表**：管理舊路徑、新路徑、處理方式與負責人。
- **curl**：查看回應標頭、重新導向過程和最終網址。
- **Google Search Console**：整理網站相關狀態與搜尋表現檢查紀錄。
- **瀏覽器開發者工具**：複測頁面載入、連結與表單請求。

## 相關連結

- [we0：建站、頁面調整與部署流程](https://we0.ai/zh)
- [Readdy：建站、程式碼匯出與營運工具介紹](https://readdy.ai/zh)
- [阿里雲開發者社群：萬小智 AI 建站情境介紹](https://developer.aliyun.com/article/1773673)

## 總結

更換建站平台的驗收對象，不只是新網站，而是從舊入口到新內容，再到諮詢動作的完整路徑。先建立 URL 對照表，再測試重新導向、頁面內容、網站地圖和業務流程，最後結合 Search Console 持續排查。平台能力應透過真實頁面示範確認，遷移責任與回復條件則應在上線前寫清楚。