站内篩選、排序、广告追踪這些功能，都會在 URL 後面挂上參數。對用戶来说方便，對搜尋引擎来说，可能意味着同一個頁面出現了十几個可訪問地址。參數 URL 要不要收錄，不能一刀切，先看它有没有獨立價值，再决定收口方式。
參數 URL 通常從哪来
把站内連結翻一遍，常见的參數大致分三類：
- 功能參數：篩選（?color=red）、排序（?sort=price_asc）、分頁（?page=2）。這類頁面通常由用戶主動操作产生，内容會随參數變化。
- 追踪參數：utm_source、gclid、fbclid、from=wechat 等。它們不改變頁面内容，只用于統計来源。
- 會话與临时參數：sessionid、sid、timestamp、随机缓存标记。這類參數對用戶和搜尋引擎都没有意义。
三類參數混在一起时，URL 组合會迅速膨胀。一個列表頁加上颜色、尺寸、排序、頁碼，很容易生成几百個入口。
搜尋引擎會怎么處理
搜尋蜘蛛發現带參數的連結後，通常會先抓取一部分。如果參數頁面内容與原頁面高度相似，搜尋引擎可能選擇忽略參數、归並到主版本，也可能把參數版本單獨收錄。具体行為並不固定，所以不建议把收口完全交给算法判断。
參數本身不是問题，參數带来的重复内容和抓取消耗才是。
先判断：這個參數頁面有没有獨立價值
處理之前，先给參數頁分堆。
可以保留的參數
- 篩選组合本身是用戶常见需求，比如“城市 + 戶型 + 價格区間”，並且頁面有獨立标题、描述和可讀内容。
- 分頁參數指向不同批次的内容，第 2 頁有獨立收錄價值。
- 站内搜尋结果的參數頁面通常不建议收錄，除非你已经為它做了獨立優化。
應当收口的參數
- 追踪參數：utm_*、gclid、fbclid、来源标记。
- 會话與随机參數：sessionid、sid、時間戳。
- 排序參數：同一批内容換個顺序，不产生新頁面。
- 容易被爬虫無限组合的篩選參數：多選叠加、空值组合。
處理顺序：從影响小的做法開始
- 内鏈和站点地图只放干净 URL。站内跳轉尽量使用無追踪參數的地址，减少蜘蛛發現參數入口的机會。
- 追踪參數用 301 或規范化處理。如果參數不影响内容，可以让带追踪參數的 URL 重定向到無參數版本，或者在頁面 head 里用 canonical 指向主版本。
- 排序、會话參數優先重定向。這類參數没有獨立内容，301 到預設列表頁比 canonical 更直接。
- 篩選參數按價值决定。有獨立價值的保留，但每一组可索引篩選都要有明确入口和 canonical 自指；没有獨立價值的，用 robots.txt 屏蔽抓取或加 noindex。
- 分頁參數保持可抓取。分頁不要用 robots.txt 屏蔽，也不要在第 2 頁加 canonical 指向第 1 頁，這样容易让後續内容失去被抓取的机會。
注意 robots.txt 控制的是抓取，不是索引。如果參數 URL 已经被外鏈指向，屏蔽抓取後仍可能出現在索引里，只是没有摘要。要让它登出索引，需要配合 noindex 或 301。
几個容易踩的点
- canonical 指向了带參數的 URL。检查模板輸出，別让 canonical 跟着目前 URL 走，把 utm 參數也带進去。
- JS 篩選直接改寫地址栏。用 pushState 生成大量可訪問 URL，蜘蛛执行脚本後可能逐一發現，需要在路由层做收口。
- 篩選和分頁叠加。?color=red&page=5 這样的组合，如果没有獨立内容，建议只保留一種參數维度。
- 站内搜尋頁被大量外鏈。搜尋结果頁參數多、内容重复，通常不值得收錄，發現後尽早加 noindex。
怎么驗證收口有没有生效
- 看服務器日誌里带參數請求的占比，如果持續偏高，說明蜘蛛還在反复抓取這些地址。
- 在 Search Console 的覆盖率报告里，關注“已排除”中與參數相關的分類是否在下降。
- 随机抓几個參數 URL，检查返回狀態碼、canonical 和頁面标题是否與预期一致。
參數 URL 不是一律要屏蔽。先分清哪些有獨立價值，再按“内鏈控制—重定向—canonical—noindex”的顺序逐层處理，比一次性全站屏蔽更稳妥，也更容易在後續排查中定位問题。