未來領航員 / AI 搜尋與內容治理 /網站改版或換 CMS 前，AI 搜尋內容怎麼搬？URL、schema 與 sitemap 遷移清單

網站改版或換 CMS 前，AI 搜尋內容怎麼搬？URL、schema 與 sitemap 遷移清單

作者：FlyPig AI 團隊發布：2026-08-27 更新：2026-08-27 閱讀：10 分鐘

摘要

很多企業做網站改版時，把焦點放在首頁、視覺、動效與新 CMS 後台。真正會傷到搜尋與 AI 摘要理解的，常常是比較無聊的地方：舊 URL 沒有對到新頁、canonical 指回錯頁、FAQ schema 還留著舊答案、OG 圖變成共用圖、sitemap 沒有更新，或原本有排名與內鏈的文章被搬成 404。

AI 搜尋時代，網站改版不是只把內容複製到新系統。你是在搬一個公開知識庫。每一篇文章、服務頁、案例頁與 FAQ 都可能被讀者、搜尋結果片段、AI 摘要、業務同仁或外部合作夥伴引用。

本文整理一份改版前後的內容遷移清單。目標不是承諾排名或 AI 引用，而是讓新網站上線後，重要內容仍能被正確找到、正確理解、正確連回下一步。

核心結論

網站改版最容易犯的錯，是把「搬版面」誤認為「搬內容系統」。

真正要搬的不是只有文字，而是這一整組訊號：

要搬的項目	沒搬好的風險	改版前要先確認
舊 URL 與新 URL	讀者、搜尋與外部連結進到 404	每個舊頁是否有保留、合併、刪除或轉址決策
redirect	舊頁權重與使用者路徑斷掉	永久搬移的頁面是否指向最接近的新頁
canonical	搜尋系統可能理解錯代表版本	新頁 canonical 是否指向自己或正確代表頁
Article / FAQ schema	結構化資料與可見內容不一致	標題、日期、圖片、作者、FAQ 是否同步
OG 圖與文章圖片	外部分享或 AI 摘要抓到錯圖	重要頁面是否使用專屬且存在的圖片
sitemap 與內鏈	新頁不容易被發現，舊頁仍被列出	sitemap、導覽、hub、延伸閱讀是否同步更新
Search Console 檢查	上線後才發現錯頁或無法索引	是否有抽樣 URL 清單與回查節奏

改版不是一天內完成的事。上線當天只是開始，真正的工作是接下來幾週確認舊頁、新頁、搜尋系統與讀者路徑是否逐步收斂。

為什麼 AI 搜尋讓網站改版風險變高

傳統 SEO 時代，網站改版後最直覺的問題是排名波動、404 增加、流量下滑。這些仍然重要，但 AI 搜尋讓問題多了一層：內容可能被摘要、轉述或拿來回答決策問題。

讀者未必會完整打開你的新網站。他可能問：

這家公司是否還提供某項服務？
某篇教學的步驟是不是還有效？
價格頁是不是仍有同樣條件？
案例頁的成果是否能代表一般客戶？
這篇 FAQ 是新版政策，還是舊版文章留下來的？

如果改版後舊 URL 消失、schema 還留著舊內容、sitemap 仍列出不該列的頁面，AI 搜尋或搜尋摘要就可能抓到一個不完整的版本。問題未必會立刻出現在排名報表，它可能先出現在業務問答、客服對話、社群截圖或客戶轉述裡。

Google Search Central 對網站搬移與 URL 變更的文件，重點是降低搜尋結果受影響的程度，而不是承諾完全無波動。Google 對 sitemap 的說明也提醒，sitemap 能協助搜尋系統發現重要 URL，但不代表所有項目都會被抓取或索引。

所以企業要把改版視為內容治理專案，而不是單純設計專案。

改版前先做 URL 命運表

每一次改版都應該先建立一張 URL 命運表。不要等工程師問「這些舊頁要導去哪裡」時，才用感覺決定。

最少要整理這些欄位：

欄位	目的
舊 URL	確認目前公開入口與外部連結
新 URL	決定對應頁面，不要臨時猜
頁面類型	文章、服務頁、案例頁、價格頁、FAQ、下載頁
處理方式	保留、合併、重寫、刪除、暫時保留
redirect 目標	舊頁若搬移，對到最接近的新頁
canonical 目標	確認代表版本，避免指向錯頁
主要內鏈來源	哪些 hub、導覽或文章連到它
風險等級	價格、政策、案例、法規、醫療、金融等要加強審核
上線後抽查	是否列入 Search Console 或人工檢查清單

這張表最重要的不是完整到漂亮，而是每個重要舊頁都有命運。它不能只列新網站會出現的頁面，也要列出舊網站中仍有搜尋、外部連結、社群分享、電子報連結或內部業務引用的頁面。

如果舊頁本來就是薄內容、過期內容或互相競爭的內容，可以在改版前先決定合併或重寫。但不要把所有不想處理的舊頁都導回首頁。這種做法對讀者沒有幫助，也會讓搜尋系統更難理解新頁是否真的是舊頁的替代版本。

redirect 不只是把舊頁丟到首頁

redirect 的核心問題不是「有沒有轉址」，而是「舊頁的讀者意圖是否被新頁承接」。

例如：

舊文章談「AI 客服真人接手」，新頁應導到同主題文章或新版客服治理頁，不應導到首頁。
舊價格頁若已改成方案諮詢頁，新頁應清楚說明價格條件、報價前提與更新時間。
舊案例頁若合併到案例總覽，總覽頁應保留足夠的產業、問題、做法與限制，避免只剩品牌口號。
舊 FAQ 若已不適用，應決定是更新答案、合併到新政策頁，還是移除並避免留下錯誤 schema。

Google 的 redirect 文件把不同 redirect 類型視為搜尋理解 canonical 的訊號之一。對企業來說，實務上要先判斷搬移是永久還是暫時，再選擇合適的轉址方式，並避免轉址鏈過長或轉到無關頁面。

改版前可以用三個問題檢查 redirect：

舊頁的核心問題，在新頁是否仍被回答？
新頁是否保留必要限制、日期、來源與下一步？
如果讀者從舊連結進來，會不會覺得被帶到不相干頁面？

只要第三題答案是會，這個 redirect 就需要重新設計。

結構化資料、問答與 OG 圖要一起重驗

網站改版常見的隱性錯誤，是正文改了，但結構化資料沒改；頁面搬了，但 OG 圖還抓舊共用圖；FAQ 刪了，但 FAQPage schema 還留在 HTML。

這在 AI 搜尋時代很危險，因為內容不是只靠肉眼閱讀。搜尋系統會看頁面上的可見文字，也會利用技術訊號理解頁面。Google 對結構化資料的說明，是幫搜尋系統理解內容並支援搜尋外觀，但結構化資料必須和頁面可見內容一致。

改版後，每個高價值頁面至少要檢查：

項目	檢查方式
title 與 meta description	是否仍反映新頁內容，不是舊 CMS 範本
canonical	是否指向新正式 URL，不是 staging、舊網域或首頁
Article schema	標題、描述、圖片、作者、發布日期、更新日期是否一致
BreadcrumbList	麵包屑是否符合新資訊架構
FAQPage	只有頁面真的有 FAQ 時才輸出，答案要和正文一致
OG image	是否使用存在、清楚、專屬或正確代表該頁的圖片
主要 CTA	是否指向真實可用頁面，不是空錨點或舊表單

不要把 schema 當成 AI 搜尋捷徑。Google 的 AI 搜尋最佳實務仍然強調基礎 SEO、清楚技術結構、可靠且對人有幫助的內容。schema 的價值是讓正確內容更容易被理解，不是替空泛內容補信用。

sitemap、內鏈與 hub 要同步上線

很多改版只測新頁能不能打開，沒有測內容系統是否還能被走完。

對搜尋與 AI 摘要而言，sitemap、內鏈與 hub 共同回答一個問題：這個網站認為哪些頁面重要，它們彼此是什麼關係？

改版時請同步處理：

sitemap 只列應該被發現的重要正式 URL。
已刪除或合併的舊頁不要繼續出現在 sitemap。
重大正文、結構化資料、圖片或 URL 改動後，再更新對應頁面的日期訊號。
hub、主題中心、文章延伸閱讀與導覽連結，要指向新 URL。
站內搜尋索引與 feed 若存在，也要一起重建。
外部常用入口，例如電子報封存頁、社群個人檔案、Google 商家、合作夥伴介紹頁，應逐步更新重要連結。

Google sitemap 文件說明，sitemap 可提供頁面、圖片與更新等資訊，協助搜尋系統更有效率理解重要內容。但 sitemap 不是替代內鏈的工具。重要頁面仍應從導覽、hub、文章與相關頁面被自然連到。

如果一篇文章只在 sitemap 裡出現，站內沒有任何語境連到它，讀者和搜尋系統都比較難判斷它在整站知識架構中的角色。

上線後 14 天的檢查節奏

改版上線後，不要只看首頁是否正常。建議用 14 天做第一輪收斂。

時間	檢查重點	目的
上線前 24 小時	URL 命運表、redirect、canonical、schema、sitemap、OG 圖	先排除明顯錯誤
上線當天	首頁、hub、前 20 個重要頁、舊 URL 轉址、表單 CTA	確認讀者主要路徑不中斷
第 1 到 3 天	Search Console 抽查、404、redirect 鏈、sitemap 提交狀態	找出搬移初期技術問題
第 4 到 7 天	重要內容頁的標題、摘要、schema、FAQ、圖片是否一致	防止新 CMS 範本造成批量錯誤
第 8 到 14 天	搜尋查詢、站內行為、客服與業務回報	檢查是否出現誤讀、錯連或錯誤期待

Google Search Console 的 URL Inspection 工具可用來查看特定頁面的索引與檢查資訊，也可測試 live URL。若只是少量重要頁面需要請求重新抓取，可以依官方 recrawl 文件使用 URL Inspection；但反覆提交同一 URL 不會讓抓取更快，應把力氣放在修正內容與技術問題。

這段時間最重要的指標不是短期流量起伏，而是錯誤是否逐步減少：

舊重要 URL 是否不再 404。
redirect 是否導向相符頁面。
新頁 canonical 是否正確。
重要頁是否有可解析的 Article 與 BreadcrumbList schema。
有 FAQ 的頁面是否同步 FAQPage schema。
OG 圖是否存在且代表該頁。
sitemap 是否收錄新正式 URL。
內部 hub 與延伸閱讀是否指向新 URL。

遷移工作表範例

內容團隊可以先用這張簡化表開始，不必等完整專案管理系統上線。

舊 URL	新 URL	頁型	處理	必查訊號	Owner	上線後狀態
/old-ai-faq	/ai-customer-service-faq	FAQ	搬移	redirect、FAQ schema、canonical	內容 + 工程	待測
/case-2024-a	/cases/manufacturing-ai-support	案例	重寫	案例限制、Article schema、OG 圖	行銷 + 業務	待審
/pricing	/consulting-plans	價格	合併	價格邊界、CTA、更新日期	產品 + 法務	待確認
/blog/ai-tools-old	/ai-tools-selection-guide	文章	更新	title、內鏈、sitemap	內容	待發布

每一列都要有 owner。沒有 owner 的頁面，在改版時最容易變成「大家以為別人會處理」。

對中小企業來說，最務實的做法是先處理三類頁面：

目前有搜尋曝光、外部連結或業務常引用的頁面。
涉及價格、政策、案例、服務範圍、表單承諾的高風險頁面。
主題 hub、首頁導覽、文章總覽與主要 CTA。

其他長尾內容可以分批處理，但不要在沒有 redirect、沒有 noindex 判斷、沒有 sitemap 清理的情況下直接刪除。

參考來源與資料時間

資料時間：2026-08-27。網站遷移、redirect、sitemap、結構化資料、AI 搜尋功能與 Search Console 介面可能更新，請以官方最新文件為準。

本文依下列官方文件整理，並只提供內容治理與改版檢查框架，不承諾搜尋排名、AI 引用、流量、詢問量或商業成果：

常見問題

Q1：網站改版後搜尋流量都會下降嗎？

未必。流量可能受 URL、內容品質、redirect、內鏈、技術結構、競爭內容與搜尋系統重新理解時間影響。比較務實的目標不是承諾不波動，而是避免可預防的錯誤，例如 404、錯誤 canonical、舊 schema、錯圖與 sitemap 不同步。

Q2：如果舊文章很多，可以全部導到新文章總覽嗎？

不建議。只有在總覽頁真的能承接舊頁意圖時才合理。若舊頁有明確主題，應優先導到最接近的新文章、服務頁或主題 hub。大量導回首頁或總覽，通常會讓讀者找不到原本要看的答案。

Q3：換 CMS 時，FAQ schema 可以先保留嗎？

只有新頁面仍有相同 FAQ，且答案與可見內容一致時才保留。若 FAQ 已刪除、改寫或移到其他頁，schema 也要同步更新。不要讓結構化資料比正文更舊或更強。

Q4：sitemap 提交後，就代表 Google 會收錄新頁嗎？

不代表。sitemap 能協助搜尋系統發現重要 URL，但不等於抓取或索引。新頁仍需要清楚內容、正常 HTTP 狀態、合理內鏈、正確 canonical 與可被抓取的技術結構。

Q5：改版後多久要看成效？

上線當天先看技術錯誤與主要路徑，第 1 到 14 天看 redirect、404、schema、sitemap 與重要頁狀態。搜尋表現可持續觀察，但不要只用幾天流量判斷成敗，先確認可控的內容與技術訊號是否正確。