有一类事故特别让人生气：正式站的内容还没定稿，搜索结果里先冒出了测试站的标题、测试站的产品图，甚至测试站的表单。预发布站的风险不在技术难度，而在它默认就是一个公开可访问的 WordPress 站点——装好、导入数据、解析指向某个域名之后，它在互联网上就是活的，剩下的全靠你记着手动收口。 多环境切换时，继续用WordPress 多环境配置同步清单核对哪些设置不应被覆盖。
它为什么会被看见
路径通常有三条。第一，地址是公开的，机器人都能访问；第二，主题或插件顺手把页面提交给了搜索引擎平台，或者生成了一份站点地图把你的测试地址登记进去；第三，最容易被忽略的一条——它和正式站共用同一个地址空间：同一域名下的子目录、同一个数据库、同一批链接，测试内容与正式内容混在一起时，连"这是测试站"这个判断都做不了。
还有一层现实约束要记住：robots meta 这类设置只有在抓取被允许时才会被读到，也就是说"用 robots.txt 把抓取挡掉，同时又希望 noindex 生效"这两件事互相冲突，官方在这一页上把这条限制写得很明确。robots meta 标签与 X-Robots-Tag 的规范规则可以写在页面 head 里，也可以走 HTTP 响应头，后者对不方便改模板的站点更实用。
三种收口方式，从强到弱
- 根本不让访问：加访问密码、限制来源地址、或者只在公司网络里能打开。这一层挡住了人，也挡住了爬虫，是首选。
- 让它没有内容价值：清空内容、加一层登录、或者只保留一个占位页。它挡不住好奇的人，但能减少被当成正常站点处理的可能。
- 明确不索引：对确实需要对外可达的预发布地址，输出 noindex 并确认它真的出现在响应里。
如果预发布站和正式站同域、共用链接，还有第四件事要一起做：把希望被收录的那个地址写成规范地址。Google 把指定规范 URL 列成几种方法，其中 rel="canonical" 是影响最强的一种，站点地图里的地址也会成为规范地址，官方还说明这些方法可以叠加使用。Google 关于指定规范 URL 的几种方法关键不是加标记，而是确认标记指向的是正式站那一版。
怎么配才不靠记忆
把收口写进建站流程，而不是写进待办清单：新建预发布环境的模板里默认带上访问密码或来源限制；默认不提交搜索引擎平台；默认不生成站点地图或生成时排除测试地址；每次部署后用一条命令或一个检查清单过一遍。如果条件允许，把这套检查做成一个可重复执行的脚本或计划任务，让它在每次部署后自动跑一遍，而不是指望谁记得。
已经漏出去过的地址要单独处理：确认它们对应什么内容，能对应到正式页的用永久重定向指过去，没有对应内容的让它返回 404 或 410。Google 对这两类的区分是：永久重定向（301、308）会让搜索结果显示新的目标地址，临时重定向则仍显示原地址——所以临时导向别处不要用 301。Google 关于重定向类型与适用场景的说明
哪些情况不适用这套做法
- 预发布站本来就打算公开（比如公开测试环境、对外 demo）：那要处理的是"不要被当成正式内容"，而不是不收录。
- 内部成员使用的子站：访问限制比索引设置更值得做，先做前者。
- 同一份内容同时存在于两个域名、且两边都要被收录：这不是预发布问题，是重复内容问题，得按规范地址的思路重新设计。
- 被邀请的外部测试者需要免登录访问：这时索引设置是唯一的防线，务必逐页确认标记真的输出了。
机制层面还有两处可以直接复用现成规范：索引标记该怎么落地，站内搜索页被收录时先查 noindex 有没有真正输出给的是同一类查法；同域场景下规范地址该指向谁，canonical 和外链指向的 URL 有什么关系讲的是这一层。而预发布环境本身属于托管验收范围，WordPress 托管验收清单里的安全运维项里有一项就是它。
怎么验证确实收住了
用 site: 查你的预发布地址前缀，看有没有结果；官方也提醒过这个结果并不总是完整的，大站更不可能看全，所以要用具体前缀一次查一个地址。Google 关于 site: 查询算符的说明然后分三步确认：直接访问该地址，看响应里有没有该有的标记；清空缓存后再看一次，排除只是缓存里没有；隔几天再查一遍索引是否在退出。官方没有公布任何"标记之后多久会退出结果"的时间口径，所以只能用复查代替等待。
收口这件事做久了会形成习惯：新建环境的第一件事不是导入内容，而是先把它关起来。等哪天你在搜索结果里看到自己的测试地址，就说明这个流程又漏了一次。
