每週都會有人想把一個真實的網站——有流量、有反向連結、累積了幾年 Google 信任度的網站——搬到 AI 建構器上。不是全新的點子，也不是原型，而是一個有東西可以失去的既有業務。這和從空白提示詞開始是完全不同的任務，而我看過的大多數問題，都是因為把它當成同一件事來處理。
有三種出錯方式頻繁到我能在看完標題之前就預測到客服工單的內容。正確的做法並不高明，只是你在停止這三種做法之後自然會走到的結果。
錯誤一：把舊內容整批倒進去，指望結構自己會理順
這種直覺很合理。你有一個網站，上面有文字，所以你把文字貼進對話框，要求建構器「把它變好」。結果通常是一個看起來新、讀起來舊的網站——一樣的流水帳式服務段落、一樣用三個標題撐起原本該有十五個標題的內容，只是包上了更漂亮的版型。建構器確實照做了你要求的事，但你要求的是換裝，不是重新思考。
災難大約在六週後浮現，這時新網站的排名跟舊網站一模一樣，甚至更差。什麼都沒改善，因為實際的資訊架構根本沒有改變——同一個本該拆成三頁的服務，還是擠在一個扁平的頁面裡；同樣缺少的常見問題內容，競爭對手的網站早已靠它排名一整年。房子的房間數不對，就算重新粉刷，房間數還是不對。
我曾有一位客戶，她的「服務」頁面有四千字，涵蓋十一項不同的服務項目。她希望原封不動遷移過去，理由是「這一直都有效」。但其實它從來沒有效——它什麼具體項目都排不上名，因為它一次講太多東西。原封不動遷移，只會得到一個更好看但依然排不上名的頁面。
真正有效的做法，是把遷移當成先做稽核、再做建構。把舊內容輸入進去，但先要求做一份內容盤點：有哪些頁面存在、每一頁實際上想針對什麼關鍵字排名、哪裡是兩個主題硬塞進一個網址、哪裡是一個主題被拆得太薄分散在五個頁面。這份盤點就是計畫。舊網站是資料來源，不是範本。
錯誤二：忘記網址才是 Google 真正信任的東西
這是代價最高的一個。網站遷移時如果改變了網址結構，卻沒有把舊路徑對應到新路徑——即使新內容確實更好——也會白白丟掉多年累積的訊號。反向連結指向的變成 404 頁面。Google 得重新爬取，在一個不同網址下重新贏得信任。來自舊書籤和電子郵件簽名的直接流量也會走進死路。
我見過有人在上線後才注意到這件事，那時分析儀表板顯示的是懸崖式下滑，而不是成長。到那個時候，解決方案就是事後補上重新導向，這確實能挽回一部分損失，但無法完全挽回——從「網址搬走了」到「有人發現並修復」之間的落差，等於是好幾週流失掉、再也拿不回來的權重。
| 舊做法 | 會出什麼問題 | 應該怎麼做 |
|---|---|---|
| 讓建構器產生任何符合新設計的網址結構 | 每一個導入的反向連結和書籤現在都指向 404 頁面 | 先匯出舊網站地圖，在開始建構前，把每個既有網址對應到新的等效網址 |
| 只重新導向首頁，讓內頁 404 | 深層頁面各自帶有獨立的連結權重——逐一流失會累積成不小的損失 | 把每一個有意義的舊網址都做 301 重新導向，即使是被合併進更廣泛頁面的網址也一樣 |
| 「等上線之後」再加重新導向 | 爬蟲和點擊的使用者，會在流量最不穩定的那段期間，正好遇到死路 | 重新導向要跟新網站同時上線，而不是事後才補 |
這些都不是什麼高深的東西，就是一張兩欄的試算表，在任何人碰建構器之前先做好。這一步之所以常被跳過，只是因為它很枯燥，而建構本身才是有趣的部分。
錯誤三：沒有回退方案的一次性大切換
第三種失敗模式跟內容或網址完全無關——而是關於切換本身是怎麼發生的。有人建好新網站，看預覽版覺得滿意，當天下午就把網域指向它。沒有測試階段、沒有在真實流量下做並排比較，也沒有為預覽時沒抓到的問題準備任何應對計畫——像是聯絡表單默默失效、結帳流程在測試時正常但在真實付款量下卡住、頁面在桌面上顯示正常但在你半數客戶使用的那款手機上壞掉。
這裡的災難是最吵鬧的一種，因為它是即時發生的。客服信箱被塞爆。有人每十分鐘就重新整理一次分析數據，看著圖表往錯誤的方向走，而要回退就得重新設定 DNS，這本身就需要時間才能生效，也就是說即使你已經決定要復原，糟糕的體驗還是會持續一段時間。
解決方法並不炫：在切換前一兩天先降低 DNS 的 TTL，這樣萬一需要回退，能快速生效；先在預覽或測試子網域上跑新網站，並真正像客戶那樣去使用它；切換後把舊網站的主機保留至少幾週不動，而不是新網站一上線就馬上關掉。最後這一步只需要花幾塊美元的主機費用，卻是真正的保險。很多人跳過這步，因為取消舊方案感覺像是把事情做個了結，而了結感覺就像進度。
正確的做法實際上長什麼樣子
整體來看，這些做法並不比錯誤的做法花更多工夫——只是把同樣的工作換個順序做。重建之前先稽核。上線之前先對應網址。切換之前先做測試階段，切換之後留幾週的回退空間。最終出來的網站，不只是看起來更新，它保留了舊網站已經贏得的一切——這正是遷移而不是從頭再來的意義所在。
