做站点运营的人大多有过这样的经历：改版前先搭一个测试站，随手把域名解析挂到公网，方便自己和同事预览。几天后翻访问日志，发现测试站上已经出现了搜索蜘蛛的访问记录，有些页面甚至已经进入搜索结果。测试环境本身不是正式内容，一旦被蜘蛛抓走，轻则浪费抓取配额，重则和正式站形成重复内容竞争。
测试站常见的几种泄漏路径
- 域名直接解析到公网 IP，没有任何访问限制，任何人或爬虫都能打开。
- 在正式域名下建了一个 /test、/v2 之类的子目录，蜘蛛顺着内链或旧日志就走进去了。
- 从线上完整拷贝数据库和模板，页面 URL、canonical、sitemap 全部和正式站一致。
- 测试环境没有独立的 robots.txt，或者直接把线上的放行规则复制了过来。
- 在后台提交 sitemap、使用抓取测试工具时，误把测试域名填了进去。
三层防护，按投入从低到高来
第一层：网络层先关上门
最省事的做法是不要让测试站暴露在公网。改成内网访问，或者用 IP 白名单、基础认证（Basic Auth）、VPN 限制访问范围。对蜘蛛来说，返回 401 或者干脆连不上，比返回一个可抓取的页面安全得多。需要注意的是，基础认证对外部来说是拒绝访问，但如果密码长期不改、地址又被外部链接引用，风险依然存在。
第二层：协议层给出明确信号
如果测试站必须临时公网可访问，比如要给客户演示，至少把 robots.txt 写成全站禁止抓取，并在服务器层面给所有响应加上X-Robots-Tag: noindex, nofollow。相比只写 robots.txt，响应头更难被误删，也不会因为有人把 robots.txt 换回线上版本而失效。
第三层：页面层再补一道
模板里统一加上 meta robots noindex，尤其是那些从线上一比一复制过来的页面。同时检查 canonical 标签——测试页如果还指着正式站的地址，等于在告诉搜索引擎这两个页面是同一份内容，反而容易让两边互相干扰。测试站的 canonical 应该指向自己，或者干脆去掉。
环境地址的写法也有讲究
不建议把测试站放在正式域名的子目录下，比如 www.example.com/v2/。原因有两个：一是这个地址天然继承了正式域名的信任度，被抓取的概率更高；二是子目录形式容易被导航、内链或者历史链接带到公网。更稳妥的做法是用独立子域名（test.example.com）或完全独立的域名，并且不要和正式站共用 cookie 作用域和 session。
从线上拷贝数据时容易踩的坑
- 数据库里的站点地址、资源域名还是正式站的，页面里生成的外链会指向线上，蜘蛛顺着走一圈又回到正式站。
- sitemap.xml 被一起拷贝过来，里面写的是正式站的 URL，等于主动把测试环境介绍给搜索引擎。
- 统计代码、客服脚本仍在运行，会往正式的数据里掺入测试流量。
上线前后的动作清单
- 搭建阶段：确定访问方式，能内网就内网，必须公网就加认证和全站禁止抓取。
- 开发阶段：robots.txt、X-Robots-Tag、meta robots 三处都设为禁止，并写进模板而不是手工添加。
- 上线前：全站替换域名，核对 canonical、sitemap、内链、静态资源路径是否都已改成正式地址。
- 上线后：确认 robots.txt 恢复为放行规则，noindex 标记和访问认证全部移除。
- 善后：如果测试站曾经公网可访问过，删除页面或返回 410，并观察一段时间日志，确认蜘蛛不再来访。
测试站被收录之后再清理，往往比一开始就挡住麻烦得多。与其事后一封封申请删除，不如在搭环境的第一步就把门关上。
另外，别只盯着自己的操作。同事之间共享预览地址、把链接发到群里、写进项目文档，都可能让测试地址流传出去。定期用日志工具筛一遍测试域名的访问来源，看看是哪些爬虫、通过什么路径找过来的，通常能发现一些被忽略的入口。