一、開場：那個沒人修的搜尋框
一家賣工業零件的公司，官網有 9,400 筆料號。客戶在搜尋框打「軸承 6204」，回傳 0 筆；打「6204軸承」才找得到。後台資料一查，站內搜尋月流量 3,100 次，其中 41% 是零結果，而有搜尋行為的訪客下單率是無搜尋行為的 4.2 倍。換句話說，這家公司每個月把大約 1,270 次最高意圖的訪問，直接丟進空白頁。搜尋框不是裝飾品，它是站上唯一會主動告訴你「客戶想要什麼但你沒給」的欄位。
二、適用情境 × 不適用情境
適合投資站內搜尋的情境：
- 商品／料號／文章數量超過 300 筆，靠分類選單找不完
- 使用者會用「非官方名稱」找東西（俗名、簡稱、型號變體、錯字）
- 已有 Google Analytics 4 站內搜尋報表，零結果率高於 15%
- 知識庫／技術文件站，客服每天回答同樣的 20 個問題
- B2B 料號站，一個商品有 3 種以上的叫法（中文名、英規型號、客戶代號）
不適合現在做的情境：
- 總資料量低於 150 筆——做好分類與篩選器（faceted filter）效益更高
- 內容更新頻率極低且結構單純（例如純形象官網 12 個頁面）
- 資料本身髒亂：品名欄位塞規格、規格欄位塞備註。先做資料清洗，否則搜尋引擎只是把垃圾檢索得更快
- 團隊沒有人能持續看搜尋 log——搜尋是需要餵養的功能，不是一次性交付
三、替代方案矩陣
| 方案 | 中文斷詞 | Typo 容錯 | 年成本（10 萬筆內） | 適合誰 |
|---|---|---|---|---|
| MySQL Fulltext（ngram） | ngram parser 可用，但精準度普通 | 無（需自行做 SOUNDEX／LIKE 補救） | NT$0（沿用現有 DB） | 資料 < 2 萬筆、預算極緊、可接受「找得到就好」 |
| Meilisearch（自架） | 內建 CJK 分詞，中文開箱可用 | 內建 typo tolerance，預設 5 字以上容錯 2 字 | NT$9,600–24,000（VPS 2C4G） | 絕大多數中小企業網站與電商 |
| Elasticsearch / OpenSearch | 需裝 IK 或 jieba 外掛，可高度調校 | fuzzy query，可調 edit distance | NT$60,000–200,000+（含維運） | 百萬筆以上、需聚合分析、有專職維運 |
| Algolia（SaaS） | 優秀，免維運 | 優秀 | 依搜尋次數計價，月流量大時成本跳很快 | 不想碰基礎建設、願意付訂閱費的團隊 |
多數台灣中小企業的甜蜜點是 Meilisearch：中文斷詞開箱可用、記憶體需求可控、同義詞與排序規則能用 JSON 設定檔管理，不需要寫 DSL。
四、完整流程拆解（含工具與交付物）
階段 1：搜尋行為盤點（3–5 天）
工具：Google Analytics 4 站內搜尋事件、既有資料庫 query log、Notion。
交付物：前 200 大搜尋詞清單、零結果詞清單、同義詞初稿表（例如「軸承 = bearing = 培林」）。這一步決定後面 80% 的成效，跳過就是在猜。
階段 2：資料模型與索引設計（3–5 天）
工具：Figma（搜尋 UI 線框）、Notion 欄位對照表。
交付物：索引欄位權重表（品名 ×10、型號 ×8、規格 ×3、描述 ×1）、可篩選欄位（facet）清單、排序規則。
階段 3：建置與資料同步（7–10 天）
工具：Meilisearch、Laravel Scout 或自寫 sync worker、Redis Queue。
交付物：全量匯入腳本、增量同步（商品更新後 30 秒內進索引）、失敗重試機制。
階段 4：前端搜尋體驗（5–8 天）
工具：InstantSearch.js 或自寫元件、Tailwind。
交付物：即時建議下拉（debounce 150ms）、關鍵字高亮、篩選器、零結果替代建議頁。
階段 5：測試與調參（3–5 天）
交付物：50 組黃金查詢測試集（每組含「應該排第一的結果」）、回歸測試腳本、同義詞正式表。
ScriptWalker 的「站內搜尋建置服務」起價 NT$68,000（含盤點、索引設計、同步機制與前端搜尋元件）；含多語系、facet 篩選與 A/B 排序實驗的完整版本自 NT$150,000 起。
五、真實成本完整拆解
- 開發費：NT$68,000–180,000（依資料筆數、欄位複雜度、是否多語系）
- 搜尋伺服器：VPS 2 核 4G 約 NT$800–2,000／月；10 萬筆商品索引約佔 600MB–1.5GB 記憶體
- 資料清洗工時（最常被低估）：料號站通常需 16–40 小時整理品名與規格欄位，約 NT$16,000–40,000
- 同義詞維護：上線後每月 1–2 小時，年約 NT$12,000–24,000
- 隱藏費用一：索引重建期間的雙倍記憶體峰值——原本 2G 主機重建時會 OOM，實務上要開到 4G
- 隱藏費用二：CDN／WAF 規則調整。搜尋 API 高頻請求容易被 Cloudflare Rate Limiting 誤擋，設定與測試約 3–5 小時
- 隱藏費用三：備份與還原演練。索引不是資料庫，壞掉要能 30 分鐘內從主資料庫重建，這個腳本要另外寫
六、實施真相 vs 客戶想像
- 客戶想像：「裝個搜尋引擎就會變聰明。」
實際：搜尋品質 70% 來自資料品質與同義詞表，30% 才是引擎。同樣的 Meilisearch，餵乾淨資料與髒資料的結果天差地遠。 - 客戶想像：「一次做完就結束。」
實際：上線第一個月的零結果 log 才是真正的需求書。第 30 天補完同義詞後，零結果率通常能從 30% 以上降到 10% 以內。 - 客戶想像：「模糊比對開到最大最好。」
實際：容錯開太寬，搜「6204」會跑出「6205、6304」，精準度崩壞。短型號通常要關閉 typo 容錯。 - 客戶想像：「搜尋速度靠伺服器規格。」
實際：多數延遲來自前端每按一鍵就送一次請求。加上 150ms debounce 與結果快取，體感速度的改善遠大於升級 CPU。可對照 web.dev 的 INP 指標建議值 200ms 以內。
七、常見陷阱 × 怎麼避開
- 陷阱 1：直接把中文丟進預設 tokenizer。「不鏽鋼螺絲」被切成單字，搜「鏽鋼」會中獎。解法：選用內建 CJK 分詞的引擎，或在 MySQL 使用 ngram parser 並設定 ngram_token_size=2。
- 陷阱 2：沒有同義詞表。客戶打「培林」，資料寫「軸承」，永遠零結果。解法：從搜尋 log 的零結果詞反向建表，上線首月每週更新一次。
- 陷阱 3：索引與資料庫不同步。商品下架了搜尋還找得到，客戶下單後才發現沒貨。解法：用 queue 驅動的事件同步＋每日凌晨全量對帳。
- 陷阱 4：零結果頁是死路。解法：零結果時回傳「你可能想找」的相近結果、熱門搜尋與客服 LINE 入口，並把該詞記進待補清單。
- 陷阱 5：搜尋 API 直接暴露且無限流。被爬蟲打爆帳單或拖垮站台。解法：只開放 search-only key、設每 IP 每分鐘上限、前端結果快取 60 秒。
- 陷阱 6：權重憑感覺設。解法：建立 50 組黃金查詢測試集，每次調權重就跑一次，用「前三名命中率」當唯一裁判，避免改 A 壞 B。
八、成功指標 + 上線後 90 天路線圖
- 第 30 天：看零結果率（目標 <15%）、搜尋使用率（目標 >20% 訪客）、平均回應時間（目標 <100ms）。動作：補齊前 100 個零結果詞的同義詞。
- 第 60 天：看搜尋後點擊率（CTR，目標 >45%）、前三名命中率（目標 >80%）。動作：依熱門詞調整欄位權重、加上 facet 篩選（品牌、規格、庫存狀態）。
- 第 90 天：看搜尋轉換率與「搜尋後離站率」。動作：把前 20 大搜尋詞做成專屬到達頁（同時吃 SEO 流量）、導入熱門詞置頂（pinned results）、評估是否加語意搜尋（向量檢索）。
九、決策清單
- ☐ 我的可搜尋資料超過 300 筆
- ☐ 我知道目前站內搜尋的月使用次數
- ☐ 我知道目前的零結果率是多少
- ☐ 我的商品／文章有「俗名或別稱」的問題
- ☐ 我的品名欄位是乾淨的，沒有塞規格與備註
- ☐ 我有明確的搜尋結果排序邏輯（不是「相關就好」）
- ☐ 我能列出 5 個一定要排第一的黃金查詢
- ☐ 我的資料更新後需要在 1 分鐘內反映到搜尋
- ☐ 我需要篩選器（價格、品牌、規格、庫存）
- ☐ 我需要多語系搜尋（中／英／日）
- ☐ 我有預算每月 NT$1,000–2,000 養一台搜尋伺服器
- ☐ 團隊有人願意每月花 1 小時看搜尋 log
- ☐ 我接受上線後還要調整 2–3 個月才會真正好用
勾選 8 項以上：值得立刻做。勾 4–7 項：先做資料清洗與 GA4 搜尋事件追蹤，一個月後再評估。低於 4 項：先把分類與篩選器做好。
十、常見問題 FAQ
Q1：用 MySQL Fulltext 真的不行嗎？
資料量在 2 萬筆以內、對錯字容忍度不高的情境，MySQL 加上 ngram parser 是可行的，成本 NT$0。但它沒有內建 typo 容錯、同義詞與即時排序調整，做到後面通常會用 LIKE 與程式邏輯打補丁，維護成本反而超過直接上 Meilisearch。
Q2：Meilisearch 撐得住多少資料？
單機處理數十萬筆文件在實務上很穩定，記憶體是主要限制——粗估 10 萬筆中文商品約需 600MB–1.5GB。超過百萬筆且需要複雜聚合分析時，才需要考慮 Elasticsearch 這類方案。
Q3：要不要直接上 AI 語意搜尋？
建議第二階段再做。語意搜尋（向量檢索）擅長「意圖模糊」的自然語言問句，但在型號、料號這種精確比對上反而容易失準。務實做法是先把關鍵字搜尋做到前三名命中率 80%，再用混合檢索（hybrid search）補上長尾問句。
Q4：從零開始建置要多久？
單語系、10 萬筆以內、資料乾淨的情況，約 3–4 週可上線。若需要先做資料清洗，通常再加 1–2 週。真正的調校期是上線後的 8–12 週。
Q5：搜尋功能對 SEO 有幫助嗎？
搜尋結果頁本身通常設 noindex，避免產生大量重複低品質頁面。真正的 SEO 效益來自「用搜尋 log 找出使用者真實用詞」，再據此做專屬到達頁與內容規劃——這才是搜尋資料最值錢的用途。
十一、下一步
把你的 GA4 站內搜尋報表匯出，我們提供免費的「搜尋健檢」：分析零結果率、前 50 大搜尋詞與同義詞缺口，回覆一份可執行的改善清單與報價級距，不需先付費。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p