一個頁面如果有三種排序方式、两種视图模式，再加上投放带上的跟踪碼，同一個内容就可能對應十几個不同的 URL。搜尋引擎發現、抓取、判断重复，都要為這些地址花時間。處理參數不是為了把 URL 變得好看，而是让有限的抓取预算用在真正有内容的地址上。
先分清楚三類參數
不同參數的性质差別很大，處理方式也不一样，動手前先归類。
功能型參數
分頁、篩選、分類切換這類參數會真實改變頁面内容，典型如 page=2、category=shoes。它們通常有保留價值，尤其是分頁，但仍需保證每頁有可索引的正文，而不是只換了一批列表項。篩選组合容易爆炸的站点，要考虑是否让部分组合頁可抓、其余用 canonical 或 robots 收敛。
會话與跟踪參數
sessionid、utm_source、gclid、fbclid 這類參數不改變内容，只记錄来源或身份。站内連結里出現它們，几乎只會制造重复地址。投放落地頁需要带參數是正常的，但站内導航、面包屑、文章正文里的連結不應该带。
展示型參數
sort、view、layout、theme 這類參數只改變排序或外观，内容主体相同。它們通常不值得單獨收錄，可以用 canonical 指向預設版本。如果排序确實對用戶有用，考虑用路径而不是參數来實現，或只保留一两種高频排序。
處理顺序：先判断，再動手
常见的错誤是先屏蔽，再發現该 URL 其實是有價值的。建议按下面的顺序走：
- 抓一份站内近期的 URL 样本，按參數名分组，看哪些出現频率最高。
- 對每组參數，訪問带參數和不带參數的两個地址，比較正文、标题、主要連結是否一致。
- 内容一致的，優先在内部連結层面消除，让站内不再产生這類地址。
- 内容有差异但價值低的，考虑用 canonical 集中信号；已经收錄的观察一段時間再决定是否屏蔽。
- 確認完全無價值且不會從外部大量進入的，再考虑 robots.txt 屏蔽。
- 改完後看抓取日誌里這類 URL 的請求量是否下降，再判断下一步。
別急着用 robots.txt 一刀切
robots.txt 屏蔽能阻止抓取，但阻止不了發現。如果站外有大量連結指向被屏蔽的參數 URL，這些連結带来的信号會被浪費，而搜尋引擎仍然會记錄這些地址存在。更麻烦的是，被屏蔽 URL 上的 canonical 指向也不會被讀取，反而让重复信号更难收敛。
屏蔽适合處理“不该被抓”的地址，不适合處理“抓了但想合並”的地址。後者應该用 canonical 和内部連結来解决。
内部連結才是最该先改的地方
外部連結带跟踪碼难以控制，但站内連結完全在自己手里。站内連結是搜尋引擎發現 URL 的主要来源，改這里见效最快。
- 導航、面包屑、分頁、相關推荐里的連結，去掉所有跟踪參數。
- 分享按钮生成的連結，不要直接寫進頁面 HTML 的 href 里。
- 站内跳轉用 301，而不是带參數的中間頁。
- sitemap 只放規范 URL，不要放带參數版本。
- canonical 與 sitemap、内部連結指向保持一致，不要三個地方三種寫法。
一份简單的自查清單
- 站内是否還在产生带 utm 或 sessionid 的連結？
- 分頁、篩選頁是否有獨立正文，還是只有列表？
- canonical 是否指向預設版本，並且自身可抓取？
- 被 robots.txt 屏蔽的 URL 上，是否還挂着 canonical 或大量外鏈？
- 改完之後，抓取日誌里這類地址的請求比例有没有變化？
參數處理没有一次性完成的说法，站点在迭代，新的參數會不断出現。比較稳妥的做法是把它当成一項常規检查，在新功能上线前問一句：這個參數會不會产生一個新的、内容相同的 URL。