preconnect指着的域名，有8个已经不存在了

摘要：122个海外品牌站的首页上一共3102条资源提示，其中201条指向的域名在整个页面里连一次都没被用到。拆开看差别惊人：打包工具自动生成的那1642条模块预加载，空转数是0；人手写进模板的419条预连接，125条空转，占29.8%。逐个域名验活还查出8个已经不解析的主机，其中6个属于同一个品牌的中国站子域，1个是某下线服务的旧地址，还有1个干脆是没被替换的模板变量。文中给出分类型空转率、重复声明规模、字体预加载的101条常见错写、两次快照的变更率，以及一套删之前必须先确认的判据。

八月二十日有篇文章翻出了一件旧事：二十多年前做SEO的人爱把关键词写成白底白字藏在页面里，如今同样的手法出现在一份法庭文件里，只不过藏的是给大模型看的指令。

这件事真正的看点不是手法多新，而是页面上给机器看的那些东西，通常没有人负责清理。用户看不见它，视觉走查看不见它，改版的时候也没人会专门去问一句它还在不在用。

网页里这类东西不止一种。今天说的是最不起眼的那一类：写在头部、告诉浏览器提前去连接某个域名的资源提示。它每一行都只有几十个字符，加进去几乎没有成本，删掉也没人会注意。

这类提示的处境有点特殊。它不像标题描述那样会被人反复打磨，也不像脚本那样出错就白屏。它介于两者之间：出了问题不会有人发现，做对了也没人会夸。于是它就一直躺在那儿，跟着模板从一次改版走到下一次改版。

更要命的是，它描述的根本不是自己站上的东西——它描述的是你跟哪些外部服务有往来。而外部服务换起来，可比模板勤快多了。

保哥把这批品牌站的首页快照翻出来，把每一条提示指向的域名跟页面上实际加载的资源逐一比对，想看看这些提前连接到底连给了谁。

首页上那些预连接声明，有多少真的连上了东西？

先把这件事的判据说清楚。一条提示写着某个域名，意思是浏览器应该提前跟它握手，因为待会儿要从那儿取东西。判断它有没有白写，只要看这个域名在页面上有没有对应的资源被加载。

还有一件事很多人不知道，抓取程序压根不执行这些提示，它们只对真实用户生效。

加载快慢到底怎么换算成排名，页面速度影响SEO的机制与优化优先级那篇讲了链路。

这几种写法各管什么先分清楚，五种资源提示技术的逐项对比是动手前该看的一份。

怎么算一条空转

比对分两层。硬判据是这个域名有没有出现在页面加载的资源地址里——脚本、样式表、图片、字体、内嵌页面、视频源、背景图，全都算。软判据放宽到整个页面文本里有没有再提到过这个域名，这能把藏在脚本字符串里的接口地址也捞进来。

抓下来的东西有没有内容得先确认，132个独立站首页有28个是空壳量的是同一种落差。

看不见的资源比看得见的更麻烦，页面上近一半的资源在监控里是一排零就是这么来的。

两层都没命中，才算完全空转。这个口径是偏保守的，也就是说真实的浪费只会更多。

这次没算进去的几件事

有四类情况被排除在外，先说清楚。

用别人的数据前先校准口径，六步校准法能挡掉大部分噪声。

逐条查一百天不如按模板抽样半天，按页面模板抽样的审计做法更适合大站。

一是只在特定交互后才加载的资源。用户点开聊天窗、展开尺码表、切换支付方式，这些动作触发的请求不在静态源码里。所以软判据那一层特意放宽到了全文搜索，能把大部分写死在脚本里的接口地址捞回来。

二是首屏之后才用到的域名。抓取拿到的是完整HTML，不区分首屏与非首屏，所以只要页面上有对应资源就算命中，不管它在第几屏。

三是指向自己域名的提示。这类在样本里不少，但它们的成本和收益都跟第三方不是一回事，单独统计意义不大，只在总数里出现。

四是抓不到首页的站。168个站是能拿到完整首页的那一批，剩下的不在任何分母里。

样本与规模

168个品牌站的首页快照里，122个站写了资源提示，一共3102条。每站的中位数是12条，平均25.4条。

首页承载的东西越来越多，架构搭错了爬虫根本走不到商品页是另一头的问题。

装得越多头部越乱，应用栈精简、性能治理与冲突排查是同一个减法。

很多站的头部本来就带着几行没人要的东西，怎么把默认塞进来的那几行去掉有具体写法。

写得最多的一个站有244条，其次是192条、169条、130条。这些数字本身就值得看两眼——一个首页需要提前握手244次，这件事怎么想都不太对。

452条没加载资源，201条连提都没提

3102条里有452条指向的域名没有任何资源被加载，占14.6%。把口径收紧到整页文本都没再出现的，还剩201条，占6.5%。

写下去却没有接收方的声明不止这一种，有多少条规则压根没人在读比想象中高得多。

这类欠账攒起来相当可观，技术债怎么排查和分批偿还给了可执行的顺序。

第三方那边自己变了你也不会知道，两天半里四分之一的站悄悄换了东西是一次实测。

站级看：122个站里53个站完全没有空转，6个站的空转比例过半，没有任何一个站是全部空转。空转最集中的几个站是这样的：

为什么构建工具生成的那批一条都不空转？

把3102条按类型拆开之后，出现了本文最干净的一组对照。

把检查接进流水线才不会反复，自动化为什么不能放在最后一段做讲的正是这件事。

这件事最终要落到前端手上，前端工程师配合SEO的七个动作点里有具体分工。

五种类型，空转率差着几十倍

这类小事攒起来才有意义，九个被低估的谷歌SEO技巧也是同一种量级。

这些指标到底值不值得投，行业基准与投入产出测算能帮你先算一笔账。

同一批资源里谁先谁后也能显式指定，浏览器的资源优先级怎么被改写是相邻的一套机制。

前两类加起来1864条，空转数是零。后两类加起来676条，空转197条。

这五种写法在HTML规范定义的链接关系清单里各有各的语义，不是一回事，但它们共用同一个书写位置，也共用同一种命运。

差别不在重要性，在于谁把它写出来的

前两类几乎全部由打包工具在构建时自动生成。工具知道这次构建产出了哪些代码块、哪些块会被哪个页面用到，于是把对应的提示写进去。下一次构建时，这批提示会被整个重新生成一遍——依赖变了，提示跟着变。

第一年最容易踩的都是默认配置，跨四种建站系统共有的12项隐性失分可以逐条对照。

自动化不是哪天突然坏的，它从第二周就开始走形而没人发现说的是同一种慢性失效。

后两类通常是人手写进模板的。某天要接一个新的分析工具，文档说加一行提前建连能快一点，于是加了。这一行从此躺在模板里，没有任何东西会在依赖变化时提醒它该走了。

这条对照能解释掉大部分现象

顺着这个思路再看前面那张站级空转表就明白了：空转多的站不是技术差，而是这块配置的年头久、经手的人多。空转为零的53个站里，有相当一批压根就只写了构建工具生成的那几类。

基建的档次也会决定这块配置的命运，共享、独立还是云主机怎么选先算清那笔速度账。

选平台时就该问清楚默认行为，托管、自建还是纯代码怎么选把各自的代价摊开了。

主题选得糙，头部就会一直乱，从代码、指标到页面构建器怎么挑主题有判断标准。

换个说法：一条配置能不能长期保持正确，跟当初写它的人有多认真关系不大，跟它背后有没有一个会自动重写它的程序关系极大。

那4条预加载空转是怎么回事

资源预加载这一类空转率只有0.7%，4条。它的特殊之处在于必须写明要预加载的具体文件，而不只是一个域名——文件路径写错了浏览器会在控制台报错，写对了就一定会被用到。

结构化数据也是写得越具体越好查，一次扒清页面五种格式的字段缺漏可以顺手做。

写得具体才查得出来，一页图片的属性怎么批量体检是同一种可验证性的例子。

这也提示了一个通用的改法：把声明写得越具体，它出错时越容易被发现。只写一个域名的声明，错了是完全静默的。

用模块预加载的那36个站是什么来路

1642条模块预加载集中在36个站上，平均每站45条，这个密度远高于别的类型。它们的共同点是前端用了现代打包工具做代码分割——页面被拆成很多小块，按需加载，构建时顺手把这一页需要哪几块写进头部。

换成前后端分离之后不少基建要重搭，清单、重定向与规范网址集体失分是常见的第一课。

代码分割这套打法有它的代价，三种渲染方式下的引用率差异实测给了量化的落差。

另外86个有提示的站一条模块预加载都没有。这不是它们做得差，只是技术栈不同：用传统模板渲染的站没有代码分割这回事，自然也就没有这类提示。

所以这组对照还有一层含义：把配置交给程序生成，前提是你的技术栈里真的有那个程序。手写模板的站没有这个便利，只能靠流程和检查来补。

被指着却已经不解析的8个域名是谁？

空转还只是没用上，更彻底的一种是那个域名今天已经不存在了。把所有第三方主机拿去逐个查一遍，一共196个，其中8个在域名解析这一层就查无此名。

域名解析是排障的第一层，从解析、线路到分发网络的网络层排障可以照着往下走。

页面上指向已经不存在的东西不止这一处，死链批量检测、分类到提交的一条龙能顺手一起做。

6个属于同一个品牌的中国站

这8个里有6个来自同一个站的首页：分析、静态资源、安全下单、通用服务、账号统一登录，各占一个子域，全部挂在同一个中国站主域下面。

在中国做站的那套基建跟海外不是一回事，备案、速度与合规怎么权衡是另一篇的主题。

子域名这种结构本身就容易留下遗迹，子域名还是子目录、权重怎么传导有六个维度的对照。

它们在页面上的角色是域名预解析，也就是让浏览器提前把域名翻译成地址。今天这一步会直接失败，因为解析不出任何结果。

需要说清楚的是，这不代表那个品牌的中国业务怎么样了，只代表这6个具体的子域名今天在公开解析里没有记录。而首页上那几行提示还老老实实指着它们。

1个是已经下线的服务旧地址

另一个不解析的主机来自某个电商平台的产品评论服务。那个服务几年前就停止提供了，商家被要求迁到别的方案上。

每年清一次外部依赖很有必要，12个站样本里的四维冗余与八步瘦身给了顺序。

第三方换了东西你这边会当场出事，脚本下载完了一行都没执行就是那种情形。

迁移那一步显然做了，因为页面上已经看不到它的任何资源。没做的是回头把头部那一行删掉——它不属于任何一次迁移清单，因为它不影响功能。

还有1个根本不是域名

最后一个查无此名的主机长这样：一对花括号包着一个变量名。这是模板引擎里的占位符，本该在渲染时被替换成真实地址，结果原样输出到了页面上。

解析这一层的边界很容易踩空，脚本比浏览器早八千字节就瞎了说的也是解析器的脾气。

模板里混进不该有的字符后果可大可小，看不见的字节把网页搞成白屏是同一类隐形故障。

浏览器拿到这一行会怎么处理？它会试着把这串字符当域名去解析，然后失败。整个过程没有任何报错会浮到运营那一层。

这一条特别值得单独拎出来，因为它证明了一件事：这块配置没有任何人在看。一个明显到只要打开页面源码就能发现的错误，能在首页上留到今天。

剩下那些查回来的状态码不能直接当死活看

196个主机里有80个返回正常，27个连不上，其余是各种拒绝或未找到。这里必须提醒一句：内容分发网络的根地址返回未找到是完全正常的，它本来就不提供根路径的页面。所以那50个未找到里绝大多数是活的。

分发网络那一层会改变你看到的东西，六层缓存与边缘路由对SEO的影响值得先弄明白。

状态码要会读才不会误判，几个常用状态码各自该在什么场合用有一张速查表。

能当硬证据的只有解析层的失败，也就是前面那8个。这条边界不划清楚，很容易把一份体检报告写成危言耸听。

那27个连不上的主机要分开看

还有27个主机域名能解析，但根地址请求不回来任何东西。这一类不能直接判死。

按地区区别对待是常见做法，按地址自动跳转带来的那些副作用比想象中大。

要弄清对面怎么看你再谈待遇，120种爬虫标识的分类与真假验证是一份可以照做的清单。

拦截往往发生在你看不见的那一层，防火墙到底拦不拦得住那些程序答案没那么简单。

常见的原因有三种：只对特定地区开放，只接受特定来源的请求，或者干脆只响应某几个具体路径而不响应根路径。前两种在跨境场景里非常普遍——我这台机器在境内，拿到的待遇跟目标用户所在地区完全不同。

这里要固化一条做法：跨站测量的每一个失败，都要先分清是这个地址坏了，还是这台机器不被接待。不做这一步，一份报告里的失败率可以轻松虚高一倍。真正能拿去当结论的，只有解析层那8个——域名不存在这件事对谁都一样。

同一个域被声明两遍甚至十遍，是怎么攒出来的？

3102条提示里有2196条是重复的——同类型、同域名、同用途，在同一个页面里出现了不止一次。涉及98个站。

页面里冗余的字节能压掉一部分，免插件压缩HTML的做法与叠加策略是配套的一手。

模板批量生成的东西撞车是常态，插件和主题各冒出一套标记怎么归一是同一类清理。

重复最多的几个站，量级相当夸张

写了244条提示的那个站里有230条是重复；192条的那个站重复189条；169条的重复166条。也就是说，这些站的提示数量看着吓人，实际去重之后往往只剩十几条。

这类重复几乎不可能是人手敲出来的。更可能的成因是模板片段被循环渲染，或者同一个组件在页面上出现多次而每次都带上了自己那份头部声明。

重复本身伤害不大，但它掩盖了真问题

浏览器对重复的提示会去重处理，所以额外的连接不会真的发起。真正的代价在两处：一是页面体积白白变大，二是任何人打开源码想清点这块配置时，都会被这堆重复淹没。

格式乱和体积大是两件事，美化、压缩与前端性能的真实账算得比较清楚。

数据乱到清点不了就没人会去治，五大指标的单一事实来源怎么建是配套的治理办法。

清点不了，就没人会去清。这是一个自我维持的循环。

另一种冗余：同一个域既预解析又预建连

还有74条属于另一种冗余，涉及30个站：同一个域名既写了域名预解析，又写了提前建连。

这类没人维护的字段到处都是，响应头里248个死字段、多数不是你写的量的是同一种存量。

还有一类为保险而写的双份配置，开启严格传输安全的配置与回滚也常被写成两套。

这两件事是包含关系——提前建连本身就包含了域名解析这一步，还额外做了传输层握手。两个都写，后面那个把前面那个完全覆盖了。

这种写法通常来自一种保险心态：不确定浏览器支持哪个，两个都写上。这个理由在很多年前成立，今天已经不成立了。

重复到底是怎么攒出来的

把重复最多的那几个站的源码翻开，成因基本是三种。

模板继承带来的重复到处都有，头部标签在模板层怎么统一给了一个小而完整的例子。

组件是设计和前端交界处的产物，设计师配合SEO的七个动作点能把交界处的问题拦下来。

第一种是组件自带。一个商品卡片组件里写了它需要的图片域名提示，页面上放了48个商品卡片，这一行就出现48次。写组件的人当时并不知道它会被这样使用。

第二种是多个应用各写各的。装了六个第三方应用，每个都往头部塞自己那份，其中四个用的是同一个内容分发域。

第三种是模板继承。父模板写了一份，子模板为了保险又写了一份，两边都没删。

三种成因有个共同点：每一处单独看都是合理的，问题只在合起来之后才出现，而没有人站在合起来那个位置上看过。

字体预加载那101条为什么等于白写？

资源预加载这一类总共562条，空转率极低，看上去是最健康的一类。但它有另一种毛病，而且发生率不低。

换成非拉丁字符集代价会翻好几倍，英文站几十KB的字体到了小语种站变成首屏最大一块是实测出来的。

字体加载这件事本身就有一套机制，闪白与闪字的成因和显示策略怎么选得先弄懂再谈预加载。

用途分布

图片这一类的处理方式最多，按比例缩放的八种前端方案可以直接挑一种用。

把小资源内联进页面是另一条路，内联的收益与代价怎么算那篇算过一笔账。

图片那一类的优化点最多，文件名、替代文本、格式与懒加载怎么落地是一份完整清单。

字体排第一并不意外，它是首屏渲染里最容易拖后腿的一环。

另外三类各有各的坑

样式表预加载140条。这一类最容易写成多余——如果那个样式表本来就是用普通方式在头部引入的，浏览器本来就会以最高优先级去取，再预加载一次没有增量，只是多一行。

中文站的字体方案又是另一套账，一行样式改掉默认中文字体是最省事的那种。

主题自带的字体请求常常是白花的，怎么把主题里那几行字体请求去掉有四种做法。

脚本预加载101条。它的风险是打乱执行时机：预加载只负责把文件取回来，不负责执行。如果原本靠加载顺序保证的依赖关系没理清，可能出现文件早就到了、执行却仍在等别人的情况。

图片预加载89条。这一类收益最直接——首屏那张大图提前取，能实打实缩短最大内容渲染的时间。前提是选对了那一张。判断办法很简单：用性能面板跑一次，看它认定的最大内容元素是不是你预加载的那一张。选错的话不但没提速，还占了带宽。

224条字体预加载里，101条少写了一个属性

字体这类资源有个特殊规矩：浏览器取它的时候必须用匿名的跨域模式，无论字体放在自己的域还是别人的域上。所以预加载字体时也必须显式声明同样的模式，两边才能对上。

缓存键对不上会带来重复下载，怎么配缓存头才不犯改了不更新的事故里有完整规则。

跨域这件事的边界很容易搞错，一张子域上的图片把主站登录态删干净就是边界没搞清的后果。

少写这一个属性的后果不是报错，而是浏览器会把同一个字体文件下载两次——预加载那次因为模式对不上被丢弃，真正渲染时再取一次。

224条里有101条少写了它，占45.1%。也就是说，将近一半的字体预加载不但没有加速，反而多花了一份流量。

为什么这个错这么普遍

因为它完全静默。页面照常渲染，字体照常显示，唯一的痕迹在开发者工具的网络面板里——同一个文件出现两行。而这个面板平时没人会盯着看。

做这行容易在细节上耗空自己，一套个人审计五步法顺手也留给自己用。

资深团队反而更容易栽在这类地方，被忽略的那几类技术SEO失灵原因说的就是这种局面。

配置每次都通过不代表没事，每八次抓取就有一次撞在跳转上是同一类隐形代价。

顺带一提，缺少用途声明的只有1条。这说明大家都知道要写用途，只是不知道字体还有额外那条规矩。

两次快照隔了一段时间，这块配置动过吗？

前面一直在说这块配置没人管，这个说法需要一个直接的证据。手边正好有同一批站在两个不同时间点抓下来的首页快照，拿来比一遍就有答案。

做前后比对最怕基线没定好，补上对照组之后差异从七成掉到两个点就是一次返工。

变更没人记就等于没发生，13类信号、5档工具栈与22周落地是一套变更日志的做法。

121个站里111个一字未改

比对办法是把每个站的提示集合拿出来——类型、域名、用途三样组成一条指纹，排序之后整体比较。两次都抓到的站有121个。

长期没人动的配置文件还有别的，给单个爬虫开组会丢掉通配组全部规则中招比例高得离谱。

长期不动的东西会悄悄失效，内容衰退的识别与分级更新是另一个场景的同一道理。

同一批站上量过另一个长期没人管的字段，41万条地址的修改时间实测结论也不乐观。

结果是111个站的这块配置完全一致，占91.7%。有变化的只有10个站。

这个数字要和别的东西对照才有意义。同一批站在这段时间里改过商品、改过首页banner、跑过活动，页面本身变化不小。而头部那十几行提示，九成以上一个字符都没动。

那10个变了的站，多半也不是有人去改它

变化的那10个站里，几乎都能看出是别的改动带来的连带效果：换了一个第三方服务，新服务的接入代码自带一行提示；或者升级了打包工具，构建生成的那批跟着重排。

大版本迁移要留回滚，十二步迁移流程与回滚演练是可以照抄的模板。

搬迁这类大动作会顺带改掉很多东西，数据库替换与域名切换的执行流程里有该核对的清单。

真正意义上有人打开模板、盯着这几行、决定删掉某一条的，从这份数据里看不出任何痕迹。

不变本身不是坏事，坏在世界会变

要公平地说，一块配置长期不变常常是好事——说明它稳定、没人乱动。问题在于这块配置描述的不是自己，而是外部依赖。

外部环境变了建议就会失灵，四层架构分歧导致优化建议跨平台失灵是同一类陷阱。

同意管理这一类服务换得尤其勤，四家主流工具横评与选型决策树能少走几次弯路。

第三方统计留下的痕迹不止一处，那些图标与脚本怎么处理才合规是相邻的一件事。

你的分析工具从一个域名迁到另一个域名，你的字体从自托管换成第三方服务，你的评论插件被平台下架。这些事一件都不会来敲你模板的门。

顺着这些域名，能反推出这块配置是哪一年写的

这批提示里指向的域名，本身就是一份地层剖面。

工具换代是常态，用第一性原理做工具选型能帮你判断哪些该留哪些该走。

统计产品换代那次改动很大，新版核心指标解析的四个常见错误是那场迁移的另一面。

指向那个老牌统计服务旧域的，多半写于新一代统计产品普及之前；指向某个已下架评论服务的，写于那个服务还在架上的年头；指向某家同意管理平台四个子域的，写于那次合规改造。每一条都能对应到一个具体的年份区间。

拿这个办法翻自己站的头部，往往能得到一个让人不太舒服的结论：这块配置的中位年龄，可能比你团队里一半人的司龄都长。

更实际的用处是排优先级——年代越久远的那几条，越可能已经失效，也越安全删。

空转一条到底要付多少钱？

这一节需要先说明边界：本文没有做端到端的加载速度对照实验，所以不会给出快了多少毫秒这种数字。下面只算能算清楚的部分。

交互延迟那个指标更难对付，主线程六个维度的实战修复有完整方法。

首字节时间那条链路上有很多可省的地方，多层缓存怎么同时影响体验指标与抓取拆得很细。

字节成本，算得出来但不多

一行提示按标签加域名估算大约60到90个字符。中位数12条的站，这块占页面不到1KB。写了244条的那个站，粗算下来在15KB上下，压缩之后还会更小。

压缩这一层还有别的浪费，出厂只压一种类型、其余字节全额计费也值得顺手查。

页面大到一定程度会被截断，抓取体积上限的八步优化是先要排除的干扰项。

所以单看体积，这不是一个值得写文章的问题。真正的成本在别处。

连接槽位是有限的

提前建连这一类会真的发起网络动作：域名解析、传输层握手、加密握手，它比域名预解析多做的那两步正是它成本高的原因。浏览器在页面加载最忙的那几百毫秒里能同时做的这类动作是有限的。

响应头那一层能承载的信息比多数人以为的多，索引指令、缓存与协商字段各管什么有一份机制图。

连接和缓存是同一条链路上的两段，回源、分层过期与缓存键怎么配可以照着排。

弱网和低端机上这笔账要重算，海外客户打开你的站到底有多卡有实测数据。

一条指向死域名的提示会占住一个位置，直到解析超时才释放。而这个位置本来可以用给真正马上要用的资源。浪费掉的不是字节，是首屏最稀缺的那段并发。

这也是为什么各家的建议里都强调提前建连要克制，通常给的参考上限是个位数。样本里超过这个量级的站不在少数。另外要留意协议层面对连接复用的规定：闲置的连接会被回收，提前太久建的连接到真要用时可能已经关了。

字体那101条的成本是实打实的一份流量

相比之下，字体预加载写错模式的代价很明确：同一个文件下载两次。一个中文字体子集动辄几十上百KB，翻倍就是实实在在的浪费，而且发生在首屏最要紧的时候。

移动端上这些代价会被放大，十大致命错误与修复顺序是一份对照清单。

首屏那几秒能压下来的空间不小，六层架构把最大内容渲染从4秒压到1.5秒是一次完整实操。

还有一项成本不在浏览器里

最后一项成本落在人身上。一块没人敢动的配置会持续消耗后来者的判断力：每次改版都要问一遍这些还要不要，每次都问不出答案，于是每次都原样留下。

推不动改动往往不是技术问题，重写汇报方式的八个步骤比反复解释有效。

没人认领的事最后都变成欠账，内容、技术、外链三类分工与团队配比是同一个协作问题。

这类欠账的特点是单次成本极低、累计成本很高，而且永远排不进任何一次排期。

还有一个更隐蔽的连带影响：这块配置里指着的域名，会被安全审计和合规盘点当成你的外部依赖清单。一个早就不用的服务留在那儿，等于在自己的资产台账上白挂一条，答问卷的时候还要专门解释一遍。

被指得最多的那批第三方域，各自的空转率差在哪？

把所有第三方域按被多少个站声明过排个序，前二十名里空转率的差异非常大，而这个差异本身是有规律的。

同样是外部依赖的白名单，53个站里45个配了、只有5个真管住脚本是另一组实测。

第三方那边的规则常常是黑箱，有人把挑源的内部字段扒了出来算是难得的一次透明。

平台自家的域几乎不空转

被57个站指着的那个电商平台内容分发域，空转数是0。被53个站指着的平台埋点域，空转数也是0。

有些平台是出厂就慢，索引器、缓存与生产模式怎么调是另一套功课。

有些东西是被平台锁死的，哪些页面元素能改、哪些改不了得先摸清楚。

平台自带的那一层要先摸清，内置、通用与专属应用的三层框架能避免重复投入。

原因很简单：这两条是平台默认模板自带的，而平台自己的资源必然会被加载。它们跟着平台的版本走，属于有人维护的那一类。

已经被新版取代的旧统计域，空转率最高

被17个站指着的那个老牌统计服务域，13个站空转，空转率76.5%。

后台那些报表也在换代，生成式AI性能报告怎么读、开关要不要关是新一轮的功课。

统计和SEO之间要做取舍，给内链加追踪参数为什么伤SEO是同一类权衡。

这个数字背后是一次行业级的迁移：新一代的统计产品不再从那个域取资源，改走标签管理器那条路。迁移做完之后，绝大多数站没有回头删掉旧域名的提示。

作为对照，标签管理器那个域被27个站指着，只有8个空转，空转率29.6%。一新一旧，差了将近三倍。

字体服务的两个域，命运完全不同

字体服务通常需要声明两个域：一个取样式表，一个取字体文件。样本里前者被16个站指着，4个空转；后者同样16个站，12个空转。

主机、插件与体验指标要一起看，从主机到核心指标的完整做法适合先过一遍。

图标字体也是同一类外部依赖，版本之间的语法差异与渲染方式换代时最容易踩。

这个差异有点意思。合理的解释是不少站把字体改成了自托管，样式表那一条因为还有别的用途留了下来，而字体文件那一条彻底失去了对象。

一个同意管理服务的四个域，7个站全部空转

还有一个更整齐的例子：某个隐私同意管理服务在样本里出现过四个不同的域，每个都被7个站声明，而且这7个站的这四条全部空转，一条不落。

卸载不干净是通病，删文章时怎么把附带的图片一起删掉是同一类收尾问题。

同意这件事在多语言站上更复杂，用户点同意之前翻译脚本一行都不许跑是那条硬规则。

四条一起进来、一起失效，说明它们是作为一整段代码被粘贴进模板的。卸载那个服务的时候，粘贴进去的那一段没有被完整地拿走。

规律可以总结成一句话

空转率低的域，共同点是它由某个还在运行的系统持续产出；空转率高的域，共同点是它由一次性的手工动作留下。判断一条提示会不会变成垃圾，看它是被写进去的还是被生成出来的。

一堆问题先修哪个得有依据，五百个站实测排出来的技术SEO优先级可以当排期底稿。

能被机器持续做的事就别靠人记，哪些SEO工作能交给工具、哪些不能划了一条边界。

再看几个空转为零的域，它们有个共同特征

榜单里空转数为零的还有几个：某个网页测试平台的域被11个站指着，零空转；某个评论应用的域被5个站指着，零空转；某个公共脚本分发网络被5个站指着，也是零空转；某个隐私合规平台的域被6个站指着，同样零空转。

有人用的东西才有人维护，为什么工具页还在稳稳拿流量说的是同一个道理。

还在跑的服务才会被持续维护，品牌被提及没给链接怎么追回是另一种持续动作。

它们的共同点不是名气，而是那个服务今天还在这些站上跑着。提示之所以没空转，不是因为有人维护提示，是因为没人需要维护——被指的东西还在原地。

反过来说，空转率是一个滞后指标：它量的不是你今天的配置质量，是你过去几年换过多少家供应商，以及每次换的时候有没有收尾。

还有一类容易被误判的：接口域

字体服务那两个域的对比里藏着一个方法论提醒：一个域名被声明了却没有资源加载，未必是废的，也可能是它只承载接口调用而不承载静态资源。

同步和异步分不清会拖垮响应，一行发邮件的代码把响应从24毫秒拖成924毫秒是个好例子。

接口这一层要单独验，用接口测试工具看清一个地址的状态码与响应头也够用了。

本文的软判据（全文搜索域名）就是为这类情况准备的。样本里452条没有资源加载的提示，有251条在页面文本里还能搜到，占55.5%——这一半多不能算废，只能算不确定。真正判定为空转的201条，是连字符串都找不到的那一批。

怎么在自己站上把空转的那几条挑出来？

这套检查不需要任何付费工具，一个人半小时能跑完一个站。

整站体检该查什么有现成框架，从抓取、内容到AI可见度的完整诊断清单可以照着排。

桌面爬虫跑一遍能顺手带出不少毛病，全站审计的十二类问题排查清单是配套的检查表。

不花钱也能把基础检查做全，预算为零时真正好用的那批工具列过一份清单。

手工版：四步

第一步，打开首页源码，把头部所有资源提示那几行拷出来，按类型和域名整理成一张表。重复的先合并，记下重复次数。

头部里还藏着别的结构化内容，把结构化数据调试这件事讲透有逐字段的排查法。

头部那一块还有别的东西要查，四大平台社交卡片的逐字段体检能一起做掉。

两种身份看到的页面可能不一样，爬虫和用户看到的页面不一样怎么揪出来是相邻的一条排查线。

第二步，打开开发者工具的网络面板，硬刷新一次页面，把实际发起请求的域名列出来。

第三步，两张表对照。出现在第一张表里、不出现在第二张表里的，就是候选空转项。

第四步，对每个候选项在源码里全文搜一次这个域名。搜得到说明它可能在某个脚本里被动态调用，先留着；搜不到就是确认空转。

批量版：把它接进构建

如果站不止一个，或者想每次上线都查一遍，做法是在构建产物上跑一段脚本：解析出所有提示的域名，再解析出所有资源地址的域名，做个差集。

重复劳动该交出去就交出去，六类耗时任务的自动化方案按投入产出排过序。

这类脚本现在写得比过去快，怎么搭一条SEO自动化工作流有完整实测。

把巡检串成工作流并不难，四个场景闭环把内耗变成产线有现成的编排思路。

这类小脚本自己写最快，用对话式编程做小工具的八步避坑讲的就是这种自养工具。

这段脚本的核心逻辑不到三十行。把它挂在构建流程的末尾，差集非空就打印警告——不用让构建失败，警告足够了，因为动态调用的情况确实存在。

顺手要查的三件事

第一，字体预加载有没有写跨域模式。这一条最值钱，样本里45.1%的字体预加载栽在这儿。

服务器配置那一层也该顺手过一遍，六层综合治理的22周实操能一次把好几件事做掉。

第二，有没有同一个域既写预解析又写建连。有就删掉预解析那条。

第三，把所有提示的域名拿去做一次域名解析。解析不出来的直接删，没有任何风险。

开发者工具本身会替你报一部分

还有一个几乎零成本的办法：预加载了却没被用到的资源，浏览器会主动在控制台打一条警告。打开控制台看一眼首页，能免费捡到一批。

有些事只能靠日志看出来，读懂抓取行为与预算浪费是配套的工具教程。

有些检查有现成工具替你做，抓取体积上限怎么实测是最省事的那一类。

可惜提前建连和域名预解析这两类不会触发任何警告——而它们恰恰是空转率最高的两类。这也解释了为什么这块问题能积攒这么久。

这件事归谁管，是它长期没人做的根本原因

值得说一句组织层面的事。这块配置卡在一个尴尬的位置：它写在前端模板里，归前端；它的收益体现在加载体验和搜索表现上，归SEO或者增长；而它变废的原因是某个第三方服务被换掉了，那件事归市场或者数据团队。

把口头约定写成文字永远划算，达标定义、违约责任与四类经典纠纷是另一个场景的同一道理。

跨职能这件事有具体抓手，后端工程师配合SEO的七个动作点是从22周账本里总结的。

三方都碰得到它，三方都不觉得它是自己的活。于是它成了那种谁都能改、谁都不改的东西。

破局的办法不是开会定责任人，而是把判断变成机器能做的事：把差集检查塞进构建流程，让它在每次上线时自己喊一嗓子。一件需要有人记得的事，迟早会没人记得；一件程序每次都会做的事，才可能长期正确。

这也正是那1864条构建生成的提示零空转的全部秘密——不是它们的作者更有责任心，是它们根本不需要作者。

删之前要确认什么，删错了会怎样？

体检报告最怕的就是按报告一删了之。这一节说清楚哪些能直接删、哪些要先确认。

要在线上验证一个改动，怎么做对照测试才不影响SEO里有官方表态和清理动作。

删这件事需要一套判据，留、改、并、删、转的决策系统比拍脑袋靠谱。

可以闭着眼睛删的三类

第一类，域名解析不出来的。它已经不可能提供任何资源，留着只有害处。

还有一类过时代码留着只有坏处，屏蔽右键这种做法今天的真实代价该删就删。

头部那些小毛病改起来往往就一两行，标题里多余空格的三种去法是个小例子。

第二类，同一域名重复出现的多余那几条。保留一条即可。

第三类，同一域名既有预解析又有建连时，删掉预解析那条。

要先确认再删的两类

第一类是页面文本里搜得到但没有资源加载的。这多半意味着某个脚本会在特定条件下才去请求它——比如用户点了某个按钮才加载的聊天窗，或者只在特定地区才启用的支付方式。这类提示是有意义的，删掉会让那条路径变慢。

筛选和交互带出来的东西最难穷举，分面导航产生的海量地址怎么治理是同一类难点。

有些第三方是在特定页面才出场的，把用户一脚踢到第三方站上的那类跳转值得单独查。

不同设备上的加载路径不一样，响应式到核心指标的三类站点改造对比能帮你想全。

确认办法是把那几个交互都点一遍，看网络面板里会不会冒出这个域名。

第二类是首屏之后才用到的域名。提前建连的价值本来就在于覆盖还没发生的请求，所以看不到资源不等于没用。判断依据是滚动到底、等页面完全静止之后再看一次网络面板。

删错了会发生什么

好消息是这类改动的破坏面很小：删掉一条提示不会让任何功能失效，最坏的结果是那个资源第一次加载时慢几十到几百毫秒。

同样的问题在不同规模的站上优先级不同，三类站点的高投入产出比修复顺序可以直接套。

想看出改动有没有效果得先有口径，从指标体系到异常诊断的完整做法可以拿来搭框架。

任何改动都要给它时间，收录、爬坡到起量的真实时间线能帮你管理预期。

坏消息是这个后果不会立刻显现，也很难被归因。所以稳妥的顺序是先删死域名和重复项——这两类零风险，往往就能砍掉大半——再花时间确认剩下的。

删完怎么验证没删错

验证不需要专业工具，两步就够。

移动端得单独验一遍，从移动友好检测到核心指标的完整流程是配套的做法。

第一步，改完之后把首页、一个分类页、一个商品页各走一遍，把主要交互都点开——搜索框、加购、切换币种、打开客服窗口。全程开着网络面板，看有没有请求因为找不到连接而卡住。

第二步，用性能面板各跑一次改前改后，重点看最大内容渲染那个数字有没有变差。删对了它应该微微变好或者不变；如果明显变差，说明删掉了一条真在用的。

这两步加起来二十分钟。相比之下，把这块配置继续放着不管的成本是每年都要重新纠结一次。

如果站上有灰度发布的能力，还可以更稳一点：先把改动放给一小部分流量，观察一两天真实用户的加载指标再全量。这类改动的信号很弱，小流量下未必看得出差别，但至少能确认没有变差。

最后提醒一句，改完记得把变更写进记录——哪一行、什么时候删的、当时的理由是什么。这几句话的价值在半年后才会显现：那时候有人问起为什么头部比记忆里干净，你能答得上来，而不是又加回去一遍。

删完之后要留一道闸

和所有这类清理一样，只删一次的结果是过一年又长回来。要让它别复发，得在流程里留个东西。

定时表达式不用背，把巡检挂上定时任务配置起来不算麻烦。

例行动作都能交给计划任务，备份、导出、缓存与证书一条龙有现成脚本可抄。

最省事的是在构建脚本里加那段差集检查，输出到构建日志。稍微认真一点的做法是给这块配置加一段注释，写清楚每一行是哪年为什么加的、什么条件下可以删。一行没人说得清来历的配置，注定会被下一个人原样留下。

常见问题解答

提前建连和域名预解析，该用哪个？

如果确定马上要从那个域取东西，用提前建连，它把域名解析和两次握手都提前做了。如果只是有可能用到，或者数量比较多，用域名预解析，它成本低得多。两个同时写同一个域是冗余，样本里74条属于这种情况，涉及30个站，建议只留建连那条。需要注意提前建连是有真实成本的动作，各家建议的数量上限都在个位数。

写多少条提前建连算多？

常见的参考上限是四到六条。样本里122个站的中位数是12条，已经超了；写得最多的站有244条，其中230条是重复。去重之后多数站落在十条上下，仍然偏多。判断的办法不是数条数，而是问每一条对应的资源是不是首屏就要用——不是的话它就在跟首屏抢连接。

预加载字体为什么一定要写跨域属性？

因为浏览器取字体文件时一律用匿名跨域模式，不管字体在不在自己的域上。预加载时如果不声明同样的模式，两边的缓存键对不上，预加载那一份会被丢弃，渲染时再下载一次。样本里224条字体预加载有101条少写了它，占45.1%。这个错完全静默，只有在开发者工具的网络面板里能看到同一个文件出现两行。

页面里搜不到这个域名，就一定能删吗？

不一定，但风险很低。要先排除两种情况：一是某个脚本在特定交互之后才去请求它，二是首屏之后才用到。前者把主要交互点一遍就能验，后者滚到底等页面静止再看一次网络面板。两条都排除之后可以删。就算删错了，后果也只是那个资源第一次加载慢一点，不会有功能损坏。

这些提示会影响搜索排名吗？

不直接影响。它影响的是页面加载体验，而加载体验是排名信号之一。所以链路是间接的：空转的提示占住首屏的连接并发，真正要用的资源排在后面，首屏渲染变慢，体验指标变差。反过来说，删掉几条死掉的提示不会让排名立刻变好，它属于那种攒起来才有意义的小改动。

为什么打包工具生成的那批不会空转？

因为它每次构建都被完整重新生成。工具知道这次产出了哪些代码块、哪个页面会用到哪一块，据此写出对应的提示。依赖变了，下次构建时提示自动跟着变。样本里这两类一共1864条，空转数是0。手写进模板的那两类676条里空转197条。差别不在写的人认不认真，在于有没有一个程序在替他持续重写。

能不能干脆全删了？

不建议。用对的时候这些提示确实有效，尤其是首屏字体和关键第三方资源。合理的目标不是清零，是让每一条都对应一个真实存在、且首屏就要用的资源。样本里53个站做到了完全没有空转，说明这个目标并不苛刻。

多久查一次合适？

换第三方服务、换字体方案、换分析工具、做改版，这四件事之后各查一次，比定期巡检有用得多——因为空转恰恰是在这些时刻产生的。如果实在要定个周期，半年一次足够。更好的做法是把差集检查接进构建流程，让它每次上线自己跑。

权威参考资料