站内搜索是给访客用的功能，但它同时会产出大量 URL。搜索词、排序方式、筛选条件、分页参数一叠加，页面数量几乎没有上限。如果不做处理，蜘蛛很可能把抓取时间花在这些低价值页面上，而栏目页和内容页反而被冷落。
先确认蜘蛛是否真的在抓搜索页
不用凭感觉判断，翻一下服务器日志或爬虫访问记录就能看出来。常见的信号有：
- 日志里频繁出现带 ?s=、?q=、?keyword=、?search= 这类参数的请求；
- 同一路径后面跟着大量不同的参数组合，且都是蜘蛛在请求；
- 搜索页的响应码是 200，返回的却是“没有找到相关内容”的空结果；
- 每次请求耗时较长，因为搜索查询本身要跑数据库。
如果只是零星几条，问题不大；如果搜索页的请求量占了日志里相当大的比例，就值得动手整理了。
搜索结果页常见的三类问题
- 无限 URL 空间。参数可以自由组合，蜘蛛顺着翻页和筛选链接可以一直走下去，形成事实上的抓取陷阱。
- 内容高度重复。不同搜索词可能命中同一批文章，页面主体内容几乎一致，标题却各不相同。
- 空结果页大量存在。生僻词、拼写错误、测试词产生的页面没有实际内容，对访客和蜘蛛都没有价值。
分情况处理，别一刀切
不希望搜索页被访问
如果站内搜索纯粹是站内工具，最省事的做法是在 robots.txt 里屏蔽带参数的路径，例如针对 ?s= 这类固定前缀写一条规则。要注意一个前提：被 robots.txt 拦住的页面，蜘蛛看不到页面里的 noindex 标签，所以屏蔽和 noindex 通常只选一种，不要同时依赖。
希望保留部分入口
有些站点的搜索页是重要的导航方式，比如按标签聚合、按分类筛选的结果页，本身有一定内容量。这种情况更适合在页面上加 noindex,follow，让蜘蛛可以顺着链接继续往下走，但不把搜索页本身当作内容页收录。同时把分页参数、排序参数做统一，避免同一个结果集出现多个地址。
至少把服务端压力降下来
不管最终选哪种策略，搜索接口都要做基本的限流和缓存。蜘蛛集中请求时如果每次都触发全表查询，容易把服务器拖慢，连带影响到正常页面的响应。
自查清单
- 拉一份最近一段时间带搜索参数的访问记录，看请求量和来源。
- 确认搜索页当前的响应码和 meta robots 设置，是否自相矛盾。
- 检查搜索表单是否会被蜘蛛顺着提交，比如是否有 GET 方式的可抓取链接。
- 检查筛选、排序、分页是否会生成大量参数组合，能否收敛成少数几种。
- 确认屏蔽规则写在 robots.txt 还是页面标签上，只保留一种。
- 验证修改后搜索页的抓取量是否下降，正常内容页的抓取是否有回升。
搜索页的处理没有统一答案。先把日志看清楚，再决定是屏蔽、是限制参数，还是留着让它正常抓取，比照着别人的配置抄一遍更靠谱。