排查收录问题时，多数人关注的是“少了什么”，但另一种情况同样常见：索引里的页面数量比站点实际页面还多。点进去看，内容一模一样，域名却不对，比如 staging.example.com、直接绑定的源站域名、CDN 提供的临时域名，甚至是几年前换掉的老域名。这不是搜索引擎抓错了，而是这些地址本来就能被公开访问、能返回 200、内容与主站一致。爬虫没有义务替站长判断哪个才是正主。
先确认多出来的是哪一套
动手处理之前，先把“多出来的那套”定位清楚，否则很容易改错地方。用站点查询、外链工具和服务器访问日志交叉核对，通常能看出重复来自下面几类差异：
- 域名差异：预发布域名、源站直连域名、CDN 默认域名、历史域名。
- 协议差异：http 与 https 同时可访问。
- 主机名差异：带 www 与不带 www 各自返回 200。
- 路径差异：测试目录、旧版目录、多语言目录的镜像。
常见来源与处理成本
来源不同，处理难度差别很大，可以按下面的顺序逐一核对：
- 预发布或测试环境：最常被忽略。为了给同事看效果，把 staging 放到了公网，robots.txt 也没改。
- 源站直连域名：绕过 CDN 直接暴露，往往没有任何跳转。
- 历史域名：换域名时只在主站做了 301，老域名仍然解析并返回内容。
- 协议与 www 变体：服务端没做统一跳转，两个版本都能正常打开。
先决定留下哪一个
收敛的前提是有一个明确的“正主”。判断依据通常是：外链最多、品牌一致、能长期维护、配置最容易统一的那一个。其余全部按副本处理，而不是“先都留着，看哪个表现好”——两套站点各自积累信号，最后往往是谁都不突出。
处理顺序：从切断访问开始
- 能关就关。预发布环境加一层 HTTP 认证、限制来源 IP，或直接不对公网开放。返回 401 比任何标签都干净，因为页面根本不会被读到。
- 必须可访问时用 noindex。如果评审需要公开访问，就在副本页面加 noindex，并且不要把它放进 robots.txt 的 Disallow——被禁止抓取的页面，爬虫读不到 noindex，反而可能因为外链被索引成一个没有描述的条目。
- 长期方案是 301。确认副本不再需要独立存在后，整站 301 到主域名，而不是逐页慢慢改。
- canonical 只当补充。它是提示而非指令，也不能替代 301。它能帮助合并信号，但阻止不了副本被继续抓取。
- 统一入口。站点地图、站内链接、对外投放的链接，全部只写主域名，避免自己又制造新入口。
- 检查配置层。CDN、负载均衡、容器默认域名、对象存储的静态托管地址，都可能生成一个可访问的副本，而且不在代码仓库里，很容易漏。
noindex 与 robots.txt 的作用点不同
robots.txt 管的是“能不能抓”，noindex 管的是“抓到之后要不要进索引”。想让它从索引里消失，就需要让爬虫能抓到那个带 noindex 的页面。反过来，如果只是不想浪费抓取预算，比如参数页、无限翻页，用 robots.txt 更合适。判断标准很简单：你希望它从索引里消失，还是只希望它少被抓。
改完之后为什么还能看到
索引更新有延迟。已经进入索引的 URL，需要爬虫重新访问、读到 301 或 noindex，再经过一轮处理才会掉出去。这段时间里它继续出现在结果中属于正常现象，不需要反复改配置。更值得做的是看服务器日志：副本域名上是否还有抓取请求，返回的是 301、401 还是 200。如果一直是 200，说明某处配置仍在放行。
自查清单
- 副本域名是否还有公网解析，指向哪台服务器。
- 该服务器上是否还有独立的站点配置，跳转规则是否覆盖全站。
- 副本是否设置了 noindex，并且没有被 robots.txt 挡住。
- 站点地图、内链、外链里是否残留副本地址。
- CDN 与对象存储的默认域名是否可公开访问。
处理这类问题的核心，是让“哪个是正主”变成服务端配置上的事实，而不是指望搜索引擎通过内容比对猜出来。配置改对之后，剩下的交给重抓周期即可，不必因为几天内没变化就推倒重来。