同一个页面，因为协议、主机名、末尾斜杠、路径大小写、参数顺序的不同，可能在服务器日志和索引里表现为好几个地址。搜索引擎把它们当成不同 URL 分别抓取、分别判断，页面能拿到的信号就被摊薄了。与其反复问「这个页面为什么收录不稳定」，不如先把 URL 写法收敛成一个版本，再观察收录状态。
一、先列出所有指向同一内容的写法
把站点上可能出现的变体列成一张表，逐项核对服务端返回什么。常见的有：
- 协议：http 与 https 各自可访问；
- 主机名：带 www 与不带 www，以及大小写混写；
- 端口：显式写出 :80、:443；
- 路径：/about 与 /About、/about 与 /about/；
- 默认文档：/ 与 /index.html、/default.aspx；
- 参数：顺序不同、追踪参数（utm_source、gclid、fbclid）；
- 会话类参数：sid、sessionid、PHPSESSID；
- 转义写法：中文路径直接写与写成 %E4%B8%AD 形式；
- 冗余符号：双斜杠、路径中的 ./ 与 ../、结尾多出来的 # 或空参数。
这张表不用一次列全，先把首页、栏目页、几篇核心内容页拿出来测，通常就能看出站点的 URL 生成习惯。
二、确认它们目前各自返回什么
对表里的每个地址，用 curl -I 或浏览器开发者工具看状态码和 Location：
- 全部 301 到同一个地址：说明服务端已做过统一，问题多半在页面内的链接写法；
- 部分返回 200、部分 301：索引里很可能同时存在两个候选地址；
- 返回 200 但内容略有差别（比如带参数的页面排序不同）：要判断这是不是同一个页面；
- 返回 404 或 500：先修可访问性，再谈收录。
同时对照日志中蜘蛛访问的完整 URL，往往能看到自己没意识到的写法，比如带上了分页参数、排序参数或一段来源标记。
三、归并的处理顺序
处理顺序建议从影响面最大的开始，改完一批观察一批：
- 选定规范版本：确定协议、主机名、是否带末尾斜杠、路径大小写规则，写成一句话，所有改动都以此为准。
- 服务器层做 301：http 跳 https、非 www 跳 www（或反之）、去掉重复斜杠、补全或去掉末尾斜杠。301 是明确的信号，比页面里的任何提示都直接。
- canonical 自指：每个页面写自己的规范地址，不要写到一个并不存在的地址，也不要在多个变体之间互相指。
- 统一站内链接：导航、面包屑、正文内链、站点地图只使用规范写法，避免同一个页面在不同入口下被写成两种地址。
- 参数收敛：追踪参数在服务端或边缘层剥离后再跳转；对内容无影响的排序、视图参数，考虑不生成可抓取的 URL。
- 观察：改完后看日志里各写法的访问占比是否向规范地址集中，索引中的候选地址数量是否慢慢减少。这个过程需要时间，不适合一天一改。
四、容易漏掉的细节
- 大小写混用：服务器和 CDN 规则对大小写的处理可能不同，路径统一用小写最省事。
- 301 不要串成链条：A 跳 B 再跳 C，链路越长越容易在中途断掉。
- 页面里的 JS 跳转不能替代 301，它更像普通链接，处理方式完全不同。
- 带参数的地址如果已经被索引，先确认它是否真的有独立内容；没有独立内容就做归并，不要简单屏蔽了事。
- canonical 与 301 指向不一致时，先以服务端跳转为准去排查。
- 站点地图只提交规范地址，别把各种变体一起写进去。
五、日常核对清单
- 新增页面是否只生成一个地址；
- 服务端跳转规则是否覆盖新出现的频道路径；
- canonical 是否与当前地址一致；
- 日志里是否出现新的变体写法；
- 站点地图是否只含规范地址。
URL 写法归并是件需要长期维护的事，新功能、新模板、新参数都可能重新制造出变体。把核对做成固定动作，比事后集中清理轻松得多。它不保证页面一定被收录，但能减少因地址歧义带来的判断成本。