網站與 App 站內搜尋功能開發指南：中文斷詞、錯字容忍與找不到結果的設計

「我們網站明明有這個商品，客人卻說搜不到。」這是做電商、內容網站或會員 App 的業主很常聽到的抱怨。站內搜尋功能看起來只是一個輸入框，背後卻牽涉到資料怎麼存、中文怎麼切詞、打錯字怎麼辦、結果怎麼排序。

許多網站上線時，搜尋功能是用最簡單的方式做的：拿使用者輸入的字，到資料庫裡比對標題有沒有包含這串文字。在商品或文章很少時看不出問題，一旦內容變多、使用者用詞五花八門，就會出現搜「保溫杯」找不到「保溫瓶」、打錯一個字就零結果的情況。

這篇說明資料庫查詢與搜尋引擎服務的差別、中文斷詞與同義詞、錯字容忍、篩選排序、找不到結果時的頁面設計，以及如何把搜尋紀錄變成內容與商品規劃的依據。

為什麼站內搜尋值得認真做

會使用站內搜尋的人，通常已經知道自己要找什麼。他們不想慢慢逛分類，而是想直接找到目標。對電商來說，這群人往往就是最接近下單的顧客；對內容網站或知識庫來說，他們是帶著明確問題來的讀者。

搜尋做不好的代價也很直接：使用者搜不到，多半不會換個詞再試，而是直接離開，或轉去問客服。所以搜尋品質不只是技術問題，也會反映在客服量與轉換上。

另一個常被忽略的價值是：搜尋框是唯一能直接聽到使用者用自己的話說出需求的地方。使用者搜了什麼、搜不到什麼，是規劃商品、內容與分類的第一手資料。

資料庫查詢與搜尋引擎服務的差別

站內搜尋的實作方式大致分兩類。

資料庫查詢：直接在網站原本的資料庫裡比對文字。做法簡單，不用多一套系統，資料永遠是最新的。限制是對中文的處理能力有限，大多只能做「包含這串字」的比對，無法理解詞彙、同義詞與錯字，資料量大時效能也會下降。

搜尋引擎服務：另外架設或使用專門處理搜尋的服務，把要被搜尋的資料同步過去建立索引。它能處理斷詞、同義詞、錯字容忍、相關性排序、多條件篩選，資料量大時也能保持速度。代價是多一套系統要維護，資料同步要設計好，否則會出現商品已下架卻還搜得到的狀況。

怎麼判斷該用哪一種

• 內容量少、使用者主要靠分類瀏覽 → 資料庫查詢加上完善的分類與篩選即可。
• 搜尋是主要入口，常有「搜不到」的反映 → 考慮搜尋引擎服務。
• 需要多條件篩選並即時顯示各選項的數量 → 搜尋引擎服務較適合。
• 資料更新非常頻繁，例如庫存與價格隨時變動 → 無論哪種，都要先設計同步機制。

使用現成的 CMS 或電商平台時，搜尋能力取決於平台本身與外掛，選型時就要把搜尋列入評估，可參考CMS 選型指南與電商網站開發指南。

中文斷詞：搜尋品質的基礎

英文用空白分隔單字，搜尋系統很容易知道哪裡是一個詞。中文沒有空白，「無線藍牙耳機」該切成「無線／藍牙／耳機」還是其他組合，需要靠斷詞處理。

斷詞做不好會出現兩種問題：

• 該找到的找不到：使用者搜「藍牙耳機」，但商品名是「無線藍牙入耳式耳機」，兩者不是連續相同的字串，簡單比對就找不到。
• 不該找到的跑出來：切詞太細時，搜「花生」可能把每個含「花」或「生」的結果都帶出來。

實務上的處理方式：

• 選用支援繁體中文斷詞的搜尋方案，並確認它對台灣用語的處理。
• 建立自訂詞典，把品牌名、產品型號、產業術語、店內常用的商品名稱加進去，避免被切錯。
• 標題、分類、標籤與內文給不同的權重，標題命中的結果排前面。

自訂詞典需要持續維護，新商品、新品牌上架時要一起更新。這通常是營運人員的工作，所以後台最好能讓非工程人員直接管理詞典。

同義詞與錯字容忍：讓使用者用自己的話也找得到

使用者不會照著你的商品命名方式搜尋。他們會用口語、俗稱、簡稱，也會打錯字。

同義詞

同一件東西有很多種說法：保溫杯與保溫瓶、手機殼與保護殼、外套與夾克。搜尋系統需要一份同義詞表，讓這些詞彼此對應。

建立同義詞表的來源：

• 搜尋紀錄中常見但零結果的詞，比對後發現其實是你商品的另一種叫法。
• 客服常被問到的說法。
• 中英文混用，例如品牌的中文譯名與英文原名。
• 台灣常見的口語與簡稱。

同義詞也分方向：搜「外套」時要帶出「夾克」，但搜「夾克」未必要帶出所有外套。設定時要想清楚，後台同樣最好讓營運人員可以自行調整。

錯字容忍

注音輸入選錯字、英文型號少打一個字母，都很常見。搜尋引擎服務通常能對英文與數字做錯字容忍，例如型號差一個字元仍能找到。中文的錯字處理較複雜，常見的補強方式是把常見錯字直接加進同義詞表，以及提供「你是不是要找…」的建議。

篩選與排序：結果多的時候怎麼幫使用者縮小範圍

搜尋結果太多和太少一樣讓人困擾。篩選與排序是幫使用者縮小範圍的工具。

篩選要依內容性質設計：電商常見的是分類、售價高低、品牌、尺寸、顏色、是否有庫存；內容網站常見的是主題、日期、文章類型。設計時注意：

• 每個篩選選項旁顯示符合的數量，避免使用者點下去才發現零筆。
• 篩選條件組合後若沒有結果，要提示使用者放寬哪個條件。
• 手機上篩選介面要能收合，不要佔滿畫面。
• 已套用的條件要清楚顯示，並能一鍵清除。

排序的預設值通常是「相關性」，另外提供「最新」「熱門」等選項。相關性的計算可以加入業務規則，例如有庫存的排前面、主推商品加權，但規則要透明可管理，不要讓相關性完全被人工規則覆蓋。

搜尋與篩選的回應速度也直接影響體驗，每次調整條件都要等很久，使用者就會放棄。效能優化的方向可以參考網站效能與 Core Web Vitals 指南。

找不到結果時，頁面該顯示什麼

零結果頁是最常被草草帶過的畫面，通常只寫「找不到相關結果」。但這正是使用者最需要協助的時刻。

零結果頁設計清單

• 重述使用者搜尋的關鍵字，讓他確認自己沒打錯。
• 提供拼字或用詞建議：「你是不是要找…」。
• 推薦熱門分類或熱門商品、熱門文章，讓使用者有地方可以去。
• 若有使用篩選，提示放寬條件並提供一鍵清除。
• 提供聯絡管道：「找不到你要的？告訴我們」，並把這些回覆收進後台。
• 不要讓頁面整片空白，也不要直接導回首頁。

如果搜尋的是確實沒有販售的商品，零結果頁也是了解市場需求的機會。把使用者留下的需求整理起來，就是一份來自顧客的選品清單。

用搜尋紀錄反過來規劃內容與商品

搜尋紀錄是站內最誠實的需求資料。建議在開發時就把紀錄功能做進去，至少記錄關鍵字、搜尋時間、結果數量、使用者點了哪一筆結果。

每月可以照做的搜尋紀錄檢視步驟

1. 列出搜尋量最高的關鍵字：確認這些詞的結果第一頁是否合理，前幾筆是不是使用者真的要的。
2. 列出零結果的關鍵字：逐一判斷是錯字、同義詞、還是真的沒有這項內容或商品。錯字與同義詞加進詞表；真的沒有的，交給內容或採購評估。
3. 列出有結果卻很少被點擊的關鍵字：代表結果與期待不符，檢查排序與相關性設定。
4. 觀察搜尋後離開網站的情況：哪些詞搜完就走，優先處理。
5. 把熱門搜尋詞回饋到導覽：常被搜尋的類別，考慮放進主選單或首頁入口。

這些發現也能延伸到外部 SEO：使用者在站內搜的詞，往往也是他們在 Google 上會用的詞，可以作為規劃新分類頁或文章的依據。站內搜尋結果頁本身的索引設定，則建議參考網站專案的技術 SEO一起規劃。要追蹤搜尋行為，也可以在分析工具中設定站內搜尋事件，做法見GA4 設定指南。

開發前要和開發團隊講清楚的事

站內搜尋的需求很容易被一句「要有搜尋功能」帶過，等到上線才發現範圍理解不同。開發前建議把以下幾點寫進需求：

• 哪些內容要能被搜尋：商品、文章、門市、常見問題，各自搜尋哪些欄位。
• 資料更新後多久要反映在搜尋結果。
• 需要哪些篩選條件與排序方式。
• 詞典與同義詞由誰維護、在哪裡維護。
• 零結果頁要顯示什麼。
• 搜尋紀錄要保存哪些欄位，誰能看報表。
• 搜尋框是否需要自動完成建議。

需求文件的整理方式可參考軟體需求怎麼寫。

搜尋功能做得好，使用者幾乎感覺不到它的存在；做不好，則會變成客服電話與流失訂單。如果你的網站或 App 常被反映「搜不到」，或正打算重做搜尋，可以和 NETVANA 討論你的搜尋需求，我們會先看你的內容結構與現有搜尋紀錄，再建議該強化資料庫查詢，還是導入搜尋引擎服務。軟體服務一律採詢問報價制，服務內容見軟體服務介紹。

延伸閱讀：電商網站的搜尋與商品結構，先看電商網站開發指南；網站平台的搜尋能力取決於選型，讀CMS 選型指南；結果頁要不要讓 Google 收錄，看網站專案的技術 SEO；搜尋與篩選的速度問題，參考網站效能與 Core Web Vitals 指南；想追蹤使用者搜了什麼，看GA4 設定指南；內部資料多了之後，找得到比寫下來更重要，可以看企業內部知識庫系統怎麼建。