顧客在搜尋框裡打了「無線藍牙耳機」，明明架上就有這項商品，結果頁面卻一片空白。或者他記得型號的後三碼想用 SKU 找，搜尋框直接回他「找不到符合的商品」。這不是商品沒上架，而是 WooCommerce 商品搜尋的預設機制本來就只看得到一小部分資料，剩下的全被擋在門外。

對一間商品超過幾百件的店來說，搜尋框幾乎等於第二個首頁。願意主動打字搜尋的訪客，購買意圖通常比隨意瀏覽的人高得多，一旦搜不到就直接離開，等於把成交機會推出門外。這篇文章會先拆解 WooCommerce 預設搜尋到底怎麼運作、為什麼常常找不到東西，再一路講到即時搜尋、模糊比對、相關度排序這些強化手段該怎麼選、怎麼導入，以及後台 SKU 搜尋突然失效時該從哪裡查起。

WooCommerce 預設商品搜尋是怎麼運作的

預設搜尋的本質，是 WordPress 那套 LIKE '%關鍵字%' 的資料庫查詢，WooCommerce 只是讓商品也一起被搜進去而已。當訪客在搜尋框送出關鍵字，系統會用 WP_Query 帶著 s 參數，到 wp_posts 這張資料表裡逐筆比對，看商品的標題、內文與摘要這三個欄位有沒有出現該關鍵字的片段。

這個機制有兩個關鍵特性決定了它的天花板。第一，它只掃 wp_posts 表的那幾個文字欄位，凡是存在別處的資料一律看不到。第二，比對方式是「字串包含」，只要關鍵字以任何位置出現在那幾個欄位裡就算命中，沒有任何相關度的概念。

更麻煩的是排序。預設情況下，搜尋結果是按照發佈日期由新到舊排列，而不是按照「跟搜尋字詞有多相關」排列。也就是說，一個標題完全命中關鍵字的舊商品，可能排在一個只有內文偶然提到該詞的新商品後面。對購物體驗來說，這個排序邏輯幾乎是反過來的。

理解這層機制很重要，因為後面所有的強化方向，本質上都是在補這三件事：擴大搜尋的欄位範圍、加入容錯與相關度判斷、以及把排序從「照時間」改成「照相關度」。

預設搜尋的五個盲點分別卡在哪

預設搜尋找不到東西，通常不是隨機故障，而是踩到下面這五個結構性盲點的其中一個。先對號入座，才知道該補哪一塊。

• 搜不到 SKU：WooCommerce 把商品貨號（SKU）存在 _sku 這個自訂欄位（postmeta）裡，而前台預設搜尋根本不看自訂欄位。顧客拿著型號或料號來找，前台一律回他找不到。
• 搜不到商品屬性：顏色、尺寸、材質、品牌這些屬性同樣存在 wp_posts 之外的地方。顧客記得「想要那款紅色的」打「紅色」進去，預設搜尋也接不住。
• 搜不到分類與標籤：商品分類與標籤是 taxonomy 資料，不在內文欄位裡。打分類名稱想一次撈出整個系列，預設機制做不到。
• 沒有錯字容錯：比對是嚴格的字串包含，少一個字、打錯一個字、多打一個空格，命中率就掉到零。中文使用者打注音選錯字、英文型號拼錯一個字母，都會直接落空。
• 大型目錄會變慢：LIKE '%關鍵字%' 這種前後都帶萬用字元的查詢，資料庫無法有效使用索引，只能逐列掃描。商品上萬筆時，每一次搜尋都可能掃過上萬列；多人同時搜尋，伺服器負載會明顯往上堆。

這五點裡，SKU 與屬性是「搜得到範圍」的問題，錯字容錯是「比對寬鬆度」的問題，效能則是「規模」的問題。一間店往往不只中一槍，所以強化方案通常得同時處理多個面向，而不是單點修補。

即時搜尋讓顧客邊打字邊看到結果

即時搜尋（一般稱為 AJAX live search 或 instant search）指的是顧客在搜尋框裡每打一個字，下方就立刻彈出符合的商品清單，不需要按下 Enter 跳轉到搜尋結果頁。這是強化商品搜尋時感受最直接的一項，因為它把「打字、送出、等待整頁重載、看結果」這段流程，壓縮成「邊打邊看」。

即時搜尋之所以對轉換有幫助，關鍵在它縮短了顧客抵達商品的路徑。好的即時搜尋下拉清單通常會直接顯示商品縮圖、名稱、價格，甚至庫存狀態與「加入購物車」按鈕，顧客在下拉清單裡就能辨認出要找的東西，少了好幾次點擊。

要做到即時搜尋，技術上需要前端在使用者輸入時非同步向伺服器發出查詢，再把回傳結果即時渲染到下拉清單。WooCommerce 預設並沒有這個機制，所以即時搜尋幾乎一定得靠外掛或自行開發來補。導入時有兩個細節值得留意：一是要對輸入做節流（debounce），避免每個按鍵都打一次資料庫造成過載；二是這類搜尋若直接打在未經最佳化的資料庫上，反而會放大前面提到的效能問題，所以即時搜尋通常會跟「索引」一起出現，這點下面會談。

模糊比對與同義詞讓打錯字也找得到

模糊比對（fuzzy matching）與錯字容錯（typo tolerance）解決的是同一件事：顧客拼錯、選錯、漏字時，系統還能猜到他真正想找什麼。預設搜尋在這塊是零容忍，差一個字就當作完全不同的詞，這對商品名稱很長、含型號或英文品牌的店尤其致命。

模糊比對的原理，是允許搜尋字詞與商品資料之間存在一定程度的差異，仍視為命中。常見做法是計算兩個字串之間的「編輯距離」，也就是要改幾個字才能從一個變成另一個，差異在容許範圍內就算找到。這樣顧客把「Logitech」打成「Logitec」、把型號尾數打錯一碼，依然撈得出對的商品。

同義詞（synonyms）處理的是另一種落差，也就是顧客腦中的說法跟你後台命名不一致。顧客打「筆電」，你商品名寫的是「筆記型電腦」；顧客打「行動電源」，你寫的是「行動充電器」。同義詞對照表的作用，就是把這些不同講法映射到同一批商品，補上「內部命名」與「真實搜尋字詞」之間的橋。

這兩項在預設搜尋裡都不存在，需要靠具備容錯演算法與同義詞設定的搜尋方案才能補上。導入時要拿捏寬鬆度，模糊比對放太寬會把不相關的商品也撈進來、稀釋相關度，反而讓顧客更難找；同義詞表則需要持續維護，搭配店內實際的搜尋紀錄來補充顧客真的會用、但目前搜不到的詞。

用程式碼手動擴充和裝外掛的取捨

要強化 WooCommerce 商品搜尋，路線大致分兩條：自己寫程式碼擴充預設查詢，或安裝專門的搜尋外掛。兩條路都走得通，差別在於投入的技術成本與能拿到的功能完整度。

手動擴充的核心，是掛上 posts_search 這個 filter，改寫 WooCommerce 送出的 SQL 查詢，把原本只看標題與內文的條件，擴大到自訂欄位、分類與屬性。舉例來說，要讓前台能搜 SKU，做法是在查詢條件裡額外加一段，去比對 postmeta 表中 meta_key 為 _sku 的欄位值；要搜分類，則是再串接 taxonomy 相關的資料表來比對分類名稱。這條路的好處是不用裝外掛、完全掌控邏輯、也不會多載入前端資源。

但手動擴充很快會撞到天花板。把搜尋範圍擴大到自訂欄位之後，下一個問題馬上浮現：要同時搜好幾個自訂欄位怎麼辦？想讓店家自己在後台改要搜哪些欄位怎麼辦？要加入相關度排序、錯字容錯、即時下拉、結果篩選又怎麼辦？這些每一項都是額外的開發量，而且全部疊上去之後，等於是自己從頭造一套搜尋引擎，維護成本相當高。

判斷的分界線大致是這樣：如果你只缺一兩個明確的小功能（例如純粹想讓前台能搜 SKU），手上又有能改 functions.php 的技術能力，一段程式碼片段就解決，沒必要為此裝外掛。但只要需求一旦延伸到即時搜尋、相關度排序、錯字容錯這類牽涉演算法與索引的功能，自己寫的投報率就很低，改用成熟的搜尋外掛會務實得多。

主流搜尋外掛的能力差異在哪

市面上的 WooCommerce 搜尋外掛功能高度重疊，差別主要落在免費版給多少、效能引擎強不強、以及介面好不好設定。以下就幾款常被討論的方案，做中性的能力對照，不涉及推薦。

• FiboSearch：安裝量大、口碑長期穩定的 AJAX 搜尋外掛。免費版就提供帶縮圖、價格與 SKU 顯示的即時下拉，對小型店已堪用；付費版加上自家的反向索引引擎，據官方說明可支撐到十萬件商品規模，並內建搜尋數據分析。多數進階功能放在付費版，設定面板開啟進階模式後會偏複雜。
• Advanced Woo Search：以自建搜尋索引表為核心的 WooCommerce 專用外掛，主打輕量、不拖慢網站。它的免費版相對大方，把 SKU 與自訂欄位搜尋這類多數外掛收進付費版的功能也放進免費版，並支援相關度排序與搜尋結果篩選（例如把特定分類的商品排除在結果之外）。
• SearchWP：定位更偏全站搜尋而非純電商，透過自訂演算法讓你決定哪些來源（文章、頁面、自訂欄位、taxonomy）納入搜尋、各自權重多少。它有 WooCommerce 整合擴充，可把 _sku 等自訂欄位加進搜尋來源，也提供即時搜尋、錯字容錯與站內搜尋字詞追蹤。
• 其他即時搜尋類外掛：另有一批主打輕量、即時、容錯的外掛，特色多半是自動偵測並索引 WooCommerce 的商品、SKU、分類、標籤與屬性，替換掉預設的 WordPress 搜尋框。

挑選時，幾個維度比「功能列表多長」更值得看。第一是效能引擎，有沒有自建索引表，這決定大型目錄下搜尋會不會卡。第二是免費版的實際邊界，你最需要的那項功能是不是被鎖在付費版。第三是設定介面與佈景主題相容性，能不能少改程式碼就把店內既有的搜尋框換掉。第四是有沒有搜尋數據分析，因為顧客搜了什麼、哪些搜尋落空，是後續優化最重要的依據。

搜尋結果優化靠的是索引、相關度與商品資料整理

把搜尋範圍補齊、加上即時與容錯之後，最後一哩是「結果優化」，也就是讓對的商品排在前面、整體查得又快又準。這一段牽涉三個彼此相關的環節。

第一是索引。預設搜尋每次都對原始資料表做全表掃描，規模一大就慢。具備索引機制的搜尋方案會先把商品的可搜尋資料整理進一張專用的索引表，查詢時直接打索引而不是掃原始資料，速度與準確度都明顯拉高。這也是為什麼即時搜尋幾乎一定要搭配索引，否則邊打字邊查只會把效能問題放大。需要注意的是，索引建立後若商品有大量異動，通常要手動或定期重建索引，否則搜尋結果會對不上實際商品狀態。

第二是相關度排序。把預設的「照日期排」換成「照相關度排」，是體感差異最大的一步。相關度的判斷通常會替不同欄位設定權重，例如標題命中比內文命中更重要、完全相符比部分相符更重要，據此把最該出現的商品推到最前面。多數成熟外掛都允許調整這些權重，讓排序貼近你的商品結構。

第三，也是最常被忽略的一塊，是商品資料本身的整理。再強的搜尋引擎，也只能搜到你存進去的資料。如果商品標題寫得含糊、屬性欄位留白、SKU 命名沒有規則，搜尋品質一定打折。實務上值得固定做的有幾件事：商品標題包含顧客真的會打的關鍵字而非只有內部代號、屬性欄位確實填好填滿、SKU 命名維持一致規則、並定期翻看店內的搜尋紀錄，把落空率高的字詞補進商品命名或同義詞表。搜尋優化不是裝完外掛就結束的一次性動作，而是跟著商品資料一起持續維護的工作。

後台 SKU 搜尋突然失效時的排查順序

前面談的多半是前台搜尋，但有一種情況是後台的 SKU 搜尋本來正常、卻突然失效。WooCommerce 後台預設就支援用 SKU 找商品，所以一旦在後台也搜不到，通常代表環境出了狀況，而非功能缺失。可以照下面的順序排查。

第一步、檢查外掛衝突。先把 WooCommerce 與搜尋相關外掛以外的外掛全部停用，再試一次後台 SKU 搜尋。如果恢復正常，就逐一啟用外掛，找出是哪一個造成衝突。

第二步、重建商品查找表並更新資料庫。如果近期曾用 CSV 大量匯入商品，有可能讓 WooCommerce 的商品資料對應出現問題。到 WooCommerce 的「狀態」頁、切到「工具」分頁，找到商品查找表（product lookup tables）的重新產生（Regenerate）功能執行一次；接著如果有「更新資料庫」的提示，也一併執行，讓 WooCommerce 重新整理商品資料。

第三步、批次重新儲存商品。到商品列表全選當頁商品，用「批次編輯」開啟後直接按更新，不改任何欄位也行。這個動作會促使 WooCommerce 重新整理這批商品的資料，常能解決後台顯示與搜尋對不上的狀況。

第四步、確認主機記憶體限制。有些主機方案有隱性的記憶體上限，會讓 WooCommerce 在資料量大時運作不正常。這類設定通常無法自己調整，需要聯絡主機商客服，請對方協助確認並視情況調高記憶體限制。

照這四步走，大多數後台 SKU 搜尋失效的狀況都能定位到原因。前台搜不到 SKU 是「功能本來就沒開」，要靠擴充來補；後台原本能搜卻失效則是「環境出問題」，要靠排查來修，兩者根因不同，別混在一起處理。

從找出盲點到讓顧客搜得到，下一步怎麼走

WooCommerce 商品搜尋的強化，說到底是沿著同一條邏輯往下補：先認清預設機制只看標題、內文與摘要，再把搜尋範圍擴大到 SKU、屬性與分類，接著加上即時下拉與錯字容錯讓顧客邊打邊找、打錯也找得到，最後用索引與相關度排序把對的商品推到最前面。需求單純就用一段程式碼擴充，牽涉到演算法與索引就交給成熟外掛，這條分界線能幫你省下大量不必要的開發。

真正要動手時，建議從一份店內搜尋紀錄開始。先看顧客實際打了哪些字、哪些搜尋落空，再決定優先補哪個盲點，會比一上來就比較外掛功能列表精準得多。搜尋框搜得準不準，最終回到的是顧客找不找得到、買不買得成，這才是強化商品搜尋值得投入的理由。