搜尋引擎選錯網址版本？比對宣告 canonical 與實際頁面

從同內容網址清單開始，對照頁面宣告、搜尋索引選取結果、內部連結與網站地圖，找出網址版本分歧的原因，並留下可複查的前後紀錄。

當搜尋結果顯示的網址和頁面宣告的 canonical 不同，問題不一定是標籤失效；搜尋引擎會把相似網址視為一組，再依頁面內容與網站訊號選出代表版本。檢查時要同時保留「網站希望哪個網址代表這份內容」與「Google 索引資料實際選了哪個網址」兩種答案。先整理同內容版本，再逐項核對宣告、內鏈與網站地圖，才能分辨是訊號分散、頁面分組不當，還是資料尚待更新。這份檢查以同一內容的多個可達網址為範圍，重點是找出哪些版本被聚在一起，以及哪些站內線索指向不同方向；可依實際頁面逐步比對。

整理同頁不同網址

先從搜尋結果中複製實際顯示的完整網址，包含協定、主機名稱、路徑、尾斜線和查詢參數；再加上你預期的主要網址、該頁自我宣告的網址，以及可能產生同內容的入口。不要只比較網址外觀，逐一打開候選頁，確認主標題、主要文字、語系、商品或文章內容是否相同；追蹤碼參數可能不改內容，篩選或排序參數卻可能改變頁面，不能一律當成重複頁。把 http 與 https、有無 www、尾斜線、大小寫、參數、列印版或手機版列成候選類型，但先記錄狀態，不要在這一步大規模合併。每個網址記下最終載入網址、頁面標題、主要內容差異、是否可被索引，以及是哪個內部入口把你帶到它。若頁面需要登入、語系依瀏覽器切換或參數會改變排序，也註明測試條件，避免把一次畫面差異誤判為不同頁。假設虛構網站 /guide 與 /guide?utm_source=email 顯示相同正文，可先列為同內容候選；若 /guide?sort=price 顯示不同排序並改變商品集合，就先保留差異待判斷。清單只收同一意圖、主內容高度相近的版本，避免把語系頁、分頁或篩選結果直接併進同一組。可把資料表分成原始網址、來源入口、內容同異、回應狀態、候選群組與暫定主頁；來源寫搜尋結果、導覽或外部分享，才看得出是哪條路徑持續暴露非預期版本。保留原始網址字串，再另建標準化欄位，不要直接覆蓋，否則尾斜線或參數差異會消失。也按文章正文、商品篩選、分頁或語系記下頁面目的。若不同網址最後載入到同一地址，把原始輸入與最後地址分欄記錄；這能分清搜尋結果帶來的入口與頁面實際呈現版本，避免只以網址字串判斷重複。

讀取頁面宣告網址

對清單中每個可抓取頁面，查看原始 HTML 的 head，不要只看瀏覽器畫面或外掛摘要。找 ，抄錄解析後的完整 href，並核對它是否是絕對網址、使用預期的 HTTPS 與主機名稱、指向可公開讀取的頁面，而且目標內容是否真與目前頁面相同。若頁面沒有宣告，記為「未宣告」；不要把空值自行解讀為錯誤，單一版本通常可以沒有替代網址，但重複頁就需要檢查整體訊號。再檢查回傳 HTML 是否只有一個有效 canonical，伺服器是否另以 HTTP 標頭宣告不同網址，以及客戶端 JavaScript 是否在載入後改寫標籤。比對原始碼和渲染後 DOM 能抓出模板或前端程式造成的差異；若兩者不同，記下抓取條件與哪個版本先出現。以虛構 /article 與 /article/ 為例，若兩頁都宣告 /article/，而該目標回傳正常內容且主題一致，宣告方向一致；若斜線版卻把 canonical 指回非斜線版，需先釐清站內預定形式與目標是否可用，再統一模板，而不是複製另一頁的標籤。語系頁也要確認是否錯指到其他語言；內容主體不同時，不宜只因共用版型就指向同一語言。若 href 使用相對路徑，記錄瀏覽器解析後的完整目的地，因為不同頁面所在目錄可能使相同字串解析到不同網址。目標若打不開、回傳錯誤或被登入牆遮住，不能只看標籤文字就視為有效；若主題或語言不同，也要回頭判斷是否把頁面錯分成重複內容。若同一頁有多個 canonical，記錄每個標籤的來源與出現位置，找出是哪個模板或外掛輸出；兩個目的地衝突時，先修正生成來源，再檢查各頁結果。最後保留頁面原始碼或檢查截圖與測試條件，方便修正後對照。

確認搜尋選取版本

宣告值代表網站偏好，不等於搜尋引擎最後採用的值。登入 Search Console 後，對清單中的各候選網址使用網址檢查，分開抄錄索引資料中 Google 選取的網址和網站宣告的 canonical；前者是索引時的判定，後者是網站提供的偏好。即時測試可用來查看目前抓取、載入資源和可檢索狀態，但它不能預測最終會選哪個 canonical，因此不能只因即時測試讀到正確標籤就下結論。要把搜尋結果顯示網址也列入比對，因為它回答使用者實際看到什麼，而不是單靠 site: 搜尋推測索引判定。檢查時固定完整路徑與參數，並留存索引狀態、宣告值、選取值；若候選網址屬不同 Search Console 資源，確認帳戶有相應檢視權限，否則把那欄記成未知，別把看不到當成沒有選取。以下是虛構路徑例子：

表中路徑與判讀都是假設，不代表實際站點狀態。網址檢查會針對輸入的確切網址提供索引資料；要理解一組重複頁如何歸類，需分別查原始版本與候選目標，並核對欄位是否來自同一資源。若目標網址屬不同網域或資源，先確認屬性涵蓋範圍與資料權限；不要把工具看不到的欄位填成「未選取」。即時測試只回答目前頁面能否被抓取，和索引資料中的選取結果不可混為一談。若 Google 選取結果指向另一候選，接著檢查該目標頁的正文、語系和入口，判斷它是否更完整地代表這組內容；先記錄觀察，再決定是否修正網站訊號。可參考 Search Console 官方網址檢查說明。

找出互相矛盾訊號

訊號要逐項對照，不能看到 canonical 指向預期網址就結案。先看同一內容的各版本是否都表達相容偏好：重複頁的標籤應指向同一代表頁，代表頁也應自我宣告；再看網站導覽、麵包屑、相關文章、產品卡片和頁尾是否持續連到那個版本。若頁面宣告 HTTPS 版，站內連結或網站地圖卻多數列出 HTTP 版，搜尋引擎會收到不同方向的提示。也要檢查網站地圖是否收錄預期版本、語系頁的 hreflang 是否回指相符語言、不同網域是否意外輸出相同主內容，以及目標頁是否可讀取且內容相關。若兩頁主體差異明顯，卻互相宣告對方為 canonical，問題可能是頁面分組錯誤，不是少加一個標籤。相反地，若追蹤參數只改網址、不改正文，且內鏈常帶參數，重複訊號就不一致。不要用 robots.txt 或 noindex 來代替 canonical 判斷：前者可能讓搜尋引擎看不到頁面內容，後者會限制頁面出現在搜尋結果，兩者解決的是不同問題。把每個觀察分成「偏好一致」「互相矛盾」「尚無資料」，並附上來源位置；先修最能解釋 Google 選取結果的衝突，避免同時改太多條件而無法判斷原因。檢查時要分清「訊號存在」和「訊號互相打架」：例如網站地圖與 canonical 都指向同一版本，即使網站仍有少數舊連結，也要標明位置，而不是把整站描述成完全相反。若伺服器回傳的標頭與 HTML 不同，保存兩份原始值；若瀏覽器載入後才出現另一個值，也保存 JavaScript 渲染結果。這些證據可幫你定位是模板、內容管理系統或前端程式產生差異，再按來源修正。最後把衝突各自連回導覽、網站地圖或原始碼證據，搜尋選取結果只作為其中一項線索。

修正內鏈與重複路徑

先選定每一組內容的主要網址規則，再修正產生重複路徑的來源。若文章正文只有一份，追蹤參數頁就沿用同一內容版本的 canonical；若篩選、排序或語系實際改變使用者要看的內容，先確認頁面是否應各自保留，再決定對應設定，不要把所有帶參數網址一律併掉。接著從全站模板與內容資料修正內鏈，讓導覽、麵包屑、推薦卡、文章連結及按鈕直接使用預定的標準網址，避免先連到另一種大小寫、主機或尾斜線形式。網站地圖也只列希望出現在搜尋結果的版本，並檢查 canonical 目標沒有指向失效、禁止索引或主題不相符的頁面。若網站有語系版本，各頁應先維持對應語言的標準網址，並讓語系標記與實際內容相符。修正時從一個頁型或一組重複網址開始：更新模板或內容欄位、重新載入頁面、查看原始碼與渲染後 DOM，再抽查內鏈和網站地圖是否輸出同一格式。這種順序能避免只改頁面標籤、卻讓系統繼續產生舊網址。記下變更涉及哪些模板、文章或參數規則，讓後續複查能分辨是整站共用設定改善，還是單一網址的偶發結果。對追蹤碼這類不改內容的參數，可先確認分析或外部分享仍會正常運作，再讓站內連結回到乾淨網址；對篩選結果則比較主體商品與搜尋意圖，只有真正代表同一頁時才合併訊號。不要為了讓檢查報告變綠而把不同內容頁指向同一目標，這會使使用者和搜尋系統都難以理解頁面差異。若頁面由共用元件產生連結，修正後抽看不同文章與語系，確認不是單頁手工改好、其他頁型仍輸出舊形式。

記錄複查前後差異

複查要沿用修正前的同一批網址與檢查條件，否則前後資料無法比較。為每個候選版本保留一列：原始網址、最終載入網址、回應狀態、主內容摘要、頁面宣告的 canonical、索引資料中的 Google 選取網址、站內連結入口、網站地圖是否收錄，以及檢查條件。修正後逐欄更新，不要只截一張首頁原始碼；網址檢查呈現的是索引資料，而即時測試呈現目前抓取，兩者回答不同問題。若標籤已更新但 Google 選取欄尚未改變，先記錄「網站端已修、索引端待重新評估」，持續觀察同一組頁面；搜尋引擎何時重抓與重新判定沒有可承諾的固定日期。若選取網址仍不符，回到內容相似度、內鏈、網站地圖、語系標記與目標可讀取性逐項查核，避免反覆重寫相同標籤。完成判準應同時包含：預定版本回應正常、重複頁宣告一致、重要內鏈指向預定版本、網站地圖列出相同版本，且後續索引資料不再顯示未解釋的分歧。將每次變更和讀取結果分開紀錄；前者證明網站端改了什麼，後者才顯示搜尋端目前的狀態。遇到資料仍不一致時，保留尚未解決的候選組與下一次檢查條件，不要只用「已修正」覆蓋舊紀錄。若問題牽涉網站內容維護與工作流程交接，可帶著這份前後清單，到 ZhenheAI 官網說明需求並討論範圍；目前首頁方向涵蓋需求釐清、最小化設計、實作與維護，適合把檢查結果連同後續責任與交接方式一起整理。下一步先挑一組實際候選網址，完成同條件基準紀錄，再開始修正：前往 ZhenheAI 官網