带参数的页面 canonical 怎么写，三种场景

参数页 canonical 的判断标准只有一条：这个带参数的地址，能不能独立回答一个搜索问题。能，就指向自己；不能，就指向无参数的规范页。

场景一：筛选参数

如果某个筛选组合有稳定的搜索需求，比如"支持私有化部署的 CRM"，最好做成静态路径页，别让参数页参与排名。没有独立需求的组合，canonical 指向无参数的列表页。

这里有个常见错误：把所有筛选页都 canonical 到首页。2026 年 6 月一个 API 目录站就这么干，5 万个参数页的 canonical 全部指向首页，结果蜘蛛把首页当成所有页的规范版本，参数页整批掉出索引，首页也承担了不该有的主题。

场景二：排序参数

排序不改变内容的集合，只改变顺序。canonical 指向无排序的默认页，?sort=price 和 ?sort=new 都指向默认列表。用户和蜘蛛都能正常访问，只是不单独收录。

如果排序页有独立价值——比如"最新发布"本身是一个栏目——那就不要参数，做成独立路径。

场景三：追踪参数

utm、gclid、ref 这类参数，优先级从高到低是：链接生成时别加 > 服务器 302 清洗 > canonical 指向干净地址。canonical 是最后一道兜底，不是方案。只靠 canonical，蜘蛛每次还是会抓一遍带参数的地址，浪费的抓取预算不会回来。

怎么验证写对了

Screaming Frog 导出所有带参数的 URL 和它们的 canonical，逐条看指向：指向首页的、指向 404 的、指向自己的分别是哪些。GSC 看"Google 选择的规范网页与用户指定的不同"这一项，数量大说明你的声明和 Google 的判断不一致。日志里看参数 URL 的抓取量有没有下降。

我们在模板里怎么写

给前端一个判断函数，输入当前 URL 和参数白名单，输出 canonical。有白名单里的参数就保留，其余全部剥掉。这个函数放在服务端渲染层，别放在浏览器里执行——蜘蛛拿到的初始 HTML 里必须已经有正确的 canonical，靠 JS 改的不算数。

我们给客户交付时会附一份参数清单：哪些参数允许进 URL、哪些必须清洗、哪些保留但不索引。开发照着实现，比口头说"参数要处理一下"有效得多。

一个补充

分页参数别和筛选参数混在一起处理。分页页 canonical 指向自己，筛选页 canonical 指向无筛选版本，两套规则分开写，模板里也要分开实现。

立场

能静态化的页面就别用参数，参数页的 canonical 是兜底不是方案。一个站如果靠 canonical 治理参数，说明前端和产品还没把 URL 设计当回事。