站内搜尋是给訪客用的功能，但它同时會产出大量 URL。搜尋词、排序方式、篩選條件、分頁參數一叠加，頁面數量几乎没有上限。如果不做處理，蜘蛛很可能把抓取時間花在這些低價值頁面上，而栏目頁和内容頁反而被冷落。
先確認蜘蛛是否真的在抓搜尋頁
不用凭感觉判断，翻一下服務器日誌或爬虫訪問记錄就能看出来。常见的信号有：
- 日誌里频繁出現带 ?s=、?q=、?keyword=、?search= 這類參數的請求；
- 同一路径後面跟着大量不同的參數组合，且都是蜘蛛在請求；
- 搜尋頁的响應碼是 200，返回的却是“没有找到相關内容”的空结果；
- 每次請求耗时較長，因為搜尋查询本身要跑資料库。
如果只是零星几條，問题不大；如果搜尋頁的請求量占了日誌里相当大的比例，就值得動手整理了。
搜尋结果頁常见的三類問题
- 無限 URL 空間。參數可以自由组合，蜘蛛顺着翻頁和篩選連結可以一直走下去，形成事實上的抓取陷阱。
- 内容高度重复。不同搜尋词可能命中同一批文章，頁面主体内容几乎一致，标题却各不相同。
- 空结果頁大量存在。生僻词、拼寫错誤、測試词产生的頁面没有實际内容，對訪客和蜘蛛都没有價值。
分情况處理，別一刀切
不希望搜尋頁被訪問
如果站内搜尋纯粹是站内工具，最省事的做法是在 robots.txt 里屏蔽带參數的路径，例如针對 ?s= 這類固定前缀寫一條規則。要注意一個前提：被 robots.txt 拦住的頁面，蜘蛛看不到頁面里的 noindex 标簽，所以屏蔽和 noindex 通常只選一種，不要同时依赖。
希望保留部分入口
有些站点的搜尋頁是重要的導航方式，比如按标簽聚合、按分類篩選的结果頁，本身有一定内容量。這種情况更适合在頁面上加 noindex,follow，让蜘蛛可以顺着連結繼續往下走，但不把搜尋頁本身当作内容頁收錄。同时把分頁參數、排序參數做统一，避免同一個结果集出現多個地址。
至少把服務端压力降下来
不管最终選哪種策略，搜尋接口都要做基本的限流和缓存。蜘蛛集中請求时如果每次都触發全表查询，容易把服務器拖慢，连带影响到正常頁面的响應。
自查清單
- 拉一份最近一段時間带搜尋參數的訪問记錄，看請求量和来源。
- 確認搜尋頁目前的响應碼和 meta robots 設定，是否自相矛盾。
- 检查搜尋表單是否會被蜘蛛顺着提交，比如是否有 GET 方式的可抓取連結。
- 检查篩選、排序、分頁是否會生成大量參數组合，能否收敛成少數几種。
- 確認屏蔽規則寫在 robots.txt 還是頁面标簽上，只保留一種。
- 驗證修改後搜尋頁的抓取量是否下降，正常内容頁的抓取是否有回升。
搜尋頁的處理没有统一答案。先把日誌看清楚，再决定是屏蔽、是限制參數，還是留着让它正常抓取，比照着別人的配置抄一遍更靠谱。