测试域名、预览部署、临时给客户看的链接，本来只应该在小范围内流通，却偶尔会出现在搜索结果里。多数情况不是搜索引擎主动找上门，而是站点自己提供了可抓取的路径：内链、站点地图、robots.txt、外链或者部署平台的公开域名。
处理这类问题，顺序比工具重要。先确认范围，再定位入口，最后才谈清理，能少走很多弯路。
第一步：确认索引里到底有哪些不该出现的 URL
凭印象搜索容易漏。建议从三个来源交叉核对：
- 索引结果：用 site: 限定测试域名或预览域名，看是否有结果；对正式域名，可加上可能泄漏的路径关键词，例如 preview、staging、test 等。
- 索引报表：在搜索后台查看覆盖率或页面报告，按 URL 前缀筛选，确认哪些版本被当作独立页面处理。
- 服务器日志：搜索蜘蛛访问测试域名或预览地址的记录，能反推出它是由哪个来源带过去的。
把结果整理成一张表：完整 URL、所属域名、是否可访问、是否在站点地图里、有没有被内链指向。这张表后面每一步都会用到。
第二步：追入口，比追结果更重要
不切断入口，清理完还会再来一遍。常见的泄漏路径有几类，建议按顺序排查：
站内可控的部分
- 内链：检查模板、导航、页脚、面包屑里是否硬编码了测试域名，尤其是营销页、帮助中心和多语言站点。
- 站点地图：测试站是否生成了自己的 sitemap.xml 并提交过；正式站的 sitemap 里是否混入了预览或参数 URL。
- robots.txt：如果测试环境允许全站抓取，等于主动敞开大门，至少应先整体禁止。
- 重定向与 canonical：配置错误会把测试 URL 当作正式 URL 的规范版本，或者反向把预览地址写进 canonical。
站外和部署侧
- 预览部署：不少托管平台会为每次提交生成一个公网可访问的预览地址，而且默认可被抓取，也不受密码保护。
- 外链与分享：文档、邮件签名、社群消息、论坛回复里贴过链接，都可能被收录。
- 临时参数：带 token、带时间戳的分享链接，一旦被抓取，等于同一内容多出一个可访问版本。
第三步：按阻断、清除、等待的顺序处理
先阻断再清除，避免边清边漏。
阻断
- 测试环境整体加访问控制：密码保护、IP 白名单、内网访问，比任何 robots 指令都彻底。
- 确实需要公网可访问的预览，用响应头 X-Robots-Tag: noindex，效果比 robots.txt 更直接，因为 robots.txt 只能阻止抓取，无法阻止已收录的 URL 出现在结果里。
- 清理 sitemap 中的非正式 URL，并撤回对测试站点的站点地图提交。
清除
- 确定不再使用的页面，返回 404 或 410，410 的语义更明确，通常收敛更快。
- 内容还要保留但不想被索引的，用 noindex 并保持页面可访问，等索引移除后再决定是否彻底下架。
- 被其他页面反复引用的 URL，先把内链改到正式地址，避免蜘蛛一次又一次发现它。
等待
移除指令生效需要时间，取决于重访频率和抓取节奏。这段时间不建议反复改策略，也不建议同时叠加多种互相冲突的指令。
核对期间记录处理方式、处理日期、复查日期三列，比凭记忆判断有没有掉干净可靠得多。
第四步：回看核对，防止二次泄漏
- 按周或按月复查一次 site 查询与索引报表，观察不该出现的 URL 数量是否在下降。
- 检查部署流程：新分支的预览域名是否默认加了 noindex，是否默认加了访问限制。
- 检查内容发布规范：文档、邮件模板、对外物料里是否还残留测试链接。
如果清理后数量反而增加，通常是入口没关严，而不是清理手段无效。回到第二步重新排查一遍，一般都能找到原因。
这类问题的本质是 URL 被不该触达它的渠道发现了。把访问控制、索引指令和链接来源三件事分开核对，处理起来会比逐个删除页面轻松很多。