在 WooCommerce 商店裝上「依顏色、尺寸、價格、品牌」篩選的側邊欄，對買家來說是好事，但對 Google 來說常常是災難的開始。每多一個篩選條件，網站就多生出一個網址；幾個篩選欄位交叉組合下來，一間只有幾百項商品的店，可以對搜尋引擎暴露出數十萬甚至上百萬個頁面。這正是多面向導覽 SEO 最棘手的地方，也是多數 WordPress 電商在不知不覺中浪費爬取資源的主因。

多面向導覽（Faceted Navigation）本身沒有錯，錯的是放任它把無限多的網址丟給爬蟲。Google 在官方文件裡直接點名，這類導覽是站長回報的「過度爬取」問題裡最常見的單一來源。這篇會說清楚這些網址是怎麼長出來的、會踩到哪些技術陷阱，以及針對 WordPress 與 WooCommerce 該用哪一套封鎖與保留策略，把爬蟲的注意力留給真正會帶來流量的頁面。

多面向導覽是什麼，為什麼對 WordPress 站是雙面刃

多面向導覽是讓使用者用多個屬性同時篩選清單的機制。在電商是顏色、尺寸、品牌、價格區間；在房產平台是房數、坪數、地區；在旅遊網站是日期、星級、設施。使用者點一下側邊欄，就能從上千筆結果裡縮到「黑色、防水、9 號」這種具體需求，這是現代清單頁的標準配備，拿掉它使用體驗會明顯變差。

對 SEO 來說，雙面刃的另一面在於：每一個篩選組合通常都會產生一個獨立網址。少數高需求的組合（例如「女款慢跑鞋 6 號」）確實能對應長尾搜尋、帶來高意圖流量；但絕大多數組合沒有人搜尋，內容又跟母分類頁高度重疊，對搜尋引擎毫無價值。問題不在於要不要用篩選器，而在於有沒有控制好「哪些組合該被爬、被索引，哪些不該」。

WordPress 站之所以特別容易出事，是因為 WooCommerce 的預設篩選小工具與佈景主題大多直接把篩選狀態寫進查詢字串，而且不會幫你做任何索引控制。裝外掛、開篩選欄位都很快，但收尾的爬取管理幾乎都得自己補。

篩選器如何把一個分類頁炸成數十萬個 URL

核心機制只有一句話：改變任何一個篩選參數，就生出一個新網址。一個賣顯示器的分類頁原本是乾淨的 /monitors/，使用者勾了 19 吋、1600×900、HDMI 之後，網址可能變成 /monitors/?size=19inch&resolution=1600x900&connectivity=hdmi。這一頁的內容其實只是母分類頁的子集，沒有新東西，只是商品少了一些。

真正的爆量來自組合的乘法效應。五個篩選欄位、每個欄位十個選項，理論上就能組出十萬個網址。更糟的是參數順序：使用者先點顏色再點尺寸、跟先點尺寸再點顏色，如果系統不強制統一順序，會產出兩個內容完全相同但網址不同的頁面，等於再乘上一輪。

這不是誇飾。技術 SEO 工具商 Botify 曾對一個商品數不到 20 萬的電商做爬取，依該站 robots.txt 的規則跑下來，可被搜尋引擎觸及的頁面竟超過 5 億個。當一個站的可爬頁面是商品數的數千倍，爬蟲幾乎不可能把資源花在對的地方。

多面向導覽 SEO 會踩到的四個技術陷阱

把這些失控網址攤開來看，傷害集中在四個面向，這也是各家 SEO 工具與 Google 文件反覆強調的共同問題。

重複內容：同一批商品換個排序、換個篩選順序，就是好幾個內容近乎相同的網址。搜尋引擎得自己猜哪一個才是該排名的版本，排名訊號被切碎散在多個頁面上，結果常常是沒有一個版本排得好。

爬取浪費與爬取陷阱：搜尋引擎分配給每個站的爬取資源有限。當爬蟲把時間耗在無窮無盡的參數組合上，就沒有餘力去抓你新上架的商品與真正重要的分類頁。Google 把「爬蟲卡在無限參數迴圈裡」這種狀況稱為爬取陷阱（crawl trap），名字就是這麼來的。

連結權重稀釋：每個網址都可能吸到內部或外部連結。當這些連結指向的是篩選變體而非母頁面，權重就被分散到一堆低價值頁面，母分類頁該拿到的權威性反而拿不滿。

索引膨脹（index bloat）：放任每個篩選網址都被索引，Google 的索引裡會塞滿成千上萬個近乎重複的薄頁面。索引裡低品質頁面比例一高，整站在搜尋引擎眼中的品質訊號就被拉低，連帶影響重要頁面的能見度。

還有一個容易被忽略的衍生問題：空結果頁。當某個篩選組合（例如某個冷門尺寸缺貨）查不到商品，頁面卻仍回傳 200 OK，搜尋引擎會把它當成軟性 404，數量一多同樣拖累整站品質。正確做法是結果低於門檻（例如少於 5 筆）時回傳 404，或對該頁加上 noindex。

WooCommerce 預設會產生哪些參數型 URL

要封鎖之前，得先認得 WooCommerce 到底生出哪些參數。這是多數英文教學講得很模糊、但對 WordPress 站長最實用的部分。常見的查詢字串包括下面幾類。

• orderby：排序參數，例如 ?orderby=price、?orderby=popularity、?orderby=date。它只改變商品排列順序，不改變商品集合，幾乎沒有獨立索引價值。
• filter_*：屬性篩選參數，例如 ?filter_color=black、?filter_size=10。這是側邊欄篩選小工具最主要的產出，組合爆量大多由它而來。
• min_price 與 max_price：價格區間滑桿產生的參數，組合數高且幾乎沒有搜尋需求。
• attribute_*：商品變體參數，例如 ?attribute_color=blue。它應該指回母商品頁，而不是各自成為獨立頁面。
• product_count 或每頁顯示筆數：純呈現用的切換，沒有索引意義。
• paged 或 page：分頁參數。它跟前面幾種不同，第 2、3 頁確實含有不同商品，處理方式要分開談。
• s：站內搜尋結果參數，跟篩選疊加時（例如 ?s=shoes&filter_size=10&orderby=date）會讓網址再翻好幾倍。

把這份清單對照自己網站的網址列，大概就能看出爬取陷阱藏在哪。值得提醒的是，購物車、結帳與會員帳號頁（/cart/、/checkout/、/my-account/）對 SEO 沒有價值，且結帳屬於私密流程，應一律封鎖，不需要也不該讓它進入索引；這裡只是把它歸類為「該封鎖」，不深入收款設定本身。

每個篩選器只有四種處置方式，沒有第五種

面對上面這堆參數，與其逐一煩惱，不如先建立一個判準：每一個篩選器，最終只會落入四種處置之一。

A 值得索引：有明確搜尋需求、又有商業價值的篩選組合，例如「黑色皮革慢跑鞋」這種既有人搜、利潤也合理的頁面。這類要給自我指向（self-referencing）的 canonical、保持可爬、並從導覽或內文主動內鏈，最好做成乾淨的路徑式網址。

B 導回母頁：為了使用體驗必須存在、但本身沒有獨立索引價值的篩選，例如單一顏色篩選。用 canonical 指回母分類頁，把排名訊號集中回去。

C 封鎖爬取：永遠不會帶來搜尋價值的參數，例如排序、價格滑桿、每頁筆數，直接用 robots.txt 擋掉，省下爬取資源。

D 純前端 AJAX：只是重新排列或重新呈現既有內容的篩選，根本不需要產生新網址。用 JavaScript／AJAX 在瀏覽器端處理，或把篩選狀態放進網址的井號片段（#），因為搜尋引擎通常會忽略井號後面的內容。

判準很簡單：這個篩選有沒有人搜尋、會不會帶來轉換。兩者皆無，就不該進索引。業界經驗值是只有大約 5% 到 15% 的篩選網址值得索引，但多數網站卻反過來，放任七成以上的篩選頁進入索引。

用 robots.txt 封鎖低價值參數的寫法與陷阱

robots.txt 是擋掉爬取陷阱的第一道防線，因為它在爬蟲消耗資源「之前」就把門關上。Google 官方對多面向導覽的建議也很直接：多數情況下沒有理由讓篩選後的清單被爬，與其如此，不如只開放單一商品頁，搭配一個不帶任何篩選、列出全部商品的分類頁。

針對一間 1,000 到 10,000 件商品的 WooCommerce 商店，常見的封鎖設定大致如下。

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*?orderby=
Disallow: /*?filter_
Disallow: /*&filter_
Disallow: /*?min_price=
Disallow: /*?max_price=
Allow: /product/
Allow: /product-category/
Sitemap: https://yourstore.com/sitemap.xml

這裡有兩個關鍵。第一、Allow: 規則會覆蓋範圍較大的 Disallow:，確保商品頁與分類頁本體始終可被爬到，而參數變體被擋。第二、規則能不能精準命中，完全取決於你的網址結構是否一致；網址沒有固定模式時，萬用字元很容易誤傷重要頁面，或漏掉該擋的網址。

robots.txt 最常被誤解的一點，是它只能阻止「爬取」，不能保證「移出索引」。如果某個網址 Google 早就知道，或有其他頁面連到它，即使你 disallow 了，它仍可能留在索引裡。所以對於已經被索引的低價值頁面，正確順序是先讓它可被爬、掛上 noindex 等 Google 重新抓到並移除後，再考慮是否封鎖爬取。一上來就用 robots.txt 擋掉，反而會讓 Google 永遠看不到那個 noindex 指令。

還有一個 WordPress 站特別容易踩的雷：如果同時有多個 SEO 外掛在寫 robots.txt，行為會變得不可預測。確認只留一個外掛管理 robots.txt，避免規則互相打架。

canonical 與 noindex 各自該用在哪一層

robots.txt 是二元的，要嘛開、要嘛擋；中間地帶要靠 canonical 與 noindex 來處理。這兩個工具常被混用，但職責不同。

canonical 標籤用在「網址必須為使用者存在、但你希望排名訊號集中到另一個版本」的情況。篩選後的頁面導回母分類頁、商品變體導回母商品頁，都屬於這一類。要注意的是，canonical 對 Google 而言是建議而非命令，實作不乾淨它就會被忽略。最常見的破壞方式是 canonical 互相打架：「紅色鞋」指向「鞋」，但「紅色鞋 10 號」卻指向自己，訊號自相矛盾，Google 就不信任了。canonical 鏈（A 指 B、B 指 C）、指向 404 頁、自我指向錯誤，也都會讓訊號失效。

noindex 用在「希望被爬、用來傳遞連結權重，但不希望被索引」的薄頁面。標準寫法是 noindex, follow：把頁面排除在索引外，同時讓爬蟲沿著頁面上的連結繼續爬下去，權重不會斷。WooCommerce 站常見的 noindex 對象包括商品很少的標籤彙整頁、為了使用體驗保留但不想單獨排名的篩選組合。Yoast SEO 與 Rank Math 都能在分類層級設定預設的 robots 指令，再針對個別高價值頁面覆寫，這比逐頁手動設定可靠得多。

一個常見的判斷困惑是：到底該 noindex 還是該用 canonical？簡單分：內容跟母頁幾乎一樣、想把訊號收攏回母頁，用 canonical；內容雖然單薄、但你還想留著它的內鏈價值、只是不想它出現在搜尋結果，用 noindex, follow。

分頁與排序參數該怎麼處理

分頁（paged / page）跟其他篩選參數要分開看，因為第 2、3 頁確實含有不同的商品，不是單純的重複內容。多數情況下，第 1 頁以後的分頁很少帶來獨立流量，搜尋者幾乎都落在第 1 頁，所以常見策略是對第 2 頁以後掛 noindex, follow：不讓深層分頁進索引，但允許爬蟲沿著連結把商品都發現到。

至於 canonical，要看內容性質。如果第 2、3 頁只是同一組結果的延續，把它們 canonical 到第 1 頁可以集中訊號；如果每一頁的商品差異明確，自我指向的 canonical 反而比較合適。關鍵是一致，不要第 2 頁指第 1 頁、第 3 頁卻指自己，這種混搭會讓 Google 無所適從。

rel="next" 與 rel="prev" 這對標記，Google 早已不再用於索引判斷，但它們對瀏覽器與無障礙工具仍有意義，保留無妨，只是別指望它能解決索引問題。

排序參數（orderby）則是另一個極端：它從不改變商品集合，只改順序，幾乎沒有任何索引價值，直接在 robots.txt 擋掉是最省事的做法。對於同時疊加排序與篩選、深度又很深的網址（例如 /jackets/?filter_size=large&filter_brand=asics&page=12），如果伺服器日誌顯示 Googlebot 反覆在抓它們卻幾乎沒帶來流量，那就是典型的爬取浪費，該優先處理。

怎麼判斷哪些篩選組合值得保留索引

決定哪些組合進 A 類（值得索引），靠的不是直覺，是搜尋需求加上轉換潛力。判斷流程大致是這樣。

用關鍵字工具量一下實際搜尋量，差異往往很明顯。以慢跑鞋為例：「白色慢跑鞋」每月可能有上千搜尋量，值得做成可索引的乾淨網址；「白色防水慢跑鞋」剩幾十，仍值得索引；但「紅色越野跑鞋 9 號」幾乎沒有人搜，就該封鎖或 noindex。台灣市場要特別留意，很多英文教學裡的範例量級不能直接套用，務必用在地的搜尋詞與實際數據去驗證，例如查「防水後背包」「大尺碼洋裝」這類組合在本地到底有沒有需求。

判斷時記得把商業價值一起放進來。某個篩選的搜尋量不大，但轉換率與利潤都高，仍然值得保留索引；反過來，搜尋量大但完全不轉換的組合，也不必硬留。搜尋需求與商業價值兩個都不及格，才是真正該排除的對象。

對於 A 類的高價值組合，建議盡量做成路徑式的乾淨網址（例如 /womens-running-shoes/）而不是查詢字串（/shoes/?gender=women&activity=running），並補上一段獨特的說明文字。這需要重寫規則，但能大幅提升爬取效率，也讓這些頁面真的像一個值得排名的落地頁，而不是一個薄薄的篩選結果。

怎麼診斷自己的站有沒有爬取陷阱

在動手封鎖之前，先確認問題的規模。下面幾個檢查不需要工程背景就能做。

第一、用 site: 指令查自己的網域，看 Google 實際索引了多少網址。如果這個數字遠高於你預期要被索引的頁面數，又看到一堆 ?filter_color=red&filter_size=8 這種變體，索引膨脹大概已經發生。

第二、打開 Google Search Console。「頁面索引」報告裡的「已封鎖（robots.txt）」與「已檢索但目前未建立索引」兩區，最能看出有沒有大量非預期的篩選頁。「涵蓋範圍」與「Crawl Stats（爬取統計）」則能告訴你 Googlebot 每天把資源花在哪些回應碼與頁面類型上。

第三、做伺服器日誌分析。日誌記錄了每一次請求，包含 Googlebot 的每一次造訪。如果發現爬蟲一再去抓多層篩選、深度分頁的網址，卻幾乎沒有對應的自然流量，那就是爬取浪費的鐵證。把 Googlebot 的爬取行為跟實際自然造訪量擺在一起比，落差最大的那批網址，就是優先要封鎖的對象。

要提醒一點：過去 Google Search Console 曾提供「網址參數」工具，讓你直接告訴 Googlebot 怎麼處理特定參數，但這個工具已經被移除。現在不能再靠它，得改用 robots.txt、canonical、noindex 與乾淨的網址結構，在伺服器端與頁面端自己把參數行為控制好。網路上仍有不少舊教學在教你用那個工具，看到請直接略過。

順帶一提，多面向導覽若全靠 JavaScript 在前端渲染，而沒有伺服器端渲染，Googlebot 得先跑完 JavaScript 才看得到內容與連結，爬取速度會明顯變慢，嚴重時甚至抓不到商品。核心商品內容應該存在於初始 HTML 裡，JavaScript 只用來強化使用者的篩選與排序體驗，這樣才不會在渲染上額外燒掉爬取資源。

控制多面向導覽的本質，不是把篩選器拿掉，而是替每一個篩選器決定好它該被爬、被索引，還是被擋在門外。先用 site: 與 Search Console 量出問題規模，再用四種處置把每個參數歸位：高需求組合做成乾淨可索引的頁面，重複變體 canonical 回母頁，純呈現參數用 robots.txt 擋掉，臨時狀態交給前端 AJAX。把這套規則套到你的 WooCommerce 商店上，Googlebot 才會把有限的爬取資源，留給真正會帶來訂單的商品與分類頁。今天就先打開 Search Console 的爬取統計，看看你的爬蟲到底把時間花在哪裡。