Faceted Navigation 索引控制｜商品篩選 SEO 完整教學

Faceted Navigation（多面向篩選導覽）是電商網站常見的功能，讓使用者依品牌、價格、顏色、尺寸等條件交叉篩選商品。但若沒有做好索引控制，這些篩選會在搜尋引擎眼中產生數十萬甚至數百萬個重複頁面，吃光爬取預算、稀釋頁面權重、引發重複內容問題。在 AI 搜尋時代，ChatGPT、Perplexity、Google AI Overviews 同樣會回避結構混亂的網域，篩選頁治理因此成為電商技術 SEO 的關鍵戰場。這篇文章適合電商網站經營者、技術 SEO 工程師，以及正在處理商品篩選 URL 結構的開發團隊閱讀。

Faceted Navigation 是什麼？為什麼會吃壞索引

Faceted Navigation 指的是商品列表頁上方或側邊的多重篩選功能，使用者可以同時勾選「品牌＝Nike」「顏色＝黑色」「尺寸＝US 9」「價格＝3000-5000 元」來縮小範圍。對使用者體驗來說，這是電商網站不可或缺的功能；但對搜尋引擎而言，每一次篩選組合都會產生一個新的 URL，問題就從這裡開始。

篩選頁的 URL 結構

典型的 Faceted Navigation 會用 URL 參數（query string）記錄篩選條件。一個鞋類分類頁可能會長出這樣的 URL：

每個 URL 在 Googlebot 眼中都是一個獨立頁面。即使內容只是同一批商品的不同排序或子集，搜尋引擎在不知道規則的情況下，會把它們全部納入爬取與索引候選清單。

對 SEO 造成的三層傷害

二、索引爆炸：篩選頁失控的真實規模

「索引爆炸」並不是抽象概念，而是真實會發生的災難。讓我們用一個常見的台灣中小電商情境計算給您看：

對一個商品總數只有 5,000 件的網站來說，產生 100 萬個 URL 是正常爬取規模的 200 倍。Googlebot 不會無限制爬完，它會根據網站權威度分配爬取預算（Crawl Budget），把預算用在最有價值的頁面，其餘的直接放棄。

實務上的訊號

若您在 Google Search Console 看到以下狀況，網站很可能已經陷入索引爆炸：

• 「已檢索 - 未編入索引」頁面數量遠多於商品總數（如 10 倍以上）
• 新上架商品要 3 週以上才被收錄
• 頁面索引報告中出現大量「重複網頁，Google 選擇了不同的標準網頁」
• 爬取統計顯示每日抓取數據異常高，但新內容索引緩慢
• 網站日誌（access log）顯示 Googlebot 大量請求帶參數的 URL

三、該索引 vs 該封鎖：依篩選類型決策

篩選頁治理的核心，不是「全部封鎖」也不是「全部開放」，而是依照每種篩選參數的搜尋價值做個別決策。同一個電商網站，品牌篩選可能值得開放，但價格篩選應該封鎖，這兩者並不衝突。

四類篩選的決策原則

判斷流程

• 用關鍵字工具驗證搜尋量 到 Google Keyword Planner、Ahrefs、SEMrush 或 Ubersuggest 查詢「品類＋篩選條件」的關鍵字。如果月搜尋量低於 100，幾乎可以直接封鎖。
  「Nike 黑色運動鞋」月搜尋量約 1,300（可做落地頁）；「US 9 黑色 Nike 運動鞋」月搜尋量低於 10（直接封鎖）。
• 看競爭對手的處理方式 搜尋目標關鍵字後，觀察排在第一頁的網站——如果都是大型電商的篩選落地頁，代表這個組合值得做。如果排前面的是內容型網站或一般分類頁，篩選頁可能沒必要做 SEO。
  搜尋「Nike 男鞋」第一頁多為 Nike 官網、Momo、PChome 的品牌篩選頁，代表這個組合值得開放。
• 評估內容是否足夠獨特 該篩選組合下的商品數量、文案描述、頁面元素是否足以與其他頁面區隔。如果只是同樣的商品換個排序順序，內容沒有差異，就不該索引。
  品牌篩選頁可加上品牌介紹文案、品牌歷史、熱銷款式介紹，內容明顯獨特；純價格區間頁則只是商品排序差異。
• 考慮維護成本 開放索引代表您要為這個頁面做 SEO 優化（title、meta、H1、內容文案）。若品牌數量太多無法逐一優化，建議只開放熱門品牌，其餘封鎖。
  電商有 200 個品牌，但只有 30 個有穩定搜尋量。建議只開放這 30 個品牌的篩選頁，其餘 170 個用 noindex 封鎖。

四、robots.txt vs noindex vs canonical：三大工具的抉擇邏輯

決定哪些篩選頁要封鎖之後，下一個問題是用什麼方式封鎖。robots.txt、meta noindex、canonical 三種工具的效果不同，誤用會讓問題更嚴重。

三種工具的本質差異

決策邏輯

建議依以下優先順序選擇工具：

五、AJAX 篩選 vs URL 參數：實作的兩條路線

在前端實作層面，篩選功能有兩種主流做法：傳統的 URL 參數重新載入頁面，與 AJAX 即時更新內容不換 URL。兩者在 SEO 上的差異很大。

URL 參數路線

每次篩選都產生新的 URL（如 /shoes/?brand=nike&color=black），整頁重新載入或前端 push state。優點是URL 可分享、可加入書籤、可被搜尋引擎索引；缺點是需要做好參數治理，否則容易引發索引爆炸。

• 適合：需要 SEO 流量、有明確搜尋需求的篩選組合（如品牌篩選）
• 注意：必須搭配 canonical、noindex、robots.txt 治理
• 優化：固定參數順序（如永遠 brand 在前、color 在後），避免不同順序產生重複 URL

AJAX 篩選路線

前端透過 JavaScript 呼叫 API，不改變 URL、不重新載入頁面，直接更新商品列表。優點是體驗流暢、不會產生大量 URL、爬蟲只看到一個原始頁面；缺點是篩選結果無法被分享或收藏，所有篩選組合也都失去 SEO 機會。

• 適合：篩選組合無 SEO 價值、追求純體驗的網站
• 注意：若仍想保留分享功能，可改用 fragment（#）方式更新 URL，Google 不會視為新頁面
• 優化：確保首次載入時商品列表已在 HTML 中（不是純 JS 才渲染），否則爬蟲什麼都看不到

混合策略（推薦）

實務上多數中大型電商會採用混合策略：對有 SEO 價值的篩選（如品牌、主要分類交叉）使用 URL 參數並開放索引；對無價值的篩選（如價格、尺寸、排序）使用 AJAX 不改 URL，或改 URL 但加上 noindex。

六、三種篩選實戰範例（品牌、價格、顏色）

理論說完，來看三個常見篩選的具體處理方式。以下範例假設網站是一個鞋類電商，分類路徑為 /shoes/。

範例一：品牌篩選（允許索引）

Nike、Adidas、New Balance 等大品牌都有穩定的「品牌＋品類」搜尋需求。處理方式如下：

• URL 結構從 /shoes/?brand=nike 改寫為 /shoes/nike/（語意化更友善）
• 頁面加入品牌介紹文案（150-300 字）、品牌歷史、熱銷款式
• Title 寫成「Nike 男鞋｜經典運動鞋款全系列｜新視野鞋業」
• Canonical 指向自己（self-referencing canonical）
• 內部連結從主分類頁、Footer、相關文章導入

範例二：價格篩選（封鎖索引）

「3000-5000 元的鞋」幾乎沒有搜尋需求，價格區間也因網站而異，沒有 SEO 價值。處理方式：

• URL 仍可保留 /shoes/?price=3000-5000（讓使用者可分享）
• 頁面加上 <meta name="robots" content="noindex,follow">（noindex 但保留 follow 讓內部連結權重流通）
• Canonical 指向 /shoes/（告訴 Google 主頁才是規範頁）
• 等 4-8 週確認索引清出後，在 robots.txt 加上 Disallow: /shoes/*price=*

範例三：顏色篩選（視商品類型而定）

顏色篩選的處理比較微妙。鞋類、服飾、配件的「顏色＋品類」有搜尋需求（如「黑色運動鞋」「白色洋裝」），3C 商品則幾乎沒有。

• 有 SEO 價值的顏色（如黑、白、紅）：改寫為 /shoes/black/，比照品牌篩選處理
• 小眾顏色（如駝色、薄荷綠）：保留參數 URL 但加 noindex
• 顏色＋品牌組合：多數封鎖，僅開放高搜尋量組合（如「Nike 黑色運動鞋」可獨立做頁）

三種篩選的處理對照

七、Faceted Navigation 常見錯誤

篩選頁治理是技術 SEO 中最容易出錯的環節之一。以下是六個常見錯誤：

• 用 robots.txt 封鎖已被索引的頁面 開發者發現索引爆炸後直接在 robots.txt 加上 Disallow，結果已被索引的頁面永遠清不掉。Google 看不到 noindex 標籤，這些 URL 會以「無內容」狀態長期殘留在索引中。正確順序：先用 noindex 等 4-8 週清出索引，再加 robots.txt。
• 所有篩選頁一律 canonical 到主分類頁 為了求快，把所有篩選 URL 都加上指向主分類頁的 canonical。問題是有 SEO 價值的品牌篩選頁也被一起排除，失去長尾流量機會。canonical 不是「萬靈丹」，應該依篩選類型個別決策。
• 參數順序不固定 前端沒有規範參數順序，?brand=nike&color=black 與 ?color=black&brand=nike 變成兩個不同 URL。應該強制統一參數順序，或用 canonical 指向「標準順序版本」。
• noindex 後又從 sitemap 提交 把 noindex 的篩選頁放進 XML sitemap，這會發出互相矛盾的訊號（一邊說「不要收錄」，一邊說「請來收錄」）。Search Console 會出現「已提交網址但被 noindex 標記」警告，浪費爬取預算。
• AJAX 篩選沒有保留首屏內容 為了避免索引爆炸改用純 AJAX 篩選，但首頁 HTML 沒有預先 render 商品列表，爬蟲看到的是空白頁面。應該確保第一次載入時主分類的商品已存在於 HTML 中，AJAX 只負責後續更新。
• 分頁與篩選混在一起治理 分頁（?page=2）與篩選是不同問題，但常被一起封鎖。分頁應該保持可索引或用 rel=canonical 自我指向，不要直接 noindex，否則分頁中的商品連結權重會被切斷，深層商品無法獲得足夠權重。

八、結論：建立篩選頁治理策略

Faceted Navigation 的 SEO 治理，本質上是讓搜尋引擎只看見您希望它看見的頁面。電商網站不能因為怕索引爆炸就把所有篩選頁封鎖，也不能放任不管讓爬蟲淹沒在參數海中。正確做法是建立一套分類分級的治理策略。

若您正在處理篩選頁問題，可以從以下五個步驟著手：

• 盤點所有篩選參數 列出網站所有可能的 URL 參數（brand、color、size、price、sort、page⋯⋯），記錄每個參數的可能值數量。
• 驗證搜尋需求 用關鍵字工具查詢「品類＋每個篩選值」的月搜尋量，分出高、中、低三級。
• 制定處理規則 依搜尋量決定「索引／封鎖／canonical」，整理成試算表，作為前端開發規範。
• 分階段執行 先用 noindex 處理該封鎖的頁面，4-8 週後確認索引清出，再加 robots.txt 節省爬取預算。
• 監控與調整 每月看 Search Console 的「索引涵蓋範圍」與「爬取統計資料」，確認封鎖頁是否真的減少、目標品牌頁是否真的開始收錄。

九、常見問答 FAQ