改版上線的前一天，流量通常還是正常的。上線後第三天，Search Console 開始出現警示——排名下滑、點擊減少、某些頁面直接從索引消失。這不是演算法更新造成的，而是改版本身缺少 SEO 的防護措施。
網站改版屬於高風險操作，風險不在設計美觀與否，而在 Google 已累積的索引資料、頁面評分、連結權重，能否平穩過渡到新架構。這篇整理的，是改版前必須備妥的項目，以及改版後如何用 Search Console（搜尋主控台）確認流量是否異常。
改版過程中最容易造成 SEO 損傷的操作，集中在幾個面向，包括：URL 結構改動、頁面標記遺失、內部連結錨點斷裂，以及 meta 欄位在搬移過程中消失或遭到覆寫。這些問題本身不難解決，難的是若未在改版前建立對照表，改版後才想補救，往往要耗費數倍時間。
301 轉址對照表改版前就要備妥
URL 改動是改版中對 SEO 影響最直接的操作。舊網址累積的反向連結（Backlink）與頁面評分，必須透過 301 永久轉址才能傳遞給新網址。若放置不理，等同於把過去所有 SEO 積累直接清空。
建立對照表的方式相當直觀。在改版前，先把現有網站所有可索引的 URL 全部匯出，再對應到新架構下的目標網址。匯出方法有幾個選項，可以用 Search Console 的「網址審查」功能逐頁確認，也可以用爬蟲工具（如 Screaming Frog）掃出完整的 URL 清單。對照表至少包含三欄：舊網址、新網址、轉址狀態。
對照表建好之後，有幾項細節值得特別確認。
- 高流量頁面優先處理：從 Search Console 的「成效」報告，篩出過去 3 個月點擊數排名前 20% 的頁面。這些頁面的 301 轉址必須在上線前測試完成，不能等上線後發現問題再補。
- 避免轉址鏈（Redirect Chain）：若舊站已有轉址規則，改版時不要疊加，要整理成「舊 URL → 最終新 URL」的直達設定。中間跳轉超過 2 層，Google 有機率不繼續追蹤。
- 404 頁面的處置方式：確認無對應新頁面的舊 URL 要如何處理。若有語意相近的頁面就轉過去；若真的沒有對應頁面，保留 404 狀態即可。不要將全部舊 URL 轉向首頁，Google 已明確表示此做法不會傳遞權重。
改版上線後，建議每天查看一次 Search Console 的「涵蓋範圍」報告，確認被排除的頁面數量沒有異常增加。
結構化資料的備份與遷移
結構化資料（Schema Markup）不出現在設計稿裡，多數人改版時不會特別留意，但它影響的是搜尋結果頁的呈現方式。評價星等、食譜步驟、活動日期、常見問題這類富媒體結果（Rich Results），背後都由結構化資料驅動。
改版前要做的，是把現有網站的結構化資料完整匯出，逐一確認類型與欄位。可以用 Google 的「豐富結果測試」（Rich Results Test）逐頁檢查，也可以直接查看頁面原始碼中的 <script type="application/ld+json"> 區塊。
遷移時有幾個細節需要注意。
- 外掛設定不會自動跟著搬移：若使用 Yoast SEO 或 Rank Math 之類的 SEO 外掛管理結構化資料，換主題或換外掛時，設定檔可能遺失，要提前匯出備份。
- 欄位覆寫的問題：部分主題或頁面建構器（Page Builder）本身也會輸出結構化資料。改版後若外掛與主題同時各自輸出，可能產生重複或衝突的標記，要用測試工具驗證。
- JSON-LD 比 Microdata 更易維護：若舊站使用嵌在 HTML 標籤裡的 Microdata 格式，改版時是整理成 JSON-LD 的好時機。集中在
<head>管理，後續修改也更便利。
改版上線後，用 Search Console 的「豐富結果狀態」報告監測是否出現錯誤或警告，通常異常會在 1 至 3 天內反映。
內鏈錨點的整理方法
內部連結（Internal Link）承擔兩項任務，一是引導爬蟲發現新頁面，二是傳遞頁面之間的主題相關性。改版最容易破壞內鏈的地方，是文章內直接寫入的舊網址，以及選單結構變動後形成的孤兒頁面（Orphan Page）。
錨點斷鏈清查
改版前，用爬蟲工具從首頁出發，把整站內部連結全部爬出來，記錄每條「來源頁面 → 目標網址 → 錨點文字」的對應關係。這份清單在改版後可直接比對，確認目標網址是否存在於新網址結構中，或已成為 404。
WordPress 站台可利用站內搜尋功能，直接搜尋舊網址字串，快速找出文章內文中寫入的舊連結。
選單與分類結構的更新
URL 改動通常伴隨分類結構調整。分類頁網址（如 /category/seo/）異動時，除了設定 301，還要確認所有文章的分類設定是否同步更新，避免文章歸類指向已不存在的分類。
選單連結要在上線前全部手動確認一遍，特別是側欄或頁尾的固定連結。這些位置的斷鏈最容易被忽略，但每個頁面都會出現。
孤兒頁面的處理
改版後若某些頁面沒有任何內部連結指向，爬蟲即便知道該 URL 存在，也會降低爬取頻率。整理方式是用 Search Console 的「網址審查」逐一確認重要頁面是否已被發現，或用 Screaming Frog 產出入鏈（Inlinks）報告，找出入鏈數為 0 的頁面，補上適當的內部連結。
meta 欄位的備份重點
這裡所指的 meta 欄位，主要涵蓋三類：標題標籤（Title Tag）、描述標籤（Meta Description），以及焦點關鍵字（Focus Keyword）設定。這些欄位通常儲存於 WordPress 的後台資料庫，而非靜態檔案。換主題或搬遷主機時，若未連同資料庫完整遷移，欄位內容就會消失。
備份時建議分兩層處理。
- 資料庫整包備份：用 UpdraftPlus 或 All-in-One WP Migration 備份整個資料庫，涵蓋外掛設定表（通常是
wp_options）和文章 meta 資料表（wp_postmeta）。這是最完整的方式，遷移失敗時可以還原。 - 逐頁欄位的 CSV 匯出：針對高流量頁面，另用 Screaming Frog 爬出現有的「Title Tag」與「Meta Description」內容，存成 CSV。萬一搬遷後外掛設定消失，這份清單可用來逐頁補回，不必從頭重寫。
此外，Open Graph 標籤（og:title、og:description、og:image）也屬於這個備份範圍。它影響的是社群媒體分享時的呈現方式。雖然不直接影響搜尋排名，但分享流量同樣重要，改版後最好確認這些欄位是否正常輸出。
URL 結構異動時如何評估風險
URL 結構異動分兩種情況，風險程度各異。
一種是「路徑格式改變」，例如把 /blog/post-name/ 改成 /post-name/，或把日期型結構 /2023/05/post-name/ 改成無日期型。這類改動影響範圍廣，每一篇文章的 URL 都會變動，是風險最高的操作，需要批次設定 301 轉址，且必須在上線後密切監測索引狀態。
另一種是「局部頁面改網址」，例如修改特定幾篇文章或落地頁的 slug，影響範圍較小。但仍需要補 301，並確認是否有反向連結指向舊網址，若有，主動通知對方更新，或至少確認轉址正常運作。
有一個常見的決策誤區，是認為「URL 改掉後 Google 會自動更新」。Google 確實會追蹤 301 並更新索引，但這個過程需要數週到數個月不等，期間舊網址的流量會中斷，排名也可能暫時下滑。改版前需要誠實評估，URL 結構改動帶來的效益，是否足以承受過渡期的流量損失。
如果現有 URL 結構本身沒有明顯的 SEO 問題，不建議在改版設計時同步調整 URL。把兩件事分開處理，可以大幅降低排查問題的難度。
設計大改後用 Search Console 驗證流量異常
設計大幅翻新時，有幾個 SEO 面向容易在無意間受到影響：頁面載入速度、行動裝置（Mobile）相容性、標題層級（H1–H6）的配置，以及內文可讀文字的比例。這些問題不需要等到排名下滑才去檢查，改版上線後立刻開啟 Search Console，按以下順序確認。
成效報告的基準比較
進入 Search Console 的「成效」報告，點擊「日期：過去 3 個月」，再切換到「比較」模式，對比改版前後相同日期區間的數據。重點查看三項指標——總點擊數、總曝光次數、平均排名。若點擊與曝光在上線後 7 至 14 天內跌幅超過 20%，需要立刻進入下一步檢查。
搜尋結果分析
「搜尋結果分析」頁面可按頁面篩選，找出掉點擊最多的前 10 個頁面，逐一用「網址審查」確認索引狀態、上次爬取時間、行動裝置可用性。若某頁面顯示「已排除——noindex 標籤」，表示改版時不慎將 noindex 設定啟用，需要立刻修正。
涵蓋範圍報告的錯誤追蹤
「涵蓋範圍」報告分四種狀態：有效、有效但有警告、已排除、發生錯誤。改版上線後，若「發生錯誤」的數字在一週內持續增加，優先排查三個方向——伺服器錯誤（5xx）、轉址錯誤（可能設定了轉址迴圈），以及被 robots.txt 意外封鎖的路徑。
核心網頁指標的監測
「核心網頁指標（Core Web Vitals）」報告呈現的是真實使用者的頁面體驗資料，指標包含最大內容繪製（LCP）、互動到下一次繪製（INP）、累計版面配置位移（CLS）三項。改版若大幅調整頁面設計或引入新的 JavaScript 函式庫，這三項指標可能在改版後 28 天內才反映完整資料。建議在這個視窗期保持每週查看一次，確認沒有新增的「需要改善」或「差」的頁面出現。