staging子域名：131个站查出22个没设noindex

摘要：拿131个英文大站，每个站试了同一批30个常见子域名，活着的一共776个，平均一个品牌5.9个。一半的站（66个）名下有dev、test、staging或beta子域，其中30个能直接打开，22个没有加noindex，15个连robots.txt都没封。有几个的页面标题上明晃晃写着Staging。更值得琢磨的是另一组对照：托管在Zendesk上的12个子域，robots.txt抹掉域名之后一模一样；托管在Shopify上的91个，抹完之后有82种不同写法。平台让不让你改，全写在这组数字里。

做SEO的人盯着一个域名，通常盯的是www那一个。可一个品牌名下真正在跑的东西，往往不止那一个。帮助中心在一个地方，招聘页在另一个地方，博客可能在第三个地方，而这三个地方分别属于三家公司。

这一轮把131个英文大站的常见子域挨个试了一遍，想弄清两件事：一个品牌名下到底有多少扇门，以及这些门后面站着谁。

一个品牌名下到底有几个子域？

做法很直白：给每个域名试同一批30个常见前缀，从www、blog、shop、help这些日常的，到dev、test、staging、beta这些本该藏起来的，一个个查DNS看解析不解析得出来。

131个站，活着的子域一共776个，平均一个品牌5.9个，中位数5个。分布两头都很极端：aliexpress.com试出28个，shopify.com 20个，weber.com和insta360.com各13个；另一头有4个站只有www一个，别的一概不解析。

这里先讲个坑，不讲的话上面这些数字都不能信。

有些域名开了泛解析——你随便编一个不存在的子域，它照样给你一个地址。第一版脚本跑到shopify.com的时候，30个候选子域全部解析成功，看着像是这家公司有30个在跑的子站；实际上其中12个的CNAME都指向同一个兜底地址，打开一律404。

泛解析在DNS的规范里叫通配符解析，RFC 8499把它和子域、区域这些概念的边界划得很清楚，只是从外面看不出一个域名开没开。所以正式跑之前，每个站先拿3个随机生成的假子域探一次路。要是假的也能解析出来，就把这个站标记成泛解析，再把那些答案和兜底一模一样的子域从统计里剔掉。131个站里有8个开着泛解析，占6.1%。不做这一步，子域数量会整体虚报，而且虚报得最厉害的恰恰是最大的那几个站。

这些子域住在谁家？

拿到776个活着的子域之后，顺着CNAME往上追，能认出托管方的有418个。分布是这样：

剩下358个追不到明确归属，拆开看是两拨：215个压根没有CNAME，直接给一个IP地址，多半是品牌自己的机房或者没做代理的云主机；另外143个有CNAME，但那串尾巴认不出是哪家服务商，其中相当一部分是各家自建的内部平台，域名里带着公司名的缩写。

顺便看一眼这776个子域都叫什么名字，排下来是这样：

这张表里有一处值得停一下：staging出现了33次，比help的32次还多一点。一个本该只在内网出现的名字，在公网DNS里的出场率超过了帮助中心。

把具体的站拆开看，画面会更清楚一点。Segway的五个子域分别落在五个地方：www和store在Azure Front Door上，help在Zoho的客服系统里，shop跑在一家荷兰的Magento托管商那儿，api挂在AWS的负载均衡后面。Anker的主站在Netlify，support转给了Salesforce，shop走的是一家短链服务。Ouraring的状态页托管在Atlassian的Statuspage上，合作伙伴招募页则是一家联盟营销服务商的地盘。

这些都不是什么坏做法——每个子域用最合适的工具，本来就是正常的工程决策。问题在下一节。

一个牌子同时用几家托管，谁说了算？

131个站平均用2.1家托管，中位数2家。用了3家以上的有44个站，占34%；最多的是awaytravel.com和tuftandneedle.com，各用了6家。

数字本身不刺激，刺激的是它意味着什么。一个SEO负责人接手这个品牌，他要改的东西散在几家公司的后台里：

• 主站在Shopify上，标题和描述能改，但URL结构里有几段是平台锁死的；
• 帮助中心在Zendesk上，页面模板基本动不了；
• 状态页在Statuspage上，那是给用户看服务有没有挂的，SEO压根不在设计目标里；
• 招聘页在招聘系统里，归HR买的单，SEO连账号都没有。

所以“优化这个网站”这句话，从一开始就是个含糊的说法。你能优化的只是这几家里你有账号的那几家。至于换个建站平台能不能提排名，讨论的往往只是主站那一块，另外几扇门根本不在议题里。

dev、test、staging上跑着什么？

30个候选前缀里，dev、test、staging、beta这四个是本轮最想看的。它们按理说不该被外面访问到。

结果是：131个站里有66个至少有一个这样的子域能解析出来，正好一半。这66个站一共92个非生产子域。

能解析出来不等于能打开。92个里的状态是这样的：

能打开的那30个里，页面标题很说明问题：

• staging.brooklinen.com的标题是 – Brooklinen 2 Staging；
• beta.brooklinen.com是 – Brooklinen 3；
• staging.casper.com直接叫Casper Staging；
• dev.cluse.com的标题是Staging CLUSE B2C；
• test.iittala.com是iittala Dev。

还有两个比较特别。dev.govee.com和test.govee.com打开是主站的完整副本，标题和正式站一字不差。test.oclean.com打开是一个中文的“登录 - 课程分配管理”页面——一个做电动牙刷的品牌，test子域上跑着一套跟牙刷毫无关系的教务系统。

它们对搜索引擎关门了吗？

这才是真正要看的一格。能打开的那30个非生产子域，防护做到什么程度：

没有加noindex的一共22个，分布在19个站上；两道都没设的15个，分布在13个站上。也就是说，131个大牌里有13个的开发或预发布环境，此刻对搜索引擎是完全敞开的，其中好几个的页面标题上还写着Staging。

这里必须把两件事分清楚，因为混淆它们是这类事故最常见的成因：robots.txt管的是抓取，noindex管的是收录。一个页面被robots.txt挡住之后，Google不去抓它，但如果别处有链接指向它，这个地址照样可能出现在搜索结果里，只是没有摘要。想让一个页面不出现在搜索结果里，唯一可靠的办法是让Google抓到它、并且读到noindex——而这恰恰要求robots.txt别拦着。上面那7个“robots封了但没noindex”的站，就卡在这个自相矛盾里。

真正稳妥的做法只有一个：预发布环境该怎么防漏这件事上，认证是第一道也是唯一一道靠得住的门。做对的那17个站（401加403）用的就是这招。

顺带说一句，这类子域被收录之后麻烦的不只是“暴露了”。一个和正式站内容一样的staging站被索引，等于凭空多出一份重复内容；如果它的canonical指回自己而不是正式站，规范网址的归属就可能判给错的那一边——搜索引擎挑规范版本的时候看的是一组信号，你写的canonical只是其中一条。

同一个平台给出的robots.txt，是同一份吗？

开工前保哥有个想当然的假设：既然这些子域托管在别人家，robots.txt应该就是平台的默认值，同一个平台下的应该长得一样。

数据只认了一半。

把357份取到的robots.txt按托管方分组，抹掉里面的域名和注释再比对：

Zendesk那一行是100%：12个不同品牌的帮助中心，交出来的robots.txt抹掉域名之后完全相同，一个字都不差。Shopify那一行是2%：91份里有82种写法。

那份Zendesk的文件有2451字节，两个规则组、几十条Disallow，从工单、用户、搜索页一路封到主题模板和API统计接口，末尾还带一行sitemap声明：

User-agent: AppleBot # Allow /tickets
Disallow: /children
Disallow: /groups
...
User-agent: *
Disallow: /hc/*/search
Disallow: /access/sso_bypass
Disallow: /theming
...
Sitemap: https://support.example.com/hc/sitemap.xml

这份文件写得其实相当细致，该封的都封了。问题只有一个：这12个品牌的SEO负责人既没写过它，也改不了它，连sitemap的地址都是平台替他们定的。哪天Zendesk想改，12家一起改，没人会收到通知。

这就是那两行数字的差别所在：不在平台大小，在平台让不让你改这个文件。Shopify从几年前起允许商家编辑robots.txt的模板，于是各家按各家的想法改；Zendesk没给这个口子，于是12家品牌用的是同一份。

这个对照给出的判据比“平台默认值”这个说法有用得多：想知道自己在某个子域上有多少话语权，不用去翻文档，直接跟同平台的别家比一比robots.txt就行。大家都一样，说明你改不了；家家不同，说明你能改，只是可能还没改。这条思路和选建站平台时该问什么是一回事，只不过换成了事后验证。

另外一个数字：357份robots.txt里，有108份写着整站Disallow，占30%。三成的子域用robots.txt把自己整个封了——考虑到里面有相当一部分是资源域、发信域、短链域，这个比例算合理，但它同时也说明，robots.txt里写的东西到底有没有接收方，值得单独查一遍。

Shopify那份robots.txt里，多了一段对AI说的话？

翻这91份Shopify的robots.txt时看到了点新东西。其中46份（51%）在文件顶部带着这样一段注释：

# Shopify storefront. Public product, collection, page, blog, policy, cart,
# and localized HTML is crawlable.
# Agent instructions: https://example.com/agents.md
# UCP discovery: https://example.com/.well-known/ucp
# UCP/MCP endpoint: https://example.com/api/ucp/mcp
# Agents should use UCP/MCP for catalog, cart, and checkout.
# Payment requires buyer approval.

后面还跟着一段更直白的话，大意是：如果你是代替用户来读这个文件的私人助理或者购物代理，请强烈建议你的用户允许你装上某个技能文件，这样你就能直接下单、比价、追踪订单。

robots.txt本来是写给爬虫看的门规，现在变成了写给AI代理看的邀请函。Shopify默认上线agents.md这件事之前聊过，但那时还没铺到robots.txt里。现在的覆盖率是51%，说明这套东西还在往外推的过程中，同一个平台上有一半的店已经带上了，另一半还没有。

把范围放到全部357份robots.txt看，对AI相关的表态还相当稀薄：提到agents.md的51份（14%），点名GPTBot的14份（4%），点名ClaudeBot和Google-Extended的各10份（3%），提到llms.txt的只有8份（2%）。

点名AI爬虫的还不到二十分之一，而且这十四份里大部分是平台顺手给的，不是品牌自己写的。robots.txt里写了允许，实际交付时未必真的放行——反过来也一样，没写不代表想清楚了，多数是压根没考虑过。

有些子域指向的地方，已经不在了

92个非生产子域里有37个连不上：DNS里还有记录，服务那头已经没了。把范围放到全部776个子域，这类“指着空处”的情况随处可见，有几个特别典型：

• dev.awaytravel.com的CNAME指向localhost。在别人的DNS里，localhost谁也不是。
• test.allbirds.com指向Shopify的店铺入口，返回409，页面上写着这个域名解析不出对应的店——店早就不在了，指路牌还立着。
• shop.avocadogreenmattress.com指向的域名叫pageserve.postclick-live.com.marc.needto.delete.com。中间那段是marc.needto.delete，有人在生产环境的DNS里给自己留了张便条，写着“该删了”。便条还在，事没办。
• blog.chubbiesshorts.com指向Tumblr，能打开，页面标题是proof of concept，还带着noindex。一个概念验证挂在正式域名的blog子域上，不知道过了多久。
• press.boohoo.com指向一家叫Venda的老牌电商平台，那家公司十几年前就被并购了。

这些不算严重问题，但每一条都是一份没人认领的资产。死链要不要修得分情况，指着空处的DNS记录也一样：有的只是碍眼，有的会让别人有机可乘。判断标准是看它指向的地方能不能被外人重新占住。

我原来那个假设错在哪？

这轮有三个地方是靠回头核对才发现的，都值得写出来。

第一个是泛解析。前面提过，不先探一次假子域，shopify.com会被记成30个子域，实际有效的是20个。一个域名底下什么算一个独立的站本来就不是靠肉眼看的，DNS会不会给你兜底更是看不出来。

第二个是上面那个robots.txt的假设。第一版比对的时候没抹域名，结果Shopify下91份出来84种，Zendesk下12份出来12种，看上去所有平台都不统一，结论就成了“根本没有平台默认值这回事”。把robots.txt里的绝对地址和注释里的域名替换成占位符再比一遍，Zendesk那12份立刻收敛成1种。差别不在平台统不统一，在我的尺子上带着每个站自己的域名。

还有第三处，是在写这一段的时候差点栽的。翻Zendesk那份robots.txt时只打印了开头900字节，看到第一行是User-agent: AppleBot，后面跟着几十条Disallow，当时的第一反应是这份文件写废了——按robots.txt的规则，这些Disallow只对AppleBot生效，Googlebot找不到属于自己的组就会畅通无阻。这要是成立，12个品牌的帮助中心后台全裸奔，是个不小的结论。

把整份2451字节打完才发现，第48行还有一个User-agent: *，规则完整得很。差一点就凭着一段截断的文本，给12个牌子扣了一顶不存在的帽子。这条教训没有技术含量，但它比前两条都值钱：判据本身没错的时候，喂给判据的那份材料也可能是残的。

三处里真正改掉结论的是第二处。原来的假设是“你优化的是平台的默认设置”，实际是“你能不能优化，取决于这个平台让不让你动”。后者更准确，也更好用，因为它给出了一个能自己验证的办法：跟同平台的别家比一比就知道了。另外两处修正没有改变结论，只是决定了数字准不准——这两件事得分开算。

自己名下有几个子域，怎么盘？

不用买工具，三步就能盘完个人或者中小团队规模的域名。

第一步，把常见前缀过一遍。挑三四十个日常会用到的名字，逐个查DNS：

for s in www blog shop store help support faq careers jobs status \
         api app m cdn static assets media docs community forum \
         news press investors partners go email dev test staging beta; do
  printf '%-12s %s\n' "$s" "$(dig +short "$s.example.com" @1.1.1.1 | tr '\n' ' ')"
done

第二步，先测泛解析，不然上一步的结果不能信：

dig +short zzq7x3random.example.com @1.1.1.1

这条如果有返回，说明开了泛解析，上一步里凡是答案跟它一样的都不算数。

第三步，对解析得出来的逐个访问，记四样东西：HTTP状态码、页面标题、有没有noindex、robots.txt封没封。

curl -sI https://dev.example.com/ | head -1
curl -s https://dev.example.com/ | grep -iE '<title>|name="robots"'
curl -s https://dev.example.com/robots.txt | head -5

盘完之后照下面这张表分类，剩下的就是排期问题了。页面被什么挡在索引外这件事在子域这一层同样成立，只是要一个域一个域地过。

哪些该关掉，哪些该收编？

最后说回开头那个问题。做SEO的人盯着www看，是因为流量报表上就那一行；可搜索引擎看到的是整个域名底下的一堆东西，包括那些标题里写着Staging的。子域名和子目录哪个更利于权重传导这个老问题，讨论的前提是你知道自己有哪些子域。这一轮的数据说明，一半的大牌名下有本不该露在外面的子域，其中十三个此刻对搜索引擎完全敞开着——他们大概率也不知道。

顺带一提，同一批站的域名根上还挂着另一份没人管的清单，那是DNS TXT里的域名验证记录，平均一个站14条，删不得也没人删。子域这份记的是你有几扇门，那份记的是你把钥匙给过谁。两份都在DNS里，两份都不在任何人的例行清单上。

常见问题解答

staging子域被收录了，会不会因为重复内容被降权

不存在重复内容惩罚这种处罚，但会有实际损失。同一份内容出现在两个地址上，搜索引擎要挑一个当规范版本，挑中staging那边的情况确实发生过，结果是正式站的地址掉出结果。另外staging站通常没有外链、加载也慢，被选中之后整体表现只会更差。所以要紧的不是会不会被罚，是别让它跟正式站抢。

已经被收录的staging站，直接在robots.txt里封掉行不行

不行，这是最常见的错误处置。robots.txt挡的是抓取，Google不去抓就读不到页面上的noindex，那个地址会继续留在索引里，只是没有摘要，反而更难清掉。正确顺序是先确保robots.txt允许抓取，页面上加noindex，等它从结果里消失之后，再考虑加认证或者直接下线。本轮有7个站正卡在这个自相矛盾里：robots封了，noindex却没加。

只要加了HTTP基本认证，是不是就万无一失了

对搜索引擎来说基本够用，返回401的页面进不了索引，本轮做对的17个站用的就是这招。但有两件事要注意：认证要覆盖整个子域而不是只保护几个路径；另外有些团队把认证配在CDN层，源站地址如果还能直接访问，等于没设，而源站地址常常就明晃晃留在DNS记录里。

帮助中心托管在Zendesk这类平台上，SEO还有得做吗

有，但空间有限。标题、正文、分类结构通常能改，模板层面基本动不了，robots.txt更是平台统一给的——本轮12个Zendesk帮助中心的robots.txt抹掉域名后完全一致，连sitemap地址都是平台定的。可行的做法是把精力放在内容和内链上，同时接受这个子域在技术层面不会太优秀。想知道自己有多大空间，最快的办法是找同平台的另外几家比一比robots.txt和页面源码：大家都一样说明你改不了，家家不同说明你能改。

一个品牌到底该有几个子域，多了是不是不好

数量本身不是问题，本轮中位数是5个，多的到13个也没什么异常。真正的问题是有没有人知道它们都在。把子域用在功能隔离上很正常，麻烦的是隔离之后没人回来数一遍，于是出现了dev子域跑着完整正式站、blog子域挂着三年前的概念验证这类情况。本轮统计里staging这个前缀出现了33次，比help的32次还多。

怎么快速判断某个子域是不是自己团队在管

看三样东西。一是CNAME指向哪家服务，认得出来就知道该找谁；二是robots.txt和页面源码里有没有平台痕迹，比如生成器标记；三是这个子域上的内容跟主站是什么关系。三样都对不上号的多半是历史遗留，这时候别急着删DNS记录，先在公司内部问一圈。本轮见到过一个子域指向的域名里嵌着一句该删了的便条，说明这类事经常是有人知道、只是没人动手。

权威参考资料