搜尋觀點
搬站後怎樣用 Search Console 判斷 canonical 重評估？
搬站後不必每天搜尋品牌名。以代表 URL 分組追蹤，才看得出 Google 是否正在正確重新處理。
網站遷移後，首頁先被找到並不代表所有服務頁、文章、分類頁和舊網址已經處理完畢。Google 會按自己的抓取與處理節奏逐步重訪不同 URL；因此 Search Console 最有價值的地方，不是提供一個「搬站完成」按鈕，而是讓團隊以證據判斷哪一類頁面仍有阻塞。
建立樣本：不要把 500 條網址混成一個問題
先挑選 20 至 40 條代表 URL，按頁型分組。每一組應包含舊 URL 和它應到達的新 URL：
- 首頁與核心服務頁：最直接影響品牌與商業查詢。
- 既有流量或外部連結較多的文章：最需要確認歷史訊號能否承接。
- 分類、產品集合或地區頁：最容易出現 pagination、篩選和內容重複。
- 中英日對應頁：同時確認 canonical、hreflang 和語言切換。
用同一張表記錄「使用者宣告 canonical」「Google 選擇 canonical」「最後抓取日期」「索引狀態」「sitemap 是否列出」「上一個動作」。這比只截圖一兩條 URL 更能看出模式。
URL Inspection 要看哪幾個欄位？
Google 選擇的 canonical
這是判斷的核心。若你的 self-canonical 與 Google 選擇一致，並且 URL 已被索引，通常不需再幹預。若兩者不同，回到頁面、redirect、sitemap 和內鏈查找衝突，不要只重送同一條 URL。
最後抓取日期
最後抓取很早，代表 Google 可能尚未看到新設定；此時先確認 robots、伺服器回應與 sitemap 可讀，再給處理一些時間。若抓取很新但 canonical 仍錯，才更可能是訊號品質或內容相似度問題。
索引狀態與偵測 URL
「未編入索引」不必然等於錯誤。重要的是它屬於甚麼原因：redirect、duplicate、soft 404、noindex，還是尚未發現。把原因和頁型放在一起看，才不會把一個正常的舊 URL 301 當成事故。
何時可以要求重新建立索引？
請求重新建立索引適合用於已完成修正、商業價值高、且 Google 已可正常讀取的新 URL。它不是替代 redirect、canonical 或 sitemap 的修復手段，也不應在每天微調 metadata 後反覆使用。先讓 URL 訊號完全一致，再選少量代表頁提交，較能避免團隊把「已按按鈕」誤當成「問題已解決」。
把索引訊號接回真實網站成效
搬站初期可同時看兩層資料：技術層看有效索引、canonical 與 crawl error；業務層看核心服務頁 impressions、clicks、品牌詞、表單和 WhatsApp 詢盤來源。若技術狀態已穩定但詢盤下跌，問題可能在內容承接或首屏定位；若流量正常但重要舊 URL 大量 404，則要回到 URL 對照與 redirect 規則。
這種分層能避免一個常見錯誤：把任何流量波動都歸咎於 canonical。Search Console 是檢查實際搜尋處理結果的工具，不是單獨解釋所有商業結果的儀錶板。
完成樣本檢查後，可回看 Canonical 修改後的正確等待與覆核節奏；若發現 redirect 或 sitemap 訊號相反，請按 URL 訊號衝突檢查方法 逐欄修正。若要安排代表 URL、服務頁與內容更新先後次序，也可一併參考 Google SEO 首 90 日優先次序 與 Google 搜尋 SEO 服務入口。也可使用 Fennec SEO Audit 整理樣本、技術問題與修正紀錄，或由 YUSIHK 協助進行 SEO 技術診斷。