很多站点的 URL 參數是“自然長出来”的：投放同事加 utm、产品加篩選排序、前端加會话标识，几年下来同一個列表頁可能有几十種參數组合。對訪客来说只是地址長一点，對搜尋引擎来说却是几十個内容几乎相同的地址，抓取预算、收錄判断和流量統計都會受到影响。下面整理一套可落地的參數治理思路。
一、先分清：哪些參數是真需求，哪些是噪音
治理的第一步不是動手屏蔽，而是把參數分類，因為不同類別的處理方式完全不同。
- 追踪類：utm_source、utm_medium、gclid、fbclid 等，不改變頁面内容，属于最该被規范化的一類。
- 篩選排序類：?color=red、?size=40、?sort=price 等，會改變頁面呈現的内容，是否要被抓取取决于這些组合本身有没有搜尋需求。
- 分頁類：?page=2、?p=3，属于正常導航的一部分，通常不该屏蔽。
- 會话與随机類：sessionid、sid、時間戳、随机數，每次訪問都不同，最容易制造出無穷無尽的地址。
- 功能類：?print=1、?preview=1、?ref=xxx，多數没有獨立價值。
二、几種處理手段，各自适合什么场景
1. canonical 指向規范地址
對内容相同、只是參數不同的頁面，在參數頁輸出指向無參數版本的 canonical，是最省事也最安全的做法。注意 canonical 要指向真實可訪問的地址，不要指向 404 頁面或需要登入才能看到的頁面。
2. robots.txt 屏蔽，要谨慎使用
Disallow 能阻止抓取，但被屏蔽的 URL 依然可能因為外鏈而被收錄，只是没有内容摘要。如果這個參數頁本身有價值，屏蔽反而會让它失去被發現的机會。只對確認無用、且數量可能無限增長的參數（比如會话 ID、随机排序值）使用。另外，屏蔽規則寫得太宽，例如直接寫 Disallow: /*?，很可能连正常的篩選路径一起挡掉。
3. 從源头减少參數
- 追踪參數只在投放落地頁出現，站内跳轉时统一去掉。
- 篩選结果能用静態路径就不要用參數，例如 /phone/black/ 優于 ?color=black。
- 會话标识優先用 Cookie 承载，不要寫進 URL。
- 排序、视图切換等纯展示類參數，尽量用前端交互處理。
4. 301 重定向到規范版本
對于已经产生外鏈、但确實不需要獨立存在的參數頁，可以做 301 跳轉到規范地址。注意別做成鏈式跳轉，也別让跳轉目标又跳回来，否則蜘蛛和訪客都要多绕几圈。
三、一套可执行的治理流程
- 從服務器日誌或搜尋後台導出近 30 天被訪問的带參數 URL，按參數名归類，統計各自數量。
- 给每個參數打标簽：保留、canonical、屏蔽、重定向，寫成清單存档。
- 先在測試环境驗證規則，確認没有誤伤列表頁、搜尋结果頁等正常功能。
- 上线後观察 2–4 周，對比抓取量與带參數 URL 數量的變化。
- 把這份清單寫進發布流程，新加參數前先過一遍。
四、几條容易踩的坑
- 用 robots.txt 屏蔽 ?page= 或 ?sort=，结果分頁和排序頁里的内容再也没机會被發現。
- canonical 全站無差別指向首頁，等于告诉搜尋引擎所有頁面都是首頁的副本。
- 參數頁和規范頁同时可訪問、都返回 200，彼此之間又没有任何關联信号。
- 只在 robots.txt 里屏蔽，却没有在站内連結里去掉參數，導致蜘蛛反复撞墙。
參數治理不是一次性任務。站点功能一改，參數就可能多出来几個。定期（比如每季度）复查一次日誌里的參數分布，比出問题後再回头找原因要省事得多。