如果你的篩選頁收錄一直增加，但真正想賣的商品頁、分類頁或活動頁遲遲沒有穩定進入索引，通常不是 Google 故意忽略你，而是網站把「哪一頁才是代表頁」說得不夠清楚。對多規格、多顏色、多排序條件的台灣電商來說，最常見的問題是 canonical、robots、內部連結、sitemap 與空結果頁的規則互相打架。先把代表頁、可爬頁、可索引頁拆開處理，再做重新提交，通常比一味送 sitemap 或狂按 Request Indexing 更有效。
為什麼篩選頁收錄會拖慢真正商品頁
Google 在 What is canonicalization 中明確指出，排序與篩選功能本身就可能產生重複內容。對電商站來說，顏色、尺寸、價格排序、促銷參數、UTM 參數，都可能讓同一批商品被拆成大量 URL。當站內沒有把代表頁講清楚，Google 就得自己猜哪個版本最值得保留。這不只會稀釋訊號，也會讓新的商品頁、更新後的分類頁，被更晚發現。
很多團隊以為「被收錄的頁面越多越好」，但如果被收錄的是低價值篩選頁，實際上等於把爬蟲資源花在你不想拿來成交的頁面上。官方在 Managing crawling of faceted navigation URLs 也提醒，faceted URLs 會吃掉大量運算與 crawl 資源，甚至拖慢新 URL 的發現速度。
先分清楚 crawl 問題、index 問題、canonical 問題
處理前要先分三層。第一層是 crawl：Googlebot 有沒有一直花時間抓參數頁？第二層是 index：這些頁面有沒有真的被納入索引？第三層是 canonical：就算多個 URL 都能被抓，Google 最終把哪個當代表頁？這三件事常被混成一件，但修法不同。
例如，某個顏色篩選頁可能仍會被抓取，但最後 canonical 指回主分類頁；這時未必需要讓它完全消失。相反地，如果你用 robots.txt 擋掉頁面，卻又期待 Google 讀到頁內 canonical，通常就會互相抵消，因為 Google 根本不一定能讀到內容。Google 官方文件把 redirect、rel="canonical"、sitemap 分成不同強度的訊號，這就是為什麼修正時不能只做一個動作。
台灣電商最該先查的 6 個修正點
1. 先定義哪一些才是你要拿排名與成交的代表頁
先列清楚三類頁面：商品頁、核心分類頁、短期活動頁。若某些篩選組合本身就有獨立搜尋需求，例如「女鞋 黑色 低跟」且你真的有完整商品量、獨立文案與商業價值，可以保留它；否則多數尺寸、排序、庫存、追蹤參數頁，都不該搶走代表頁的位置。
2. canonical 不要只貼，還要前後一致
Google 在 canonical 文件 中說明，redirect 與 rel="canonical" 都是強訊號，sitemap 則是弱訊號，而且多個方法疊加會更有效。實務上最常出錯的是：頁面 canonical 指向 A，但 sitemap 放的是 B，內部連結卻又大量導向 C。這種情況下，Google 仍可能自己選別的版本。
3. 不要把 robots.txt 當成 canonical 替代品
如果你的目標是告訴 Google「真正的代表頁是哪個」，優先處理 canonical 與內部連結一致性。官方明講，不要把 robots.txt 拿來做 canonicalization，因為被 robots.txt 擋住的 URL 仍可能被索引，只是 Google 未必讀得到完整內容與頁內訊號。robots.txt 比較適合用在你確定不想讓大批 faceted URLs 被持續爬取的情境。
4. 空結果或無意義組合要回正確狀態碼
faceted navigation 文件特別提到，若篩選組合沒有結果，應回傳 HTTP 404，而不是把所有空結果都導回同一個列表頁。對電商站來說，這件事很重要，因為大量零結果 URL 如果都還回 200，不只浪費 crawl，也會讓 Google 以為這些頁面仍值得評估。
5. 內部連結與 sitemap 要只推你想保留的版本
canonical 是告訴 Google 你的偏好，但內部連結是你每天都在投票。若導覽、商品卡、麵包屑、站內推薦區塊，都持續把使用者與 Googlebot 帶去參數版 URL，你等於一邊說「這不是代表頁」，一邊又大量推薦它。sitemap 也只該放你想成為代表頁的版本。
6. 驗證不要只看 site:，也不要只按 Request Indexing
Google 在 site: operator 文件 裡直接提醒，site: 結果不是完整索引清單，也不適合拿來估算你到底有多少頁被收錄。另一份 Ask Google to recrawl 文件則說明，重新提交是輔助流程，不是取代訊號修正的捷徑。對台灣電商更務實的做法是：先用 URL Inspection 看代表頁是否可索引，再觀察不想保留的參數頁 canonical 是否被接受，最後才做重新提交。
canonical、robots、sitemap 各自該做什麼
| 訊號 | 適合用途 | 不該期待它單獨完成的事 |
|---|---|---|
| Redirect | 舊 URL 已廢棄，明確把流量與訊號收斂到新 URL | 不適合處理仍需要存在的所有篩選頁 |
| rel="canonical" | 多個近似頁面仍要存在，但要指定代表頁 | 不能取代糟糕的內部連結與混亂 sitemap |
| robots.txt | 減少大量低價值 faceted URLs 的爬取成本 | 不能穩定告訴 Google 哪一頁才是 canonical |
| Sitemap | 補強你想保留哪些 URL，幫助新頁被發現 | 不是把所有 URL 丟進去就會自動收錄 |
| 404 | 處理空結果、重複或無意義的篩選組合 | 不能拿來替代內容頁本身的 canonical 規則 |
如果你是產品量中等、工程資源有限的台灣品牌電商，最常見的順序是：先定義代表頁，再整理內部連結與 sitemap，接著補 canonical，最後才處理哪些 faceted URLs 要擋爬、哪些空結果要回 404。這個順序能先把商業價值最大的頁面穩住。
怎麼驗證修正有沒有生效
第一步：挑 5 到 10 個代表頁做人工檢查
把最重要的商品頁、分類頁、活動頁各挑幾個，確認頁面原始碼中的 canonical、站內連結、sitemap 與實際可存取 URL 都一致。若你有 staging 站，也要避免 relative canonical 或測試站 URL 混入正式站。
第二步：挑 5 到 10 個不想保留的篩選頁做反向檢查
這些頁面要看的是：是否仍大量出現在站內導覽、是否被 sitemap 收錄、是否應該回 404、是否有合理 canonical 指回更上層頁面。若你仍需要使用者瀏覽這些頁面，但不希望它們成為代表頁，就更要把內部訊號講清楚。
第三步：用 Search Console 驗證，不要只看肉眼結果
site: 指令可當輔助，但 Google 官方已說明它不會列出所有已索引 URL，排序也不是穩定的。真正要看的，是 URL Inspection 是否顯示頁面可索引、Google 選擇的 canonical 是否符合你的設定，以及後續幾週代表頁的曝光是否穩定增加。
誰適合這套做法，誰不適合
適合：商品規格多、顏色尺寸多、站內有排序與篩選、常上檔期活動、但又沒有大型 SEO 工程團隊的台灣電商與品牌官網。
不太適合直接照抄：頁面數極少的品牌形象站、只有單品單頁的極簡官網，或本來就刻意經營某些篩選組合作為獨立落地頁的站點。這些情況下，重點不是大量控管 faceted URLs，而是先定義哪些組合真的有獨立搜尋需求。
資料更新與來源
本文以 2026 年 6 月 15 日可讀取的 Google 官方文件為主，重點放在 canonical 訊號強弱、faceted navigation 的 crawl 管理，以及 site: 與重新提交的驗證限制。由於本次可見 SERP 快照對此題的競品結果偏雜訊，本文將它們視為次要背景，不把未驗證的排名說法寫成事實。
- Google Search Central: How to specify a canonical URL with rel="canonical" and other methods
- Google Search Central: What is canonicalization
- Google Crawling Infrastructure: Managing crawling of faceted navigation URLs
- Google Search Central: How To Use the Site Search Operator
- Google Search Central: Ask Google to Recrawl Your Website
結論
當篩選頁收錄搶在商品頁前面，多半不是因為 Google 特別偏愛參數頁，而是你的網站沒有把「哪一頁值得被當代表頁」講清楚。先定義代表頁，再讓 canonical、內部連結、sitemap、robots 與 404 朝同一個方向工作，通常就能把 crawl 資源從低價值頁面拉回真正有成交機會的頁面。
FAQ
篩選頁一定都要擋掉嗎？
不一定。如果某個篩選組合本身有穩定搜尋需求、足夠商品量與獨立商業價值，可以保留；問題在於不要讓所有低價值組合都跟代表頁搶訊號。
只加 canonical，就能解決商品頁沒收錄嗎？
不一定。若內部連結、sitemap、robots 規則仍互相打架，Google 仍可能自行選擇別的版本。canonical 要和其他訊號一致才有用。
robots.txt 能不能直接解決重複頁收錄？
robots.txt 比較適合節省 crawl 資源，不是穩定指定 canonical 的工具。被擋爬的 URL 仍可能在某些情況下被索引。
site: 查不到頁面，是不是代表沒有收錄？
不能這樣判斷。Google 官方說 site: 結果不會完整列出所有已索引 URL，應改用 URL Inspection 與實際表現數據一起看。
修正後多久才看得到變化？
這取決於網站規模、更新頻率與 crawl 狀況。先把訊號修對，再觀察幾週比較合理；若站內規則仍混亂，只靠重新提交通常不會穩定改善。