「我們網站要改版,怕影響 SEO」是過去的問題。今天的問題是:「怕影響 AI 引用率」。
AI 引用是多年累積的「網站認識」——改版做錯,這份認識可能在 1-2 週內消失。這篇是完整的改版遷移檢查清單,做完這 6 步驟,12 個案中 11 個能保留 90%+ AI 引用權重。
6 步驟完整遷移流程
步驟 1:改版前匯出完整 URL 清單
最重要的一步。用工具跑全站:
- Screaming Frog(推薦):免費版 500 頁、Pro 無限
- Ahrefs Site Audit
- Sitemap.xml:直接從現有 sitemap 取
- Google Search Console:匯出已索引頁面
匯出的 URL 清單格式:
URL, 頁面類型, 月流量, AI 爬蟲訪問, 預計新 URL
https://example.com/insights/ai-ready, Article, 1200, 45, /insights/ai-ready
https://example.com/services/web-design, Service, 800, 28, /services/web-design
...
典型網站約 100-1000 個 URL,全部要列出。
步驟 2:301 redirect 對應表
每個舊 URL 對應到新 URL(傳統 SEO 權重的遷移細節可參考網站改版的 SEO 遷移完整實作):
# Nginx 設定
rewrite ^/old-blog/(.*)$ /insights/$1 permanent;
rewrite ^/services/website/(.*)$ /services/$1 permanent;
rewrite ^/about-us$ /about permanent;
或 Laravel:
// routes/web.php
Route::get('/old-blog/{slug}', fn($slug) => redirect("/insights/{$slug}", 301));
規則:
- ✅ 用 301(永久重定向),不是 302(暫時)
- ✅ 每個舊 URL 都要有對應,不能有遺漏
- ✅ 長度盡量短,不要 5 層重定向(A → B → C → D → E)
- ❌ 不要全部 redirect 到首頁(會被視為作弊)
步驟 3:Schema.org 同步遷移
改版前匯出 Schema 清單:
# 用 Screaming Frog 抓所有 Schema
crawl > export > Custom Extraction > "Schema.org JSON-LD"
新版 CMS 要重建相同 Schema 邏輯(不是手動複製 HTML,是重建生成系統)。
改版後驗證:
- 隨機選 10 頁
- 用 Rich Results Test 跑
- 確認 Schema 類型與欄位都正確
步驟 4:保留語意化 URL 結構
強烈不建議改 URL 結構。如果現有結構是:
/insights/{slug}
/services/{slug}
/cases/{slug}
/about
/contact
就保持。真的要改要評估代價:
| 改動 | 代價 |
|---|---|
| 路徑層級不變、slug 不變 | 0%(無 redirect 需求) |
| slug 不變但路徑層級改 | 5-10%(每頁需 redirect) |
| 改整個 URL 結構 | 20-40%(大量 redirect + 重新索引時間) |
步驟 5:改版後監控(首月每天)
第一個月每天監控:
- GSC 涵蓋率報告:看 4xx 錯誤是否暴增
- 404 監控:用 GSC 或 Sentry 抓 404 URL
- AI 爬蟲訪問:server log 看 GPTBot、ClaudeBot 訪問量
- 核心關鍵字排名:用 Ahrefs / Semrush 看波動
異常處理:
- 看到大量 404 → 立刻補 301 redirect
- AI 爬蟲訪問驟降 → 檢查 robots.txt 是否誤改
- 排名大幅下滑 → 確認 Schema、內部連結是否完整
步驟 6:重新提交與通知
改版上線後:
# 提交新 sitemap 到 GSC
https://example.com/sitemap.xml
# 觸發 Google 重新索引重要頁面
GSC > URL 檢查 > 提交以建立索引
對 AI 爬蟲:
- llms.txt 更新:列出新版重要頁面
- 重要頁面在社群分享:促進外部連結重新建立
- email 訂閱者通知:告知改版
改版時機選擇
時機影響改版風險:
| 時機 | 風險 | 適合 |
|---|---|---|
| Q1(淡季) | 低 | B2C 電商 |
| Q2-Q3 | 中 | 多數產業 |
| Q4(旺季) | 高 | 不建議改版 |
避開重大行銷活動前 2 個月——改版完要時間穩定,旺季前才上線等於用最重要時段試錯。
元伸客戶改版實戰
某 B2B 工業客戶從舊 PHP 系統改 Laravel + Vue(屬於企業形象網站的長期維運場景):
改版規模:
- 原網站 280 頁
- 新網站 320 頁(含 40 頁新內容)
- URL 結構保留 95%
遷移工程(4 週):
- 第 1 週:URL 清單匯出 + 對應表
- 第 2-3 週:Schema 重建 + 內容遷移
- 第 4 週:測試 + Staging 驗收
- 上線後第 1 個月:每天監控
6 個月後成效:
| 指標 | 改版前 | 改版後 |
|---|---|---|
| AI 引用率 | 月均 80 次 | 月均 96 次(+20%) |
| 自然流量 | 4,200/月 | 5,100/月 |
| 404 錯誤 | 0 | 7(皆已補 redirect) |
改版沒有影響原有引用權重,反而因新版結構優化提升了 20%。
不要犯的 6 個錯誤
- ❌ 沒做 URL 對應就上線:保證流失 30-50% 流量
- ❌ 301 改 302:暫時重定向不會傳遞權重
- ❌ 首頁吃掉所有 redirect:被 Google 視為作弊
- ❌ 改版上線後沒監控:問題累積 1 個月才發現太晚
- ❌ 同時改太多事(換 CMS + 改 URL + 改視覺):問題排查困難
- ❌ 改版時擋 robots.txt 防爬:AI 看不到新版反而更糟
若改版同時要更換網域,請另外搭配網域變更時的 AI 引用權重保留做雙重佈局。
結語:改版是風險最高的網站工程
改版不只是視覺更新,是牽動 SEO + AI 引用 + 使用者體驗的完整工程。做對了,新版本繼承舊版本的所有累積;做錯了,多年的努力歸零。
元伸科技在執行客製化網頁設計的改版專案時,URL 對應表是專案啟動的第一份交付物——沒有完整對應表不上線。這是改版工程的最低底線。