入口頁本身结构简單，出問题的地方往往不在頁面内容，而在地址。同一條入口頁 URL 後面挂上不同參數，蜘蛛看到的可能就是几十個“不同”的地址，抓取预算被摊薄，真正的主版本反而不容易被识別。這篇文章只讲參數這一件事：它從哪来、怎么收敛、怎么判断有没有收敛成功。

參數是怎么把一條入口頁變成多條地址的

蜘蛛判断頁面是否相同，主要看 URL 本身。只要參數键值對不一样，它預設就是另一個地址，需要重新抓一遍。哪怕返回的内容完全一致，它也不會自動帮你合並。

常见的參數来源大致有几類：

• 統計與追踪參數：utm_source、from、ref 之類，通常由站外連結或投放渠道带進来。
• 會话類參數：sessionid、sid、token，一旦出現在 URL 上，同一條入口頁每次訪問都是新地址。
• 功能類參數：排序（sort、order）、篩選（filter）、分頁（page）、视图切換（view=list）。
• 程序自動拼接：模板里寫死的 ?v=1、?t=時間戳，頁面本身没用到，但地址上一直带着。

前两類基本没有保留價值，後两類要分情况看：排序和篩選如果内容确實不同，属于正常頁面；如果只是同一批内容換了排列顺序，長期留在索引里意义不大。

規范化處理：先定主版本，再决定其余地址的出路

不管用哪種手段，前提都是先明确一條入口頁的唯一主地址，再把其他變体当成它的副本處理。

1. 在頁面上声明 canonical

在 head 里放 rel="canonical"，指向不带多余參數的主地址。這是最温和的做法，不阻断抓取，只是传递“谁才是主版本”的信号。注意 canonical 要指向同一條入口頁的干净地址，而不是指向目标頁——指向目标頁等于告诉蜘蛛這條入口頁是別人的副本，入口頁本身就没有存在必要了。

2. 用 robots 或服務端規則挡住無意义參數

會话 ID、纯統計參數這類，可以在 robots.txt 里按參數模式屏蔽，或者在服務端直接拒绝带這些參數的請求。前提是這些參數對真實用戶也没有用。如果站内連結本身就會带上它們，先改連結，再谈屏蔽。

3. 需要合並时用 301

当多條地址已经各自被收錄、内容又完全一样，可以考虑 301 到主地址。但要清楚這是相對不可逆的動作：跳轉鏈條不宜過長，也不要让跳轉目标本身又带參數，否則等于原地打轉。

4. 從源头统一站内連結

入口頁之間的互鏈、模板里的導航、頁脚連結，都尽量指向不带多余參數的地址。站内連結是蜘蛛發現地址的主要入口，這里带參數，前面的規范化和屏蔽都會打折扣。

怎么驗證參數已经收敛

1. 先從訪問日誌里筛出带問号的請求，按參數名归類，看看哪些參數出現频率最高。
2. 挑几個高频參數地址，和主地址對比頁面标题、正文首段、主要連結，確認内容是否真的相同。
3. 持續观察一段時間日誌，看同一參數地址的抓取次數是否下降、主地址的抓取是否更集中。
4. 在搜尋端的站点工具里查看已發現地址數量與收錄情况，作為辅助參考，不作為唯一依據。

這一步的目的不是追求“地址數越少越好”，而是確認蜘蛛把抓取集中在真正有價值的入口頁上。

几個容易踩的坑

• 一刀切屏蔽所有參數：分頁、篩選這類參數被一起挡掉後，正常内容也跟着無法被抓取。
• canonical 和 301 同时用且指向不一致：頁面声明一個主地址，服務器又跳到另一個，信号互相冲突。
• 用 JS 在加载後改地址：蜘蛛看到的往往是原始 URL，改地址對多數抓取行為没有帮助，反而增加排查难度。
• 只改模板不改歷史連結：老頁面里遗留的參數連結還在被爬，收敛效果會慢很多。

參數處理没有统一答案，判断标准只有一條：這條地址對用戶和蜘蛛是否有獨立價值。有，就保留並做好内容；没有，就统一到主地址上。

建议先用小批量入口頁试一遍：加上 canonical、清理站内連結、观察两周日誌。確認主地址抓取占比上升、重复地址請求下降後，再推到全量。參數治理是持續動作，新功能上线、投放換渠道都可能带回新參數，定期看日誌比一次性大改更實在。