站内搜尋是很多站点最容易失控的 URL 源头。它的入口就在頁面顶部，用戶随手可用，蜘蛛也一样能顺着走進去。区別在于：用戶点几次就停了，蜘蛛會沿着结果頁里的連結一路展開，一旦搜尋條件可以被组合，參數空間几乎是無限的。
為什么站内搜尋會批量产出 URL
大多數站内搜尋用的是 GET 表單，關鍵詞直接拼在查询串里。当结果頁本身返回 200 狀態碼、又不带任何禁止索引的标记时，每一個搜尋词都對應一個可以被抓取、甚至被收錄的地址。如果搜尋還支持排序、分頁、時間范围、分類篩選，參數组合就會成倍增長。搜尋引擎會發現其中一部分，然後顺着结果里的内鏈繼續發現更多，這個過程不需要人工干预。
蜘蛛可能從哪些地方走進站内搜尋
- 頁面顶部的搜尋表單，action 指向搜尋路径，參數以 GET 方式提交。
- 热门搜尋词、關鍵詞云、标簽墙，這些模块通常直接輸出带參數的連結。
- 搜尋结果頁内部互相連結，例如结果頁底部推荐的相關搜尋。
- 排序與分頁控件輸出的連結，带上 sort、page、range 等參數。
- 站点地图或 RSS 輸出里混入了搜尋地址，這種情况排查时容易被忽略。
URL 泛滥带来的三個直接後果
- 抓取预算被稀释。蜘蛛把時間花在大量近似頁面上，真正需要更新的詳情頁和栏目頁被推迟。
- 重复内容增多。不同關鍵詞可能命中同一批商品或文章，只是排列顺序不同。
- URL 發現的信号被噪声淹没。新頁面出現在抓取日誌里时，往往被成百上千條搜尋地址盖過去，排查問题變得困难。
先從日誌確認范围，再决定怎么收敛
動手之前建议先量化。在抓取日誌里按路径篩選出包含 search、q、kw、s 這類關鍵詞的請求，看三個數字：占全部抓取請求的比例、出現過的不同參數组合數量、這些請求的平均响應時間。如果占比超過一成，或者參數组合數遠大于站内實际頁面數，就值得處理。
同时確認一件事：真正被用戶大量使用的篩選頁，是否和搜尋頁共用同一個路径。如果共用，直接屏蔽整條路径會誤伤有價值的頁面，需要更细的規則。
几種收敛做法與使用顺序
robots.txt 屏蔽搜尋路径
這是最直接的做法，寫好規則後蜘蛛不會再請求该路径下的 URL。但要注意一個顺序問题：已经被抓取並建立索引的搜尋頁，如果先被 robots.txt 屏蔽，蜘蛛就無法讀取頁面上的 noindex，這類頁面會長期留在索引里。更稳妥的顺序是，先放開抓取、让頁面返回 noindex，等索引清理完成後再考虑屏蔽。
给结果頁加 noindex
适合搜尋頁仍需要被用戶訪問、但不希望被索引的情况。noindex 只影响索引，不影响抓取，因此對抓取预算的节省有限，需要和屏蔽規則配合使用。
把搜尋表單改為 POST
POST 提交的參數不會出現在 URL 里，蜘蛛無法通過表單构造出新的搜尋地址。改造时要確認站内所有調用搜尋的入口都同步調整，避免留下舊版 GET 連結。
控制連結的輸出
热门搜尋词、相關搜尋這類模块，可以選擇不给連結加 href，或者通過脚本触發跳轉。這样用戶点击仍然可用，蜘蛛不會把它当作可跟進的路径。分頁控件則可以限制只輸出前几頁。
參數規范化
對保留下来的篩選參數，固定參數顺序、不輸出空參數、把大小寫和多余空格统一處理，能减少同一结果對應多個 URL 的情况。
收敛之後要复查什么
規則上线後，隔一段時間回看日誌，確認三件事：搜尋路径的請求數量是否明顯下降；原本依赖搜尋入口的頁面是否仍然被正常抓取；被屏蔽的路径下有没有誤伤正常栏目。改動通常不會立刻反映在日誌里，需要观察一段抓取周期再下结论。
站内搜尋本身不是問题，問题在于它产出的 URL 無人管理。把它当成一個需要设定邊界的入口，而不是让它自由生長，抓取预算才能落在真正需要更新的頁面上。