做站点运营，很多人把注意力放在新頁面怎么被更快發現上，却忽略了另一件更耗资源的事：站点自己在源源不断地生产 URL。列表頁的篩選、排序、视图切換、每頁條數、會话标识，每一項都可能让同一批内容對應出几十上百個地址。蜘蛛顺着這些連結爬，抓到的往往是高度重复的頁面。
URL 膨胀是怎么發生的
假设一個列表頁有 5 個篩選维度，每個维度有 8 個可選值，理论上能组合出三萬多條 URL，而里面展示的内容大部分是重叠的。排序參數更典型：預設排序、價格升序、價格降序、销量排序、上架時間排序，只要這些是 HTML 里真實可点的連結，蜘蛛就會一個個爬過去。再叠加“每頁顯示 20/50/100 條”“列表视图/網格视图”這類參數，數量涨得比想象中快。
這些頁面本身不算错誤，問题在于它們會把抓取量摊薄。同一份内容被反复抓取，真正需要更新、需要被發現的頁面反而排不上队。
先分清哪些參數代表内容
處理之前要先分類，思路大致是三種：
- 内容型參數：用戶會主動搜尋這個组合，比如某個颜色加某個尺碼，這類组合有獨立需求，可能值得保留。
- 排序與视图型參數：只改變了展示顺序或布局，内容没變，通常不需要被收錄。
- 追踪與會话型參數：utm 来源、會话 ID、ref 之類，對用戶和蜘蛛都没有意义，属于纯噪音。
只有第一類存在被收錄的理由，後两類基本是抓取预算的消耗品。
一份可执行的自查清單
- 在服務器日誌里按查询字符串做統計：带問号的請求占總請求的比例是多少，出現频率最高的參數是哪些。
- 用站内搜尋指令查一下自己域名下带參數的 URL 大概有多少條進入了索引。
- 打開列表頁源碼，確認篩選和排序是普通連結、按钮，還是表單或脚本提交。
- 检查站内搜尋结果頁是否可以被直接抓取和收錄。
- 检查分頁與篩選叠加後产生的 URL，例如同时带 page 和多個篩選條件的地址。
把這五項跑一遍，通常就能看出問题集中在哪几個參數上，不必對全站動手。
處理手段和它們的邊界
能改連結形式就先改
排序、视图切換尽量用表單或脚本触發，不在 HTML 里生成可爬的連結。這一步成本最低，也不會带来屏蔽風險，属于優先項。
想清楚是要“少抓”還是“不收錄”
這两個目标對應不同手段，混用容易出問题。robots.txt 屏蔽的是抓取，不是索引；被屏蔽的 URL 如果被外鏈引用，仍可能出現在搜尋结果里，只是没有摘要描述。
如果目标是“不希望它被收錄”，让頁面自己返回 noindex 更可靠；如果目标是“减少抓取压力”，才考虑用 robots.txt 屏蔽。反過来，一旦用 robots 挡住了抓取，蜘蛛就讀不到頁面上的 noindex，两者很难同时生效。
canonical 指向主版本
對于保留下来的參數頁面，可以在頁面里把 canonical 指向無參數的主版本，帮助搜尋引擎理解哪一個是代表地址。注意 canonical 是建议而不是强制指令，如果參數頁本身有獨立搜尋需求，就不适合强行指向主版本。
站内搜尋结果頁建议單獨處理
站内搜尋产生的頁面數量不可控，且内容随查询词變化，多數情况下没有獨立價值，可以設定為不收錄，同时保留用戶正常使用。
會话與追踪參數在服務端忽略
如果條件允许，让服務端直接忽略這些參數，用戶看到的地址更干净，也不會額外产生新 URL。
改完之後看什么
回到日誌里看两個指标：带參數 URL 的抓取占比有没有下降，以及被收錄的參數頁數量有没有收敛。這類變化通常不是立刻發生的，蜘蛛需要一段時間重新评估，观察周期拉長一点更稳妥。
最後提醒一句：不要一次性把所有带參數的地址全部屏蔽。有些參數确實承载着用戶的搜尋需求，一刀切會把本来能带来訪問的頁面一起挡掉。建议先從日誌里占比最高、内容重复最嚴重的几個參數動手，观察一段時間再做下一步决定。