很多站点都在页头放了一个搜索框，但对它的关注往往只停留在“能用就行”。实际上站内搜索是少数几个能让 URL 无限增殖的功能：一个关键词一个地址，再加上筛选、排序和分页，理论上可以生成无穷多个页面。如果不做任何约束，蜘蛛顺着这些地址一路爬下去，既占用抓取配额，也容易把搜索结果页当成站点的正式内容。
一、搜索结果页要不要让蜘蛛抓
多数情况下，站点并不希望搜索结果页进入索引，原因是它没有独立的信息价值，内容还会随收录数据不断变动。常见的处理方式有两类：
- 用 robots.txt 屏蔽搜索路径：像 /search、?s= 这类特征明显的地址，直接禁止抓取。这是最省事的做法，但要注意屏蔽的同时，也会挡住页面里指向其他文章的链接。
- 给页面加 noindex：允许蜘蛛抓取页面，从而发现结果里那些指向正文的链接，但不让页面本身进入索引。适合搜索结果中确实包含大量文章入口的场景。
两种方式不必全站统一，按自己的站点结构选一种就行。要避免的是互相矛盾的做法：一边屏蔽搜索路径，一边又指望蜘蛛从搜索结果里发现新文章。
二、分页和筛选参数要设上限
搜索结果的分页比栏目分页更容易失控，因为它往往没有一个固定的总页数。常见的问题有：
- 翻到第五十页仍然是空列表，页面照样返回正常状态码。
- 筛选参数随意组合，同一批结果被拆成几十个不同地址。
- 按时间、按热度等排序方式，每一种都对应一套独立地址。
建议的做法是：给分页设一个硬性上限，超出范围时直接返回错误状态或跳回第一页；筛选和排序参数用 canonical 指向不带多余参数的版本，或者干脆对参数版本加 noindex；结果为空时给出明确的“没有找到相关内容”提示页，而不是一片空白。
判断标准很简单：把搜索引擎当成一个没有耐心的访客。它愿意在一个栏目里翻十页，但不会愿意在一个看不到尽头的搜索列表里翻五十页。
三、性能和资源开销
站内搜索通常是全站最耗资源的入口之一，尤其是带模糊匹配的时候。自查时可以留意几点：
- 搜索请求是否直接打到主数据库，访问高峰时会不会拖慢正常页面。
- 有没有频率限制，防止有人用脚本反复刷搜索接口。
- 搜索页面本身是否走了缓存，热门关键词能不能直接从缓存返回。
如果搜索依赖独立服务，还要确认它挂掉时前台不会白屏，而是给出一个可以正常阅读的提示。
四、一份可以照着做的自查清单
- 随机搜几个词，看看结果页的标题和描述是否合理，还是所有页面共用同一套模板文案。
- 检查搜索路径是否被 robots.txt 或页面级标签正确约束，两种方式有没有打架。
- 手动翻到分页末尾，确认超出范围的页码返回的状态码是否符合预期。
- 查看访问日志里搜索路径的抓取占比，比例过高说明参数需要收敛。
- 在手机上试一次搜索，确认输入法回车后能正常提交，键盘不会挡住按钮。
- 确认搜索结果页不会把站内链接指向草稿、预览或临时地址。
五、小结
站内搜索是访客找内容的快捷方式，也是站内 URL 最容易失控的角落。把它当成一个正式功能来运营——限制参数组合、约束分页范围、明确索引策略、留出资源余量——比起事后在日志里发现几万条无意义的搜索地址，要省事得多。