開發环境、測試环境、预览环境被搜尋引擎收錄，通常不是被针對，而是某個入口漏了出去。這類 URL 一旦進入索引，既會占用抓取资源，也可能让用戶搜到错誤版本的頁面。處理之前，先要弄清楚它是怎么被發現的。
一、不该被收錄的环境，通常從哪几個口子漏出去
- 没有环境区分配置。測試域名直接沿用了生产环境的 robots.txt 和頁面模板，既没禁抓，也没加 noindex。
- 内部連結用了绝對地址。複製生产代碼时忘了改域名，測試站点的頁面互相連結，甚至跳到生产站，蜘蛛顺着走一遍。
- sitemap 混入測試 URL。构建脚本生成多份站点地图，或者測試环境也開放了 /sitemap.xml。
- 公開分享。需求文档、群聊记錄、工單、演示連結里出現過的地址，都可能被別人贴到能被抓取的地方。
- 域名泛解析。任意子域名都能解析並返回 200，被掃到就等于暴露。
- 监控與第三方服務。可用性监测、预览部署工具生成的临时域名，不少預設没有訪問限制。
這些口子單獨一個都不致命，但同时存在时，URL 被發現只是時間問题。
二、几道闸门，强度和适用场景不同
常见的處理方式有四種，效果差別很大，不要混用。
- 訪問控制。Basic Auth、IP 白名單、VPN 内網訪問。頁面根本打不開，搜尋引擎自然也拿不到内容，是最干净的方案。
- robots.txt 禁抓。阻止蜘蛛抓取内容，但如果 URL 通過外鏈被發現，仍可能以只保留 URL 的形式出現在索引里，或者長期停留在已發現狀態。
- noindex。需要頁面能被抓取到才會生效。如果 robots.txt 同时禁止了抓取，noindex 就传不出去，两者互相打架。
- 切断入口。去掉所有指向该环境的連結、站点地图條目和公開分享记錄。這是配合手段，不是唯一手段。
比較實用的组合是：要么彻底不可訪問，要么允许抓取但明确 noindex。別一邊禁抓一邊指望 noindex 生效。
三、已经進了索引，怎么往回撤
第一步是先改狀態，再谈移除。顺序反了，往往白忙一场。
- 先让頁面返回 401、403 或 404，或者加上 noindex，确保索引里的地址下次被抓取时能收到不要收錄的信号。
- 如果頁面短期還必须能訪問，比如正在對外演示，可以用临时移除工具處理，但要知道它只是临时手段，通常几個月後失效，長期還是得靠上面的技術手段。
- 检查是否存在镜像：同一套内容可能挂在多個域名或子域名下，只處理一個，其他的還會冒出来。
- 留意 canonical。如果測試頁面的規范地址指向了生产頁，搜尋引擎有可能不索引測試地址、把信号合並到生产頁，但這属于顺带结果，不是可以依赖的常規做法。
處理完之後，索引里的记錄不會立刻消失，需要等下一次抓取和重新判断。期間不要反复改動配置，否則容易让狀態更乱。
四、避免下次再發生
- 环境配置分离：測試环境預設禁抓加訪問限制，生产配置只用于生产。
- 构建和部署时加校驗：基础地址、站点地图域名、規范地址指向，都應在發布前检查一遍。
- 新环境上线先加訪問控制，再考虑内容。
- 内部文档里统一說明哪些地址可以外發，哪些只能内網打開。
測試环境真正的問题不是被收錄，而是被外部訪問到了。收錄只是這個問题的一個可见後果。
把入口堵住、狀態改對，剩下的交给時間。收錄层面的清理，本质上是把不该公開的東西重新變回不该公開的样子。