很多团队在上线前会先部署一套测试站或预发布域名，用来验收、演示、给客户确认。它和生产站内容几乎一样，差别只在域名。如果没有做访问限制，搜索引擎很容易把它当成一个正常站点收录，于是同一批内容在索引里出现了两份。

测试站被收录的常见入口

• 域名曾经对外开放过一段时间，爬虫抓到一次后会持续回访。
• 测试站的 robots.txt 和 sitemap 没有单独处理，站点地图里列着和生产站相同的 URL。
• 内链、邮件、客服误发的链接、二维码或分享按钮指向测试域名。
• 生产站模板里硬编码了测试域名的绝对地址，比如图片、JS 或某个锚点。
• 其他站点或社交平台复制内容时，顺手带走了测试域名。

它带来的不只是多一份副本

通常不会立刻让排名掉下去，但会制造几个实际麻烦：索引信号被拆成两份，外链和分享数据落在测试域名上，用户点进搜索结果的可能是旧内容、报错页或带调试信息的页面。如果测试站和生产站的价格、文案、库存并不一致，还可能被当成内容质量不稳定的信号来处理。

处置顺序：先切断，再清理

1. 先限制访问

首选服务端访问控制：HTTP Basic Auth、IP 白名单，或干脆让域名只在内网解析，返回 401 或 403。爬虫拿不到内容，这是成本最低的止血方式，也能避免新的 URL 继续进入索引。

2. 必须对外可访问时用 noindex

如果测试站要给客户演示，至少在 HTML 的 head 里加 noindex，并确认它是服务端返回的，而不是靠 JS 注入。这里有个常见误区：robots.txt 里的 Disallow 只能阻止抓取，不能阻止已收录的 URL 出现在结果里。而且被 disallow 的页面，搜索引擎读不到你的 noindex，也就无法按你的意愿移除。

3. 让已收录的地址明确失效

已经进入索引的测试站页面，让它返回 404 或 410，或加上 noindex 后等待重新抓取。如果数量不多、内容明显是重复副本，可以先用站长平台的移除工具做临时屏蔽，但那是短期手段，长期还是靠状态码和 noindex 落实。

4. 检查生产站一侧

确认生产站页面的 canonical 指向自己而不是测试域名；检查模板、图片、脚本里有没有残留的测试域名绝对地址；检查 sitemap 是否混进了测试域名。这一步容易被跳过，但它决定了清理之后会不会再被带回去。

上线前的几个检查动作

• 部署时把测试环境设为不可公开解析，或默认开启基础认证。
• 测试站 robots.txt 默认全站 disallow，同时关键页面带上 noindex，两层一起用。
• 复制模板时替换掉所有绝对域名，静态资源尽量走环境变量。
• 发布前用 site: 语法查一遍测试域名，确认没有意外收录。
• 把测试域名的站点地图提交记录、站长平台资源一并删除。

处理这类问题的顺序通常是：先挡住访问，再让已收录的地址明确失效，最后回头检查生产站是否被牵连。反过来的话，往往一边清一边又被抓回去。

测试站被收录不算灾难，但拖久了会变成一批需要逐个清理的旧地址。在上线流程里加一步访问限制，比事后一个个移除要省事得多。