canonical 標籤設錯時會發生什麼事

canonical 標籤不是重複內容橡皮擦

canonical 標籤會告訴搜尋引擎，當多個 URL 含有相同或高度相似的內容時，你偏好的 URL 是哪一個。常見的 HTML 版本如下：

<link rel="canonical" href="https://example.com/preferred-page/">

也有 HTTP header 版本，主要適用於 PDF 這類非 HTML 檔案：

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

聽起來很簡單。問題通常從團隊把 canonical 標籤當成安全整理各種麻煩情境的方式開始：多層篩選導覽、追蹤參數、列印頁、近似重複的產品頁、分頁、staging URLs，以及舊活動頁。

canonical 標籤不是刪除按鈕。它不是重新導向。它不能取代資訊架構。而且它也不保證會被遵循。

搜尋引擎會把 canonicals 視為強烈提示。它們會將 canonical 標籤與其他訊號比較：重新導向、內部連結、sitemap URLs、hreflang annotations、內容相似度、HTTP status codes，以及使用者和爬蟲實際遇到的 URLs。如果這些訊號彼此衝突，搜尋引擎可能會忽略你的 canonical，或直接選擇另一個 canonical URL。

這就是為什麼 canonical 設錯時會如此令人困惑。瀏覽器裡的標記看起來正確，但錯誤的頁面卻出現在搜尋結果中——或者正確的頁面消失了。

canonical 指向錯誤 URL 時會發生什麼

當搜尋引擎看到重複或近似重複的 URLs 時，通常會把它們分成一個群組，並選出一個 URL 作為 canonical。被選中的 canonical 是最可能被索引並顯示在搜尋結果中的版本。來自重複頁面的訊號可能會被整合到這個被選中的 URL。

如果你的 canonical 標籤指向錯誤頁面，可能會發生幾種情況。

1. 錯誤的 URL 被索引

假設你有兩個 URLs：

• /mens-running-shoes/
• /sale/mens-running-shoes/

如果特價頁面的 canonical 指向主要分類頁，而內容幾乎相同，且特價 URL 只是篩選後的版本，那可能沒問題。但如果特價頁面有獨特文案、獨特商品，以及自己的搜尋需求，canonical 就可能壓制它。

這個頁面仍可能被爬取。使用者也仍可能存取它。但搜尋引擎可能會決定不單獨索引它，因為你告訴它們另一個 URL 才是偏好的版本。

這是最常見的 canonical 失誤：不是戲劇性的技術故障，而是安靜地從索引中消失。

2. 排名訊號整合到錯誤的位置

canonicals 常用來整合連結與重複內容變體等訊號。當重複頁面確實等價時，這很有用。當它們不等價時，這就有風險。

如果一篇部落格文章有這類追蹤 URLs：

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

那麼把兩者都 canonical 到 /guide-to-canonical-tags/ 是合理的。

但如果西班牙文版本、含有額外內容的列印版本，或具備不同意圖的產品變體都指向同一個 canonical，你可能正在合併本應分開保留的訊號。結果可能是所有頁面的相關性都變弱。

canonical 標籤談的是等價性。如果兩個頁面滿足不同搜尋意圖，它們大概不應該互相 canonical。

3. 搜尋引擎忽略該標籤

canonical 不是命令。如果 canonical 目標會重新導向、回傳 404、被封鎖、帶有 noindex，或包含非常不同的內容，搜尋引擎可能會忽略它。

某種程度上這是好事：錯誤的 canonical 不一定總是摧毀索引。但這也表示你不能假設該標籤正在做你以為的事。一個頁面可以宣告某個 canonical，而 Google 選擇另一個。

當內部連結、sitemaps 和 canonicals 意見不一致時，這尤其常見。如果每個內部連結都指向 /product，你的 sitemap 列出 /product/，而你的 canonical 指向 https://www.example.com/product?ref=main，你就在自己的訊號之間製造了一場小爭論。

搜尋引擎很擅長解決這場爭論。它們不一定擅長用你原本預期的方式來解決。

4. 除錯變得不必要地困難

錯誤的 canonicals 很少大聲失敗。它們產生的症狀看起來像其他 SEO 問題：

• “Discovered, currently not indexed” 或類似的索引停滯狀態
• 錯誤的 URL 針對某個查詢取得排名
• 參數 URLs 出現在報表中
• 分類頁明明可爬取卻沒有出現
• 國際頁面被折疊到錯誤的語言版本
• 新範本上線後，被索引的頁面少於預期

這就是為什麼 canonical 除錯應包含原始 HTML、渲染後 HTML、HTTP headers、重新導向，以及 sitemap entries。如果你已經在調查 redirect chains 或不一致的 headers，同樣的習慣也適用；像我們的 production 環境中重新導向與 HTTP headers 除錯小工具指南這樣的實用 HTTP 檢查流程，通常能比盯著 CMS 欄位更快抓到 canonical 矛盾。

代價最高的 canonical 錯誤

把所有頁面 canonical 到首頁

這仍然會發生。範本欄位被留空、plugin 回退到網站根目錄，然後突然間數百個頁面都宣告首頁是 canonical。

搜尋引擎可能會忽略這點，因為內容明顯不同。但如果足夠多的訊號都很混亂，有些頁面可能會被捨棄或被錯誤分群。至少，你是在每個頁面上送出無用且自相矛盾的提示。

首頁幾乎從來不是內部頁面的 canonical。

把分頁頁面 canonical 到第一頁

長久以來，有些網站會把 /category/page/2/、/page/3/ 等頁面 canonical 回第一頁。用意是避免重複的分類頁。

問題在於，分頁頁面不是重複頁面。它們包含不同項目，並協助爬蟲發現更深層的內容。把它們全部 canonical 到第一頁，可能會降低搜尋引擎完整處理後續頁面的機會。

通常，分頁頁面應該使用 self-referencing canonicals，除非有特定理由要整合。

沒檢查搜尋意圖就 canonical 篩選頁

多層篩選導覽會帶來困難選擇。有些篩選 URLs 是垃圾：

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

其他則可能是有價值的 landing pages：

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

一刀切的 canonical 規則，常常會把有用的搜尋頁與無用的參數噪音一起抹掉。在 canonical 篩選頁之前，先問問該篩選頁是否有穩定內容、內部連結、搜尋需求，以及明確的使用者需求。

如果答案是肯定的，它可能值得被索引，並使用 self-referencing canonical。

把 canonicals 指向重新導向或被封鎖的 URLs

canonical 目標應該乾淨、可索引，並回傳 200 OK。不要把 canonicals 指向會重新導向、回傳錯誤、需要 cookies、被 robots.txt 封鎖，或帶有 noindex 的 URLs。

這是最容易自動化的檢查之一。爬取你的網站，並標記沒有回傳乾淨 200 response 的 canonical targets。

把 canonical 和 noindex 混用，好像它們意思相同

rel="canonical" 和 noindex 解決的是不同問題。

當存在重複頁面，而你希望訊號整合到偏好的 URL 時，使用 canonical。當你完全不希望某頁被索引時，使用 noindex。

兩者一起使用會送出尷尬訊息：「不要索引這個頁面，但也請把它當作另一個頁面的重複訊號。」搜尋引擎通常能繞過這點，但這不是乾淨的指示。如果某頁是重複頁面，就 canonical 它。如果它不應該出現在搜尋中，且沒有有用的重複關係，請考慮 noindex。

實用的 canonical 稽核

你不需要大型 SEO 平台，也能找出許多 canonical 問題。從一次爬取、幾個 URL 樣本，以及一份試算表開始。

針對每個重要範本，檢查：

1. 頁面是否正好有一個 canonical 標籤？ 多個 canonical 標籤會造成模糊。
2. canonical 是否為絕對 URL？ 使用完整 URL，包含 protocol 和 hostname。
3. canonical 目標是否回傳 200 OK？ 避免重新導向、被封鎖或出錯的目標。
4. canonical 目標是否可索引？ 沒有 noindex、沒有 robots 封鎖、沒有身份驗證要求。
5. 內容是否真正等價？ 相似不一定等於等價。
6. 內部連結是否一致？ 盡可能連到 canonical URL 格式。
7. sitemap 是否一致？ sitemaps 通常應列出 canonical、可索引的 URLs。
8. hreflang tags 是否一致？ 國際頁面需要一致的 canonical 與 hreflang 關係。
9. 渲染後 HTML 是否與原始 HTML 相符？ JavaScript 可能會變更或注入標籤。
10. 搜尋引擎選擇了哪個 canonical？ 檢查工具可以揭示你宣告的 canonical 與被選中的 canonical 何時不同。

這也是 Lighthouse 可以派上用場的地方，但只能在其限制內。它可以標記部分可爬取性與文件問題，但它不了解你的商業意圖或 canonical 策略。把它視為一項輸入，而不是裁決。如果你需要更冷靜地把有用發現與噪音分開，請參考如何閱讀 Lighthouse report 而不恐慌。

self-referencing canonicals 通常是不錯的預設值

每個重要且可索引的頁面，通常都應該宣告自己為 canonical。這不是因為沒有該標籤搜尋引擎就無法判斷。而是因為當參數、追蹤連結、被複製的 URLs，以及 CMS 怪癖為同一內容建立替代路徑時，self-referencing canonicals 可以降低模糊性。

對於乾淨的產品頁，這通常是正確的：

<link rel="canonical" href="https://example.com/products/linen-shirt/">

對於追蹤 URL，canonical 通常應指回乾淨版本：

<link rel="canonical" href="https://example.com/products/linen-shirt/">

對於真正不同的產品變體，答案視情況而定。如果紅襯衫、藍襯衫、黑襯衫有相同描述，只有顏色不同，一個 canonical 產品頁可能就足夠。如果每個變體都有各自的需求、評論、圖片、庫存與內部連結，獨立可索引的頁面可能更合理。

產品變體沒有通用的 canonical 規則。只有一個問題：對搜尋者來說，這些頁面是否可以互換？

canonical 標籤應符合網站實際的 URL 政策

多數 canonical 錯誤都是更深層 URL 政策問題的症狀。網站尚未決定 trailing slashes 是否重要、uppercase URLs 是否應該解析、是否允許參數、HTTP 是否重新導向到 HTTPS，或 www 是否為 canonical。

為每個 URL 選定一個乾淨版本，並讓整個系統一致：

• 將非偏好的 URL 版本重新導向到偏好版本。
• 內部連結到偏好版本。
• 在 XML sitemaps 中放入偏好版本。
• 在偏好頁面上使用 self-referencing canonicals。
• 只將真正重複的頁面 canonical 到偏好 URL。

當所有這些訊號都指向同一方向時，canonical 標籤就會變得無聊。這正是目標。

重點結論

canonical 標籤很強大，因為它們會影響索引與訊號整合。它們也因同樣理由而危險。

錯誤的 canonical 不一定總是會讓頁面從搜尋中移除。搜尋引擎可能會忽略它。但仰賴搜尋引擎拯救糟糕訊號並不是策略。更安全的做法，是只把 canonicalization 用於真正的重複頁面，保持目標乾淨且可索引，並讓你的內部連結、重新導向、sitemaps 和 canonicals 說同一個故事。

canonicals 不是讓你藏起混亂架構的地方。它們是你確認架構已被整理乾淨的地方。