「替代網頁（已正確設定標準網址標籤）」並非 SEO 錯誤，而是代表這個網址透過 canonical 標籤，正確指向另一個頁面作為主要版本，而 Google 也認同並採用了這個設定，因此這個網址本身不會被索引，索引權重會集中在標準網址上。
什麼是「替代網頁（已正確設定標準網址標籤）」？
假設網站存在兩個網址：
https://example.com/product/shoes
https://example.com/product/shoes?source=facebook
兩個網址顯示的主要內容幾乎完全相同。
第二個網址的 HTML <head> 中設定：
<link rel="canonical" href="https://example.com/product/shoes">
這等於向 Google 表示：
「雖然目前這個網址可以正常存取，但真正希望你視為主要版本的是 https://example.com/product/shoes。」
Google 在處理這組網址後，如果接受這個 canonical 關係，就可能選擇 /product/shoes 為標準網址，並為該頁建立索引。
至於 /product/shoes?source=facebook 則會被視為替代或重複網址，而不會被單獨建立索引。於是第二個網址便可能在 Search Console 中出現：「替代網頁（已正確設定標準網址標籤）」
Google 的 canonicalization（標準化）本質上就是從一組相同或高度相似的網址中選擇一個具有代表性的網址。Google 通常只需要讓代表版本出現在搜尋結果中，而不必讓每個重複網址都成為獨立搜尋結果。
為什麼 Search Console 顯示「未建立索引」？
很多網站管理員可能看到「網頁未建立索引」時，就會下意識以為網站的「SEO 出問題了。」。但其實「未建立索引」只是描述結果，並不等於發生錯誤。
Google 也明確指出，重複網址通常不會出現在搜尋結果中。Google 會先將內容高度相似或完全重複的網址歸為同一組（Cluster），再從中選出一個作為代表版本收錄到索引，其餘則歸類為替代版本。
canonical 標籤是你向 Google 提供的強烈訊號，但並非絕對指令——Google 還會綜合考量重新導向、內部連結指向、Sitemap 收錄，以及各版本內容的實際相似度，才做出最終判斷。
哪些情況容易出現這個索引狀態？
1. URL 追蹤參數
最常見的例子是帶有追蹤參數（如 UTM）的網址，這種情況一般建議將canonical 指向乾淨版本。
例如：
/product/a
/product/a?utm_source=google
/product/a?utm_source=facebook
/product/a?campaign=summer
如果內容相同，理想狀況通常是參數版本 canonical 到：
/product/a
2. 排序與篩選參數
在電商網站中，同一產品有多個網址變體（如不同排序參數），這種情況最好並以canonical 統一指向主要版本。
/category/shoes
/category/shoes?sort=price
/category/shoes?sort=newest
/category/shoes?view=grid
如果這些網址並沒有真正不同的搜尋價值，就可能設定相同 canonical。
但假如每一頁都有獨特產品集合、標題、文案，而且分別對應不同搜尋需求，例如「紅色鞋」、「男裝鞋」、「跑鞋」等，那麼它們可能本來就應該成為獨立 landing page。如果全部 canonical 到 /shoes/，反而可能犧牲有價值的 SEO 頁面。
假設：
/shoes/?color=red
/shoes/?gender=men
/shoes/?type=running
在這些情況下，如果這些子頁面具有可觀的搜尋流量，最好將 canonical 指向自身。
3. HTTP 與 HTTPS
現代網站通常應統一使用 HTTPS，避免 HTTP 與 HTTPS 版本同時可以正常存取。
例如：
http://example.com/page
https://example.com/page
對 Google 而言，這是兩個不同的 URL。如果兩者都回傳 200 OK 並顯示相同內容，Google 就需要判斷哪一個才是主要版本。
雖然可以透過 Canonical 指定 HTTPS：
<link rel="canonical" href="https://example.com/page">
但如果網站已經全面採用 HTTPS，更建議直接使用 301 Redirect，將 HTTP 永久重新導向 HTTPS。
同時應確保 Canonical、內部連結與 XML Sitemap 都使用 HTTPS。如此可以讓所有訊號保持一致，也避免網站長期存在兩套可存取的 URL。
4. www 與非 www
以下兩個網址同樣屬於不同 URL：
https://www.example.com/page
https://example.com/page
網站通常應選擇其中一種 hostname 作為統一版本，例如：
主要版本：
https://example.com/page
那麼：
https://www.example.com/page （301 重定向）→ https://example.com/page
如果選擇 www 作為主要版本，方向則相反。
這種情況同樣更適合使用 301 Redirect，而不是只依賴 Canonical。因為網站通常沒有必要讓 www 與非 www 兩個版本長期同時提供相同內容。
設定完成後，也應同步統一：
- Canonical URL
- 內部連結
- XML Sitemap
- hreflang（如有）
- HTTP → HTTPS 規則
最終最好讓所有網址訊號都指向同一個 hostname。
5. 尾斜線
以下兩個 URL 看起來非常相似：
https://example.com/product
https://example.com/product/
但對伺服器與搜尋引擎而言，它們可能是兩個不同的 URL。
如果：
/product → 200 OK
/product/ → 200 OK
而且兩者顯示完全相同的內容，就可能產生重複網址。
網站應建立一致的尾斜線規則，有無結尾斜線分別不大，重點是全站保持一致。
與 HTTP／HTTPS、www／非 www 一樣，如果兩個 URL 實際上只是同一頁的不同寫法，通常使用 301 Redirect 統一 URL 會比單純設定 Canonical 更乾淨。
6. AMP 或手機版本
Google 官方在這個 Search Console 狀態的說明中，也特別以 AMP、行動版與電腦版之間的替代關係作為例子。
例如：
https://example.com/article
https://example.com/article/amp
AMP 版本可能 canonical 回普通版本。
7. Session ID 或系統參數
例如：
/product/123
/product/123?sessionid=abc123
部份 CMS、舊式電商平台或客製化系統可能產生大量此類網址。
Canonical 可以協助搜尋引擎理解哪一個才是主要 URL，但更理想的做法通常還包括從網站架構源頭控制不必要的 URL 產生。
替代網頁（已正確設定標準網址標籤）需要處理嗎？
我們建議定期確認標準網址確實指向你希望被索引的版本，避免誤設。在檢查帶有這類索引狀態的網址時，最好先判斷頁面的 Canonical 指向哪一個頁面，並確認是否是你真正希望排名的網址。
例如 /product/shoes?utm_source=facebook 的 canonical 並設定為 /product/shoes
如果 /product/shoes 就是你希望 Google 索引的版本，那麼你就不必為了讓參數 URL 變成「已建立索引」而修改 canonical。
這是完全正常的技術行為，代表你的 canonical 標籤設定正確，通常毋須任何處理。
不過，如果網址的 canonical 被設定為 /product/shoes?utm_source=facebook ，那你就需要檢查網站是否有技術問題。
什麼情況反而需要處理？
假設你希望頁面有獨立排名，但 Search Console 顯示它是「替代網頁（已正確設定標準網址標籤）」
那麼，通常問題都是源自網站的 canonical 設定了其他網址作為主要版本，那麼你需要重新評估 canonical 的設定邏輯，例如檢查是否將所有分類頁面都誤指向首頁。
最常見的情況是：
- 大量不同產品都 Canonical 到分類首頁
- 重要 SEO Landing Page 被當成替代頁
- Canonical 指錯頁
例如：
/product/red-shoes
卻設定：
<link rel="canonical" href="https://example.com/product/blue-shoes">
如果紅鞋與藍鞋本來就是不同商品，這個 canonical 就可能不合理。
Google 可能因此將其中一頁視為另一頁的重複版本。
設定 Canonical URL 注意事項
設定 Canonical 時，不應只檢查 <link rel="canonical"> 本身。Google 會綜合 Canonical、Redirect、內部連結、Sitemap 等訊號判斷主要版本，因此網站的 URL 訊號最好保持一致。
1. 該使用 301 Redirect 時，不要只依賴 Canonical
如果替代 URL 沒有必要繼續讓使用者獨立存取，優先考慮 301 Redirect；如果多個 URL 有合理存在的需求，但內容相同或高度相似，再考慮 Canonical。
因此，以下情況通常較適合 301：
- HTTP → HTTPS
- www → non-www（或反向）
- /page → /page/（或反向）
- 舊 URL → 新 URL
而 Canonical 更常用於仍有理由存在的 URL 變體，例如：
- /product
- /product?utm_source=facebook
- /product?ref=email
301 是將 URL 真正統一；Canonical 則是在多個仍然存在的 URL 中指定偏好的代表版本。
2. 內部連結直接指向 Canonical URL
假設主要版本是：
https://example.com/product
但網站導航、文章及產品推薦大量連結到：
https://example.com/product?ref=nav
即使參數版本正確 Canonical 回 /product，這種架構仍然不理想。
內部連結應盡可能直接使用：
https://example.com/product
而不是依賴 Google 不斷整理網站自己產生的 URL 變體。
3. XML Sitemap 只提交主要版本
Sitemap 應優先提交希望 Google 建立索引的 Canonical URL。
例如：
參數版本：https://example.com/product?tracking=123
Canonical：https://example.com/product
Sitemap 應提交：
<loc>https://example.com/product</loc>
而不是持續提交參數版本。
4. 多語言網站不要把 Canonical 與 hreflang 混為一談
如果三個頁面分別提供完整的英文、繁體中文與日文內容，它們通常都是具有獨立價值的語言版本，而不是單純的重複 URL。合理的網站架構是各語言頁使用適當的 Canonical，再透過 hreflang 表達語言／地區關係。
假設網站有 /en/product、/zh-hk/product、/ja/product，你不應只是把所有語言版本 Canonical 到英文頁，而是應採用自我指向標準網址（Self-referencing canonical）。
5. 讓所有 Canonical 訊號保持一致
假設真正希望排名的是：
https://example.com/product
理想狀態是：
- Canonical → https://example.com/product
- Sitemap → https://example.com/product
- Internal Links → https://example.com/product
- HTTPS → https://example.com/product
- Preferred Host → https://example.com/product
避免出現：
- Canonical → /product
- Sitemap → /product?id=123
- Internal Links → /product?ref=nav
- Redirect → /products/product
雖然 Google 可以處理部分不一致的訊號，但網站沒有必要增加搜尋引擎判斷主要 URL 的難度。
常見問題 FAQ
「替代網頁（已正確設定標準網址標籤）」需要修正嗎？
通常不需要。如果替代 URL 正確指向你希望 Google 索引的 Canonical URL，這通常代表設定正在正常運作。
修正後多久才會改變？
即使內容問題已修正，Google 仍可能在一段時間內將頁面保留於原有的重複內容群組中。重新評估可能需要最多約兩週，而內容差異越明顯，頁面通常越容易被重新區分。
每個頁面都應該設定 Self-Canonical 嗎？
通常是良好的做法，但不能用來取代完整的 URL 標準化策略。例如網站產生大量參數 URL 時，不能只是讓每個參數頁全部 Self-Canonical，而不考慮它們是否其實是同一內容的不同網址。
Google 一定會接受我設定的 Canonical 嗎？
不一定。Canonical 雖然是重要訊號，但 Google 最終仍會自行判斷代表 URL。因此，建議讓網站的所有 Canonical 訊號保持一致，使 Google 更容易判斷哪頁才是主要版本。
關於作者
