本文从为什么要做站内搜索出发，对做站内搜索存在的问题和具体设计步骤展开了梳理和分析，并从用户角度对需要注意的问题进行了总结，与大家分享。

一、为什么要做站内搜索

对于一个单独的内容站来说，搜索其实不算是用户的常用功能，因为在绝大部分情况下，用户会更加偏向于询问他人，也就是传说中的伸手党。当无法从他人获取自己想要的内容时，用户才会倾向于去找进行搜索这个动作，而这个动作的发生环境通常也不是在一个单独的内容站内，更多地会更偏向使用 Google、百度等搜索引擎。

站在用户的角度，这样做当然是更有意义的，能够用较低的成本增加找到自己想要内容的几率。但是与此同时，一个单独的内容站为什么还需要自己做搜索呢？

1. 让用户尽可能少地离开网站去获取信息

如果让用户都去通过搜索引擎获取本站信息，用户搜索关键词的结果排序里，你的网站不一定能够进入第一页内。我们其实也都知道让搜索引擎去获取本站信息得以被搜索的初衷，不是去维护现有用户，而是希望获得更多精准用户。

所以，站内搜索的主要目的是提高用户使用本站的深度，获取用户搜索关键词数据等。不过这部分需要时间去积累。

2. 部分网站不开放数据

有些网站由于业务上、战略上等等原因，不会开放数据给搜索引擎使用，那么为了降低用户找到内容的成本，提供站内搜索就是必然的选择。

这种现象多出现于电商、O2O 等平台，同时也由于移动互联网的发展，入口和用户习惯的改变，导致信息孤岛急速扩张，更多的平台选择了只有部分开放甚至不开放数据。（现在也有巨头在尝试打破这个现象，比如说曾经的小米传送门，和现在的微信搜一搜）

3. 用户使用习惯的改变

这一部分其实前面已经提到了，当前使用互联网的第一大入口已经从浏览器等传统 PC 环境转向移动设备上的 App。呈现给用户的形式再也不是一连串不知所谓的网址，而是手机桌面上可见的、鲜艳的 App 图标，至于传统 PC 上用户用得很多的网站聚合页，也更多被各种 App Store 所替代。

当用户进入 App，呈现给他的就只有当前 App 的内容，这种情况下用户本能地会去选择使用 App 内的搜索。

不过做站内搜索也有一些需要说明的问题：

（1）开发成本相对较高

如果一旦要求高一点，希望做一个体验还过得去的站内搜索，涉及的东西就很多了，大体上可以分为：

每一部分都直接影响到最终的用户体验。

当然如果随便一点，或者内容复杂度低，MVP 试行等等，都可以考虑先直接用 SQL 去模糊查询。

1. 搜索词处理（纠错、改写、分词等）
2. 关键词和数据的匹配（标题匹配、内容匹配、生产者匹配以及权重）
3. 排序（时间、相关性、数据类型）

（2）投入产出比相对较低

前面说到了开发成本较高，那么在开发完成之后，这个功能的使用率会是多少呢？搜索是一个主动行为，在没有额外机制和奖励的情况下，用户是被动的。同样的，除非是知网、淘宝、知乎这种平台，在绝大部分平台上，这项功能的使用频次必定不会太高。

这也属于那种重要但不紧急的任务，站内搜索对于一个网站的必要性就有点像是，手机上发短信的功能，用户可以不用，但是你不能没有。

（3）内容量问题

搜索不到内容是一个搜索功能使用的时候最尴尬的时候，尽管可以通过一些手段，比如说相似内容推荐、热门搜索推荐等等；但是不可否认的是，在正常情况下（用户搜索正常词句，且与平台相关）如果搜索不到内容，尽管做了这些处理，但依旧是没有彻底解决根本的用户效率问题。

所以，在做这个功能的时候，平台的内容量一定是必须要考虑的问题。

二、搜索：词、匹配、排序

在讲具体内容之前，需要给大家先介绍一下搜索引擎搜索方式—— Site。

这应该也算是大家都会经常用到的搜索技巧了，这种搜索方式其实完全可以理解成各大搜索引擎给网站提供的免费站内搜索。

那就有个问题出现了，为什么不去使用搜索引擎的 Site 方式作为网站的站内搜索呢？这样的网站其实是有一些的，比如说 V2EX。

用搜索引擎的站内搜索好处有很多，比如说开发成本极低，用户使用成本低，搜索精准度相对较高等等

但是坏处其实也有一些：

• 首先是排序，搜索引擎的排序算法是你无法干预的，这就导致无法提供业务上所需要的排序；比如说商品网站，搜索电饭煲，搜索引擎可能更偏向相关度、时间等等，但是其实在业务层面，销量、好评率等等也是非常重要的考量因素，而这些数据不说搜索引擎能不能纳入权重，就算能，那这些数据是否能够提供给第三方也是个问题
• 然后是网站类型不同导致的数据类型问题，资讯、问答、社区、商品等等类型的平台，所提供可供搜索的内容是完全不一样的，而现在搜索引擎很大程度并不能完全满足绝大部分的内容类型。
• 最后就是更新，目前想要让搜索引擎快速收录网站链接的方式中最主流的是站点地图，但是站点地图的最大问题就是更新不及时，也很难预测到什么时候会编入索引，什么时候会收录。

1. 搜索词处理

搜索词解析方式目前比较普遍一点的就是分词和纠错。

前者目前来讲，稍微好做一点。GitHub 上也要大量开源的分词框架库可以使用，同时也支持自定义。这一部分建议之后要好好收集一下用户的搜索词，看看分词出来的词语是否切合用户当时希望表达的意思。同时也要根据业务调整，比如说在电商平台搜索 ”智能电视“，不能结果出来只有 ”智能“ 和 ”电视“，”智能电视“ 这个词本身就应该也作为一个关键词存在。

后者难度稍微高一点，因为现在的纠错不在于说没有方法去做，而是在于说假如不契合业务，可能会导致一些奇怪的结果。

尤其是错误纠正方面（纠错的流程大体为 错误字(词)识别 → 错误字(词)纠正）。不过错字(词)有时候确实会影响到分词效果，进一步影响到搜索的结果，所以这个还是有必要去做的，不过可以考虑用户量再大一些，数据更加丰富的时候去做会更好。

以及后面可以涉及到更加深入的用户搜索词预测，这个就更加复杂了，笔者也不了解，就不多说了。

2. 匹配

互联网上的能看到的内容都可以叫做数据，而绝大部分数据都会存在于数据库的一张一张表之中。匹配的根本就是将搜索词拿来去这些表里查找，找到合适的数据。

但是这样做效率太低了，为了提高效率和精准度，自然要规定一下搜索的范围，所以通常我们会对搜索进行分类处理，比如说这个关键词是搜索商品的，这个关键词是搜索文章的。

当然，让用户去选要搜什么分类已经是古早互联网时期的做法了，现在更加常见的做法是展示出所有的内容，但是分块展现，比如说知乎，综合下就带有话题、专栏、问题三种形式。

上面说的是匹配的范围，匹配还有另外一个重点就是匹配的覆盖面：

同一个类型的数据，比如说一篇文章，可能包括标题、作者、时间、内容、评论等等数据。那么你的匹配是要覆盖到哪些数据？标题？作者？时间？或者内容？

如果上面很多都想做匹配的话，那就叫多字段匹配或者多字段搜索，最简单的方式就是把多个字段组合起来建索引。

另外，如果说你还希望搜索匹配这篇文章的内容，而文章的内容通过都是很长的富文本或者文本形式，那么可能你还需要使用全文匹配来帮助你。

以上两种其实只是目前比较常见的搜索匹配方式，技术领域中有很多方法来解决这些问题，但是还是建议产品有时间可以多了解一下，可以更加理解技术的局限、边界和成本。

3. 排序

排序一般会根据相关度、内容用户相关数据、时间等等情况排序，比较依赖于业务属性。比如说新闻网站，时间维度的权重可能就会比较重；电商网站可能就比较看重销量、知名度、利润、优惠（比如说特定打折时期，将品类中让利较多的商品展现出来吸引用户）；内容网站可能还会涉及到用户是否读过，解决用户想凭借几个词找到之前度过的文章这个场景。

所以这部分很难说有什么标准的解法，视业务和用户群体而定。

三、用户视角

这部分是相对比较偏设计的，也是整个搜索的最后一部分，我大概整理了一些点可供参考：

1. 搜索框位置

现在的网站和 App 中，搜索框位置通常处于上方，这个位置属于一个不会阻挡正常内容消费，也能够很方便使用的位置。

我个人出于对用户习惯的考虑，比较建议如果没有特殊情况或者产品结构倾向的话，放在顶部即可，可以不是搜索框的形式，但是一定要有足够清晰的标识，降低用户找功能的成本。

2. 引导文

引导文就是指搜索框内，未输入时的提示；古早时期，比较常见 ”请输入搜索关键词“ 这种说法，但其实这个位置还是比较重要的，既可以提前展示重要信息又可以作为推广的渠道。所以更加建议和运营方商量去决定如何处理。

3. 热门搜索词

点击搜索的时候，在部分 App 和网站，会展示出热门搜索词。这些搜索词和引导文一样可以起到引导用户使用的作用，同时也在一定程度上降低了用户的使用成本。

不过这部分做起来不算简单（主要是运营规则和逻辑），同时效果在前期通常不太明显，建议初期不做。

4. 搜索历史

这在大部分网站或 App 中都属于一个补足用户体验的功能，但并不是刚需。所以我个人认为和热搜一起属于初期无需做的功能。

5. 结果相对较少或者没有时的处理

结果少或者没有，有时候其实不是数据的问题，而是在前面的搜索词处理上出了问题，比如说没有纠错等等。

但是毕竟已经展示给用户了，还是得思考一下如何展示。

展示相关度比较高的内容应该更加推荐的做法，因为这样会相对更加符合用户的预期。

当然，重点就是相关度了，相关度的理解也比较取决于业务——文章的分类、商品的品类和可能有的具体 SKU 属性、求职产品的职业或城市或行业等等。

有了对相关度的解读，之后就是具体的文案提示和结果展示了。

四、总结

其实上面有很多我自己说的，在现实中的项目也没有做到，但是由于其中的搜集、学习，因此对这个功能有了更加全面的了解，之后的迭代才会更有把握做好，希望这篇文章对大家有点用吧。

作者：许珂诚，微信公众号：XKC的123

本文由 @许珂诚 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议