很多站点在查收錄时都會遇到一個現象：真正的頁面没几條，索引里却躺着一大串带問号的地址——?sort=、?color=、?utm_source= 之類的參數把同一個頁面複製成了几十上百個版本。它們算不上垃圾頁，但也很少有人真的需要從搜尋引擎点進来。處理這類 URL，關键是先分清哪些參數有用，哪些只是系統留下的痕迹。
參數 URL 是怎么被收錄的
搜尋引擎並不天然排斥問号。只要連結出現在站内、sitemap 或外部来源中，並且返回正常内容，它就有机會被抓取和索引。常见的产生方式有几種：
- 篩選和排序：商品列表按價格、销量排序，或按颜色、尺寸篩選，每次操作都生成新 URL。
- 追踪參數：推廣連結上的 utm 系列參數，被分享、轉载後進入站内連結。
- 會话與标识：早期系統把 sessionid、會員标识直接寫進地址栏。
- 分頁與视图：翻頁、切換列表與網格视图生成參數地址。
這些地址往往和主版本内容高度相似，一旦被大量收錄，最直接的後果是分散抓取预算，让真正需要更新的頁面排队更久；同时，同一内容對應多個 URL，也會让搜尋引擎在挑規范版本时犯难。
先分類，再動手
參數治理最忌讳一刀切。把所有带問号的地址全挡掉，可能顺手把有價值的篩選组合也挡没了。可以先做一個简單分類：
- 有獨立價值的參數頁：某個篩選组合本身有稳定搜尋需求，比如固定品牌加固定品類。這類頁面内容足够獨立，可以留着，並给它明确的标题、正文和自指 canonical。
- 無獨立價值的參數頁：排序、视图切換、临时篩選。這些頁面内容與主版本基本一致，用戶也不太可能搜到。
- 追踪參數：utm、ref、from 之類，只影响統計，不影响内容。
- 會话與身份參數：最好從源头就不产生，而不是靠後續規則收拾。
几種常见的收口方式
canonical 指向干净版本
對排序、视图、追踪參數這類頁面，让 canonical 指向不带參數的主版本，是最省事的做法。注意 canonical 是建议而非命令，頁面本身仍需可訪問、内容一致，也不要在同一個頁面里寫多個互相矛盾的 canonical。
用 robots.txt 挡住
挡住抓取能省下抓取预算，但也有代價：一旦 URL 被 robots.txt 屏蔽，頁面上的 noindex、canonical 等信号就传不回来了，已经收錄的地址可能長期停留在索引里。所以更稳妥的顺序是，先让頁面能被抓取並给出 canonical 或 noindex，等索引狀態收敛後，再考虑是否屏蔽。對已经確認無用的會话參數，如果它来自站内連結，最好直接改掉連結生成逻辑。
把規范版本放進 sitemap
sitemap 是提示，不是白名單。只提交不带參數的規范地址，能减少搜尋引擎把參數版本当成獨立頁面的机會。但前提是站内連結也別到處撒參數地址，否則 sitemap 一邊收敛、内鏈一邊發散，效果會互相抵消。
追踪參數單獨處理
推廣連結上的 utm 通常不该被索引。可以在服務器端把它重寫到干净地址，或者用 canonical 统一指向干净版本。如果站点有统一的連結生成規則，從源头去掉參數是最省事的。
判断一個參數頁该不该留，可以問两個問题：它有没有獨立的内容，有没有獨立的搜尋需求？如果答案都是否，那它大概率只是系統副产品。
怎么確認收口有没有生效
不要只看改動当天。可以按下面的顺序观察：
- 抓取日誌里带參數的訪問占比是否下降，規范頁面是否拿到了更多抓取。
- 索引覆盖率报告中，带參數地址的數量是否在回落；回落通常以周為單位。
- 站内搜尋几個典型參數组合，看留下的那一版是否稳定。
- 核對 sitemap、内鏈、canonical 是否指向同一個版本，避免信号互相打架。
一些容易忽略的细节
- 參數顺序和大小寫不同的地址（?a=1&b=2 與 ?b=2&a=1）也可能被当成不同 URL，規范做法是固定參數顺序和大小寫。
- 分頁不要随便 noindex，它和參數頁的處理逻辑不同，通常用自指 canonical 加清晰的翻頁連結更合适。
- 如果某個參數頁确實带来流量，別急着清掉，先確認它是内容頁還是列表頁，再决定留還是並。
- 參數治理不是一次性的，新功能上线、活動頁改版都可能重新产生參數地址，定期看一眼抓取日誌比事後补救省力。
參數 URL 的問题很少能靠一條規則解决。更現實的做法是：把參數按用途分好類，對每類给出明确的信号，然後耐心观察索引缓慢收敛。這個過程的节奏由搜尋引擎决定，站点能做的是把信号理顺，而不是催收錄。