给 Markdown 站内搜索建索引时，正文和导航要分开处理
静态站点的搜索一开始看起来很简单：把页面内容抓出来，做个索引，前端输入关键字再匹配就行。真做起来以后，经常会发现搜索结果里全是“上一篇、下一篇、文章目录、相关文章”这些导航文字，真正想找的正文反而被稀释了。
别把整页 HTML 当成天然可搜索文本
很多站点的索引构建偷懒，直接拿渲染后的整页 HTML 去抽文字。这样做确实省事，但副作用也很明显：目录、侧边栏、页脚版权、按钮文案、代码复制提示，全都会被塞进搜索库。结果用户搜一个术语，前几条命中的摘要都不是正文，而是一些重复性很高的模板文字。
尤其是 Markdown 文档常带层级目录，标题词会被重复出现多次。如果索引不做区分，目录本身的权重甚至会压过正文，让搜索看起来像“能搜到”，但读者点进去以后发现并不是自己要的内容。
最好在 Markdown 结构层就把可索引内容拆开
我比较认同的做法，是在 Markdown 还没完全渲染成页面之前，就把搜索需要的字段拆出来。比如：
- 标题作为高权重字段
- 各级小标题作为辅助定位字段
- 正文摘要作为结果预览字段
- URL 和锚点作为跳转字段
目录、页脚、站点导航则明确排除，不让它们参与正文检索。这样即便页面层后来改了布局，搜索索引也不会跟着把一堆模板文案重新吃进去。
代码块和长链接也值得单独处理
技术文章最容易把搜索噪音拉高的，还有代码块和长链接。很多人确实会搜函数名、配置项名，所以代码完全丢掉也不合适；但如果整个代码块原样入库，搜索摘要又会很难看。更稳一点的方式，是只保留关键标识符，或者给代码内容单独降权。
链接也是类似。正文里出现一长串 URL，对搜索质量通常没什么帮助，还会占掉不少索引空间。把它们清洗掉，或者只保留链接文本，结果会干净很多。
搜索结果摘要要服务“判断要不要点进去”
我现在更在意的不是“搜不搜得到”，而是用户看到结果列表时，能不能很快判断这一条值不值得点。摘要如果总是目录、按钮文案、代码碎片，用户就得来回试错。摘要如果能稳定展示正文里最接近关键字的自然段，搜索体验会立刻靠谱很多。
所以 Markdown 搜索这件事，真正重要的不是索引引擎选哪一个，而是内容管道有没有把正文和导航拆开。只要索引输入是干净的，后面的搜索结果通常就不会太差。