站内搜索是个奇怪的入口：用得人不多，但用的人都是带着明确目的来的。搜索框给不出结果，这些人不会再看第二页，直接回搜索引擎，顺手还把你的站从收藏夹里删了。
WordPress 的默认搜索在这件事上确实不太行。输入关键词后，它生成的是类似 WHERE post_title LIKE '%关键词%' OR post_content LIKE '%关键词%' 的查询——前后都带通配符，数据库索引用不上，只能一行一行扫。文章上了几千篇，一次搜索就能把 CPU 顶到满，运气不好还会被爬虫顺手刷成小型拒绝服务。
图片由 AI 生成
先确认问题出在哪
不是所有“搜索慢”都要上搜索引擎。先用两个动作分辨：
- 在数据库里给
post_title建索引，看搜索有没有变快。变快说明只是缺索引，加个插件做倒排表就能撑住。 - 打开慢查询日志，看搜索语句的
Rows_examined。几十万行起步，说明每次都在全表扫，这时候换引擎才有意义。
方案一：插件在数据库里另建索引
Relevansi 这类插件的思路是把标题、正文、标签拆成词，存进一张自己维护的索引表，搜索时查这张表而不是扫主表。装完重建一次索引，几千篇文章几分钟能跑完。
优点是零新增服务，装完即用，后台还能调权重——标题命中比正文命中权重高，这个对结果质量提升很明显。缺点是索引表还在同一个数据库里，搜索压力没转移出去，文章过了几万篇、并发一上来，瓶颈照旧。
适合什么站：文章几千篇以内、服务器只有一台、不想多维护一个服务的。装之前记得看一下它和缓存插件的兼容性，页面缓存和搜索结果是两套逻辑，混在一起容易出“搜出来是旧结果”的问题。
方案二：独立搜索引擎
Meilisearch 是这类方案里门槛最低的。Rust 写的单二进制，Docker 一条命令起服务，空闲内存一百多 MB，返回结果在毫秒级，拼写容错和分面过滤都是开箱即用。搜“wrdpress”也能出来 WordPress，这种体验是数据库方案给不了的。
部署时有几个点必须做对：
- 生产环境设
MEILI_ENV=production并配置 master key，否则接口是裸奔的。 - 给前端用只读的 search key，绝不能把 admin key 写进浏览器。这是最常见的翻车点。
- 数据目录挂 volume，容器重建不丢索引。
- 索引同步要挂到发布、更新、删除三个动作上，否则新文章搜不到。
- 端口只监听 127.0.0.1，前面用 Nginx 反代并加限流。
需要提醒的是中文。Meilisearch 的分词对中文是按字切分的，短词没问题，长句和同义词经常不理想。上线前务必拿真实的中文查询试一轮，必要时配同义词表。Typesense 是另一个选择，GPL-3.0，内存占用大约是数据集的 2 到 3 倍，中文表现也要实测。
还有一点：Meilisearch 没有官方 WordPress 插件，集成要么用社区插件，要么自己写一个索引器加一个搜索页。会写 PHP 的话不难，但要接受“以后出问题得自己查”。
图片由 AI 生成
方案三：托管搜索
Algolia 这类服务的好处是不用管运维，前端组件成熟，搜索分析面板能直接看到哪些词搜不到结果——这个数据对内容运营很有用，能反过来指导选题。
代价是按搜索次数计费。访问量小的站一个月花不了多少，但一旦有爬虫疯狂调搜索接口，账单会很难看，所以务必配好限流和防刷。
怎么选
| 场景 | 建议 | 理由 |
|---|---|---|
| 几千篇文章，单机 | 数据库索引类插件 | 零新增服务，够用 |
| 几万篇，内容型站点 | Meilisearch 自建 | 毫秒响应，成本可控 |
| 不想运维 | 托管搜索 | 省事，按量付费 |
| 纯静态站 | 构建期生成本地索引 | 无后端，随构建更新 |
搜索优化的收益不在“更快”，而在“搜得到”。先把结果质量调好——标题权重、同义词、停用词——再考虑换引擎，顺序反了会白花钱。
最后一个小建议：把搜索日志留下来。哪些词被搜了、哪些词零结果，两周看一次，你会发现一批本该有、但没有的页面。这比任何关键词工具都直接。
