症狀：你設了 Canonical，但 Google 沒在聽
即使你在 HTML head 中正確放入了 rel=canonical 標籤，Google 仍可能選擇索引一個完全不同的頁面版本。這是最常見的技術 SEO 困惑之一：你明確告訴 Google「請用這個 URL」，但 GSC 的索引報告或排名結果卻顯示另一個 URL 才是主角。常見症狀可能包括：GSC 中索引了帶有追蹤參數、www 與非 www 版本、或 HTTP 版本的 URL，而不是你設定的 canonical 版本；或者，你期望獲得排名的頁面，其搜尋結果顯示的網址與你預期的不符。在這種情況下，第一步不是檢查標籤語法是否錯誤，而是進入診斷流程，了解 Google 為何忽略你的「提示」。
診斷第一步：用 GSC 的「URL 檢查」確認 Google 的視角
打開 Google Search Console，使用「網址審查」工具貼上你想確認的頁面 URL，這裡的資訊是所有診斷的起點。在工具載入的報告中，找到「索引涵蓋範圍」區塊，重點觀察兩個欄位：「使用者宣告的規範網址」顯示你 HTML 中設定的 canonical 目標；「Google 選取的標準網址」則顯示 Google 實際採用的版本。如果兩者一致，代表你的設定被接受了。如果不一致，這就是問題的核心：Google 有足夠的理由，根據它自己的判斷，選擇了另一個版本作為標準。接下來的所有排查，都圍繞著「為什麼 Google 的判斷與你的設定不同」這個問題展開。
常見原因與排查：為何 Google 會忽略你的 Canonical
Google 忽略 canonical 標籤通常有四大類原因，每種原因對應不同的平台排查方法。首先，檢查你設定的 canonical 目標 URL 本身是否健康。在台灣主機或平台上，常見的失誤是目標 URL 被 noindex 標籤封鎖，或被 robots.txt 擋住了爬蟲存取。例如，WordPress 站長在安裝某些安全或優化外掛時，可能不慎對分類頁或標籤頁啟用了 noindex，卻忘了 canonical 還指向這些頁面。你可以直接在瀏覽器輸入 canonical 目標 URL 存取測試，同時在 GSC 的 URL 檢查工具中查看「已抓取的頁面」部分，確認 Googlebot 是否被允許存取。
其次，canonical 目標 URL 返回的 HTTP 狀態碼非 200 OK。如果目標 URL 返回 404 或 410，Google 無法找到有效內容來合併；如果是 301 或 302，這本身就構成了一個重定向信號，可能讓 Google 選擇最終目的地作為標準。舉一個匿名的台灣電商案例：一家服飾店為每個產品顏色設置了獨立 URL（如 /product/shirt?color=red），並將所有顏色版本的 canonical 指向主產品頁（/product/shirt）。然而，由於後台設定疏失，主產品頁在某一時期被暫時設定為「維修中」的 503 狀態。在此期間，Googlebot 爬取時發現 canonical 指向一個不可用的 URL，於是自行選擇了帶有 ?color=red 參數的版本作為標準網址，導致流量和權重分散。
第三，內容差異過大。即使 canonical 標籤指向的 URL 可以存取，但如果兩個頁面之間的可見內容差異過大，Google 可能判定 canonical 設定不當，並執行自己的規範化邏輯。這在自架網站使用不同模板呈現相同資料庫內容時可能發生。第四，多個互相衝突的 canonical 設定。例如，一個頁面在 HTML head 中設定 canonical 指向 A URL，但在伺服器回應的 HTTP header 中又透過 Link 標頭設定指向 B URL，這種矛盾會讓 Google 陷入困惑。檢查時，除了檢視頁面原始碼的 <head> 區塊，也應使用瀏覽器開發者工具查看網路請求的回應標頭。
修復與驗證：確保 Google 採用你的 Canonical 設定
根據上述診斷結果進行針對性修復，並透過 GSC 強制 Google 重新評估你的頁面。如果問題是 noindex 或 robots.txt，請立即移除相關封鎖設定。如果 canonical 目標 URL 狀態異常，請修正使其返回 200 狀態碼。如果是內容差異問題，則需要重新評估是否真的適合使用 canonical，或改用 301 轉址更為恰當。修復完成後，必須回到 GSC 的「網址審查」工具，對你設定的 canonical 目標 URL 點擊「要求建立索引」。此操作會強制 Googlebot 訪問頁面並重新處理其規範化信號。同時，建議前往 GSC 的「涵蓋範圍」報告，篩選「已提交的網址」或「所有已知的網址」，觀察之前因 canonical 問題可能顯示為「已探索-目前已未建立索引」的 URL，其狀態是否在修復後逐漸轉為「已建立索引」。
這是一個建立主題權威的關鍵節點：當你的頁面因為 noindex 被忽略時，你應該去檢查 noindex 標籤的正確用法；當爬蟲被 robots.txt 擋住時，你需要理解 robots.txt 的正確設定。此外，確認所有正確的規範網址都已包含在你的 Sitemap XML 中，這能主動引導 Google 發現並索引正確的版本。
最佳實踐：什麼時候該用 Canonical？什麼時候該用 301？
Canonical 標籤與 301 轉址處理重複內容，但機制與適用場景截然不同，選錯會讓後續調整困難。簡單來說，301 轉址是 HTTP 層級的「永久搬遷」指令，伺服器直接告知瀏覽器和爬蟲「這個地址已永久棄用，請去新地址」，舊 URL 會從使用者體驗和索引庫中逐漸消失，連結權重的傳遞更為集中和可靠。Canonical 標籤則是 HTML 層級的「提示」，它讓多個 URL 都可以被訪問，只是建議 Google 將排名信號集中到其中一個，其效果取決於 Google 是否採納這個建議。
因此，決策框架非常清晰：當一個 URL 永久不需要存在（例如舊版網址、錯誤拼寫的網址），請使用 301 轉址。當多個 URL 代表相同的內容，但出於使用者追蹤、A/B 測試或電商顏色/尺寸選擇等原因必須保留時，使用 canonical 標籤。例如，帶有 ?utm_source=... 追蹤參數的 URL 適合用 canonical 指向原始乾淨版本；而一個已經退役的產品頁面，則應該 301 轉址到分類頁或相似產品頁，而非僅設定 canonical。正確選擇能讓你的 爬取預算 得到最有效的利用，避免 Googlebot 在無意義的重複版本上浪費資源。
平台設定指南：WordPress、Shopify 與自建站的實務細節
不同網站平台設定 canonical 的方式與常見陷阱各有不同，台灣網站主需針對自身架構注意。在 WordPress 生態系中，使用 Yoast SEO 或 Rank Math 等 SEO 外掛通常是最直接的方式，它們一般在每個頁面的編輯後台提供「標準網址」欄位。需注意的是，確保外掛設定沒有被其他程式碼片段或佈景主題的 wp_head 輸出覆蓋。一個常見陷阱是使用頁面編輯器（如 Elementor）建立的內容，在某些佈景主題下可能無法正確繼承外掛設定的 canonical。
Shopify 平台會自動為產品頁、集合頁等生成 self-canonical（指向自身的 canonical），這通常無需手動修改。然而，當使用某些產生額外 URL 參數的 app 時（例如追蹤 app 或篩選 app），可能產生非預期的重複版本。此時應檢查這些 app 產生的 URL 是否被正確排除在索引之外（透過 noindex 或直接禁止爬取），而非錯誤地指向一個可能無效的 canonical 目標。對於自建站或使用特定 CMS（如台灣常見的 Webnode、Wix 或本地化電商系統），必須直接檢查頁面模板的 <head> 區塊。如果動態生成 canonical，務必確認在所有頁面類型（首頁、商品列表、商品詳情、文章）中，邏輯都正確無誤，特別是處理 URL 參數或分頁時。
常見設定錯誤快速自診
最後，提供一個快速自診清單，如果你遇到 canonical 無效，請優先檢查以下錯誤：所有頁面的 canonical 都指向首頁（這是 CMS 模板錯誤的典型症狀）；canonical 目標 URL 是 404 或被 noindex 擋住；形成了 canonical 鏈（A 指向 B，B 指向 C）；或者，你在 HTML head 和 HTTP header 中設定了不同的 canonical URL。修正這些基本錯誤，通常是解決問題的第一步，也是最重要的一步。