很多站点都在頁头放了一個搜尋框，但對它的關注往往只停留在“能用就行”。實际上站内搜尋是少數几個能让 URL 無限增殖的功能：一個關鍵詞一個地址，再加上篩選、排序和分頁，理论上可以生成無穷多個頁面。如果不做任何约束，蜘蛛顺着這些地址一路爬下去，既占用抓取配額，也容易把搜尋结果頁当成站点的正式内容。
一、搜尋结果頁要不要让蜘蛛抓
多數情况下，站点並不希望搜尋结果頁進入索引，原因是它没有獨立的信息價值，内容還會随收錄資料不断變動。常见的處理方式有两類：
- 用 robots.txt 屏蔽搜尋路径：像 /search、?s= 這類特征明顯的地址，直接禁止抓取。這是最省事的做法，但要注意屏蔽的同时，也會挡住頁面里指向其他文章的連結。
- 给頁面加 noindex：允许蜘蛛抓取頁面，從而發現结果里那些指向正文的連結，但不让頁面本身進入索引。适合搜尋结果中确實包含大量文章入口的场景。
两種方式不必全站统一，按自己的站点结构選一種就行。要避免的是互相矛盾的做法：一邊屏蔽搜尋路径，一邊又指望蜘蛛從搜尋结果里發現新文章。
二、分頁和篩選參數要设上限
搜尋结果的分頁比栏目分頁更容易失控，因為它往往没有一個固定的總頁數。常见的問题有：
- 翻到第五十頁仍然是空列表，頁面照样返回正常狀態碼。
- 篩選參數随意组合，同一批结果被拆成几十個不同地址。
- 按時間、按热度等排序方式，每一種都對應一套獨立地址。
建议的做法是：给分頁设一個硬性上限，超出范围时直接返回错誤狀態或跳回第一頁；篩選和排序參數用 canonical 指向不带多余參數的版本，或者干脆對參數版本加 noindex；结果為空时给出明确的“没有找到相關内容”提示頁，而不是一片空白。
判断标准很简單：把搜尋引擎当成一個没有耐心的訪客。它愿意在一個栏目里翻十頁，但不會愿意在一個看不到尽头的搜尋列表里翻五十頁。
三、性能和资源開销
站内搜尋通常是全站最耗资源的入口之一，尤其是带模糊匹配的时候。自查时可以留意几点：
- 搜尋請求是否直接打到主資料库，訪問高峰时會不會拖慢正常頁面。
- 有没有频率限制，防止有人用脚本反复刷搜尋接口。
- 搜尋頁面本身是否走了缓存，热门關鍵詞能不能直接從缓存返回。
如果搜尋依赖獨立服務，還要確認它挂掉时前台不會白屏，而是给出一個可以正常阅讀的提示。
四、一份可以照着做的自查清單
- 随机搜几個词，看看结果頁的标题和描述是否合理，還是所有頁面共用同一套模板文案。
- 检查搜尋路径是否被 robots.txt 或頁面級标簽正确约束，两種方式有没有打架。
- 手動翻到分頁末尾，確認超出范围的頁碼返回的狀態碼是否符合预期。
- 查看訪問日誌里搜尋路径的抓取占比，比例過高說明參數需要收敛。
- 在手机上试一次搜尋，確認輸入法回车後能正常提交，键盘不會挡住按钮。
- 確認搜尋结果頁不會把站内連結指向草稿、预览或临时地址。
五、小结
站内搜尋是訪客找内容的快捷方式，也是站内 URL 最容易失控的角落。把它当成一個正式功能来运营——限制參數组合、约束分頁范围、明确索引策略、留出资源余量——比起事後在日誌里發現几萬條無意义的搜尋地址，要省事得多。