摘要：把132个独立站首页对自己地址的所有声明抠出来，逐对比较。严格按字符串比，全部声明完全一致的只有29.4%；只放宽一条规则，忽略末尾那个斜杠，立刻跳到74.6%；再忽略www、再忽略协议、再忽略参数和大小写，最高只到77.0%就不动了。也就是说，这些页面自相矛盾的地方里，四分之三只是一个斜杠，剩下的23%是真分歧，怎么放宽规则都消不掉。分歧最集中的一对是hreflang的默认版本和结构化数据里的地址，41个可比对的页面里有13个对不上。

先说一个让人心里一沉的场景。你接手一个新客户的站，博客刚上线还没被收录，你打开搜索平台的网址检查工具想看看进度，结果那一栏写着“谷歌选定的规范网址”，后面跟着一个你从来没见过的域名，看着还挺像垃圾站。

这不是假设，2026年8月13日有位从业者在社交平台上晒过这么一张截图，完整经过见Search Engine Roundtable关于选定的规范网址指向垃圾站的报道。谷歌那边的回应是：有时候几个域名共用过同一个停放页或者过渡页，就容易出现这种情况，建议过几周再看看会不会变。

新站迟迟不被收录还有别的成因，页面不被Google收录的急救手册按症状分诊列过一遍。

这句回应里藏着本文要讲的全部内容。注意那个动词——选定。不是“你声明的规范网址”，是“它选定的”。这两个字段在同一个界面上并排放着，一个写你说的，一个写它选的，而它们经常不一样。

这就是第三种病。前两篇讲过另外两种：一种是东西根本不在你交出去的字节里，另一种是东西在但对方那次请求没拿到。这一种最麻烦：对方拿到了，读懂了，然后用了自己的判断。

它到底按什么选，Google选择Canonical URL的9大决策逻辑拆过完整判据。

上一篇换了7种身份各要一次，robots.txt说允许GPTBot仍有10个站进不去。

那一篇量的是同一批站的正文可读字符，132个独立站首页有28个是空壳。

三种病的药方互为毒药。缺失型你去补内容，送达型你去查通路，采信型呢？绝大多数人的第一反应是把声明写得更用力一点——再写一遍、写得更绝对、多加几个地方声明同一件事。这个动作在采信型面前不但无效，还经常帮倒忙，因为对方不采信的原因通常不是没看见，而是它同时看见了好几份互相矛盾的证据，只好自己挑一份。

所以这篇文章不讲规范网址标签怎么写，那种教程遍地都是。它想量一件几乎没人量过的事：一个真实的网站首页，到底对自己的地址做了几次声明，这些声明互相打架的比例有多高。

样本还是那132个国际化独立站首页，跟前两篇同一批，这样三层结论可以互相印证。

基础写法不在本文范围内，Canonical URL是什么有完整的设置指南。

提前说一句结论，免得读到一半失去耐心：这些页面在地址这件事上自相矛盾的地方，四分之三只是一个末尾斜杠，无伤大雅；但剩下那四分之一是真的在说两件事，而且它们的所有者八成不知道。

还有一件事得先讲清楚，不然后面容易读偏。本文不讨论规范网址标签该怎么写，也不讨论多语言标签的语法。这篇文章只关心一件事：同一份HTML里，那几处各自独立生成的地址，彼此对不对得上。语法全对、每一处单看都没毛病，合在一起仍然可以是矛盾的——这正是这类问题难被发现的原因。

同一个首页，会对自己的地址做几次声明？

先把要量的东西数清楚。

这两个指令能不能一起用，noindex和Canonical能同时用吗分了9种场景。

一个页面能声明自己地址的六个位置

很多人以为地址声明只有规范网址标签一处，实际上一个现代电商首页通常同时用了三到四处，而且它们分属不同的系统、由不同的模块生成。这几处大多写在link元素上，MDN关于link元素与rel属性的条目把canonical、alternate、hreflang这几种关系的写法列在了同一页。

结构化数据这一层怎么落地，结构化数据Schema怎么配合SEO落地附了常见避坑。

最后那一行是这篇文章的锚。前面五个都是声明，是页面在说话；最后一个是事实，是服务器在做事。做对齐审计的时候，永远拿事实那一行当基准，别拿任何一个声明当基准。

各个来源的覆盖率

132个首页里，各来源出现的比例是这样的：

事实这一行由状态码决定，HTTP状态码怎么影响SEO讲了301、302、404和410的选择。

规范网址标签的覆盖率最高，91.7%，符合预期，它是这行的标配。base href则是干净的零——132个站没有一个用它，这个标签在现代前端里基本退休了。

更有信息量的是每页同时存在几个来源：6个站一个都没有，9个站只有1个，29个站有2个，54个站有3个，34个站有4个。

哪些标签还值得用，网页语义化HTML改造按8类标签评过。

不同页面类型的配法不一样，各类页面的meta robots和canonical配置按5类拆过。

也就是说，88个站在同一个页面里对自己的地址说了三遍以上。说三遍本身不是问题，问题是这三遍由三个互不通气的模块生成，而且没有任何一处校验它们说的是不是同一件事。

这几处声明分别被谁读

要理解它们为什么会打架，得先知道它们各自是给谁看的。这一点比语法重要得多。

地址结构本身也有讲究，电商网站为什么爱用扁平URL有10000个站的实测。

规范网址标签的读者主要是搜索引擎的索引系统。它在做的事情是把内容相同的一批地址归成一组，然后挑一个当代表，只有这个代表会出现在搜索结果里，其余的把权重让给它。

og:url的读者是社交平台的抓取器。你把链接贴进社交平台或者即时通讯工具，对方会去抓这个页面，用这个字段决定卡片上显示哪个地址、点击跳到哪里。它跟收录基本无关，但跟分享后的实际落点强相关。

归不到一起就成了索引膨胀，索引膨胀的诊断与处置给了决策矩阵。

分享出去之后的可见性是另一套打法，Search Everywhere全渠道实战讲了怎么铺。

hreflang那一组的读者也是搜索引擎，但走的是另一条链路：语言与地区匹配。它回答的是同一份内容有哪些语言版本、匹配不上时去哪一版。

结构化数据里的地址，读者这两年变多了。除了搜索引擎的富媒体展示，各类AI答案系统在整理实体信息时也会读它。当一个AI答案里出现某个品牌的官网链接，那个链接有不小的概率就是从这个字段取的。

这一组标签的完整写法，国际化SEO和hreflang怎么做有避坑清单。

它对AI搜索到底有没有用，结构化数据对AI搜索的实测给了官方说法与数据。

最后，服务器实际服务的地址，读者是所有人——包括那些根本不解析HTML的系统，比如链接检查器、广告平台的落地页审核、以及各种把地址当字符串存起来的地方。

读者不同，所以没人负责让它们一致

把上面这一段连起来看，问题的根就露出来了。

落地页审核读的是另一份东西，广告文案原料全在落地页上讲了它的取料方式。

这五处声明服务于五拨不同的读者，因此在组织里通常也分属不同的人：做搜索的管第一处，做社媒的管第二处，做多市场运营的管第三处，做数据与富媒体的管第四处，做运维的管第五处。

每个人都在自己那一处写下了正确的答案，而没有任何一个人的职责是让这五个答案彼此相等。

跨语言的实体对不上是同一类协作问题，国际化SEO最难的不是hreflang列了五大根因。

这也解释了为什么这类问题在小站上反而少见——小站上这五处很可能是同一个人配的，或者干脆由同一个主题模板一次输出。规模越大、分工越细，打架的概率越高。本文数据里那些声明来源最多的站，恰恰也是分歧最集中的那一批。

og:url这个字段，多数人只用对了一半

五处声明里，og:url是最容易被当成配置项随手填掉的一个，值得单独说两句。

大站的审计要成体系，企业网站SEO审计框架给了检查表。

它的覆盖率71.2%，仅次于规范网址。但它的作用跟收录基本无关，它决定的是社交分享出去之后的落点：卡片上显示哪个地址、点开跳到哪里、以及那些统计分享数的系统按哪个地址计数。

最后那一点是很多人没想到的：如果同一个页面在不同时期用不同的地址被分享出去，那些分享计数是分开算的，不会合并。对做社媒投放的独立站来说，这意味着你的分享数据被拆成了几份。

参数怎么打才不乱，UTM链接构建器规范附了SEO避坑清单。

另一个常见错法是把它填成站点首页而不是当前页面。有些主题的默认设置就是这样，结果每一篇文章分享出去，卡片上的地址都是首页。这个错误在页面上完全看不出来，只有在分享的那一刻才暴露。

所以自查的时候，别只看它有没有填，要看它填的是不是当前这一页。把一篇文章分享到任意一个即时通讯工具里，看看弹出来的卡片指向哪，三秒钟就能验完。

主题默认值的坑不少，WordPress文章和页面怎么选讲了收录与权重的差别。

先把测量口径钉死

这类比较最容易在口径上出事，所以把规则先摆出来。

取值方式：规范网址标签取link元素的href属性原文；og:url取meta的content；hreflang取值为x-default那一条的href；结构化数据取顶层实体的url字段；最终地址取跟随全部跳转之后的那个地址。全部保留原样，不做任何清洗。

比较范围：只比较那些同时存在两个以上来源的页面，一共126个。只有一个声明的页面没什么好比的。

比较方法：把一个页面上所有存在的来源两两比，全部相同才算这一页一致。这是个很严格的判据，一处不一致整页就算不一致。后面会看到，正是这个严格性让分层放宽变得有意义。

base href为什么是干净的零

132个站零覆盖，这个结果值得单独说一句，因为它是这份数据里唯一一个百分之百确定的结论。

这个标签的作用是给页面里所有相对路径指定一个起点。它在早年很常用，因为那时候页面结构简单，用它能省掉一堆重复前缀。现在它基本消失了，原因有三个。

一是它的作用域太粗。它会影响页面里所有的相对地址，包括脚本动态插入的那些，一旦设错就是全页崩，而排查起来极难，因为出问题的地方和设置的地方隔得很远。

二是现代框架都有自己的路由和资源地址管理，不需要靠这个标签兜底。三是绝大多数站现在直接输出绝对路径，问题从根上就不存在了。MDN关于base元素的说明里也写着，一个文档里最多只能有一个这样的标签，而且它必须出现在任何相对地址被使用之前。

链接形态本身也影响权重传递，按钮链接和JS链接会稀释权重吗对比了4种形态。

这条结论对做审计有个用处：如果你在一个现代站上看到了这个标签，那它大概率是历史遗留或者某个老插件塞的，值得单独查一下它有没有在悄悄改写别的地址。

那6个一个声明都没有的站

另一头也得看。132个站里有6个首页一个地址声明都没有，既没有规范网址，也没有社交标签、多语言声明和结构化数据。

页面被悄悄改写的事真发生过，浏览器自动翻译把yes改成forks是一个实例。

这6个站不是简陋的小站，它们的首页HTML都在几万字节以上，视觉上做得相当讲究。它们只是把所有精力放在了给人看的那一层。

这种状态的实际后果，是这个页面的身份完全由接收方推断。推断的依据只剩下跳转终点、内部链接和外部链接。对一个只有一个首页地址、没有多余参数的站来说，这样其实也能工作；但只要出现第二个可达地址，风险就立刻实体化。

给机器看的那一层怎么量，语义化HTML到底影响AI抓取吗拿样本页跑过。

值得一提的是，这6个站里有几个是本文后面会提到的多语言大站。多语言站没有任何地址声明，是这批数据里我认为风险最高的一种组合。

这次测量的边界在哪里，哪些结论不能外推？

把局限性摆在前面说，后面的数字才好用。这一节不好看但必须有。

这些语言版本的实际待遇，hreflang写的语言版本只被当成规范页的别名有实测。

只测了首页

首页在地址声明这件事上是最特殊的一页。它的地址最短、被链接得最多、被人工检查过的次数也最多。所以这批一致率应该被理解成上限，不是平均值。

真正容易出问题的是商品页和分类页，它们数量大、由模板批量生成、经常带参数。一个模板上的地址拼接错误，在首页上可能看不出来，在十万个商品页上就是十万处不一致。

首页的特殊性还体现在别处，首页首屏从导航到分类区怎么设计讲了它的职责。

模板批量生成地址最怕失控，电商筛选器URL不爆炸的方案是一套8步流程。

这也是我建议做抽查而不是只测首页的原因。首页测出来是好的，不能推出全站是好的；首页测出来有问题，那全站一定有问题。

只采了一次，而且只从一个出口

所有请求在同一个时间窗内、从同一台位于中国的服务器发出。这个条件对做了地理分流的站影响很大。

上一篇量到过好几个站按请求方来源分发到不同的国家站。那意味着同一个页面的地址一致性，从不同出口测会得到不同的结果。这批数据只代表其中一个出口看到的样子。

还有一个时间维度的问题：地址声明会随发版变化。今天一致的站，下周上一个新插件就可能不一致。单次采样看不出这种波动。

分流出问题时怎么排，从DNS、线路到CDN的网络层排障给了顺序。

变更要有记录才查得动，SEO变更日志的企业站治理列了13类信号。

不比较语义，只比较字符串

这是最重要的一条边界。本文所有的一致与不一致，判断依据都是字符串比较加上分层归一化，不涉及任何语义判断。

所以有几类情况会被误判成不一致，而它们其实是合理的。比如多语言站的默认版本本来就不必等于规范网址，前面已经说过；比如某些站的结构化数据写的是品牌实体的官网而不是当前页面的地址，这在规范上也说得通。

我的处理办法是把这类情况留在数据里，但在解读的时候单独指出来。把合理的差异也算进去，会让分歧率偏高；但如果凭主观判断剔掉一部分，这份数据就没法被别人复现了。两害相权，我选了可复现。

这份数据能支撑的那一句话

把上面三条摆清楚之后，这批数字能支撑的结论其实只有一句：在只看首页、只从一个出口、只做字符串比较的条件下，一个页面内部的地址声明有23%存在无法用格式差异解释的分歧。

数据可复现有多重要，10条最佳实践清单里8条数字对不上是个反例。

这一句已经够用了。它不需要外推到全站，也不需要精确到小数点，它要说明的只是一件事：这个问题的规模比行业里默认的大得多。

为什么用这批样本，而不是随机抽

还有一个问法值得回答：为什么不随机抽一批站，那样不是更有代表性吗？

因为代表性要看代表谁。随机抽的样本代表的是整个网站群体的平均水平，而那个平均水平里包含大量个人博客、企业官网、几页纸的小站，它们的地址结构简单到不会有这个问题。把它们混进来，分歧率会被稀释得看不出问题，而稀释出来的那个数字对任何一个真实的独立站都没有参考价值。

这批132个站是按有独立品牌、有多语言版本、体量中大以上三个条件筛出来的。它们代表的是行业里做得比较认真的那一批，也就是很多人拿来当参照对象的那一批。

地址结构本身的9个细节，URL结构与slug优化讲了它怎么影响抓取。

所以读这些数字的时候要记住一件事：这不是平均水平，这是被当成标杆的那一批的水平。23%的真分歧出现在这样一批站上，含义比它出现在随机样本里重得多。

三次测量用的是同一批站，这件事本身有用

三篇文章、三个完全不同的问题，用的是同一个样本池，这不是省事，是有意为之。

好处是结论可以叠加。同一个站在三份数据里的表现能对上：那些首页正文几乎为空的站，往往也是没有地址声明的那一批；那些防护配置极严的站，往往也是地址结构最复杂的那一批。三层数据落在同一批对象上，才能看出这些问题不是孤立的，它们经常长在同一个站上。

更实际的一层好处是：它把三个抽象的判据变成了一套可以连起来跑的体检。抓一次首页，就能同时回答三个问题——字节里有没有内容、换个身份还拿不拿得到、页面对自己是谁说了几句话。

渲染模式决定字节里有什么，AI爬虫抓不到JS渲染的引用率实测做过对比。

这三件事在多数团队里是三个人分别在管，甚至根本没人在管。而它们其实共用同一个动作：把首页抓下来，认真看一遍它到底交出了什么。

把宽容度一层层放开，一致率涨到77%就再也不动了

这一节是全篇的尺子，也是我认为这次实验里最值得复用的方法。

体积这一头也要量，46个电商站的页面体积实测发现4个站的商品链接没被读到。

一层一层松开规则

直接问“这些声明一致吗”是问不出东西的，因为答案取决于你有多宽容。所以我把宽容度做成了阶梯，每一层只放宽一条规则，并且写明放宽的是哪一条。

口径变了数字就没法比，一条五年趋势线上有三处口径变更讲的是同一类问题。

这张表要横着读，读的是每一层比上一层多救回了几个站。

第0层到第1层，从37跳到94，一条规则救回57个站。这些页面自相矛盾的地方里，超过四分之三只是一个末尾斜杠。

第1层到第3层，一共只多救回3个。www救回2个，协议救回1个。

地址形式的选择会放大这类差异，网站URL用扁平还是层级含301改版实战。

第3层之后，再怎么放宽都是零。参数不救人，大小写也不救人。剩下那23%是真分歧，它们不是格式差异，是这些声明确实指向了不同的页面。

这把尺子为什么值得抄走

分层归一化这个做法，可以用在任何一个“到底一致不一致”的问题上，它比单个百分比有用得多，原因有三条。

第一，它把结论和口径绑在一起。29.4%和77.0%都是对的，区别只在你认不认末尾那个斜杠。一个不写明归一化规则的一致率，是没法被别人复现的。

第二，它能自动分出问题的性质。跳变发生在哪一层，问题的性质就在那一层：跳在斜杠层就是模板拼接问题，跳在www层就是域名规范化问题，跳在协议层就是历史迁移的残留。

判据写明白才有用，一个词值不值得单开一页用87个站的站点地图给了答案。

协议迁移的跳转怎么配，HTTPS 301跳转的双向实战有可直接抄的配置。

第三，也是最要紧的一条：它能告诉你放宽到什么程度就没用了。那条曲线一旦走平，说明剩下的都是真问题，再优化你的比较逻辑也是浪费时间。这个平台期的位置，比曲线本身更有价值。

末尾那个斜杠到底要不要紧

既然它一个人就贡献了57个站的差异，得单独说两句。

对搜索引擎来说，根域名后面那个斜杠通常不构成两个不同的地址，主流搜索引擎会把它们当同一个。所以这57个站的差异，绝大多数不会造成实际的收录问题。

但它会造成另外两个麻烦。一是对比困难：你自己做审计的时候，工具报出一堆不一致，你得逐个确认是不是斜杠问题，很浪费时间。二是它是一个信号：同一个页面上的两个模块，连末尾斜杠这种事都没对齐，说明它们之间确实没有任何共享的地址生成逻辑。今天差一个斜杠，明天上多语言的时候就会差一个语言前缀。

归并结果在报表里怎么显示，Google索引覆盖的8种状态讲了每种的含义。

层级前缀的影响，目录层级URL对SEO有何影响给了6招优化。

所以我的建议是：斜杠层面的不一致不用当故障处理，但值得当成技术债记下来。修它的成本很低，通常就是在一个地方统一生成地址，然后所有模块引用它。

第0层那37个站，做对了什么

严格比字符串就完全一致的有37个站。翻了一遍它们的共同点，答案很朴素。

第一个共同点是地址简单。这37个里的绝大多数，首页地址就是带www的域名加一个末尾斜杠，没有语言前缀、没有地区路径、没有参数。地址越简单，能写错的地方越少。

第二个共同点是声明来源少。它们里有不少只有两三个来源，而不是四个。来源少不代表做得好，但确实降低了打架的概率——两个人吵架的可能性总比四个人低。

架构决定地址复杂度，独立站网站架构怎么搭讲了抓取深度。

第三个共同点才是真本事：那些既有四个来源、又严格一致的站，几乎都是把地址集中在一处生成的。你能从字节里看出来，四处写的字符串一模一样，连大小写和斜杠都分毫不差，这种整齐不可能是四个模块各写各的凑出来的。

这也就给出了唯一有效的解法：把当前页面的规范地址做成一个函数，所有需要输出地址的地方都调用它。这个改动在多数系统里是半天的活，但它一劳永逸。

重写规则也该集中管，.htaccess的六层综合治理给了可版本化的写法。

这把尺子还能量什么

分层归一化不只能用在地址上。凡是遇到“两边到底一不一致”的问题，都可以照着搭一遍。

比如比对商品标题在站内和在渠道上的一致性：第0层严格比，第1层忽略空格差异，第2层忽略标点，第3层忽略品牌前缀。跳变发生在哪一层，就知道问题出在录入、模板还是渠道映射。

再比如比对价格：第0层严格比，第1层忽略货币符号写法，第2层忽略千分位，第3层允许一分钱的误差。如果第3层还是对不上，那就是真的不一样，不是格式问题。

商品在渠道上的身份还有另一套标识，跨境电商GTIN怎么申请讲了它的作用。

定价本身怎么定，从成本加成到价值定价的决策框架是另一篇。

关键在于每一层只放宽一条规则，并且写清楚放宽的是什么。一次放宽三条，你就永远不知道是哪一条救回了那些样本。这是我从这次实验里拿到的最通用的一条方法。

29.4%这个数字，对外该怎么说

做审计报告的人会遇到一个现实问题：这一堆数字里，该把哪一个写进结论。

只写29.4%是不诚实的，因为它把一大堆无害的斜杠差异算成了问题，听起来像天塌了。只写77.0%也不够，因为它把真问题的规模说小了，而且掩盖了那57个站的技术债。

我的写法是三句话：严格比只有29.4%一致；其中绝大多数差异只是末尾斜杠，放宽这一条之后升到74.6%；再怎么放宽最高只到77.0%，剩下的23%是真分歧。三句话缺一不可，缺了第一句显得问题小，缺了第三句显得问题大，缺了中间那句就没人知道该先修什么。

这个写法还有一个附带好处：它自带优先级。斜杠层的问题批量修、成本低、优先级低；真分歧层的问题要一个一个查、成本高、优先级高。一个数字给不出优先级，一条曲线可以。

怎么把技术结论讲给非技术的人听，老板听不懂SEO错其实在我们给了讲法。

归一化也会归过头

分层归一化好用，但它有一个方向上的风险，得说清楚。

放宽规则的每一步，都是在假定某个差异无关紧要。这个假定在多数情况下成立，但不是永远成立。忽略末尾斜杠对根域名成立，对某些服务器上的路径就不一定；忽略大小写对域名部分成立，对路径部分不成立，因为路径在很多服务器上是区分大小写的。

所以我在做第5层的时候特意只对域名部分忽略大小写，路径保持原样。如果连路径大小写也忽略，一致率会更好看，但那个好看的数字里就混进了真实存在的问题。

参数带来的地址变体也是同一类，URL中srsltid参数的SEO影响给了4种处置。

更通用的说法是：归一化每放宽一条，都要能说出这条为什么在这个上下文里无害。说不出来的那一条就别放宽。这是分层法唯一需要小心的地方，也是它最容易被用坏的地方——为了让数字好看，一路放宽到什么都一致，然后得出一切正常的结论。

这个风险跟上一篇提过的那次尺子失效是同一类：判据本身没错，错在被用在了不该用的地方。一把尺子的诚实程度，取决于它有没有拒绝测量的能力。

剩下那23%的真分歧，都长什么样？

接下来看具体是哪几对在打架。

样本边界画错的后果，调研数据里没有一个非会员是个典型。

配对分歧率排行

把所有能配对的来源两两统计，在第1层的口径下，分歧率是这样的：

这张表从上到下读，是一条很清楚的线索。

为什么最后一行只有2.2%

先看最底下那一行。规范网址和og:url，90个页面里只有2个对不上，分歧率2.2%，是全表最低。

原因不难猜：这两个字段在绝大多数系统里是同一段代码生成的，或者一个直接引用了另一个。它们不是达成了共识，它们是同一句话说了两遍。

这条给审计带来一个实用提示：如果你的站这两个字段不一致，那问题一定不小，因为连最容易一致的一对都出事了。值得优先查。

同一套模板里的分页也共用这套逻辑，Shopify集合页分页SEO实操讲了canonical怎么设。

报表里怎么看出这类问题，GSC的数字为什么人人都读错逐项拆过。

为什么排在最前面的都跟hreflang有关

再看最上面四行，全部涉及hreflang的默认版本。这个字段跟谁比都容易打架，跟结构化数据比31.7%，跟规范网址比28.1%，跟实际地址比23.4%，跟og:url比20.8%。

根源在于这个字段的语义跟其他几个不一样。规范网址回答的是“这一页的正式地址是哪个”，而hreflang的默认版本回答的是“语言都匹配不上的时候把人送到哪一版”。前者是身份，后者是兜底策略，它们本来就不必是同一个地址。

问题在于这个“本来不必”在实践中被滥用了。多语言模块通常由另一个团队或者另一个插件负责，它按自己的逻辑挑一个兜底版本，而完全不知道页面上还有别的地方在声明身份。

身份和意图是两回事，搜索意图到底有几种讲了5种类型。

插件各管一段最容易出事，Shopify博客标签页SEO优化讲的是权重稀释。

更要命的是，兜底版本经常被设成某个具体国家的版本。后面会看到实例，有的站默认版本指向芬兰站，有的指向英国站，有的指向欧盟站，而同一个页面的结构化数据写的是裸域名。两句话都合语法，但拼在一起就是在说这个网站有两个主页。

分歧率要和覆盖率一起读

这张表有个陷阱，不说清楚容易读反。

看最上面那一行：hreflang默认版本与结构化数据，41个页面里13个对不上，31.7%。这个比例很高，但分母只有41——因为只有41个页面同时具备这两个来源。

再看倒数第三行：规范网址与实际服务地址，121个页面里9个对不上，7.4%。比例低得多，但分母是121，覆盖了绝大多数站。

多语言内容在AI检索里的处境，多语言AI可见性怎么做讲了翻译内容为什么吃亏。

比例高说明这一对容易打架，绝对数大说明这个问题影响面广，两个视角要分开用。做优先级排序的时候看绝对数，做根因分析的时候看比例。

还有一个更实用的读法：把分歧率高的那几对当成一份预警清单。你的站如果同时具备hreflang默认版本和结构化数据这两处声明，那就有将近三分之一的先验概率对不上，值得主动去查一遍，而不是等出事。

指标怎么排优先级，网站收录速度实操指南用三平台数据做过对比。

和实际服务地址比，才是真正的体检

表里有三行是拿声明去和服务器实际服务的地址比，这三行的含义跟其他行不一样，值得单独拎出来。

声明与声明之间打架，说明的是内部不一致，问题在协作。声明与事实打架，说明的是这个页面在撒谎——不是故意的，但效果一样。

三行的数字是：规范网址与实际地址7.4%、结构化数据与实际地址12.8%、多语言默认版本与实际地址23.4%。规范网址那一行最低，说明它是被维护得最认真的一个字段，这符合预期。

收录、排名、流量卡在哪一层，这三件事要分开查给了分层方法。

og:url与实际地址的分歧是6.4%，只有6个页面，是全表倒数第二低。这个数字有点出乎意料——一个跟收录无关的字段，反而比结构化数据更贴近事实。

原因大概是它通常和规范网址同源生成，跟着后者一起对齐了。这也从侧面说明，只要地址是在一处生成的，跟着它输出的字段就都是对的；一处生成解决的是一批问题，不是一个。

结构化数据还能表达链接关系，用SignificantLink和RelatedLink提升内链效果是另一种用法。

为什么没有一对是零

整张表里最低的一对是2.2%，没有任何一对做到零。这件事本身就说明了点什么。

2.2%对应的是2个页面，而这两个页面的规范网址与og:url不一致，几乎可以断定是两处分别硬编码的结果——有人在模板里手写了一个，在插件设置里又填了一个。

这类硬编码是所有地址不一致里最难发现的一种，因为它不遵循任何规律，不会在同一批页面上同时出现，只在某一页上错。批量审计能抓到它，逐页人工检查反而抓不到，因为没人会去检查一个看起来一切正常的页面。

声明来源越多，越容易打架吗

这是个很自然的疑问，数据也支持它，但支持的方式有点意外。

按来源数量分组之后：只有2个来源的29个站，一致率明显更高；有4个来源的34个站，一致率最低。这符合直觉——参与的人越多越难对齐。

但更值得注意的是分歧的性质变了。来源少的站，出问题多半是格式差异，放宽一层就救回来了；来源多的站，出问题往往是真分歧，怎么放宽都救不回来。

原因也不难理解。当一个页面同时有四处声明的时候，说明这个站做了多语言、做了社交、做了结构化数据，也就意味着它是个有多个市场、多个版本的复杂站。而复杂站的地址本来就有多个合理的候选，选哪个是个真问题，不是拼错了斜杠那么简单。

所以这条规律的实用含义是：如果你的站声明来源多，别指望靠一次格式清洗解决问题，那些分歧多半需要一个一个去做业务判断。反过来，如果你的站只有两三处声明却仍然不一致，那大概率是个便宜的修复。

canonical自指率92.6%，那9个不自指的站分别错在哪？

这一节全是实例，每一条都回到原始字节核对过，零推测。

先看自指率

规范网址标签最常见的用法是自指，也就是首页的规范网址就写首页自己。121个有这个标签的站里，严格按字符串比，自指的有96个，79.3%；忽略末尾斜杠之后是112个，92.6%。

另外有一个数字值得单独说：指向另一个域名的规范网址，一个都没有。跨域规范网址在技术上是允许的，但它风险极高，等于把自己这一页的权重让给别人。这批中大型品牌站里零出现，说明这条底线大家守得还不错。

标签页的地址最容易忘了自指，Shopify博客tag标签URL优化含301重定向实战。

把权重让给别人这件事，Google出站链接会损害SEO吗从链接图谱算过。

还有一个小发现：有一个站的首页写了两条规范网址标签，值相同。这在规范里属于未定义行为，搜索引擎通常会忽略全部或者取第一条。值相同所以没造成实际伤害，但它说明这个页面上有两个模块都在写这个标签，而它们互相不知道对方存在。

九个不自指的站，四种毛病

插件互相覆盖是常态，WordPress标签相关文章实战记过一次反模式拆解。

逐条说几个最有意思的。

第一个是刀具品牌那条，原始字节是一个相对路径，文件名就叫“countryselector.canonical”。这明显是模板里的变量名没被替换掉，把变量名本身当成路径输出了。浏览器会把它解析成一个不存在的地址，而这个错误在页面上完全看不出来，因为规范网址标签本来就不显示。

第二个是健身器材那条。它的首页规范网址指向一个叫“八月促销变体”的地址。这大概率是A/B测试工具留下的：测试期间把首页换成了变体版本，收工时忘了把标签改回来。这个错误的性质比看上去严重，因为它等于在告诉搜索引擎：我的首页不是首页，那个促销页才是。

模板标签调用写错的形态类似，模板标签怎么调用有速查表。

实验期的数据也会骗人，A/B测试赢了上线却掉了问题出在那26天。

第三个是那个三个斜杠的。协议后面本该是两个斜杠，它写了三个。这种错误一眼就能看出是字符串拼接的时候，一边的变量自带了斜杠，另一边又硬加了一个。

那两个带443端口的，我特意去核对了

数据里有两个站的最终地址带着443端口。第一反应是我自己的抓取工具加的，那样的话这条数据就得作废。

这类脚本问题怎么自动化兜住，独立站服务器怎么用cron把运维自动化给了做法。

所以我把这两个站的跳转链原样打了出来。结果是：一个站返回301，响应头里的目标地址原文就写着带443端口的地址；另一个站先返回308跳到裸域名，再返回301，目标地址同样带着443端口。两个都是它们自己写死在跳转响应里的，不是抓取工具的产物。

443是加密连接的默认端口，写不写在语义上没有区别，RFC 3986定义的统一资源标识符通用语法里就把省略默认端口列为标准的归一化步骤之一。但作为字符串它就是不一样了，而搜索引擎处理地址的时候，很多环节是按字符串来的。一个多余的端口号，足以让同一个页面在某些系统里变成两个地址。

同一批站的响应头还量过别的，304状态码能省抓取预算测了142个站。

响应头这一层还有别的机关，HTTP响应头的X-Robots与Vary机制逐个讲过。

这件事也顺便说明了核对原始字节的必要性。如果我没去看那条跳转链，就会把自己工具的嫌疑当成事实写进结论里，这份数据就废了一角。凡是看着像自己工具造成的异常，一定要单独核一遍，因为它有一半概率不是。

模板变量没渲染这类错，怎么防

那个把变量名当路径输出的案例，看着离奇，其实是最常见的一类模板事故。

工具打架时该信谁，收录数据到底信site命令还是GSC给了三源校准法。

它的成因通常是变量名拼错、或者模板引擎的语法用错了一个符号、或者那个变量在这个页面的上下文里根本不存在。这三种情况下，多数模板引擎的默认行为是输出空字符串或者原样输出，都不报错。

危险就在这个不报错上。页面能正常打开，视觉上毫无异样，只有藏在头部的那一行字是错的。而头部这些标签恰恰是最没人看的地方。

标题标签也常踩这个坑，自定义title标签的5场景实战有代码。

防它的办法有三个，从便宜到贵。最便宜的是上线前跑一次头部体检，把几个关键标签的值打印出来人工扫一眼，三分钟。中等的是写一条断言：规范网址必须以协议开头且能解析成合法地址，不满足就构建失败。最贵也最彻底的是前面说的那个统一函数，从源头上不给手写留机会。

A/B测试留下的残骸

那个把首页规范网址指向促销变体页的案例，属于另一类事故：临时状态被永久化。

服务器层还有20项值得查，服务器配置对SEO的影响清单列全了。

A/B测试工具改页面的方式有两种。一种是客户端改写，脚本在浏览器里把内容换掉，这种通常不影响头部标签。另一种是服务端分流，直接给不同的人返回不同的页面，这种就会把整个页面连同头部标签一起换掉。

第二种更快也更利于收录，但它有个后遗症：测试结束之后，如果分流规则没有干净地撤掉，某些请求方还会一直拿到变体版本。而爬虫恰恰是那种最容易被规则遗漏的请求方。

做法上有一条硬规矩值得立：任何服务端分流的实验，实验期内变体页的规范网址必须指回原页，而不是指向自己。这样即使规则忘了撤，收录层面也不会出事。

顺便一提，这个案例里的变体页名字带着月份。也就是说这个测试至少是那个月做的，而标签一直挂到现在。促销早就结束了，它的名字还留在这个站对自己身份的声明里。

实验前先把测量框架定清楚，埋点之前先设计测量框架是同一个顺序问题。

首页到底要不要写自指的规范网址

既然92.6%的站都写了，这个问题好像不用问。但它值得问，因为理由不是随大流。

自指标签的价值不在于告诉对方这一页在哪，那件事跳转和链接已经说清楚了。它的价值在于把一堆你没预料到的变体地址收拢回来。

想想一个首页可能有多少个能打开的形式：带与不带www、带与不带末尾斜杠、带广告追踪参数的、带社交来源标记的、被人手工加了大写字母的、带一个无意义空参数的。这些形式里的每一个，只要能返回200，就是一个独立的候选地址。

而它们全都会输出同一份HTML，也就都会带上那个自指标签，指回同一个正版地址。一行标签，把无穷多个变体一次性收拢。这就是它真正的作用。

过滤器产生的地址最多，电商过滤器SEO实战对比了5类参数处理。

用robots去挡参数是另一条错路，robots.txt能禁止UTM追踪参数吗讲了危害。

反过来说，如果你的站严格保证只有一个可达形式，其余全部301过来，那这个标签的边际价值确实不高。但真做到这一点的站极少——本文数据里81.8%的首页最终服务的地址跟输入的都不是同一个，这已经说明地址形式的膨胀是常态。

所以结论很简单：写，而且写绝对地址。成本是一行，收益是把一类你永远数不清的问题一次性关掉。

三十秒自查自指

不需要工具，一条命令加一次肉眼比对就够。

先取事实：对首页发一次跟随跳转的请求，把最终地址记下来。再取声明：把页面源码里那一行规范网址标签抠出来。两个字符串并排放着看。

比的时候按三层看：完全一样，很好；只差一个末尾斜杠，记成技术债；差别不止斜杠，那就是本文说的那9个站里的一员，需要单独查。

这个动作最值得做的时机有三个：接手一个新客户的站时、自己的站换过模板之后、以及每次改完跳转规则之后。三十秒，能挡住的是那种能挂几个月没人发现的问题。

顺带一提，本文那9个不自指的站，全都是行业里有名有姓的品牌。这个检查之所以没人做，不是因为它难，是因为它太简单了，简单到不像是一件需要专门去做的事。

为什么hreflang的默认版本和结构化数据最容易打架？

上一节留了个尾巴，这一节把这12条分歧全部摊开。

同一批站的另一项体检，211个站有152个拿不出图标也是这种简单到没人做的检查。

12条分歧，形态高度一致

这12条我逐个回到原始字节核对，全部为真，没有一条是解析错误。而且它们的形态整齐得惊人：

同类核对方法也能用在竞品研究上，产品评测只做SEO就够了吗讲了深度研究法。

形态只有两种。一种是默认版本指向某个具体的国家或语言版本，而结构化数据写裸域名或者www主域名；另一种更麻烦，两边各指一个不同的语言版本，一个说英文站是主的，另一个说中文站是主的。

顺带说一个细节：储能设备那个站的默认版本地址里带着一个双斜杠的路径。这又是一处字符串拼接问题，和前面那个三斜杠是同一类毛病，只不过换了个位置。这类拼接错误在多语言站上出现的频率明显更高，因为地址是由好几段变量拼起来的，每一段的斜杠归属都要有人拍板。

多版本内容的组织逻辑，AI搜索时代内容优化的底层逻辑给了5步框架。

换域名时的拼接问题更集中，换域名后台跳转登不上记了三种改法。

两个团队，两套主页的定义

这12条分歧的成因，我认为是一个组织问题，不是技术问题。

多语言模块的负责人在回答一个运营问题：一个说着我们不支持的语言的用户来了，把他送到哪里最不容易流失。答案通常是英文站或者主要市场站。

结构化数据的负责人在回答一个品牌问题：我们这个品牌的官网地址是什么。答案通常是裸域名，因为那是印在名片和包装上的那个。

两个答案在各自的语境里都对。但它们被放进同一份HTML之后，就变成了两个互相矛盾的身份声明，而读这份HTML的机器不知道这两句话是两个部门说的。

要说明的是，这两个字段本来就不必相同，这不是硬性错误。真正的风险在于当同一个页面上有三四个来源、彼此各指一处的时候，接收方必须自己挑一个作为准。挑的过程你参与不了，结果你也控制不了。

多语言站的地址为什么特别容易拼错

这12条里出现了两处斜杠拼接错误——一个三斜杠，一个双斜杠路径。这不是巧合。

单语言站的页面地址通常是两段：域名加路径。多语言站至少是四段：域名、语言码、地区码、路径，有时候还要加上货币或者渠道标识。每一段之间的斜杠归谁管，就是一个需要被明确规定的事。

常见的错法是这样：域名变量自带末尾斜杠，拼接的时候又硬加了一个，于是出现双斜杠；或者反过来，两边都以为对方会加，结果一个都没有，两段直接粘在一起。

更麻烦的是，这类错误在浏览器里往往看不出来。浏览器对多余的斜杠很宽容，双斜杠路径照样能打开，页面正常显示。只有当这个地址被当成字符串去比较、去归并、去做规范判断的时候，多出来的那个字符才会变成一个真正的分歧。

防它只有一个可靠办法：地址拼接必须走同一个函数，函数内部统一规定每一段的斜杠归属，其他地方一律不许手工拼。听起来是老生常谈，但这批中大型站里做到的还不到三分之一。

先统一哪一处

如果你的站已经有了这个问题，改造有先后。

先统一规范网址和og:url，这两个通常最容易，改一处就行，而且它们的分歧率本来就低，改完能立刻拿到一个干净的基准。

再统一结构化数据里的地址。这一步的难点是那个字段的语义容易被理解成品牌官网而不是当前页面地址，所以改之前要先跟负责的人对齐它到底该写什么。我的建议是：页面级实体写当前页地址，组织级实体写裸域名，两者分开，别混在一个字段里。

面包屑也是一处地址声明，面包屑导航SEO怎么做讲了四种类型。

实体之间的关系怎么搭，Schema的graph与知识图谱讲了做法。

最后才动多语言声明。它牵涉的运营逻辑最多，改动前要跟负责各市场的人确认兜底策略。这一步经常改不动，改不动也没关系——只要另外三处是齐的，剩下一处的分歧对结果的影响就小得多。

这12个站的行业分布说明了什么

把这12个站的行业排一下：骑行服饰、快时尚、母婴、香氛、厨房家电、清洁电器、储能设备、园艺工具、数码配件、骑行装备、水晶饰品、充电配件。

看不出行业集中，但看得出另一个共同点：它们全都是做多个国家市场的品牌，而且大多数是在近几年才快速铺开市场的那一类。

这个共同点比行业更有解释力。一个站的地址结构，通常是在它只有一个市场的时候定下来的，那时候地址简单、声明也少。等到开第二个、第三个市场，语言前缀、地区路径、国家子域名一层层加上去，而最初那套地址生成逻辑没有跟着重构。

多市场该建几个站，出海该建一个大站还是多个品牌小站算过这笔账。

新市场的地址由新模块生成，老的声明还留在老地方。于是分歧不是某一天突然出现的，是随着市场扩张一点点积累的。

这一条对正在做多市场扩张的独立站特别有用：地址结构的重构窗口在开第二个市场的时候，不在开第五个的时候。第二个市场的时候改，成本是一个模板；第五个的时候改，成本是五套跳转规则加一次全站地址迁移。

默认版本到底该指向哪

既然这个字段是分歧的重灾区，那就把它该怎么设说清楚。

新市场的节奏怎么排，新品上市从蓄水到复盘的GTM框架是另一篇。

它的定义是：当访问者的语言和地区都匹配不上你声明的任何一个版本时，把他送到这一版。所以判断标准只有一个——对一个你完全不了解的陌生人，哪一版最不容易让他掉头就走。

常见的三种选法各有代价。选英文国际版最稳，代价是对已有明确主市场的品牌来说，可能把本该进主市场的人分流走了。选主市场版转化最好，代价是一个来自完全不相干地区的人会看到一堆他买不到的商品和一个不对的货币。选一个语言选择页最中立，代价是多一次点击，而且这个页面通常内容很薄。

陌生访客的意图怎么判断，看SERP后落地页要改成什么样给了7步。

我的倾向是选英文国际版，但有个前提：这一版必须是真的能下单的完整站，不能是个空壳。兜底页的价值在于它是一个能完成交易的落点，不是一个礼貌的转接台。

还有一条容易被忽略的：这个字段的值应该和规范网址体系兼容。如果你的默认版本指向某个具体语言版本，那那个版本的页面自己得有正确的自指标签，别让它既是别人的兜底又不承认自己是一页。

能不能完成交易还看支付，独立站支付方式怎么配按地区拆过。

多语言站还有一个额外的风险

顺着上一句往下说，多语言站有一处特别容易出事，而且出了事很难查。

正确的做法是每个语言版本的页面都自指：中文版的规范网址写中文版自己，英文版写英文版自己，然后靠多语言声明把它们串成一组。这样每一版都是独立的一页，各自可以被收录。

常见的错法是让所有语言版本都指向同一个主版本。写的人的想法通常是“这些是同一个页面的不同语言，应该归到一起”——听着很合理，实际后果是除了主版本之外的所有语言版本都放弃了自己被收录的机会。

每个页面类型该配什么，Shopify怎么给页面加结构化数据讲了128种类型怎么选。

这个错误的隐蔽之处在于，它在短期内看不出问题：页面都能打开，多语言声明也写了，报表上也没有报错。只有当你发现某个市场的自然流量一直起不来，去查那个语言版本的收录状态时，才会看到它被归并掉了。

判断方法很简单：打开任意一个非主语言版本的页面，看它的规范网址写的是自己还是别人。写的是别人，那就是这个错。三十秒能验完，但很少有人想到去验。

收录状态变化有时滞，已收录页面加noindex后多久消失做了6场景实测。

81.8%的首页，你输进去的地址不是它最终服务的那个

还有一层事实经常被漏掉：连你自己都不一定知道你的首页地址是什么。

跳转是常态，不是例外

132个能正常给出页面的首页里，97个是经过跳转才拿到的，占73.5%。而最终服务的地址与最初输入的地址不是同一个字符串的，有108个，占81.8%。

这两个数字要分开看。前者说的是发生了跳转，后者说的是跳转之后地址真的变了——包括加www、加末尾斜杠、加语言前缀、换成国家子域名这几类。

抓取报告里跳转类问题占多少，Google抓取报告怎么读给了占比与排查顺序。

81.8%意味着什么？意味着在这行里，你输入的地址和你实际拿到的地址不一样，是绝对的常态。那些声明字段如果是照着某个人记忆里的地址手写的，出错几乎是必然的。

跳转链上还藏着别的东西

这批数据里的跳转链，短的一步，长的三四步。步数多本身不算问题，但每多一步就多一个能写错的地方，前面那两个443端口就是在跳转链上写死的。

跳转配错就变成软404，GSC 404错误修复讲了排查实战。

多域名跳转怎么配才干净，多域名301跳转到主域名的完整配置有实例。

还有一类值得留意：跳转的目标随请求方变化。上一篇量到过好几个站，浏览器身份被送到中国站，搜索引擎身份被送到国际站。这种情况下，你的规范网址标签在两个不同的落点上会呈现出完全不同的一致性，而你从自己电脑上只能看到其中一种。

做审计的时候，最终地址这一列必须从真实的跳转链里取，不能用你输入的那个。这听起来是常识，但很多现成工具默认报的是你输入的地址。

中国这一侧的分流更复杂，中国搜索流量不是百度的天下拆了5个战场。

工具看到的和真实的可能不同，网页历史快照还能怎么查列了5个工具。

一个可以马上做的检查

打开命令行，对你的首页发一次跟随跳转的请求，把每一跳的状态码和目标地址打印出来，再把最终地址和页面里的规范网址标签放在一起看。

这个动作三十秒，能一次性回答三个问题：跳了几次、最后落在哪、声明的和落点是不是同一个。如果这三个答案里有任何一个让你意外，那就说明你对自己网站地址的认知已经过期了。

跳转链的四种常见形态

把这批站的跳转链归一下类，形态就四种，各有各的坑。

第一种是补全型：从裸域名跳到带www，或者从http跳到https，或者补上末尾斜杠。这一类最常见也最无害，只要声明字段写的是跳转之后的那个形式就行。

第二种是分地区型：根据来源把你送到某个国家站。这一类要小心，因为不同请求方看到的终点不同，你的声明只能对准其中一个。

第三种是路径迁移型：老地址跳到新地址。这一类的风险是链条会越接越长，改版几次之后可能变成三跳四跳，每一跳都是一次损耗。这类跳转应该用永久重定向，MDN关于301永久重定向的条目写明了它与临时重定向在缓存与方法保留上的差别。

按设备分流是同一类做法，JS判断移动端并自动跳转讲了它的SEO代价。

迁移后的层级关系要重新声明，Shopify博客多级面包屑导航给了3种方案。

第四种最少见也最麻烦：跳到一个功能页，比如国家选择页或者语言选择页。这种情况下你的首页实际上不是内容页，而是一个中转站，而中转站的内容通常很薄。本文数据里那个把变量名当路径输出的站，它的模板变量名恰好就叫国家选择器，多半就属于这一类。

裸域名还是带www，到底怎么选

这个老问题在这批数据里有个新角度。

导航把人送到哪一屏是同一类问题，类目导航改版做了三轮讲了那一屏缺什么。

从收录角度看，两者没有高下，选哪个都行，关键是选定之后全站统一。真正的差别在运维层面：带www的可以用别名记录，裸域名在很多解析服务上只能用A记录，切换服务商的时候会更麻烦一点。

这批数据里绝大多数站选了带www，少数几个选了裸域名，其中一个就出了前面那个家具品牌的问题：规范网址写不带www，服务器服务带www。这不是选错了，是选完之后没有把所有地方都改过来。

资源类型也跟这个选择有关，GSC网域与网址前缀资源对比给了6场景选型。

所以决定权其实不在选哪个，而在于你有没有一份清单，列出所有需要写死这个选择的地方：跳转规则、规范网址、站点地图、社交标签、结构化数据、内部链接、广告落地页、邮件模板里的链接。漏掉任何一处，都会在某个时刻变成一份竞争性证据。

跳转链每多一跳，损耗在哪

常有人问多一跳到底有没有代价。有，但不在你以为的地方。

邮件那一侧的链接也归它管，Flow和Campaign到底有什么区别讲了两者的分工。

权重传递的损耗这两年已经被官方多次淡化，正常的永久跳转基本不损失权重。真正的代价在另外三处。

第一是抓取成本。每一跳都是一次完整的请求往返，链条越长，抓完同样数量的页面需要的请求次数越多。对页面数量大的站，这笔账是实的。

权重从哪来，谷歌SEO外链建设的16种白帽做法讲了获取路径。

第二是延迟。用户端每一跳都要重新建连接、重新握手，在跨境网络条件下一跳可能就是几百毫秒。三跳跳完，首字节时间可能已经超过了大多数人的耐心阈值。

第三，也是跟本文最相关的：链条越长，中间某一跳写错的概率越高，而中间跳的目标地址几乎没有人会去检查。前面那两个带443端口的案例，一个就出现在两跳链条的第二跳上。

首字节时间怎么优化，TTFB怎么优化才不白费串起了缓存与抓取。

实践建议是把链条压到一跳。改版多次积累下来的老跳转，与其一层层接，不如定期把它们摊平成直接指向最终地址。这个动作在跳转规则文件里是一次批量替换，成本很低，但很少有人做。

跳转链该被记下来

还有一件几乎没人做但成本极低的事：把关键页面的跳转链定期记一份。

做法就是每周对首页和几个主要入口跑一次跟随跳转的请求，把每一跳的状态码和目标地址存成一行文本，带上日期。存三个月，你就有了一份跳转链的历史。

记录多了要管好，服务器日志怎么管才不爆盘有轮转方案。

这份历史的价值在出事的时候才显现。有一天某个页面的地址在搜索结果里变了，或者广告落地页开始报审核不通过，你打开这份记录，一眼就能看出跳转链是哪天变的、变成了什么。没有这份记录，同样的问题要靠回忆和猜测排查，通常要花掉半天。

它跟前一篇提到的身份可达性监测可以合并成同一个脚本：同一次请求，既记状态码和字节数，也记整条跳转链。多存两个字段而已。

11个站的首页根本没有规范网址标签，会怎么样？

反方向也得看。

没有声明，接收方就自己定

132个站里有11个的首页完全没有规范网址标签，覆盖百货、家居、快时尚、母婴、咖啡机几个大类，都不是小站。

没有这个标签不等于会出事。搜索引擎在没有声明的情况下会自己选一个作为规范版本，判断依据包括哪个地址被链接得更多、哪个跳转的终点、哪个内容更完整、哪个在站点地图里。选得对的概率其实不低，尤其是结构简单的站。

问题出在两种情况。一种是同一份内容有多个可达地址——带参数的、带追踪码的、带地区前缀的——这时候它可能选中你不想要的那一个。另一种就是开头那个案例：几个域名共用过同一个停放页或者过渡页，内容一模一样，它就可能把你的地址归并到别人那儿去。

选完还要分层，Google分层索引揭秘讲了三层的差别。

买域名前该查什么，域名生成器怎么用讲了命名策略与避坑。

为什么共用过停放页会导致这种结果

这个机制值得讲清楚，因为它解释了那张吓人的截图。

搜索引擎判断两个地址是不是同一个页面，用的是内容相似度。两个域名在某段时间里都指向同一个域名注册商的默认停放页，那段时间它们的内容是逐字节相同的。系统就会把它们归成一组，从组里挑一个当代表。

等你把新站上线了，你这个地址的内容变了，但归并关系不会立刻解除。它需要重新抓取、重新比较、重新分组，而这个过程是有滞后的。这也是官方建议“过几周再看”的原因。

这一条是采信型故障的典型特征：你改了，但它要等；等多久不由你定，而且没有任何进度条。

抓取频率能不能提，Google抓取预算优化的12项实操给了边界。

新站上线时该做的三件事

如果你正好在做一个新域名的站，这三件事能明显缩短那个等待期。

第一，首页和所有重要页面都写上自指的规范网址标签。它不是万能的，但它是你唯一能直接表达意图的地方。

第二，站点地图提交上去，并且确保里面写的地址和规范网址标签完全一致，包括末尾那个斜杠。站点地图是一份很强的信号，它和标签一致的时候，两份证据是叠加的；不一致的时候，是互相抵消的。

第三，尽快让新内容跟老的停放页产生足够大的差异。内容差异越大，归并关系解除得越快。这也意味着上线初期就该有真实的内容，别拿一个只有导航的骨架页占着。

这份文件写错的方式很多，Sitemap到底怎么写才不出错收了2400个站的坑。

内容要形成共识才被引用，AI搜索不引用你的共识层6信号给了90天路径。

参数地址是最容易被忽略的那份证据

没有规范网址标签的站，最大的风险来自参数。这一节单独说，因为它在电商站上普遍存在。

一个商品页可能同时有这些形式能打开：原始地址、带广告追踪参数的、带社交分享参数的、带站内搜索来源标记的、带筛选条件的、带排序方式的。它们的内容完全相同，地址各不相同。

每一个能打开的形式，都是一份独立的证据。你在广告里投了三个月带追踪参数的地址，那个形式被点击了几十万次，还被别人复制粘贴分享出去——从证据强度上说，它未必比你那个从没人链接过的原始地址弱。

处理办法按力度分三档。最轻的是保证所有参数形式都输出指向原始地址的自指标签，这样参数再多也归一。中等的是在服务器层把已知的无意义参数剥掉再跳转过去。最重的是干脆不产生这些地址，改用别的方式传递来源信息。

要提醒一句：不要用robots规则去屏蔽参数地址。屏蔽的后果是接收方读不到那些页面上的规范网址标签，反而没法把它们归并到正版上，问题会变得更难解决。这是一个经典的把采信型当送达型处理的错误。

那11个站有什么共同点

把这11个没有规范网址标签的站放在一起看，共同点比我预想的清楚。

筛选页该不该禁有判别法，电商筛选URL要不要写Disallow给了三类分法。

第一个共同点：它们里有好几个是本文前面提到的多语言大站，也就是说地址结构最复杂的那一批里，反而有几个连最基本的声明都没有。

第二个共同点更有意思：这11个里有几个的首页HTML本身就很薄，几千字节，内容基本靠脚本在浏览器里生成。这就跟前两篇的结论接上了——一个页面如果连正文都没在字节里，那它多半也不会在字节里认真声明自己是谁。

多市场要面对的不止一家搜索引擎，2026全球搜索引擎格局做了多平台拆解。

第三个共同点是它们大多有地区跳转。首页不是一个内容页，而是一个把你分流到某个国家站的中转站。中转站的模板往往是单独做的，很简陋，SEO模块根本没挂上去。

三条合起来指向同一个判断：缺失地址声明，很少是一个孤立的疏忽，它通常是首页架构本身有问题的一个症状。发现这一条，值得顺手去看看这个首页还缺什么别的。

新站上线的时间线，大概长这样

既然讲到新域名，把这条时间线摊开写一遍，省得干等着焦虑。

上线当天到第三天，通常什么都不会发生。这几天的任务是把该做的都做完：自指标签、站点地图、内部链接形式统一、内容填满。这三天做的事，决定了后面几周的走向，之后再补效果就差很多。

第一周到第二周，开始被抓取，但收录状态大概率还是模糊的。这段时间最容易做出错误动作——看到状态不对就去改标签，改完再等，等不到再改。忍住。

新站前期该干什么，零预算SEO增长的5个策略附了30天清单。

第二周到第四周，如果有域名共用历史这类问题，这段时间是它解除归并的窗口。判断依据是抓取记录：如果抓取频率在上升、抓到的页面数在增加，那就是在正常推进。

一个月之后还没有变化，才轮到重新排查。这时候排查的对象也不该是标签，而是那份竞争性证据到底还在不在。

这条时间线是个粗略的参考，具体快慢跟站的规模、内容更新频率、外部链接情况都有关。它的用处不在精确，在于给出一个心理上的锚——知道两周内没动静是正常的，就不会在第五天去做那个会重置周期的动作。

它为什么必须自己选一个？

讲完现象，回到机制。这一节是全篇的落点。

接收方面对的是一堆证据，不是一条指令

很多人对规范网址标签有个误解，以为它是一条命令。官方文档里其实写得很明白，它是一个强信号，不是指令。这一点在最早的规范里就定下来了——RFC 6596对canonical链接关系的定义用的词是偏好版本，而不是唯一版本。

接收方要做的是从一堆证据里选出最可信的那个。证据包括：你的规范网址标签、你的站点地图、你的内部链接指向、你的跳转终点、别人链接到你时用的地址、你的多语言声明、你的结构化数据。这七样里只有前两样是你明确写下的，其余五样都是你在无意中产生的。

另一份也常被误当成指令的文件，robots.txt写废了网站会从谷歌消失讲了它的真实约束力。

内链的形式也是一份证据，给内链加UTM参数为什么伤SEO讲了取舍。

当这些证据一致的时候，选择是显然的。当它们打架的时候，系统按自己的权重去评，而这个权重表你看不到。

本文的数据说明的正是这件事：23%的页面在给出互相矛盾的证据，而它们的所有者大概率不知道。

两个并列字段就是采信型的标志

怎么一眼认出你正在面对一个采信型问题？看官方界面上有没有两个并列的字段，一个记录你说的，一个记录它选的。

规范网址是最典型的一对：一栏叫“用户声明的规范网址”，另一栏叫“谷歌选定的规范网址”。这两栏并排存在，本身就是在告诉你，第二栏可以不等于第一栏。

这张表里的每一行都遵循同一个逻辑：你提供的是一份候选，不是一个指令；对方在你的候选和它自己观察到的证据之间做选择。

识别方法也统一：凡是官方界面上把“你填的”和“实际的”分成两栏显示，或者措辞里出现选定、检测到、系统判定这类词，都属于这一类。

反过来，那些只有一栏的字段，比如robots指令、跳转规则、页面上真实存在的文字，基本都是指令型的，说了就算。分清哪些是指令、哪些是候选，比记住每个字段该怎么写更有用。

这个模式在别处也一样成立。页面标题你写一份，搜索结果里显示的可能是另一份；描述你写一份，摘要可能是它自己从正文里摘的；商家名称你填一份，展示出来的可能是它认定的另一个形式。凡是措辞里出现“选定”“检测到”“系统判定”这类词的字段，都属于这一类。

认出来之后，处置方式跟另外两种病完全不同：你不能直接指定结果，只能去改变证据的分布。

商家名称的展示形式也是它定的，112个独立站里17个在犯的双语重复是实测。

标题被改写的机制，title写了为什么被Google改写讲了截断与重复。

能控制的和不能控制的，得先分清

面对采信型问题，最耗人的不是修不好，是分不清哪些事根本不该花力气。

完全能控制的有四样：跳转规则、页面里的各处声明、站点地图、内部链接使用的地址形式。这四样加起来已经覆盖了证据里的大部分权重，而且改动成本都不高。

部分能控制的有两样：外部链接使用的地址形式、内容与其他页面的相似度。前者你能做的只是在给出链接时统一形式，别人怎么写你管不着；后者你能做的是让内容尽快变得独特。

哪些下滑不该算你的账，流量下降不等于SEO失败给了8个维度。

完全不能控制的有三样：对方的评估周期、对方的权重表、以及历史上这个域名发生过什么。开头那个案例里的域名共用历史，就属于这一类——你什么都没做错，你只是买了一个有前科的域名。

把三类分开之后，动作就清楚了：在四样完全可控的上面做到极致，在两样部分可控的上面做能做的，在三样不可控的上面只做一件事——等，并且记下开始等的日期。

域名本身的选择也有讲究，带连字符的域名到底伤不伤SEO讲了官方口径。

这个分类还有一个心理上的好处。采信型问题最折磨人的地方是没有确定的反馈，很容易让人不断折腾。知道哪些事已经做到头了，才敢停手。

投入和产出之间没有确定的时间关系

采信型还有一个让人难受的属性：滞后。

缺失型是阶梯式的，补一处多一处，改完刷新就能验证。送达型是开关式的，关掉就通，验证同样立刻。采信型两样都不是——你改完之后要等它重新抓取、重新评估、重新分组，而这个周期从几天到几周不等，取决于你的站被抓取的频率。

这个属性带来两个实际后果。一是不要在等待期里反复改，每改一次等于把评估周期重置一次。改完就停手，记下日期，两周后再看。

二是不要用短期数据去判断有没有效果。三天没变化说明不了任何事，因为它可能还没重新抓到那一页。

七份证据，权重各不相同

既然结果由证据决定，那就得知道哪份证据重。官方没有公布权重表，但从公开文档和大量案例里能推出一个大致的强弱顺序。

这张表有两个用法。

第一，当低强度的证据和高强度的证据打架时，通常不会翻盘，但会增加不确定性。结构化数据写错一个地址不太可能真的改变结果，但它会让本来清晰的信号变模糊。

第二，也是更重要的：最强的那份证据恰好是你最容易忘记的那一份。跳转规则往往是几年前配的，配的人可能已经离职，而它的权重比你精心维护的标签还高。做审计时先看跳转，再看标签。

站点地图这份证据被低估了

表里排中间的站点地图，实际使用中经常被当成一个纯粹的收录工具，忽略了它同时也是一份地址声明。

老配置该定期回看，Apache服务器怎么安全加固讲了从版本隐藏到访问控制。

你在站点地图里写的每一个地址，都是在说这个形式是正版。如果站点地图里写的带末尾斜杠，而规范网址标签写的不带，那你就自己给了两份互相打架的证据，而且两份都出自你手。

这类不一致极其常见，因为站点地图通常由另一个插件或者另一个脚本生成，它有自己的地址拼接逻辑。这又回到了同一个根因：地址不是在一处生成的。

所以对齐审计的最后一步永远是比对站点地图，而且要逐字符比，不要肉眼扫。肉眼扫是看不出末尾斜杠差异的，这也是为什么这类问题能长期存在。

站点地图自己生成也一样，免插件sitemap实战指南讲了分页与缓存策略。

AI答案里的那个官网链接，取自哪一份

这一节往前看一步，因为地址声明的读者名单这两年变长了。

当一个AI答案提到某个品牌并附上官网链接的时候，那个地址是从哪来的？可能的来源有三个：它抓到的页面里的结构化数据、它抓到的页面的实际地址、或者它从别的信息源里学到的那个地址。

三个来源里，结构化数据是唯一你能直接写死的那个。而它恰恰是本文那张证据强度表里排最后的一份。在传统收录的语境里它权重最低，在实体信息整理的语境里它反而是最直接的来源。

AI引用到底看什么，3000条数据揭开AI搜索引用的认知差做了实证。

这个错位有实际含义：同一个字段在两条链路上的重要性不一样，所以不能只按其中一条链路去决定怎么写它。

具体的建议是把两类实体分开写。描述当前这个页面的实体，地址写当前页；描述组织或者品牌的实体，地址写你希望被当成官网的那一个，通常是带www的裸首页。两个写在一个结构化数据块里没问题，写成两个并列的实体即可，别让它们共用一个地址字段。

另外要提醒的是，本文数据里结构化数据的覆盖率是65.2%，也就是有三分之一的站在这个字段上什么都没说。在传统收录时代这不算大事，在实体信息被大量整理的今天，它等于把这道题的答案权完全交给了别人。

为什么加大声明力度反而会把事情弄糟？

这是采信型最典型的误判动作，值得单独讲。

实体权威怎么建，AI搜索时代实体权威的四阶段协作框架给了路径。

常见的三种错误反应

发现它选的不是你写的，大多数人的第一反应会落在这三种里。

第一种是再声明一遍。既然它没听我的，那我多写几个地方，规范网址写、社交标签写、结构化数据也写。这个动作的实际效果，是把证据数量从三份增加到五份，而如果新加的这两份和已有的不完全一致，你反而制造了新的矛盾。

第二种是写得更绝对。把相对路径改成绝对路径，把参数全带上，把大小写统一。这些动作本身没错，但它们解决的是格式问题，而你面对的是真分歧。

第三种是反复提交重新抓取。这个动作除了重置评估周期之外，没有别的作用。

旧内容怎么改才有效，把旧版更新为AI搜索可信来源给了12步。

为什么这三种反应这么本能？因为在日常生活里它们通常有效。别人没听清，你就再说一遍、说大声一点、说得更肯定，这套办法对人管用。对一个从多份证据里做加权判断的系统，它一点都不管用，因为问题从来不是音量。

这也是我把这三种病分开讲的原因。缺失型和送达型都可以靠“做得更多”来解决——多补一处内容、多开一个白名单。只有采信型不行，它要的是做减法。在一个习惯了加法的行业里，减法是最反直觉的那个动作。

正确的动作只有一个：去找那份竞争性证据，然后消除它。不是加强你的声明，是让对方看不到别的选项。

怎么找出那份竞争性证据

按这个顺序找，命中率最高。

先看同一个页面上的其他声明来源。把本文列的那五处逐个抠出来放在一起比，这是最容易命中的一步，本文数据里23%的页面在这里就能找到问题。

再看这个内容有几个可达地址。带参数的、带追踪码的、大小写不同的、带与不带末尾斜杠的、分页形式的，逐个试一遍能不能打开。能打开的每一个，都是一份竞争性证据。

然后看内部链接。你自己的导航、页脚、面包屑、站点地图里，指向这个页面用的是哪个形式的地址。如果站内用的是A形式而标签写的是B形式，那是一份很重的反向证据。

站内搜索页就是典型的一批，站内搜索URL该Disallow吗对比了4种方案。

页脚这块地怎么用，独立站页脚不是杂物抽屉讲了它的收口作用。

最后才看外部因素：别人链接你时用的地址、有没有域名共用历史、有没有做过站点迁移。

消除的手段有三种

找到之后，处置手段按力度从轻到重是三种：改成一致、跳转过去、彻底不可达。

改成一致最轻，适合那些本来就该一致的字段，比如同一页上的几处地址声明。跳转过去中等，适合那些有历史原因存在的替代地址，让它们都301到正版。彻底不可达最重，适合那些纯属意外产生的地址，比如测试环境泄漏出去的那一套。

三种手段的共同点是：它们都在减少选项，而不是在加强主张。这是采信型问题的通用解法，也是它跟另外两种病最根本的区别。

测试环境泄漏怎么清，Staging站被索引后的8步清除给了四层防御。

一个真实的处置顺序

保哥去年处理过一个户外用品客户的类似情况，过程可以直接照搬，就不展开细节了，只讲顺序。

症状是某个分类页在搜索结果里始终显示成另一个带筛选参数的地址，标题和描述都是那个筛选版本的，看起来很像被降级了。

第一步不是改标签，是列可达地址。列完发现同一份内容有五个形式能打开：干净地址、带排序参数的、带每页数量参数的、带一个历史遗留的活动参数的、以及一个大小写不同的。

筛选和搜索结果页的落地问题，40个电商站的站内搜索页实测是同一类。

第二步查内部链接。结果很打脸：站内导航里那个入口用的就是带排序参数的地址，因为设计上希望用户进来默认按销量排。整站所有指向这一页的链接，用的都是那个参数版本。

第三步才明白发生了什么。规范网址标签写的是干净地址没错，但站内几百条内部链接都在投票给参数版本，而内部链接的证据强度比标签只低一档。两边打架，对方选了票多的那个。

第四步的处置是改内部链接，不是改标签。把导航入口改成干净地址，默认排序改成在服务端处理而不体现在地址上。改完之后大约三周，显示的地址换了回来。

这个案例里有两条经验值得记：一是错的地方和症状出现的地方经常不是同一处；二是等待期真的有三周，中间那两周什么都没发生，很容易让人以为改错了而去乱动。

一份地址声明对齐清单，怎么跑？

最后落到可以照着做的步骤上。

等待期里怎么验证，提示词级前后测实验框架讲了怎么设计对照。

五步，一个页面十分钟

第一步，取事实。命令行发一次跟随跳转的请求，记下每一跳的状态码和最终地址。这是基准，别用你输入的那个地址。

第二步，取声明。把页面源码保存下来，抠出规范网址、og:url、hreflang的默认版本、结构化数据里的url这四处。注意要看原始源码，不是浏览器渲染之后的，因为有些框架会在运行时改写它们。

第三步，做分层比对。先严格比，不一致的再忽略末尾斜杠比一次，还不一致的再忽略www比一次。记下它在哪一层变成一致，那一层就是问题的性质。

第四步，列可达地址。把这个页面所有能打开的地址形式列出来，逐个确认它们是不是都指回了同一个规范版本。

第五步，比对站点地图。确认站点地图里那一条和规范网址标签逐字符一致。

全站怎么抽样

一个页面十分钟，全站显然跑不完，所以抽样规则比跑得多更重要。

按模板抽，不要按流量抽。地址声明是模板层的东西，同一个模板生成的一万个页面，问题是完全一样的。所以先把站里的模板类型列出来——首页、分类页、商品页、内容页、专题页、搜索结果页，每类抽一个就够。

然后在每类里挑最复杂的那一个，不是最典型的那一个。带参数最多的、路径最深的、语言版本最多的那一个，最容易暴露拼接问题。典型页面往往是模板作者测试时用的那个，早就被检查过了。

抽样审计的完整方法，AI时代技术SEO的五个新层次列了42步。

最后补两个特殊对象：一个是最近上线的新模板，一个是从别处迁移过来的老页面。这两类是问题最集中的地方。

加起来大概八到十个页面，一个下午能跑完，覆盖的是全站绝大多数的地址生成路径。比起跑一万个页面拿到一万条重复的结论，这个投入产出比高得多。

做成例行检查的两个触发点

全站每页都跑不现实，选触发式更划算。

第一个触发点是上线新模板或者新插件。地址声明基本都是模板层的东西，改模板最容易一次性改坏几十个页面的一致性。

第二个触发点是上多语言或者开新市场。本文的数据已经很清楚了，分歧率最高的四对全部跟多语言声明有关。开新市场之前先把地址生成逻辑统一到一处，比开完之后再来对齐便宜得多。

把三项检查合成一张表

这三篇讲的三件事，实操上可以合并成一次抓取、一张表。

抓取只做一次：对目标页面发一次跟随跳转的请求，把每一跳和最终的HTML都留下来。这一份字节能同时喂给三项检查。

第一项是内容可读性：把标签剥干净，数一下剩多少可读字符。低于阈值就是空壳，这一项决定了后两项还有没有意义。

第二项是身份可达性：换两三个爬虫身份把同一个地址再要一次，比状态码和正文长度。有差异就是送达问题。

内容在哪一步丢的，搜索引擎抓取和渲染DOM分几步讲清楚了。

第三项就是本文这一项：把几处地址声明抠出来，跟最终地址做分层比对。

防护层怎么查，防火墙到底拦不拦得住AI爬虫拆过一遍。

三项跑完，一个页面十几分钟，输出是三行结论：它有没有内容、机器拿不拿得到、拿到之后认不认它说的身份。这三行合起来，基本覆盖了一个页面在机器那一侧可能出的所有基础问题。

交付的时候把三项并排放在一张表里，比分成三份报告有用得多——因为它们经常互相解释。一个页面同时在第一项和第三项上出问题，那多半是模板整个没做好，不是三个独立的疏忽。

这一项通常和抓取可达性放在同一张表里交付。原因是它们回答的是同一个问题的两个部分：机器能不能拿到你的页面，以及拿到之后认不认你说的那个身份。

用什么工具跑

不需要买东西，命令行加一个能解析HTML的脚本就够了，但有几个细节决定了结果准不准。

取源码要用跟随跳转的方式，并且记录整条链，别只要最后那一份。很多现成工具默认只给你最终内容，跳转链上的信息就丢了。

日志那一侧有现成工具，服务器日志分析工具教程讲了怎么读预算浪费。

解析要用真正的HTML解析器，不要用正则去抠标签。这批数据里有个站的规范网址标签中间插了一个额外属性，还有个站的标签闭合方式不一样，正则很容易漏掉或者抠错。

结构化数据要能处理嵌套。现在很多站用的是图结构，一个脚本块里放好几个实体，顶层的地址字段可能在第二层。只取第一个url字段是这类脚本最常见的错。

解析这件事有更稳的写法，5种PHP代码识别搜索引擎蜘蛛含反转换法。

嵌套结构怎么写才对，FAQPage结构化数据的8步实战有完整示例。

还有一条容易忽略：要看原始源码，不是浏览器渲染之后的。有些前端框架会在运行时改写头部标签，两者可能不一样，而搜索引擎和大多数抓取器读到的是前者。

报告怎么写才有人改

这类发现最容易被写成一堆没人看的技术细节，最后归档了事。有效的写法是三列。

单页应用的问题更集中，SPA站AI爬不到的真相对比了四种渲染模式。

第一列写事实：这一页的几处声明分别是什么，服务器实际服务的是什么，逐字符列出来，别做任何美化。

第二列写它落在哪一层：格式差异还是真分歧。这一列决定了优先级，也决定了归谁改。

第三列写具体动作：改哪个文件的哪一处，改成什么。不要写“建议统一地址声明”这种话，写“把主题模板里那一行改成调用规范地址函数”。

最后加一句预期时间：改完之后需要等两到三周才能看到变化，这段时间内不要反复调整。把这句写进报告，能省掉后面好几轮“怎么还没效果”的沟通。

交付物写成规范才不返工，内容简报怎么写才能一次到位是同一个思路。

交给别人做的时候，怎么验收

这类活儿经常外包给建站服务商或者代运营，验收的时候有几个问题值得直接问出口，因为它们不太好糊弄。

第一个问题：这个站的地址是在哪一处生成的？能指出具体是哪个文件、哪个函数的，说明确实动过手；答不上来或者说各个模块自己处理的，那就是本文说的那种状态。

第二个问题：末尾斜杠这件事是怎么定的？这个问题看着琐碎，但它是本文数据里最大的一块差异来源。一个连这个都没有明确约定的项目，其余的一致性多半是碰运气碰出来的。

第三个问题：多语言的兜底版本指向哪，为什么是它？答案里如果只有技术理由没有运营理由，说明这个值是插件默认给的，没人真的做过决定。

第四个问题：怎么验证改完之后生效了？期待的答案是一个可以复现的检查步骤，而不是一句我们会持续关注。能给出检查步骤，说明对方知道这件事需要等，也知道等完之后看什么。

四个问题不到十分钟，比看一份几十页的审计报告更能判断对方的水平。这不是刁难，是因为这几个问题的答案恰好覆盖了地址一致性的全部要害：在哪生成、格式怎么定、多版本怎么选、改完怎么验。

反过来，如果你就是被问的那一方，这四个问题也值得自己先答一遍。答不上来的那一个，通常就是你的站下一次出问题的地方。

什么时候该停手

最后说一个容易被忽略的判断：不是所有分歧都值得修。

有三种情况可以放着不管。第一种是那些语义上本来就允许不同的字段，比如多语言的兜底版本和页面身份，前面已经说过。第二种是末尾斜杠这类格式差异，记成技术债，等下次改模板时顺手带上。

第三种最需要判断力：当修复的成本明显超过风险的时候。比如一个多年不更新的历史专题页，它的几处声明对不上，但它既没有流量也没有商业价值，那就别动它，把时间花在商品页上。

反过来，有三种情况必须立刻修：首页、主要分类页、以及正在投放广告的落地页。这三类的共同点是它们既有流量又有多个可达形式，正是分歧最容易产生实际后果的地方。

老页面还有没有价值，主题权威做到位为什么还是不选你列了18大盲区。

还有一条判断线可以直接用：如果一处分歧会导致搜索结果里显示出一个你不希望别人看到的地址，那它就必须修，不管流量多少。地址是给人看的，一个带着测试参数或者促销活动名的地址出现在搜索结果里，损失的是信任，那笔账不好算但确实存在。

最后一个数字

再回到那张表：严格比29.4%，放宽到极限77.0%。中间那57个站被一个斜杠救回来，而剩下的23%，无论你怎么放宽规则都救不回来，因为它们说的确实不是同一件事。

信任是怎么攒起来的，出海独立站的社会证明体系讲了信任工程。

你的页面对自己是谁说了三遍以上，而每四页里就有将近一页，三遍说的不一样。在这种情况下，接收方选了一个你不喜欢的答案，其实一点都不奇怪——它只是从你给的几个答案里挑了一个。

三篇写到这里，那条链算是走完了：东西得先在字节里存在，然后得送到对方手上，最后它到了还得被采信。三段各有各的判据、各有各的投入曲线，也各有各的典型误判。同一句“没通过”，在这三段里分别意味着你还没做、你做了但它没到、它到了但不算数。

如果只带走一件事，那就带走这个提问顺序：先问这个信息除了眼睛还有谁能读到，再问换个身份要一次结果一不一样，最后问这个结论是我声明的还是它算出来的。三个问题，十分钟，能省掉几周朝错误方向使的劲。

常见问题解答

搜索平台里显示的规范网址和我写的不一样，是不是我写错了？

不一定。那两个字段是并列的，一个记录你声明的，一个记录系统选定的，它们本来就允许不同。规范网址标签在官方定义里是强信号不是指令，系统会把它和站点地图、内部链接指向、跳转终点、外部链接使用的地址、多语言声明、结构化数据一起当成证据来评估。所以先别改标签，先去找那份跟你的声明打架的证据。本文实测的132个首页里，有23%在页面内部就存在无法用格式差异解释的真分歧。

三个问题各自的验证方法，AI爬虫到底有没有抓你的站讲了日志那一条。

末尾那个斜杠到底要不要紧？

对收录来说通常不要紧，主流搜索引擎会把根域名带不带末尾斜杠当成同一个地址。但它在本文的数据里贡献了最大一块差异：严格按字符串比只有29.4%的页面所有声明一致，只忽略末尾斜杠就跳到74.6%，一条规则救回57个站。它真正的意义是一个信号——同一个页面上的两个模块连这种事都没对齐，说明它们之间没有共享的地址生成逻辑，今天差一个斜杠，明天上多语言就会差一个语言前缀。

为什么hreflang的默认版本和其他声明最容易打架？

因为它回答的是另一个问题。规范网址回答的是这一页的正式地址是哪个，而hreflang的默认版本回答的是语言都匹配不上时把用户送到哪一版，前者是身份，后者是兜底策略，本来就不必相同。问题在于多语言模块通常由另一套插件或者另一个团队负责，它按自己的逻辑挑兜底版本，完全不知道页面上还有别的地方在声明身份。本文数据里，它跟结构化数据的分歧率是31.7%，跟规范网址是28.1%，都是全表最高的几项。

首页没有规范网址标签会出什么问题？

大多数时候不会出问题，系统会自己选一个规范版本，结构简单的站选对的概率不低。风险集中在两种情况：一是同一份内容有多个可达地址，带参数的、带追踪码的、带地区前缀的都能打开，这时候它可能选中你不想要的那一个；二是这个域名过去和别的域名共用过停放页或者过渡页，那段时间内容逐字节相同，系统会把它们归成一组并挑一个代表，而这个归并关系在你上线新内容之后不会立刻解除。

发现选定的规范网址指向一个陌生域名，我该做什么？

按顺序做三件事。先确认自己的页面有自指的规范网址标签，并且站点地图里的地址与标签逐字符一致，包括末尾斜杠。再尽快让内容与那个共用过的停放页产生足够大的差异，差异越大归并关系解除得越快。最后是等，官方给的建议是几周之后再看。切忌在等待期里反复改动或者反复提交重新抓取，每改一次都等于把评估周期重置一次，反而更慢。

多写几个地方声明同一个地址，是不是更保险？

正好相反。这是采信型问题里最典型的错误动作。多加两处声明，如果它们和已有的三处不完全一致，你就把矛盾从三份证据扩大到了五份。本文数据里，规范网址与og:url的分歧率只有2.2%，因为它们通常是同一段代码生成的；而涉及多语言声明的几对分歧率都在20%以上，正是因为它们出自不同的模块。正确的做法是减少选项，不是加强主张。

地址里那个443端口是怎么来的？

是站点自己写死在跳转响应里的。本文数据里有两个站的最终地址带着443端口，我特意把它们的跳转链原样打出来核对过：一个站的301响应头里目标地址原文就带着端口，另一个先308跳到裸域名再301到带端口的地址，都不是抓取工具加的。443是加密连接的默认端口，写不写在语义上没区别，但作为字符串就是两个不同的值，而地址处理有很多环节是按字符串来的。

这套对齐检查要不要全站都跑？

不用，选触发式更划算。两个触发点最值得盯：上线新模板或新插件的时候，因为地址声明基本都是模板层的东西，改一次能同时改坏几十个页面；以及上多语言或开新市场的时候，本文数据里分歧率最高的四对全部与多语言声明有关。日常抽查的话，首页、一个分类页、一个商品页各跑一次就够，一个页面十分钟。

规范网址和og:url不一致，严重吗？

严重。这一对在本文数据里的分歧率只有2.2%，是全表最低，因为它们在绝大多数系统里由同一段代码生成，或者一个直接引用另一个。它们不是达成了共识，是同一句话说了两遍。所以一旦你的站这两个字段对不上，说明连最容易一致的一对都出事了，几乎可以断定是两处分别硬编码的结果：有人在模板里手写了一个，又在插件设置里填了另一个。这类硬编码是所有地址不一致里最难发现的一种，因为它不遵循规律、只在某一页上错，逐页人工检查反而抓不到。

怎么判断一个问题属于采信型而不是另外两种？

看官方界面上有没有两个并列的字段，一个记录你说的，一个记录它选的。规范网址是最典型的一对，页面标题、描述摘要、商家名称展示形式也都属于这一类。凡是措辞里出现选定、检测到、系统判定这类词的字段，结论都是对方算出来的，你只能通过改变证据分布去影响它，不能直接指定。这跟缺失型（东西不在字节里）和送达型（东西在但那次请求没拿到）的处置方式完全不同，用错了不只是无效，还会更糟。

权威参考资料

摘要：同一批211个独立站首页，这次换了7种身份各要一次，只看谁拿得到、谁拿不到。132个站愿意对普通浏览器给出真页面，在这132个上，Googlebot拿到97.7%，GPTBot拿到90.9%，而什么身份都不报的那一次只拿到48.5%。更意外的是反向：robots.txt里明确点过GPTBot名字的13个站，13个全都把页面交了出来；真正在送达环节挡住AI爬虫的，恰恰是那些robots.txt里一个字都没提过它的站。文章还记了一个55字节的402付费墙和一个字节数为0的418。

上一篇文章的结尾留了个尾巴。当时抓211个独立站首页，最后只剩132个能拿来做内容分析，剩下那79个要么连不上、要么撞上人机验证、要么直接被403挡回来。我说那79个的去向是另一篇文章的题目。

这就是那一篇。

那一篇把132份首页的可读字符逐个数了一遍，132个独立站首页有28个是空壳，算是这次实验的上半场。

先把两篇的关系交代一下，免得混。上一篇问的是：抓回来的字节里到底有没有字。这一篇问的是更前面的一个问题：字节到底有没有到你手里。前者是内容问题，后者是通路问题，而通路出事的时候，内容写得再好也没有任何意义。

这两个问题的先后顺序不能颠倒。先确认拿得到，再讨论拿到的东西够不够好。顺序反了，你会在一个根本没送出去的页面上花几周时间调标题、补描述、加结构化数据，然后困惑于为什么一点变化都没有。

先讲一件2026年8月中旬在圈子里传得挺广的事，原始报道是Search Engine Roundtable关于误配置内容分发网络重创SEO的那篇。有位技术顾问接手了一个客户，客户的自然流量在两周里几乎归零。所有人第一反应都是算法更新，因为曲线掉得又快又干净，长得就像被核心更新削了一刀。查完之后真相是这样的：客户的IT外包商在内容分发网络的后台点开了一个爬虫控制开关，一键屏蔽所有机器人。

同样的顺序问题在流量诊断里也成立，收录、排名、流量是三件事讲的就是别把三层混在一起查。

这类后台的选项密度确实高，独立站的缓存与回源率优化决策树能帮你分清哪些开关碰得、哪些碰不得。

这一下同时打穿了三条业务线。搜索引擎抓不到，页面陆续掉出索引；购物广告的商品列表全部消失；而广告账户那边毫无察觉，钱照扣，一天没落下。整整两周，客户的网站内容一个字都没改过。

我把这件事记下来，不是因为它离奇，而是因为它太不离奇了。这一类故障有一个共同的形状：东西明明还在，只是那一次请求没拿到。它和“东西根本不存在”是两种病，药方还互为毒药——上一篇讲的是前者，这一篇讲的是后者。

掉出去之后怎么捞回来，页面不被Google收录的急救手册按症状分诊列了完整流程。

更麻烦的是它的隐蔽性。缺失型故障你自己能查出来，抓一次页面剥掉标签数一数就完了。送达型不行，因为拦截发生在边缘，请求根本没到你的服务器。你的访问日志里干干净净，一条记录都没有，唯一记着这件事的是对方。

所以这篇文章不打算讲配置怎么点。配置面板一年改三次版，写下来第二个月就过期。它要解决的是更前面那个问题：一个页面拿不到，你怎么在十分钟之内判断它属于哪一种病。判据只有一条，后面会用211个站的实测数据把它撑起来——同一个地址，换一个身份再要一次，两次结果不一样，那就是送达型。

日志能回答什么、不能回答什么，AI爬虫到底有没有抓你的站那篇分得很细。

把这类判据成体系地排一遍，AI时代技术SEO的五个新层次是本站的审计总纲。

一次开关被点开，为什么你的后台什么都看不到？

先把这类事故的形状讲清楚，不然后面的数据你会不知道该往哪儿放。

三条业务线是被同一个动作打穿的

前面那个案例里最值得咂摸的细节，不是流量掉了多少，是三件事同时发生却互不通气。自然搜索的排名开始滑坡，购物广告的商品列表消失，付费广告继续正常投放并且正常扣费。

这三件事共用同一个前提：机器要能读到你的落地页。搜索引擎读不到就不给排名，购物平台读不到就下架商品，而广告投放系统的账单逻辑跟落地页能不能被读到没有强绑定，于是它就成了三条线里唯一没报警的那条。

商品列表这条线还有自己的资质门槛，跨境电商GTIN怎么申请讲的是它另一头的合规要求。

这就是送达型故障最恶心的地方。它不会给你一个统一的报警，它会给你三个互相矛盾的信号。一条线沉默，一条线报警，还有一条线在正常收钱。你坐在中间，很难第一时间想到这三件事其实是一件事。

另一位顾问在同一周晒出了另一个案例。一家在线市场类网站被爬虫压得服务器扛不住，团队只好在防火墙层加了一层机器人访问限制，纯粹是为了让站活着。结果曲线掉得跟被算法更新处理过一模一样。他的原话是：这看着像核心更新甚至像垃圾内容更新，但它不是。

多个信号打架的时候需要一条共同的时间轴，SEO变更日志的企业站治理给的就是这套记法。

被抓到扛不住是真实存在的，网站被恶意流量打崩时的识别与应急拦截讲的是另一头的压力。

为什么它长得像算法更新

两者的曲线确实很像，因为掉的都是“被收录页面能带来的流量”这一层。但形状上有几处能分开。

算法更新的下滑通常有结构：某一类页面掉得多，另一类掉得少，长尾和头部的比例会变，不同国家的市场往往不同步。防火墙误伤的下滑没有这种结构，它是整片的，所有类型的页面按同一个节奏往下走，因为拦的是请求，不看你是什么页面。

时间点也不一样。算法更新有一个业内共同的时间戳，你在几个行业媒体上都能查到同一天。配置误伤的时间戳只在你自己的变更记录里，而绝大多数团队根本没有变更记录这个东西。

还有一个更简单的分法：算法更新不会让你的购物广告商品列表消失。一旦出现“自然流量和商品列表同时消失，但广告费照常扣”这种组合，八成不是算法的事。

到底是谷歌动了还是你自己动了，排名突然抖一下的分层归因有一套现成判据。

抓取报告里那几类问题地址各占多少，Google抓取报告怎么读给了排查顺序。

日志里为什么找不到证据

很多人的第一反应是去翻服务器日志，看看搜索引擎爬虫是不是不来了。这个动作方向没错，但会得到一个误导性的结论。

拦截发生在边缘节点，也就是内容分发网络那一层。请求在那里就被判了，返回一个403或者一个人机验证页，然后结束。这一整趟往返，你的源站从头到尾都不知道发生过。所以你打开访问日志，看到的不是“爬虫来了被拒绝”，而是“爬虫没来”。

这两句话在日志里长得一模一样，含义差着十万八千里。前者是送达问题，后者是抓取需求问题，处置方式完全相反。分开它们的唯一办法，是去边缘那一层的日志里看，或者更直接——自己扮成那个身份去要一次。

边缘那一层能做的事比多数人以为的多，边缘SEO是什么讲了它的原理与落地形态。

日志里要看得出真实来源IP，得先把格式配对，访问日志怎么配才查得清问题有现成模板。

三条业务线，三套互不相通的告警

再往深一层看，这类事故之所以能拖两周，跟工具本身的设计也有关系。

搜索端的报告有延迟。抓取异常的数据从发生到出现在报表里，通常要隔一到三天，而且它默认按周汇总，一条曲线要跌得足够深才会引起注意。等你看见它，事情已经发生一阵子了。

购物端的反馈快一些，商品被拒会有邮件通知。但那封邮件的措辞通常是商品层面的，比如某个商品的落地页无法访问，看着像是单个商品的问题。收件人多半是运营，运营的第一反应是重新提交，而不是怀疑整个站的机器人策略。

这份报表的口径坑不少，GSC的数字为什么人人都读错逐项拆过一遍。

重新提交之后多久能回来，网站收录速度实操指南用三个平台的数据给了参考区间。

广告端根本不参与。投放系统关心的是出价、预算、素材和落地页能不能打开——注意，是能不能被真人打开。真人打得开，钱就照花。于是三条线里唯一实时的信号，恰好是唯一不报警的那一条。

这也解释了为什么这类故障的发现往往靠一个巧合：某个人手痒去查了一下收录，或者某个客户问了一句为什么搜不到你们了。它不是被监控发现的，是被人撞见的。

变更记录这件小事，值多少钱

开头案例里有一个容易被忽略的细节：动手的是客户的IT外包商，而发现问题的是SEO顾问。这两个角色之间通常没有共享的变更记录。

我见过太多这样的结构了。网站的域名解析在一个人手里，内容分发网络在另一个人手里，服务器在第三个人手里，而对流量负责的那个人，往往三个后台都没有账号。出了事，第一小时全花在找谁动过手上。

解法不复杂，就是一份共享的变更记录，谁在哪个后台改了什么，一行字。它的价值不在于防止犯错，而在于把排查时间从两周压缩到两小时。

把这些分散的动作收进定时任务，独立站服务器怎么用cron把运维自动化是最省心的做法。

做外贸独立站的团队还有一个额外的复杂度：链路上的角色更多。域名可能在境外注册商，加速可能用了境外的内容分发网络，源站可能在境内，中间还可能夹着一层做国内访问优化的节点。每多一层，就多一个能悄悄拦人的地方。

这条链路上最常见的意外，是那些为国内访问做的优化配置。有些高防和加速产品的默认规则对境外来源的请求更严，而搜索引擎爬虫的出口恰恰全在境外。你为了让国内用户打开得快一点，顺手把抓取你的那批机器归进了可疑名单。

判断方法还是那一条：换个身份要一次。如果境内出口的请求正常、境外出口的请求被挡，那问题就在这一层，跟你的内容毫无关系。

主机放境内还是境外本来就是取舍，外贸独立站用国内主机还是国外主机把备案、速度与合规摆在一起算过。

海外用户打不开的排障路径，从DNS、线路到CDN的网络层排障是同一套方法的另一面。

如果连这个都推不动，还有一个更低成本的替代品：把关键配置定期导出成文本存一份。内容分发网络的规则、robots.txt、跳转规则，每周一次，存进版本库。下次出事的时候，跑一次比对就知道动了什么。

这也是我决定跑这次实验的原因。与其猜，不如把211个站排成一排，用7种不同的身份各要一次，看看谁拿得到、谁拿不到。

跳转规则这一层最容易失控，.htaccess的六层综合治理给了可版本化的写法。

同一个首页，7种身份各要一次会发生什么？

方法先交代清楚，因为这篇所有的百分比都挂在这一段上。

7种身份是怎么选的

样本沿用上一篇那211个国际化独立站的域名，覆盖服饰、家居、消费电子、美妆、户外几个大类，都是有独立品牌、面向多国市场的品牌自营站。用同一批样本的好处是，两篇文章的结论可以直接互相印证。

身份一共7种，除了用户代理串不同，其余请求参数完全一致：都跟随跳转，都开压缩，都不执行脚本，超时都是同一个数，并发窗口也是同一个。

这批站几乎都做了多语言，国际化SEO和hreflang怎么做是理解它们结构的前提。

需要说清楚一件事：我报的这些名字全部是自称。用户代理串本来就是一行可以任意填写的文本，这一点MDN关于User-Agent请求头的说明里写得很清楚。请求是从一台普通的云服务器发出去的，IP地址跟这些爬虫官方公布的网段没有任何关系。也就是说，这台机器唯一做的事情，就是在请求头里写下一行字。

这个设定不是偷懒，它恰恰是实验的一部分。真爬虫的身份是可以被反查的：拿到IP之后做一次反向域名解析，再把解析出来的域名正向解析回去，看两次能不能对上。这套流程各大搜索引擎都公开写过。所以这次实验里，一个站放不放我进去，直接反映了它到底是按名字判断，还是按行为判断。

基线不能拍脑袋定，得从数据里长出来

211个域名里，普通Chrome请求真正拿到一个像样页面的只有132个。剩下79个的构成是：32个直接给了人机验证页，18个连不上或者连接被重置，12个返回4xx，还有十几个返回了正文极短的空响应。

各家爬虫的串长什么样、怎么验，爬虫识别与UA分类指南列得很全。

验证页背后那套机器人管理逻辑，防火墙到底拦不拦得住AI爬虫拆过一遍。

所以后面所有比例都算在这132个上。这么定的理由是：只有当一个地址已经证明了它愿意对普通请求给出真页面，你才有资格说另一个身份被“挡住”了。否则你只是在统计一堆本来就打不开的站。

这一步看着琐碎，其实是这类审计最容易出事的地方。上一篇栽过一次跟头：把一批HTML里几乎没有可读文本的空壳页混进结构审计的样本，某个结论虚高了6.4倍，另一个虚高了11倍。判据一个字都没写错，错在样本边界。

7种身份的成绩单

数字在传播中走样是通病，10条最佳实践清单里8条数字对不上是另一个例子。

先看前五行。搜索引擎爬虫和AI爬虫之间确实有差距，但没有传言里那么夸张——最高97.7%，最低90.9%，中间隔着不到7个百分点，换算成绝对数是9个站。

然后看最后一行。什么身份都不报的那一次请求，通过率直接砍掉一半还多。在这批站上，沉默比自称是AI爬虫的代价大得多。

抓取量的对比更悬殊，AI爬虫抓取量已超Googlebot 3.6倍给了量级。

什么算“拿到了页面”

这个判据得说清楚，因为它决定了上面每一个数字。

一次请求要算成功，得同时满足四个条件：状态码在200到299之间，最终正文超过1500字节，不是人机验证页，连接没有失败。任意一条不满足，都记成没拿到。

1500字节这条线是有来历的。这批数据里，正常首页的字节数中位数在3万以上，而所有验证页和错误页都在3000以下，中间有一段非常干净的空档。把线画在这个空档里，两边都不会误判。

字节这条线两头都要看，46个电商站的页面体积实测量的是上限那一头。

识别验证页的办法是看正文特征：这类页面通常带一段固定的提示文案和一个挑战脚本，长度集中在2000到6000字节之间，标题字段往往是“请稍候”或者“正在验证”这一类。逐个人工核对过一批之后，我把特征固化成了几条字符串匹配。

这里有一类特别容易漏的情况：状态码200、正文只有几百字节的“薄响应”。全部211个域名里，普通Chrome拿到这种薄响应的有10个。它们不是拒绝，也不是验证，就是一个空壳——服务端返回了一个骨架，内容等着客户端去请求。

薄响应在监控里是最隐蔽的一种，因为它状态码正常、响应时间正常、甚至还有HTML结构。要发现它，只能加一条正文长度的检查。这也是上一篇文章的主题。

薄响应多半是渲染模式造成的，AI爬虫抓不到JS渲染的引用率实测做过对比。

可提取性有更系统的量法，语义化HTML到底影响AI抓取吗拿样本页跑过。

为什么只测7种，不测更多

能测的爬虫身份远不止7种，光是叫得出名字的AI相关抓取程序就有二三十个。选这7个是有取舍的。

桌面Chrome和空用户代理是两个必需的极端，一个代表“最受欢迎的身份”，一个代表“没有身份”。中间五个覆盖了三类利益关系：会还流量的搜索引擎、只取不还的训练抓取、以及介于两者之间的AI搜索抓取。

这些串在日志里长什么样，AI Agent抓取日志的8类UA实测做过完整账本。

再加身份的边际收益很低。同一家公司的多个抓取程序，在防护规则里通常被归进同一个分类，测三个和测一个的结果高度重合。而每多一个身份，就要多跑211次请求，对被测站是实实在在的负担。

时间窗也是个变量。全部1477次请求在同一个时间窗内跑完，避免出现“这个站是白天抓的、那个是深夜抓的”这种偏差。做送达型测试，时间必须被控制住，因为限流规则本身就是时间的函数。

这次实验的边界在哪里

把局限性摆在前面说，后面的数字才好用。这份数据有四个地方是不能超出去解读的。

时间维度还有另一层，304状态码能省抓取预算量的是同一批站的条件请求能力。

第一，只测了首页。首页往往是全站防护配置最松的一页，因为它承担品牌展示的职责，谁都不希望它出问题。商品页、搜索结果页、筛选页的待遇通常更严。所以这批通过率应该被理解成上限，不是平均值。

第二，只采了一次。送达型故障有很强的时间性，限流是按窗口算的，某个站在某一分钟拒绝你，下一分钟可能就放行。单次采样能看出结构性的差异，看不出偶发的抖动。

搜索结果页本身也有问题，40个电商站的站内搜索页实测发现查无结果和查得到长得一样。

响应时间和抓取预算是联动的，TTFB怎么优化才不白费把两头串在了一起。

第三，只有一个出口。所有请求从同一台机器发出，IP在中国。这个条件对做了地理分流的站影响很大，后面有一整节在讲它。换个出口重跑，部分结论会变。

第四，身份是自称的。这既是实验设计的一部分，也是一个边界——它测的是“按名字放行”这套逻辑，测不出那些真的做了验证的站会怎么对待真爬虫。不过从结果看，做验证的站少到可以忽略。

跨语言的实体对不上是另一类顽疾，国际化SEO最难的不是hreflang列了五大根因。

把这四条摆清楚之后，这份数据能支撑的结论其实只有一句话：在同一个时刻、同一个出口、只看首页的条件下，身份这一个变量能造成多大的差别。而答案是：能造成从48.5%到97.7%的差别。这已经足够说明问题了。

这个结果第一眼是反直觉的。按常理，你不说自己是谁，系统应该没有理由针对你。实际情况正好相反，而原因在下一节。

空用户代理的通过率只有一半，被挡的63次里有59次撞上验证页

这一节讲那个对照组，因为它是整份数据里信息密度最高的一行。

被挡的不是拒绝，是验证

空用户代理的63次失败里，59次拿到的是人机验证页，只有4次是干脆的403。这个比例几乎是压倒性的，说明拦它的不是一条黑名单规则，而是那套“我不认识你，先证明你是人”的默认逻辑。

验证页和拒绝页是两种东西。拒绝页的意思是“我知道你是谁，我不给”，验证页的意思是“我不知道你是谁，你先过一关”。前者针对身份，后者针对未知。

三层拦法各有代价，拦AI爬虫该不该给了robots、UA与WAF的选型框架。

而机器过不了那一关。它不执行脚本，不算工作量证明，不点复选框。所以对一个不执行脚本的请求方来说，验证页在效果上等价于永久拒绝，只是它长得更客气一点，还回一个看起来正常的HTTP状态。

这里有个细节值得记一笔：这59个验证页里，很多返回的状态码不是403而是200，正文两千来字节。如果你的监控只看状态码，它们会被记成“正常”。一个返回200的验证页，在你的可用性看板上是绿的，在爬虫眼里是一堵墙。

36个站的robots.txt字节数几乎一样

整理这批数据的时候，我顺手把每个站的robots.txt也抓了下来，本来只想统计规则。结果排序的时候看到一件怪事：132个站里有36个的robots.txt大小挤在3560到3720字节这个极窄的区间里。

状态码的语义值得复习，HTTP状态码怎么影响SEO把301、302、404和410的选择讲透了。

自己写这份文件时有虚拟与物理的优先级问题，robots.txt该怎么写才不冲突说明了顺序。

一百多个互不相干的品牌，文件大小差不到5%，这不可能是巧合。翻开内容一看，规则结构确实高度一致，屏蔽的都是购物车、结账、订单、后台那几类路径，只有域名和站点地图那几行不一样。这是同一个建站平台自动生成的模板。

真正有意思的是下一步：这36个站里，有34个的空用户代理请求撞上了人机验证页。比例是94.4%，远高于全样本的47.7%。

哪些页面类型值得屏蔽，电商robots.txt该屏蔽的7类页面给了清单。

同一批站的另一处平台默认值，53个支付页的CSP实测也是配了等于没配。

把这两件事合起来看，结论就出来了：这批站的声明层是平台给的，送达层也是平台给的，店主两边都没有动过手。他打开后台，看到一份写得挺规整的robots.txt，很容易以为那就是自己网站对机器的全部态度。其实那份文件只是平台的说明书，真正决定谁能进门的是另一套他没打开过的开关。

顺带一提，做完归一化去掉域名之后，这36份文件里只有2份是完全一致的。模板是同一个，但每个站都被注入了那么一点点属于自己的东西——就像同一款毛坯房，交房时每家的电表编号都不一样。

37个站还在配一个搜索引擎早就不读的指令

既然robots.txt都抓下来了，就顺手多量了几项。123份能正常解析的文件里，112份声明了至少一个站点地图，总共550行，平均每个站快5行。这个数字挺健康。

另一项就没那么健康了：37个站还在用Crawl-delay这条指令，占比30%。这条指令主流搜索引擎早就明确说过不支持，抓取节奏由它自己的算法决定。

站点地图写错的方式比想象中多，Sitemap到底怎么写才不出错收了2400个站踩过的坑。

两种robots指令的分工经常被搞反，robots.txt和meta robots什么时候用哪个讲了边界。

这37个站不是写错了语法，是在对着一个没人听的收音机认真调频。它不会造成伤害，但它是一个信号：这份文件多半是很多年前配好之后就再没人碰过。一个多年没人碰过的robots.txt，和一套去年才上线的机器人防护策略，凑在同一个域名上，两边说的话对不上是迟早的事。

文件大小的分布也很有意思。最小的一份只有39字节，第二小的62字节，最大的一份57578字节，中间差着1476倍。57578字节是个什么概念？它比这批站里三分之一的首页HTML还大。

一份39字节的robots.txt和一份57578字节的robots.txt

这两个极端值得各说几句，因为它们代表了两种完全不同的治理思路。

39字节那一份，内容只够写一行用户代理加一行允许。它传达的信息是：我们知道这个文件应该存在，所以放了一个，但我们没有任何要限制的东西。对一个内容不多、结构简单的品牌站来说，这个选择其实相当合理。

57578字节那一份是另一个极端。这么大的文件里塞的通常是成百上千条筛选参数的屏蔽规则，一条一条列出来。它反映的是一个站的URL空间已经膨胀到必须靠黑名单去管的地步。

这两种做法没有绝对的高下，但有一条经验是通用的：robots.txt的长度和站点的URL治理质量，往往成反比。规则越长，说明能被生成出来的无效地址越多。真正干净的架构不需要那么多条禁令。

筛选器地址爆炸有系统解法，电商筛选器URL不爆炸的方案是一套8步流程。

无效地址进了索引就是另一笔账，索引膨胀的诊断与处置给了决策矩阵。

还有一个观察角度是站点地图声明。112个站在robots.txt里声明了站点地图，总共550行，平均每站4.5行。声明多行的通常是做了分卷的大站，这是好习惯。而那11个一行都没声明的站，等于把发现新页面这件事完全交给了链接爬行。

平台默认值正在替大多数人做决定

把这一节的几个发现串起来，会得到一个比单条数据更重要的判断。

靠链接爬行就得看架构深浅，独立站网站架构怎么搭讲的正是抓取深度。

36个站用同一份模板生成robots.txt，其中34个的空用户代理请求被同一套逻辑拦下。这不是36个独立的决策，这是一个决策被复制了36次。

这件事本身不坏，平台默认值通常是行业里比较稳妥的选择，能挡掉大量低质量抓取。问题在于所有权的错觉：店主以为那是他的配置，其实那是平台的配置，而平台会改。

平台改默认值的时候，通常会发一封邮件或者写一篇更新日志，很少有人读。等到下一次分类逻辑调整，你的站的行为会跟着变，而你的文档里什么都没变。

所以对用建站平台的独立站来说，有一个动作特别值得做：把平台生成的robots.txt完整存一份到本地，注明日期。每季度取一次，做一遍比对。变了不一定是坏事，但不知道它变了，一定是坏事。

报一个名字就能进，129个站没有一个反查过我的IP？

现在回到那个最锋利的问题上。

托管平台悄悄改规则的事发生过，托管主机可能正悄悄拦AI爬虫是一个真实案例。

这台机器什么都没做，只是写了一行字

再强调一次实验的设定：发请求的是一台普通云服务器，IP在中国，跟任何一家搜索引擎或AI公司的官方网段都没有关系。它做的唯一一件事，是在请求头里写下Googlebot这个词。

结果是129个站把首页交了出来。

用代码识别蜘蛛有几种写法，5种PHP代码识别搜索引擎蜘蛛含反向验证的做法。

没有一个站对我做过反向解析验证。这件事在数据里是可以证明的：如果有站做了验证，我这个身份必然通不过，因为我的IP反查出来是一家云厂商，怎么都不会变成googlebot.com。而129这个数字，跟真Googlebot能拿到的上限已经贴得很近了。

反向解析验证这套流程一点都不神秘，各大搜索引擎的官方文档里都写着，很多服务器软件也内置了。它的原理是拿到访问者IP，先反查域名，再把域名正查回IP，两次对得上才认。整个过程一次请求，几毫秒。

没人做的原因也不神秘：默认配置里它是关的，打开它需要一点点运维知识和一点点性能预算，而不打开它在绝大多数日子里不会出任何问题。

反查验证在Nginx上怎么配，Nginx拦AI爬虫与限速怎么不误伤Googlebot有完整配置。

按名字放行，就等于把门锁交给了报名字的人

把这条结论和上一节的空用户代理放在一起，整套逻辑就完整了。

这些防护系统的判据是名字，不是行为。你说你是Googlebot，它就当你是Googlebot；你什么都不说，它就把你当可疑对象拦下来验证。于是在这套规则里，愿意报名字的都进去了，什么都不说的反而被挡在外面。

这个机制有一个直接的商业后果，值得每一个正在纠结“要不要拦AI爬虫”的站长想清楚：你在后台勾掉的那些复选框，只对那些老老实实报名字的爬虫有效。真想拿你数据又不在乎规矩的那一类，改一行用户代理串就绕过去了，成本是零。

换句话说，这类拦截的实际效果是筛掉守规矩的，留下不守规矩的。你想拦的没拦住，不想拦的拦了一堆。

想知道它们到底抓什么，AI爬虫到底抓你什么是从代码逆向出来的。

那三个连Googlebot都没进去的站

129之外还剩3个。Googlebot在这3个站上也没拿到页面，其中2个撞了验证页，1个连接直接失败。

撞验证页的那两个里有一个是运动品牌的主站。它的表现相当极端：普通Chrome拿到200，17万字节的完整首页；空用户代理也拿到200，同样17万字节；而Googlebot、Bingbot、GPTBot、ClaudeBot、PerplexityBot这五个身份，全部拿到366字节左右的403。

五个身份，五张几乎一样大的拒绝页，而那两个不报名字的请求畅通无阻。这个站的规则写得清清楚楚：只要你自称是爬虫，不管你是哪家的，一律不给。

17万字节还不算大，Googlebot抓取的2MB限制才是那条硬线。

另一个站更彻底。普通Chrome和空用户代理都能正常拿到3万多字节的页面，五个爬虫身份全部是连接失败，状态码0，一个字节都没有，连robots.txt都取不到。这不是拒绝，是根本不建立连接。

反向解析验证怎么开，为什么很少有人开

既然按名字放行有这么大的窟窿，那把验证打开不就完了？确实是这样，但阻力比想象中大。

这份文件取不到的后果很重，网站突然从谷歌消失多半是robots.txt写废了讲了机制。

技术上，这个功能在主流的Web服务器和防护产品里都有现成的开关。原理前面说过：拿到访问者IP，先做反向域名解析，再把解析出来的域名正向解析回IP，两次对得上才认这个身份。搜索引擎官方也公布了可供比对的IP段清单，直接按段匹配更快。

阻力主要有三个。第一是性能，反向解析要走DNS查询，虽然可以缓存，但在流量高峰期加一层外部依赖，运维不愿意。第二是维护，AI爬虫的官方IP段列表更新频繁，而且不是每一家都公布，公布了的格式也各不相同。

按IP段核验伪造爬虫的做法，后台日志里的爬虫伪造识别有5000个站的实战数据。

新出现的代理型爬虫怎么认，Google-Agent是什么单独讲过一个。

第三个阻力最实在：不打开它，99%的日子里什么都不会发生。伪装爬虫身份来抓数据的行为，对绝大多数独立站来说不构成可感知的成本，那就没人有动力去开这个开关。

我的建议是分层处理。对搜索引擎爬虫做严格验证，因为误伤代价太高，值得那点性能开销；对AI爬虫按名字放行或者拒绝就够了，反正真想绕的也绕得过去。把验证的力气花在你最不能失去的那个身份上。

按行为判断长什么样

名字之外还有另一条路，就是看行为。这条路更贵，但更结实。

行为特征包括请求节奏、路径分布、是否读取样式和脚本资源、是否遵守robots.txt里的禁令、有没有携带合理的接受头。真爬虫和伪装者在这些维度上的差别，比用户代理串那一行字大得多。

举个具体的：真正的搜索引擎爬虫会去读robots.txt，而且会在抓取之前读。一个从来不取robots.txt、上来就直奔商品列表的请求方，不管它自称是谁，都值得怀疑。

抓取和渲染分几步，搜索引擎抓取和渲染DOM分几步决定了哪些资源会被取。

再举一个：真爬虫的请求间隔通常是分散的，会跟着服务器响应时间自动调节；脚本化的抓取往往节奏固定得像节拍器。把访问日志按秒聚合画一条曲线，规律得过分的那一条，多半不是它自称的那个。

这些判断在中大型站上有成熟的产品可以买，小站自己做性价比不高。但知道这套逻辑存在是有用的，至少你在选防护产品的时候，可以问一句：你们是按名字判还是按行为判。

现成工具能省很多事，服务器日志分析工具教程讲了怎么读出预算浪费。

132个站里有77个至少挡了一个身份

把整张矩阵摊开数一遍，结果比单看某一行更有冲击力。

132个证明了自己愿意给普通请求真页面的站里，7种身份全部拿到页面的只有55个。剩下77个站，至少有一个身份在门外。占比58.3%。

这77个的构成很不均衡。绝大多数只挡了空用户代理那一个身份，属于默认防护带来的副作用，站主大概率不知道。真正对多个爬虫身份区别对待的，是十几个。

同一批站的另一项体检，211个站有152个拿不出图标用的是同一个样本池。

把这77个按“挡了几个身份”分一下：挡1个的最多，挡2到3个的少数，挡5个以上的只有个位数——但这几个站恰好都是知名品牌，防护配置明显是专门做过的。

这个分布本身说明了一件事：大多数的拦截不是决策，是默认值。真正做过决策的站，你从矩阵上一眼就能认出来，因为它们的模式是干净的、有规律的，而不是零星地缺一格。

顺带纠正一个常见的误解。行业里聊起爬虫拦截，语气通常是“大家都在拦AI”。这批数据不支持这个说法。真正针对AI爬虫做过区别对待的站是个位数，绝大多数站的AI爬虫通过率跟搜索引擎爬虫只差几个百分点。拦AI这件事在讨论区里的热度，远高于它在配置文件里的热度。

把这类矩阵纳入固定动作，企业网站SEO审计框架给了完整检查表。

robots.txt写着允许，为什么GPTBot还是有10个站进不去？

这一节是全篇的骨架，讲的是同一个网站的两层配置怎么互相不认识。

声明层和送达层是两套独立的系统

先把概念摆清楚。robots.txt是声明层，它写的是“我希望你抓什么”，本质上是一份君子协定，靠对方自觉遵守。防火墙、机器人管理、边缘规则是送达层，它决定“你这次请求到底拿不拿得到字节”，是物理层面的强制。

协定这个词是有出处的，机器人排除协议一直到2022年才正式成为标准文档，也就是RFC 9309定义的机器人排除协议，在那之前它当了将近三十年的行业惯例。而送达层那些工具，大部分是最近五到八年才普及的。

误以为它有强制力就会写出错误规则，robots.txt能禁止UTM追踪参数吗是个典型误区。

抓取、索引、排名这条链的基本盘，搜索引擎到底怎么工作讲得最清楚。

两层的年龄差、归属团队差、更新节奏差，凑在一起就是本节数据的来源。

写规则的和配防护的，通常不是同一批人

这个组织问题比技术问题更难解，但它才是错配的真正源头。

robots.txt归谁管？多数公司里归做SEO的那个人或者那个外包团队，因为它是SEO工具箱里的东西。改它不需要权限，只要能改网站根目录的一个文本文件。

防护规则归谁管？归运维或者安全。他们的KPI是可用性和防攻击，不是收录量。在他们的世界里，多拦一个来源是安全的，少拦一个是有风险的。所以每一次拿不准的时候，默认动作都是往紧了配。

不同页面类型的规则要分开配，各类页面的meta robots和canonical配置按5类页面拆过。

跨部门讲清楚价值有方法，老板听不懂SEO错其实在我们给了一套讲法。

这两拨人开会的频率，通常是一年一次，还是在出事之后。他们之间也没有共享的语言：一个说的是抓取预算和收录率，另一个说的是每秒请求数和阻断率。

有一个成本很低的改善办法，是把“爬虫可达性”变成一个双方都认的指标。做法是把本文那个每天跑的脚本的输出，同时发给这两拨人。同一个数字，两个部门看，比开十次会管用。

抓取预算这个词要用对，Google抓取预算优化的12项实操说明了它的边界。

更进一步，可以在防护规则的变更流程里加一个必选项：任何涉及机器人分类的改动，上线前跑一次身份对照。这个动作三分钟，能挡掉本文开头那一整类事故。

两个方向的错配，各占一半

上线流程里还该加一道防护，Staging站被索引后的8步清除讲的是反方向的泄漏。

先看中间那一列。robots.txt明明写着允许，实际却没拿到页面，GPTBot有10个站，ClaudeBot有8个，Bingbot有4个，PerplexityBot有3个，连Googlebot都有1个。

这10个站的名单我逐个核过，涵盖家居、快时尚、手机配件、护肤、户外装备几个大类，没有明显的行业集中。它们的共同点只有一个：写规则的人和配防护的人不是同一批人。

再看最右边那一列，这个方向更值得玩味。robots.txt里明确写着禁止抓取根目录，服务器却照样把页面交了出来，Googlebot有15个站，ClaudeBot有14个，GPTBot和PerplexityBot各13个，Bingbot有12个。

同一批站的商家名称也体检过，112个独立站里17个在犯的双语重复是另一处细节。

这个方向严格来说不算故障，因为robots.txt本来就只约束自觉遵守它的一方，服务器没有义务照着它拦人。但它把那件事说透了：这两层根本不通气，谁也不知道谁写了什么。

为什么错配总是往一个方向偏

把两列放在一起看，能看出一个规律：越是新出现的爬虫身份，声明与送达不一致的概率越高。Googlebot只有1个站错配，GPTBot有10个，差了整整十倍。

站内搜索页该不该禁，站内搜索URL该Disallow吗对比了4种方案。

原因不难想。Googlebot出现了二十多年，几乎所有防护产品的默认白名单里都躺着它，误伤它的成本人尽皆知，出厂设置就已经替你避开了。GPTBot是2023年才出现的名字，它落在哪一档、被哪条规则匹配到，取决于每家产品各自的分类逻辑，而这套分类逻辑还在频繁调整。

这条规律有实用价值：做排查的时候，别从最老的那个身份查起，从最新的那个查起。老身份大概率被默认放行了，新身份才是错配的高发区。

这些产品各自的抓取策略并不相同，主流AI搜索工具实测对比做过10款横评。

那10个站分成三种形态

把robots.txt写允许却没送达的那批站逐个翻开，形态其实只有三种。

第一种是挑战型。服务端返回了人机验证页，状态码可能是403也可能是200。这类站的意思是“我不确定你是谁”，属于默认防护开得比较紧。这一类占了大头。

第二种是直拒型。干脆的403，正文很短，服务器字段指向某家边缘产品。这类是有人明确配过一条规则，只是配规则的人不知道robots.txt里写了允许。

第三种最容易被忽略：跳转丢失型。服务器返回301指向另一个地址，而那个地址对这个身份又是另一套待遇，跟着跳几次之后就断在半路。表面上没有任何拒绝动作，结果是一样的。

这三种的修法完全不同。挑战型要去调防护等级或者加白名单；直拒型要去找那条规则；跳转丢失型要去查跳转链本身。把它们混在一起当成同一个问题处理，是这类排查最常见的浪费。

跳转链本身也常出错，HTTPS 301跳转的双向实战有可直接抄的配置。

做一次两层对齐审计需要多久

这件事其实不难，难在没人把它当成一个固定动作。

做法是列一张两列的表。左边一列从robots.txt里抠出来：每个被点名的身份，允许还是禁止，禁止的是哪些路径。右边一列从实测里来：同一个身份实际拿到了什么。

然后只看不一致的行。左允许右没拿到，是误伤，优先级最高。左禁止右拿到了，是声明没有强制力，通常不用管，除非你本来指望它拦住什么。

一个中等规模的站，这张表连测带填半小时能做完。而它能回答一个几乎没人能立刻回答上来的问题：你的网站到底对哪些机器开着门。大多数团队对这个问题的答案，是基于三年前某一次配置的记忆。

有的爬虫根本不吃通配符，robots规则的星号对AdsBot无效就是一个例外。

保哥做技术审计的时候，这张表通常放在报告的第一页。原因很简单：它是整份报告里唯一一个客户看完会立刻打开后台去改的东西。

点名了GPTBot的那13个站，一个都没有真挡住它

接下来这组数据是这次实验最出乎我意料的一条，它把上一节的结论又推进了一层。

让报告推得动预算有套讲法，预算会上SEO总被砍怎么办用的是商业语言。

写过条款的，全部放行

123份能解析的robots.txt里，明确点过GPTBot名字的有13个站——不管是允许还是禁止，只要文件里出现过这个词就算。

这13个站里，GPTBot实际拿到页面的是13个。一个不落。

表态这件事有更可核查的写法，AI内容披露怎么写主张用不做什么的清单。

而剩下那110个从没提过GPTBot的站，GPTBot拿到页面的是99个，通过率90%。

三个AI爬虫身份，三条一模一样的结论：凡是在robots.txt里认真写过它的站，没有一个在送达层挡住它；真正挡住它的，全部来自那些robots.txt里一个字都没提过它的站。

这个反差说明了什么

第一层解释是最直白的：认真写过AI爬虫条款的团队，说明有人专门想过这件事。想过这件事的人，通常也会去检查防护规则有没有误伤，两层是同一批人配的，自然对得上。

第二层解释更有意思。没写过条款不代表没态度，恰恰相反，那110个站里挡住GPTBot的11个，多半是买了一套“一键拦AI爬虫”的服务，钱付了，开关开了，规则由服务商维护。他们的态度写在账单上，不写在robots.txt里。

这也就意味着，你去读一个站的robots.txt，读到的信息量比你以为的少得多。它只能告诉你这个站有没有人手写过规则，告诉不了你这个站到底放不放行。要知道后者，只有一个办法：真的去要一次。

凭感觉选策略容易翻车，GEO效果怎么验证建议给每条建议配一个对照组。

数据源打架时该信谁，收录数据到底信site命令还是GSC给了三源校准法。

顺手量到的AI爬虫条款分布

既然统计了，就把完整名单放出来。123个站的robots.txt里，各个AI相关爬虫被点名的次数是这样的：GPTBot 13次，PerplexityBot 12次，OAI-SearchBot 11次，ClaudeBot和ChatGPT-User各10次，Google-Extended 9次，Amazonbot 8次，CCBot 7次，anthropic-ai、Applebot-Extended、Bytespider各6次，Claude-Web和meta-externalagent各5次。

点名之后真写了禁止根目录的更少：Bytespider 3个站，CCBot和Amazonbot各2个，GPTBot、ClaudeBot、Google-Extended、Applebot-Extended、meta-externalagent各1个。

两组数字放一起，画面就清楚了：132个中大型独立站里，真正在robots.txt里明确禁止某个AI爬虫的，一只手数得过来。行业里关于“要不要拦AI”的讨论声量很大，但落到文件里的动作非常少。大多数站的做法是既不表态也不设防，把这件事整个交给平台默认值。

被点名最多的和被禁止最多的不是同一批

把点名次数和禁止次数放在一起排，会看到一个错位。

点名次数最高的是GPTBot，13次，但真写了禁止根目录的只有1个站。禁止次数最高的是Bytespider，6个站点名、3个站禁止，禁止率50%。CCBot和Amazonbot的禁止率也都在四分之一以上。

这个错位说的是两种不同的心态。写GPTBot的人多数在做一件“表明我知道这件事”的动作，具体规则往往是允许或者只禁几个目录。而写Bytespider的人通常是被抓怕了，那是一条带着情绪的规则。

顺便说一句，名单本身也在快速变化。这123份文件里出现的AI相关爬虫名字有二十来个，其中有几个是2024年之后才出现的，还有几个已经改过名。一份三年没更新的robots.txt，上面的AI爬虫名单大概率有一半已经失效。

国内那几家的抓取和带量情况，AI流量来源漏掉九成按日志逐条拆过。

按UA拦截的老代码尤其容易过期，WordPress拦截恶意User-Agent记了一次死亡迁移。

一份能拿去对照的身份清单

为了让上面那些数字能直接用，把这批文件里出现频率最高的几个身份整理成表。每一行的最后一列是最要紧的：拦掉它，你会失去什么。

这张表里最容易配错的是第三行和第六行。ChatGPT-User不是训练抓取，它是用户在对话里问到某个地址时才去取一次的实时请求，把它归进“拦AI训练”这一档，效果是用户当场问起你的品牌，对方拿不到你的页面。

Google-Extended则相反，它只控制生成式用途，不影响搜索收录，是唯一一个可以放心用来表达“不想被拿去训练”的开关。很多想拦AI又怕影响收录的站，其实要的就是这一个，却去动了别的。

实时取页决定了当场能不能被引用，2万条数据揭秘AI引用机制总结了5条规律。

官方对这类做法的态度也变过，Google官方指南叫停的5个动作值得对照着看。

做配置之前把这张表过一遍，能避开大半的误伤。名单会变，但分类逻辑不太会变——分清“训练用”、“检索用”、“用户实时取页”这三类，比记住二十个名字有用得多。

那个空用户代理进得去、AI爬虫进不去的站

数据里有一个站的组合特别值得单拎出来，因为它把本节的结论翻过来演示了一遍。

按引擎分别优化更有效，四大AI搜索引擎的GEO策略做了分引擎拆解。

这是个北欧家居品牌。普通Chrome拿到200，Googlebot拿到200，Bingbot拿到200，空用户代理也拿到200，四个身份拿到的字节数几乎一模一样，都是6040上下。

而GPTBot、ClaudeBot、PerplexityBot三个身份，全部拿到403，正文2097字节的人机验证页。

同一批数据里品牌词那条线更隐蔽，AI引用拆品牌词和非品牌词画在一句你看不到的话上。

这个站的规则设计得非常清楚：搜索引擎放行，未知来源放行，AI抓取拦截。在它这儿，报出AI爬虫的名字比什么都不报还要吃亏。

这个案例的价值在于它证明了名字判断的双向性。上一节说沉默会被当成可疑，这个站说沉默反而安全，两者并不矛盾——因为规则是每个站自己写的，而这批站的规则彼此之间毫无共识。

没有共识这件事本身就是结论。你没法从“行业惯例”推出任何一个具体站点的行为，只能一个一个去测。在机器人这件事上，不存在一套大家都在用的规矩，只存在一百多套各不相同的默认值。

那64个连空用户代理都放行的站

反方向也值得看一眼。132个站里有64个把页面给了什么都不报的那次请求，占48.5%。

这64个站的共同特征是防护层比较薄。要么是自建服务器没上第三方防护，要么是上了但只开了基础的攻击防御，没开机器人管理。它们不是特意对匿名请求友好，是压根没配这一层。

这个状态好不好，得看你怎么权衡。好处是任何读取方都能拿到内容，包括那些还没被主流防护产品收录进分类表的新爬虫——这两年新出现的AI抓取程序，多数属于这一类。坏处是低质量抓取和数据采集也一样畅通。

服务器这一层影响SEO的地方不止一处，服务器配置对SEO的20项影响列了完整清单。

我的看法是，对绝大多数独立站来说，这个状态比默认全拦要好。被多抓几次的成本是可计算的带宽，被少收录一次的成本是看不见的流量。两边都不确定的时候，选那个错了还能补救的。

换个角度说，如果你是那个做AI抓取的一方，最理性的策略就是不报名字。这大概是整个机器人协定体系里最尴尬的一处：老实交代身份的一方，承担了全部的不确定性。

抓取本身是有成本的，碳中和SEO运营把爬虫经济学算进了同一套规范。

402这个1997年就写好、二十多年没人用的状态码，怎么突然出现了？

这一节讲一个单独的站，因为它一个站就讲完了整件事的未来形态。

55个字节的付费墙

这个站是做手机配件的国际品牌。7种身份的结果分成三档，干净得像是有人特意设计过：

那55个字节是一段JSON，内容类型是application/json，正文是一句话：请联系站点所有者以获取访问权限。响应头里的服务器字段是那家内容分发网络的名字。

402这个状态码的正式含义是“需要付款”。它1997年就被写进HTTP规范，在现行的RFC 9110的HTTP语义定义里也仍然在册，之后二十多年一直挂着“保留待将来使用”的牌子，是整个状态码表里最著名的那个空位。MDN关于402状态码的条目至今还写着它是实验性的、尚未有标准用法。现在这个空位被填上了。

响应头这一层能表达的东西很多，HTTP响应头的X-Robots与Vary机制逐个讲过。

三档待遇背后是一套定价逻辑

把这三档摆开看，它不是防护，是分级供货。

浏览器免费拿，因为浏览器背后是可能下单的人。搜索引擎免费拿，因为搜索引擎会把流量还回来。而训练型AI爬虫既不下单也不还流量，于是它拿到一张账单。

这个逻辑一旦成立，接下来的事情就顺理成章了。同一家内容分发网络在2026年8月宣布，要给AI代理配上可以按访问付费的钱包；同一批新闻里还有一条更要紧的：从2026年9月15日起，新注册域名的默认设置会变成——被归类为训练型或代理型的爬虫，在展示广告的页面上一律屏蔽；而那些“既做搜索又做训练”的混合型爬虫，在所有拦AI训练的配置下都会被屏蔽。

流量还回来这件事本身在变，流量下降不等于SEO失败给了8个维度的解释。

同一家还在推另一种交付方式，给AI交付内容的HTTP内容协商实操讲了怎么配。

混合型这三个字是关键。Googlebot就在这一档里。

这条变更公布之后，社区里已经有人报告，把AI训练设成屏蔽之后，Googlebot和Bingbot取站点地图开始收到403，把开关关掉就恢复，完整经过见Search Engine Journal关于AI爬虫屏蔽波及Googlebot的报告。到底是配置误操作还是分类逻辑提前生效，官方还在核实。但对独立站站长来说，结论是一样的：那个看起来只关乎AI的开关，另一头连着你的自然流量。

你现在就该做的一件小事

不用等到9月。打开你的防护后台，把爬虫分类那一页翻出来，逐条确认三件事：搜索类是不是允许，训练类你选的是什么，混合类被归到了哪一边。

另一家搜索引擎值得单独维护，Bing SEO怎么做讲了它被低估的地方。

后台之外源站这一层也要看，Nginx全页缓存怎么配影响的是同一条链路。

如果你的后台里根本没有“混合类”这个概念，那更要留意，说明你用的版本还没更新到这一套分类，等它更新的那天，你的选择会被自动映射到新分类里去，映射规则不一定合你的意。

按访问付费一旦普及，独立站有三条路

这件事对独立站的影响还没显现，但方向已经能看出来了。往前推演，大致有三条路。

第一条是收费。你把内容当成资产，给AI抓取标个价。这条路只对内容本身有稀缺性的站成立——独家评测、原创数据、专业教程这一类。绝大多数电商站的商品页不具备这个条件，因为同样的商品信息在十几个渠道都有。

第二条是全放。你判断被AI引用带来的曝光价值高于内容被使用的损失，于是彻底开放，甚至主动优化机器可读性。做品牌认知、做长尾获客的站多数会走这条。

这类内容的索引控制有讲究，帮助中心和知识库SEO怎么做讲了工程化做法。

可见性怎么系统地做，AI搜索可见性的5维度策略给了实战路径。

第三条是分层。核心内容收费或者屏蔽，导购型、目录型的内容全放。这条路技术上最麻烦，但商业上最讲得通。

选哪条不是这篇文章能替你决定的，但有一个前提是共通的：你得先知道现在的状态是什么。这批132个站里，绝大多数处在“既没选也不知道自己在哪一档”的位置上，而默认值正在替他们做选择。

混合型分类为什么是个陷阱

再回到那条9月生效的分类规则上，因为它设计得确实别扭。

问题的根源是同一个爬虫在做两件事。搜索引擎抓你的页面，一部分用于建索引给你导流量，一部分用于训练它的生成式产品。这两件事共用一个用户代理串，站长没有办法只同意前者不同意后者。

于是分类系统只能造一个“混合型”的桶把它装进去，然后规定：只要你选了拦AI训练，混合型就一起拦。逻辑上自洽，后果上很吓人——你以为你在拒绝被训练，实际效果是拒绝被收录。

另一处说不清的争议，结构化数据对AI搜索到底有没有用做了官方说法加实测。

这个设计把一个本该由内容方和平台方去谈的问题，转嫁成了站长的一个二选一。站长手里那个开关，只有全开和全关两档，中间那些他真正想要的选项并不存在。

短期内能做的只有一件事：确认你现在选的是哪一档，以及默认值变更之后你会被映射到哪一档。这两个问题的答案不在文档里，在你自己的后台里。

两层都得写才生效的例子还有一个，一键退订必须写两层少一层就被限流。

顺便说一句，从技术上说，402现在的用法比它原本的设想更实在。原本的设想是给网页做小额支付，从来没落地过；现在它变成了机器之间的收费闸口，居然跑通了。一个状态码等了二十九年，等来的客户不是人，是机器。

被挡回来的那几百个字节，能告诉你什么？

拒绝页本身是有信息量的，而且信息量远比大多数人以为的大。这一节讲怎么读它。

先看服务器字段和状态码的组合

把132个站上所有“没拿到页面”的响应汇总，按服务器和状态码分组之后，分布是这样的：

自定义错误页配不好会变成软404，自定义错误页怎么配才不踩坑讲了状态码的坑。

第一行就占了六成。这说明一件很实际的事：你排查送达问题的时候，大概率只需要打开一个后台。

另外有一条负面结论也值得记：这批被挡的响应里，那个专门用来标记“本次拦截由谁做出”的响应头，一个都没出现。这个头是有标准的，但默认不开。所以别指望响应头会自己承认是它拦的，你得靠状态码、服务器字段和正文长度这三样去推。

正文长度是个被低估的线索

拒绝页的字节数比你想的更能说明问题。这批数据里有几个非常清晰的簇。

默认不开的响应头不止这一个，浏览器HTTP缓存头怎么配是另一处容易漏的地方。

第一个簇是356到372字节，一共出现了几十次，横跨十几个互不相干的品牌——运动鞋、快时尚、百货、奢侈品、小家电都有，服务器字段全是同一家内容分发网络。十几个毫不相干的大牌，用的是同一张370字节的拒绝页。它们甚至不知道自己撞了衫。

第二个簇更整齐：某个快时尚集团旗下六个品牌，六个独立域名，拒绝页字节数在357到366之间，服务器字段被隐藏了。同一套基础设施，六张同款的门。

同一家边缘产品的行为值得摸清，CDN对SEO到底有什么影响拆了6层缓存与边缘路由。

第三个簇是极短的那些。有两个站的403正文只有25字节，还有两个站只有17字节。17个字节是什么概念？一条短信的十分之一。它们连“你被拒绝了”这句话都懒得写完整。

正文长度之所以有用，是因为它能帮你判断这道墙是谁砌的。几百字节的标准页，多半是内容分发网络的默认拒绝模板；十几二十个字节的，通常是有人手写了一条规则并且随手返回了一个字符串；几千字节还带脚本的，那基本就是人机验证页。

六个品牌，六个域名，同一张门

第二个簇值得再拆一下，因为它演示了一件很多人没意识到的事。

批量查异常地址有成套方法，网站死链怎么批量查出来从检测到提交一条龙。

那六个品牌分属同一个快时尚集团，各自有独立的域名、独立的站点、独立的运营团队，在消费者眼里是六个不同的牌子。而在这次实验里，它们对爬虫身份的响应是同一套：同样的403，同样隐藏了服务器字段，正文字节数在357到366之间。

这意味着六个品牌共用同一套基础设施和同一份防护策略。改一次，六个站一起变。对做竞品分析的人来说这是个好消息——测一个就等于测了六个；对这个集团自己来说，这是一处单点风险。

一个大站还是多个小站，出海该建一个大站还是多个品牌小站算的正是这笔账。

同样的模式在另一家的十几个大牌身上也成立，只不过它们不属于同一个集团，而是买了同一家内容分发网络的服务，用了同一份默认拒绝模板。运动鞋、快时尚、百货、奢侈品、小家电，五个八竿子打不着的行业，被同一张370字节的纸挡住。

从审计的角度，这个现象有一条很实用的推论：当你发现某个站的拒绝页字节数落在几个常见值附近，基本可以判定它用的是默认模板，也就意味着这条规则大概率没有人专门配过。没有人专门配过的规则，通常也是最容易改回去的。

反过来，如果拒绝页是定制的、带品牌标识的、甚至写了联系方式，那说明有人认真对待过这件事。这时候你要做的不是去改配置，是去找那个人聊。

那几个特别的响应

有一个站对ClaudeBot返回了418。

418这个状态码的正式定义来自1998年愚人节的一份玩笑规范，含义是“我是一个茶壶”，用来表示这台设备拒绝冲泡咖啡因为它是茶壶。它从来不是正经的HTTP状态码，但主流软件栈里一直留着它，很多防护系统拿它当“我就是不想理你”的委婉表达。

这个响应的正文字节数是0，服务器字段是空的。一个茶壶，什么都没说。这大概是整份数据里最有幽默感的一次拒绝。

拦截也可以在更前面一层做，Linux服务器的防火墙端口规则怎么配讲了端口层的做法。

还有4个站的情况完全不同：它们对7种身份一视同仁，全部返回429，也就是请求过多。其中3个站的429响应带着3万3千多字节的HTML正文，服务器字段是同一家前端托管平台。

这4个站不在132的基线里，因为连普通Chrome都没拿到页面。它们不是在挡爬虫，它们是在挡所有人。如果你只测了爬虫身份没测浏览器身份，很容易把这种情况误读成“我被针对了”。

负载高到要限流的时候，服务器突然变慢负载飙高怎么排查是上游的功课。

429这个状态码的含义是请求过多，正确的用法是配一个说明什么时候可以重试的响应头。这4个站里没有一个配了。对爬虫来说，这意味着它只能靠自己猜下次什么时候再来，而多数爬虫的策略是保守——猜错了就少来，少来就意味着你的新页面被发现得更慢。

更值得注意的是那三个带着3万多字节HTML正文的429。一个状态码说“你请求太多了”，同时又给了你一整页内容，这在协议层面是矛盾的。检查工具会按状态码判失败，浏览器会按内容正常渲染，两边看到的是两个世界。这种自相矛盾的响应，是监控系统误报的重要来源。

限流是按什么算的

既然说到429，顺手把限流的机制讲清楚，因为它是送达型故障里最容易被误解的一种。

限流通常按三个维度中的一个或几个算：来源IP、身份标识、或者两者的组合。按IP算的话，同一个数据中心出来的所有请求会共用配额——这就是为什么你从云服务器测的结果，可能比真实用户的体验差。

时间窗也有讲究。有的按固定窗口算，每分钟清零；有的按滑动窗口算，看过去六十秒。前者在窗口边界会出现两倍的突发容量，后者更平滑。这个差别决定了你的监测脚本会不会周期性地误报。

同源请求还有别的副作用，给内链加UTM参数为什么伤SEO讲了分析与抓取的取舍。

还有一层是并发限制，跟总量无关，只看同一时刻有几个连接。一个每秒只发一次请求但从不关闭连接的脚本，照样可能触发它。做监测的时候记得让每次请求独立完成，别复用长连接。

还有一个站更离奇：7种身份全部返回404，正文10个字节，服务器字段是某家对象存储服务。一个知名户外品牌的主域名首页，对所有人都是404。这多半是域名解析或者跳转规则出了问题，而它显然已经这样有一阵子了。

监测跑起来之后日志会涨，服务器日志怎么管才不爆盘有现成的轮转方案。

怎么让脚本自动认出拒绝页

如果要把这套检查做成每天跑的自动化，识别拒绝页这一步必须机器化。人工看一眼当然准，但没人愿意每天看。

可以用的信号有四个，按可靠性排序。

最可靠的是正文长度加状态码的组合。正常首页几万字节，拒绝页几百字节，验证页两千到六千字节，中间的空档非常宽。定一条阈值几乎不会误判，前提是你先测过自己站的正常值。

第二可靠的是关键字符串。在你的正常首页里挑一段一定会出现、又不会出现在任何错误页上的文字，比如某个固定的导航项或者版权行。检查这段字符串在不在，比检查状态码结实得多。

第三是内容类型。前面那个402返回的是application/json，而正常首页一定是text/html。类型不对，直接判失败。

第四是服务器字段的变化。正常情况下你的站每次返回的服务器字段应该是稳定的，一旦某次变成了另一个名字，说明这次响应不是你的源站给的。这一条特别适合发现“被中间层接管了”的情况。

把四个信号组合起来，一个几十行的脚本就能跑。误报率主要来自站点自己发版本，所以报警最好带上一句“和昨天比变了什么”，而不是只说“失败了”。

字节数相同不代表内容相同

还有一个反过来的陷阱，是我在整理这批数据时才意识到的。

那几个Akamai集群的拒绝页，字节数在356到372之间浮动，差几个字节。刚开始我以为是不同的模板，核对之后发现是同一张页面——差的那几个字节是页面里嵌的请求标识符，每次都不一样。

反过来也成立。那三个返回429的前端托管站，七次响应的字节数分别是33790、33801、33799、33795、33793、33793、33791，全都在33790附近抖动，看着像七个不同的页面，其实是同一个模板加上时间戳。

所以做长期监控的时候，不要把字节数当成内容指纹，它每次都会抖。要比对内容，得先把动态部分剥掉再做散列，或者干脆只比关键字符串在不在。这个坑我见过不止一个团队踩，表现是监控天天报警，报到最后没人看了。

同一个域名，为什么给浏览器和爬虫送去了不同的国家？

这一节要讲一个我原本没打算测、但数据自己跳出来的维度。

身份不是唯一的变量，来源地也是

先坦白一个实验条件：这批请求是从一台位于中国的服务器发出去的。这个条件我原本当成噪音，后来发现它是信息。

那个运动品牌的例子最典型。普通Chrome请求最终落在中国站，服务器字段是一个国产的网关软件，17万字节；而五个爬虫身份落在国际站的403上。同一个域名，两条完全不同的路。

中国这一侧的搜索生态是另一套，中国搜索流量不是百度的天下拆了5个战场。

咖啡机品牌那个更直白：Chrome和空用户代理都被送到了它的中国站，五个爬虫身份连接都建立不起来。手机配件品牌也是，Chrome和PerplexityBot拿到的是中国站的175233字节，Googlebot拿到的是国际站的173747字节。快时尚品牌那个则是Chrome和Googlebot进了中国站，其余五个身份被301跳到国际域名之后就停在那儿了。

这四个站说的是同一件事：决定你拿到什么的不只是“你是谁”，还有“你从哪儿来”。

这件事对做多市场的独立站意味着什么

如果你的站做了地理分流，那么你在自己办公室里打开页面看到的东西，和搜索引擎在它的数据中心里看到的东西，可能根本不是同一个页面。

这不是什么新鲜风险，但它在送达型故障里会变成一个特别讨厌的干扰项：你从北京测一次没问题，同事从法兰克福测一次也没问题，而爬虫从它自己的出口测一次拿到403。三个人拿着三个不同的结果吵架，谁都没说谎。

所以排查这类问题，测试请求的出口位置必须被当成一个变量记下来。一份不写明“从哪里发的”的送达测试报告，价值大概等于一份不写单位的体检报告。

字节数差两倍以上的那四个站

还有一类更隐蔽的差别：页面给了，但给的不是同一份。

把Chrome和Googlebot拿到的字节数逐个对比，差异超过两倍的有4个站。一个户外配件品牌给爬虫的字节是给浏览器的2.13倍，一个北欧家具品牌只给了0.17倍，一个运动鞋品牌给了0.38倍，还有一个生活杂货品牌给了1.74倍。

字节数不等于内容量，多出来的可能只是没被压缩的模板，少掉的可能只是延迟加载的组件。但2.13倍和0.17倍这种量级，基本可以断定服务端确实按身份走了不同的分支。

给爬虫和给浏览器的差别还有更细一层，Googlebot为什么不读preload讲的就是这类差异。

给爬虫的比给浏览器的多，通常是好意——把客户端才会渲染的内容提前吐出来了。给爬虫的少一大半，那就要查一查少掉的是什么。0.17倍的意思是，爬虫看到的那一版页面，六分之五的内容不在。

地理分流和多语言声明是两件事

这里要澄清一个经常被混为一谈的问题。

地理分流发生在服务端，它根据你的IP决定把你送到哪个版本，动作是跳转或者直接改变响应内容。多语言声明发生在页面里，它告诉搜索引擎“这个页面还有这些语言版本”，动作是提供信息，不改变任何人拿到什么。

前者是强制的，后者是建议的。一个把用户强行跳走的站，就算多语言声明写得再完整，搜索引擎也可能只收录到它被跳到的那一版。

这些声明的实际待遇比预期低，hreflang写的语言版本只被当成规范页的别名是上个月的实测。

这批数据里能看到这个后果。四个做了地理分流的站，爬虫身份拿到的最终地址和浏览器身份完全不同，有两个甚至落在了不同的顶级域名上。对搜索引擎来说，它抓到的就是它被送到的那一个，其余版本能不能被发现，取决于别的路径。

比较稳的做法是：不强制跳转，给出一个明显的地区切换入口，让访问者自己选，同时把各语言版本的关系声明完整。这话说起来容易，跟增长团队的KPI经常打架，但从收录的角度它确实是最干净的方案。

怎么测多个出口

如果你的站做了地理分流，那单点测试是不够的，得从多个出口各测一次。

首屏那块地怎么安排，首页首屏从导航到分类区怎么设计有一份取舍清单。

成本最低的办法是用几家不同区域的云服务器，各开一台最小规格的机器，跑同一个脚本。三个区域基本够用：你的主要市场、你的第二市场、以及搜索引擎数据中心比较集中的那个区域。

更省事的办法是用现成的多地拨测服务，很多监控产品自带这个功能，配置一下就能从十几个城市同时发请求。缺点是这类服务通常不让你自定义用户代理串，做不了本文这种身份对照。

多台机器跑起来之后备份也得跟上，服务器怎么用rsync做增量备份讲了异地恢复。

还有一个几乎零成本的土办法：找几个在不同国家的同行或者客户，请他们打开页面截个图。不够严谨，但发现“某个国家看到的是完全不同的页面”这种问题，它足够了。

怎么在十分钟内判断故障属于哪一种？

数据讲完了，这一节讲怎么用。

三种病的判据表

一个检查没通过，可能是三件完全不同的事：东西根本不存在、东西存在但对方没拿到、对方拿到了但不采信。这三种的处置方式互为毒药，用错了不只是无效，是把事情弄得更糟。

判据这件事在选题上也成立，一个词值不值得单开一页用87个站的站点地图先替你答了一半。

这张表可以贴在工位上。同一句“没通过”，在这三格里分别意味着：你还没做、你做了但它没到、它到了但不算数。

送达型的两个特有属性

送达型故障有两个属性是另外两种没有的，理解它们能省掉大量无用功。

第一个是开关性。它几乎没有中间态，要么全通要么全断，不存在“部分页面受影响”这种渐变。所以如果你看到的是某一类页面掉、另一类不掉，那大概率不是送达问题，别往这个方向查。

开关型与滞后型的差别在实验里也有，A/B测试赢了上线却掉了问题出在那26天。

第二个是恢复的不对称。把开关关掉，拦截立刻消失，但流量不会立刻回来。索引要重新建立，商品要重新审核通过，抓取频率要重新爬回原来的水平。开头那个案例里，配置改回来之后，客户的流量是“只是刚开始恢复”。

这个不对称有一个很实际的推论：送达型故障的成本跟它持续的时间不是线性关系。断三天和断两周，恢复周期差的远不止四倍。所以这类问题的排查优先级应该高于它表面上的严重程度。

恢复要等多久，分四段看

把恢复这件事拆开，能看到四段各自独立的时钟，它们不同步。

第一段是拦截解除，这一段是即时的。开关一关，下一次请求就能过。这也是唯一你能控制节奏的一段。

第二段是重新抓取。搜索引擎不会因为你修好了就立刻回来，它按自己的调度表走，而且刚经历过一批失败的地址，重试频率通常会被下调。这一段从几天到几周不等，站的权重越高越快。

第三段是重新索引。抓到不等于立刻回到索引里，还要过一遍质量评估。掉出去的页面重新进来，往往比第一次进来更慢。

第四段是排名恢复。这一段最不可控，因为在你缺席的这段时间里，你原来的位置已经被别人占了，而占位的一方现在有了新的数据支撑。你不是回到原来的位置，你是重新去争一次。

那几种状态各自意味着什么，Google索引覆盖的8种状态给了算法决策路径。

回来之后进哪一层索引也不一定，Google分层索引揭秘讲了三层的差别。

购物类的商品列表是另一条时钟，通常比自然搜索快，因为它有明确的重新审核机制，但也要按批处理。开头那个案例里，配置改回来之后一段时间，客户的状态是“只是刚开始恢复”——注意这个措辞，那已经是修好之后的事了。

把四段加起来，一次两周的送达故障，完全恢复往往要一到两个月。这就是为什么这类问题值得用一个每天跑一分钟的脚本去防。

十分钟的分诊流程

真到了现场，按这个顺序走：

第一步，用普通浏览器的身份从外网要一次首页，确认站本身是活的。这一步排除掉“其实所有人都进不来”那4个站的情况。

第二步，换成搜索引擎爬虫的身份要同一个地址，比较状态码和字节数。两次结果不同，送达型基本坐实。

第三步，再换两三个AI爬虫身份各要一次。如果只有新身份被挡，去查防护产品的分类规则；如果连搜索引擎身份都被挡，立刻处理，这是在烧钱。

第四步，看拒绝响应的服务器字段和正文长度，定位是哪一层拦的。

第五步，才轮到去读robots.txt。注意顺序：robots.txt是最后一步不是第一步，因为它只能告诉你意图，告诉不了你事实。这一节的数据已经证明了，这两件事经常对不上。

三种病会同时出现

判据表是为了讲清楚才分成三格的，真实现场经常是混着的，而且顺序有讲究。

典型的混合形态是这样：一个页面既是空壳（缺失型），又对某些身份拿不到（送达型）。这时候先修哪个？先修送达。因为送达没解决，你补的内容对方一个字也读不到，改了等于没改。

另一种混合是送达型加采信型：页面能拿到了，但搜索引擎选了另一个地址当规范版本。这时候先解决送达，再等它重新评估，因为采信的前提是它得先拿到你的新版本。

三种病连在一起，其实是一条有先后的链：东西得先存在，然后得送到，最后才谈采信。修的顺序必须跟这条链一致，跳着修就是白干。

反过来，诊断的顺序可以倒着来，因为最容易验证的是最后一环——去看看对方到底采信了什么，通常一个后台工具就能看到。发现它采信的不是你想要的，再往前推是送到了没有，最后才问东西在不在。

误判的代价不一样

三种病判错的代价并不对称，这个不对称决定了你该往哪边偏。

把送达型误判成缺失型，代价是你花几周重写内容，问题一点没解决，而且这几周里损失一直在累积。这是最贵的一种误判。

把缺失型误判成送达型，代价小得多：你去查了一圈防护配置，发现没问题，然后回头查内容。浪费半天，但不会往错误方向投入大量资源。

把采信型误判成缺失型，代价是最典型的那个错误动作——加大声明力度。同一件事再声明一遍、写得更绝对，而对方不采信的原因是存在竞争性证据。这种情况下加强声明不但无效，有时候还会因为新增了一处不一致而让情况更糟。

所以经验法则是：拿不准的时候先按送达型查，因为它最便宜、最快、而且误判它的代价最高。十分钟能排除掉的事，没有理由放到最后。

三句话，把三种病问出来

如果只想记一件事，就记这三句问句，它们能覆盖绝大多数现场。

第一句：这个信息，除了眼睛之外还有谁能读到？问出来的是缺失型。答案如果是“打开页面就看得见啊”，那你已经答错了——看得见靠的是浏览器执行了脚本，而对方没有那双眼睛。

第二句：换一个身份再要一次，结果一样吗？问出来的是送达型。这句话的好处是它可以立刻被执行，不需要讨论，两分钟就有答案。

第三句：这个结论是我声明的，还是对方算出来的？问出来的是采信型。凡是对方算出来的东西，你只能提供证据去影响它，不能直接指定它。措辞里带着“已选定”“已检测到”这类词的字段，多半都属于这一类。

三句话按顺序问，能在十分钟内把方向定下来。方向定错了，后面做多少都是负数。这也是这一系列文章想说的全部意思：先分清是哪种病，再谈治法。

顺序还有一层用处，是它能帮你判断该找谁。缺失型的活儿落在前端和内容那一侧，送达型的活儿落在运维和安全那一侧，采信型的活儿多半落在信息架构和数据一致性那一侧。问错了人，得到的答案通常是一句真诚的“我这边看着没问题”，而这句话在三种病里都成立。

所以真到了要拉群的时候，先把这三句问句发进去，让每一方各自回答与自己相关的那一句。比起描述现象，让各方去验证一条明确的判据，能省掉大半的扯皮。

这套自查怎么跑才不会误伤自己？

最后讲操作层面的注意事项，都是踩过的。

别用真爬虫的身份去压别人的站

先说边界。这套方法用在自己的站上没有任何问题，那是必要的运维检查。用在别人的站上要克制：单个地址取一次，间隔拉开，不要并发压。

这次实验对每个域名只发7次请求，全程跑完，没有对任何一个站造成可感知的负载。做竞品调研和做压力测试之间只隔着一个频率参数，别越过去。

三个容易读错的信号

第一个，200不等于拿到了页面。前面那59个验证页里有相当一部分返回的是200。判断标准要加一条正文长度，或者干脆检查正文里有没有你期待的关键字符串。

第二个，403不等于robots.txt写了禁止。这两件事在不同的层，403是送达层的动作，robots.txt是声明层的文字。看到403就去改robots.txt，是本文开头说的那种“药方互为毒药”的典型。

第三个，连接失败不等于站挂了。有8次响应是连接层就被丢弃的，状态码是0。这种情况下站本身活得好好的，只是那个身份的握手被拒了。

把这件事变成例行检查

送达型故障的最佳防御不是配置得多完美，而是缩短发现它需要的时间。开头那个案例损失了两周，而这个检查跑一次不到一分钟。

做法很简单：写一个每天定时跑的小脚本，用三到四个身份各请求一次首页和一个商品页，把状态码和正文长度记下来，任意一项跟昨天不一样就发个通知。不需要复杂的监控系统，一个定时任务加一个通知接口就够了。

保哥给客户做技术审计的时候，这一项现在是固定动作，成本极低但抓到过好几次问题。有一次是客户换了套防护方案，服务商的默认模板把两个AI爬虫身份归进了黑名单，客户完全不知情，是脚本第二天早上报出来的。

这个脚本大概长什么样

说得再具体一点，免得看完还是不知道从哪儿下手。

需要的东西只有三样：一个能发HTTP请求的命令行工具、一个能定时执行的任务、一个能把消息推到你手机上的接口。三样在任何一台Linux服务器上都是现成的。

循环的结构是两层：外层遍历你要监测的地址，一般是首页、一个分类页、一个商品页，三个足够；内层遍历身份，桌面浏览器、搜索引擎爬虫、一个AI爬虫，三个也够。九次请求，跑完不到一分钟。

每次请求记四个值：状态码、正文字节数、最终地址、服务器字段。存成一个纯文本文件，一行一条，带上时间戳。

比对逻辑就是拿今天的文件和昨天的比，任意一个值变了就推送一条消息，消息里带上变化前后。不要设复杂的阈值，任何变化都值得看一眼，因为这些值在正常情况下本来就不该变。

唯一需要注意的是别把自己的监测请求发成攻击。间隔至少几秒，串行跑，别并发。你监测的是自己的站，但如果同一个脚本被复制去测别人的站，这条纪律就重要了。

哪些地址值得放进监测清单

三个地址不是随便挑的，选错了监测等于没做。

首页必选，它是防护配置最松的一页。首页出问题，说明配置改得很激进，性质严重。但反过来不成立——首页正常不代表别的页面正常，这也是为什么不能只测首页。

第二个选一个分类页或者列表页。这类页面通常带参数，而很多防护规则是按参数特征触发的。它是最容易被误伤的一类，因为筛选参数长得很像自动化抓取的痕迹。

移动版和桌面版还可能不是同一页，移动优先索引的渲染机制讲了掉量自救。

筛选页要不要禁有判别法，电商筛选URL要不要写Disallow给了三类分法。

第三个选一个商品详情页，而且要选那种深层路径的。它代表你真正想被收录的那一层，也是抓取链路最长的一层。

还有两个可选项。一个是站点地图文件本身，前面提到的社区报告里，最先出问题的就是它——爬虫取站点地图收到403，而首页是好的。另一个是robots.txt，它被拦住的话性质更严重，因为爬虫会因此暂停整站抓取。

加上这两个，一共五个地址，三个身份，十五次请求。跑完两分钟，覆盖了这类故障90%以上的表现形态。这可能是整个技术SEO工具箱里投入产出比最高的一个动作。

指令生效的时滞也要算进去，已收录页面加noindex后多久消失做了6个场景的实测。

交付给客户的时候怎么写

最后说一句写报告的事，因为这类发现很容易被写成一堆没人看的技术细节。

有效的写法是三行。第一行写事实：某某身份在某某地址上拿到的是什么，附上状态码和字节数。第二行写后果：这个身份拿不到页面，会导致什么业务后果，尽量换算成能被理解的东西。第三行写动作：具体到哪个后台的哪一页，改什么。

不要在报告里解释协议原理。决策者需要的是“这个开关关着，你的商品列表就没了”，不是机器人排除协议的历史沿革。原理放附录，或者放到这样一篇文章里。

给数字配上口径说明同样重要，一条五年趋势线上有三处口径变更是个反面教材。

交付物写成规范才不返工，内容简报怎么写才能让稿子一次到位是同一个思路。

最后留一个数字当结尾。这次实验里，129个站把首页交给了一台只是在请求头里写了个名字的普通服务器。它们既没有查这个名字的真伪，也没有看这次请求的行为。门锁装得很认真，钥匙是喊出来的。

常见问题解答

robots.txt写了Allow，为什么爬虫还是抓不到页面？

因为这是两层不同的东西。robots.txt是声明层，写的是你希望对方抓什么，靠对方自觉遵守；防火墙、机器人管理、边缘规则是送达层，决定这次请求到底能不能拿到字节。本文实测的132个站里，robots.txt写着允许但GPTBot实际拿不到页面的有10个站，ClaudeBot有8个，连Googlebot都有1个。排查顺序应该是先测实际送达，最后才读robots.txt。

怎么快速判断流量下滑是算法更新还是爬虫被拦？

看三个特征。算法更新的下滑通常有结构，某类页面掉得多、某类掉得少，不同市场不同步；爬虫被拦是整片下滑，所有页面按同一节奏走。算法更新有全行业共同的时间戳，配置误伤只在你自己的变更记录里。最有辨识度的一条是：如果自然流量和购物广告的商品列表同时消失，而付费广告照常扣费，那基本可以排除算法更新。

为什么空用户代理的请求反而更容易被挡？

因为这类防护是按名字放行的，不是按行为。你自称是某个已知爬虫，规则里能匹配到对应的条目就放行；什么都不报的请求匹配不到任何已知条目，直接落进“未知来源先验证”的默认分支。实测数据里，空用户代理的通过率只有48.5%，被挡的63次里有59次是撞上人机验证页，而不是干脆的拒绝。

我的服务器日志里查不到爬虫被拒绝的记录，是日志坏了吗？

不是。拦截发生在边缘节点，请求在那里就被判了并返回响应，整趟往返你的源站从头到尾不知情。所以源站日志里看到的不是“爬虫来了被拒绝”，而是“爬虫没来”。这两句话在日志里长得一样，含义完全不同。要看到真相，得去边缘那一层的日志，或者自己扮成那个身份去要一次。

2026年9月15日那次默认设置变更，我需要做什么？

那次变更的要点是：新注册域名的默认设置里，被归类为训练型或代理型的爬虫在展示广告的页面上会被屏蔽，而“既做搜索又做训练”的混合型爬虫在所有拦AI训练的配置下都会被屏蔽。Googlebot属于混合型。所以要做的事只有一件：现在就去防护后台把爬虫分类那一页翻出来，逐条确认搜索类、训练类、混合类各自被归到了哪一边，别等默认值自动映射。

拦AI爬虫到底有没有用？

对守规矩的那一批有用，对不守规矩的那一批没用。本文的实验已经证明了这一点：一台普通云服务器只在请求头里写了一行字，129个站就把首页交了出来，没有一个站做过反向解析验证。真想拿数据又不在乎规矩的，改一个用户代理串就绕过去了，成本是零。所以这类拦截的实际效果，是筛掉了愿意报名字的那一批，留下了不报名字的那一批。

只测首页够不够，为什么还要测站点地图？

不够。首页通常是全站防护配置最松的一页，因为它承担品牌展示职责，谁都不希望它出问题；而分类页带参数、商品页路径深，被误伤的概率都更高。站点地图和robots.txt这两个文件尤其要测：社区里那份关于AI爬虫屏蔽波及搜索引擎的报告，最先出问题的就是站点地图取不到，而首页一直是好的。robots.txt被拦的性质更严重，爬虫会因此暂停整站抓取。建议的监测清单是首页、一个分类页、一个深层商品页、站点地图、robots.txt，共五个地址。

为什么修好之后流量没有立刻回来？

因为恢复分四段，只有第一段是即时的。拦截解除是开关一关就生效；重新抓取要等搜索引擎自己的调度，而且刚经历过一批失败请求之后重试频率通常会被下调；重新索引还要再过一遍质量评估；排名恢复最不可控，因为你缺席的那段时间里位置已经被别人占了，你不是回到原位，是重新去争一次。一次持续两周的送达故障，完全恢复往往要一到两个月。这个不对称正是这类问题排查优先级要高于其表面严重程度的原因。

做这种多身份检测，会不会对被测网站造成压力？

用在自己的站上完全没问题，属于必要的运维检查。用在别人的站上要克制：单个地址取一次，间隔拉开，不做并发压测。本次实验对每个域名总共只发了7次请求，全程没有对任何站造成可感知的负载。做竞品调研和做压力测试之间只隔着一个频率参数。

权威参考资料

摘要：对211个国际化电商域名各发了七次请求，看它们在被问“这个页面变了没有”的时候答不答得上来。首页这一层，142个能正常响应的站里只有52个回得出304，占36.6%；四成的站连一个可以拿来协商的凭据都不给。更麻烦的是有25个站给了ETag却不认自己发的ETag，重发照样全量返回。另外还有16个站连发两次拿到的ETag就不一样，其中五个的字节长度段一模一样、只有哈希段在变。

Google在管理抓取预算的官方文档里，有一条建议写得很短：支持304状态码。如果一个页面自上次抓取以来没有变化，返回304就等于告诉Google复用缓存那一份，替你省下服务器带宽和资源。

这条建议很好懂，也很容易被跳过。因为它跟同一份文档里的其它建议不太一样——它不在Search Console里，不在任何一份报告里，没有一个检查会告诉你做到了没有。

那到底有多少站真的做到了。保哥把手上那批国际化电商域名拿来实测了一轮：先正常请求一次拿凭据，再拿着凭据重发，看它回什么。结论是三成六。而这三成六背后的故事，比这个数字本身有意思得多。

这篇文章的前半段讲机制：条件请求到底在问什么、这条建议属于哪一类规则、为什么它没有任何反馈。后半段是实测的四道关卡，以及一份能用一条命令跑完的自检。

Google那句建议的原文到底说了什么？

先把原文和它所在的位置摆清楚，因为这决定了它的分量。

回原文核对是这个系列反复强调的动作，七万五千条答案实证的引用偏好也是靠原始数据说话。

它写在哪一份文档的哪一节

这条建议出现在大型站点抓取预算管理指南里，属于“减少抓取预算浪费”那一节。同一节下面还有另外八条建议，包括合并重复内容、用规则屏蔽不必要的页面、给永久删除的页面返回404或410、消除软404、保持站点地图更新、避免重定向链、优化页面加载速度、以及排查抓取问题。

同一份文档里其余八条建议怎么落地，抓取预算优化的十二项实操指南里逐条拆过，可以配着这一条一起做。

把这九条排在一起看，会发现支持304这一条的位置很特别：其余八条都是内容侧或者信息架构侧的活，只有它是纯服务端行为。

原话的三个要点

原文一共三句话，拆开是三层意思。

抓取这一侧的硬约束不止一条，Googlebot抓取2MB限制的八步实战优化是另一条会直接卡住内容的限制。

第一层是动作：支持304这个状态码。第二层是条件：当一个页面自上次抓取以来没有变化的时候。第三层是收益：告诉Google复用它缓存的那一份，从而节省你的服务器带宽和资源。

请注意第三层的措辞：省的是你的带宽和资源，不是Google的。这句话的主语很关键——它没有承诺你会被抓得更勤，也没有承诺收录会变快。它承诺的只有一件事：同样的抓取次数，你少发很多字节。

这条建议的收益到底该怎么算

很多人一看到抓取预算就想到收录速度，然后期待一个排名或者流量层面的回报。这个期待多半会落空。

页面体积直接决定这笔账有多大，四十六个电商站的页面体积实测量的正是同一批站的字节规模。

更实际的算法是这样：你的服务器每天为爬虫发出去多少字节，其中有多少是重复发送的完全相同的内容。本次实测里，142个站的首页平均大小是707 KB，全部加起来一次就是98 MB。如果一个爬虫每天来抓十次而内容一次都没变，那就是十次707 KB。

支持304之后，这十次里的九次可以压缩成一个空响应。省下来的不是抽象的预算，是实实在在的出口带宽和数据库查询。对流量大的站，这笔账相当可观；对小站，说实话省不了几个钱，但它也几乎不花什么力气。

还有一层收益不太容易量化但确实存在：返回304的响应，服务端往往不需要走完整的渲染流程。一个动态页面的全量响应可能要查十几次数据库、跑一遍模板、再做一次压缩；而一次304只需要比对一个字符串。这部分省下来的计算资源，在大促这类高峰时段的价值远超带宽本身。

它跟抓取频率是什么关系

这是个高频误解，值得说清楚。支持304不会直接让Google抓得更勤，官方也没这么承诺过。

抓取频率的真实情况只能从日志里看，日志分析一步步挖出AI爬虫真相给了一套可复用的分析顺序。

但它们之间有一层间接联系：抓取速率的上限，一部分取决于系统观察到的你的服务器响应状况。如果你的站响应快、错误少，系统会更愿意多抓；而全量返回一个大页面比返回一个空的304慢得多。

所以合理的预期是：这条建议的主要收益在你自己这一侧，抓取侧的收益是次生的、不确定的、也没法单独归因。把它当成一件降本的事去做，比当成一件提效的事去做更不容易失望。

为什么这条建议和其它建议不一样？

这是前两篇文章里那个三分法的第三格，也是最容易被忽略的一格。

这三类规则背后是同一套身份与信任机制，实体主页怎么搭才算把品牌身份立住给了整体框架。

平台介入的第三种方式

前面两篇分别讲了禁止型和代劳型：禁止型是平台立规矩、违反了要挨罚；代劳型是平台自己算、你只能摆原料。这一篇讲第三种，可以叫亲自型——这件事百分之百发生在你的机器上，平台只能建议，做与不做只有你自己知道。

第一类禁止型的样本是名字字段，商家名称禁令当尺子量出来的那份结果是这个系列的第一篇。

同一批电商站的另一项体检也是这个量级，四十个电商站的站内搜索页实测可以并排看。

三十秒的判据

判断一件事是不是亲自型，问两个问题就够。

第二类代劳型的样本是图标与站点名称，favicon要上广告位而两百多个站拿不出图是这个系列的第二篇。

第一个问题：这件事发生在谁的机器上。发生在你这边的，平台只能建议，因为它没有任何执行手段——它总不能替你改服务器配置。

第二个问题，也是更好用的那个：有没有一个官方工具能告诉你做到了没有。有的话，说明平台在意这个结果、并且愿意为你提供反馈；没有的话，那这件事就完全是你自己的事。

条件请求这一条，两个问题都指向亲自型。Search Console里没有这一项，富媒体测试工具里没有，页面体验报告里也没有。你唯一的检查手段是自己发一次请求。

亲自型的投入曲线是线性的

这一点跟前两类差别很大。禁止型是阶跃：过线之前为零，过线之后不再增长。代劳型是钝的：收敛候选很有用，超出之后无效。亲自型是线性的：做多少得多少，而且不封顶。

服务端这一层的活基本都属于做多少得多少，服务器配置对SEO影响的二十项清单里全是这一类。

为什么线性，因为它省下来的东西是按次计的。你的站被抓得越频繁、页面越大、变更越少，这条建议的收益就越高。这也是为什么它写在“大型站点”那份文档里——规模本身就是它的乘数。

也正因如此，它是三类里唯一一个值得长期投入的。禁止型做完就该走人，代劳型收敛完就该停手，只有亲自型的活会随着你的站变大而持续升值。

没有反馈这件事有多要命

把三类规则的反馈机制并排看，差别一目了然。

没有反馈的时候只能自己造一个观测，给那条建议配一个注定无效的对照组讲的就是怎么造。

禁止型有明确的通知：资料被暂停会发邮件，手动操作会在后台显示，你不可能不知道。代劳型虽然没有通知，但结果是肉眼可见的——搜索一下自己的品牌，图标和名字对不对一目了然。

亲自型两样都没有。做与不做，页面表现完全一样；做错了和做对了，浏览器里看不出任何区别。你的服务器可能已经连续三年在为爬虫重复发送同样的几百KB，而没有任何一个系统觉得这值得提一句。

所以它的失败模式是“一直没做”

其它两类规则的失败通常是一次性事件：某天改错了、某天被罚了。亲自型的失败是一种持续状态——它从上线第一天起就没做，然后一直没做，中间没有任何一个时刻会变糟，也就没有任何一个时刻会引起注意。

持续状态的失败最难被注意到，用户扫完一整屏一个都没点开这件事也是同一种静默。

这解释了本次实测的一个现象：做到和没做到的分布，跟站点规模、品牌知名度、技术水平的相关性都不强，反而跟“用的是哪套基础设施”高度相关。因为绝大多数团队从来没主动做过这个决定，最终结果就是它们的服务商替它们做了。

一次条件请求究竟在问什么？

要看懂后面的数据，得先把机制过一遍。这套东西不复杂，但有几个反直觉的点。

机制讲清楚了才知道报表在说什么，hreflang备用网址被当成规范页别名也是先把机制拆开。

整个流程分两步

第一步，客户端正常请求一个地址，服务端返回内容，同时在响应头里附上一张或两张“凭据”。凭据有两种：一种叫 ETag，是这份内容的一个标识符；另一种叫Last-Modified，是这份内容的最后修改时间。

抓取与渲染分几步直接影响服务端要付出多少，搜索引擎抓取和渲染DOM分几步把这条链路拆开讲过。

第二步，客户端下次再来的时候，把凭据带上：拿ETag的用If-None-Match这个请求头，拿时间的用If-Modified-Since。服务端比对之后，如果内容确实没变，就返回304和一个空的响应体；变了就返回200和完整内容。

这套机制的正式定义在 HTTP语义规范里条件请求那一章，缓存相关的部分则在另一份专讲HTTP缓存的规范里。

两种凭据的差别比想象中大

响应头这一层的能力比多数人以为的多，用内容协商给AI交付Markdown的实操是另一个用法。

规范里还区分了强校验和弱校验：ETag前面带W斜杠前缀的是弱校验，表示两份内容语义等价但字节未必完全相同。本次样本里绝大多数ETag都是弱校验，这很正常，因为动态生成的页面很难保证字节级一致。

弱校验在这里是加分项

很多人看到弱校验会觉得不严谨，其实反过来。弱校验允许你说“这两份内容语义上是一样的”，即使它们的字节不完全相同。这正好是动态页面需要的能力。

想看别人的响应头怎么配，十款网站技术栈检测扩展的实测对比里有能直接读的工具。

理论上，一个实现得好的服务端可以主动利用这一点：把页面里那些不影响语义的部分——随机令牌、请求编号、渲染时间戳——排除在哈希计算之外，然后打上弱校验标记。这样即使字节变了，标识符也不变，条件请求照样能生效。

本次实测里没有看到有站这么做。那五个长度段不变、哈希段变的站，用的都是对整个响应体做哈希的默认实现。它们打了弱校验的标记，行为却是强校验的。标记和实现不一致，这是另一种形式的名不副实。

这也给出了一条很具体的改造思路：你不一定要把随机令牌从页面里挪走，只要把它排除在哈希计算之外就行。前者要动前端和后端的交互方式，后者只需要改一处哈希逻辑，成本差好几倍。

最容易被误解的一点

很多人以为返回304就等于“这个页面被缓存了”，然后担心内容更新之后用户看到旧版。这是两件事。

缓存与索引状态经常被混为一谈，已收录页面加noindex后多久消失的六大场景实测把这两件事分开量过。

缓存策略由Cache-Control这类响应头决定，它说的是“这份内容可以被存多久”。条件请求说的是“存着的那份还能不能用”。前者决定要不要问，后者决定问了之后怎么答。

所以支持304完全不影响内容的时效性——内容真变了，服务端就返回200和新内容，一秒钟都不会延迟。它省的只是那些确实没变的时候的重复传输。

还有一个概念也常被混淆

304和200之间还夹着一个容易被忽略的区别：304不是“这个页面没变”，而是“你手上那份还能用”。主语是客户端手上的副本，不是页面本身。

概念混用是很多错误结论的起点，一条五年趋势线上有三处口径变更就是一次口径混用的代价。

这个区别在实践里有意义。假设一个页面被改了又改回来，字节完全恢复原样，那么ETag也会恢复原样，条件请求照样返回304，而中间那次改动对客户端来说等于没发生过。这套机制关心的是等价，不是历史。

反过来的情况也存在，而且更常见：内容在语义上完全没变，字节却变了。页面里换了个随机令牌、请求编号变了一位、某个时间戳精确到了秒，这些都不影响任何人读到的东西，但足以让整份内容的哈希彻底改变。

这就是后面那批数据的核心矛盾：一个用来判断“是不是同一份内容”的机制，实际判断的是“是不是同一串字节”，而这两者在动态页面上经常对不上。规范给了弱校验这条出路，可惜实测里几乎没人真的用起来。

为什么这套机制没被更广泛地实现

说一句公道话：对静态文件来说这件事几乎是白送的，服务器自动就做了；难的是动态页面。

静态与动态的差别决定了这件事的难度，SaaS托管自建与纯代码的选型全拆解里有各类栈的对比。

动态页面要生成ETag，服务端得先把整个响应体渲染出来，才能算出哈希——而渲染本身就是最贵的那一步。算完哈希发现可以返回304，省下的只是网络传输，计算已经花掉了。

要真正省掉计算，得在渲染之前就知道内容有没有变，这需要一个可靠的版本标识：内容的更新时间戳、缓存条目的版本号、或者数据层的变更序号。这一步是有设计成本的，也是大多数站停在半路的地方——它们生成了ETag，但那个ETag是渲染完之后算的。

第一关：142个站里有多少个能被问？

要回答“变了没有”，你首先得给出一个可以拿来比对的凭据。这一关卡住的站比预想的多。

能不能被问取决于你有没有给出可引用的东西，GSC品牌词过滤器的五步使用指南里那套拆分也依赖你先给出可用的标记。

怎么测的

对211个域名的首页各发一次普通请求，跟随跳转，从最终那个响应的头里读ETag、Last-Modified、Cache-Control、Vary、Server这几项。211个里有142个返回了200，其余是人机验证、跳转或者连不上，不进统计。

批量发请求并读响应有现成的做法，网站死链怎么批量查出来的一条龙流程可以直接改来用。

有一个技术细节值得交代：响应头必须取最后一个响应块的，不能取第一个。因为跟随跳转的时候，会依次收到跳转响应的头和最终响应的头，两者的ETag和缓存策略往往完全不同。如果取错了，测的就是跳转那一跳的行为，跟内容页没关系。

这一步在写脚本的时候特别容易搞错，而且错了之后数据看起来完全正常——你会得到一批合法的、但描述的是另一个东西的响应头。这类错误的隐蔽性跟本文后面要讲的那几个问题是同一个性质。

七次请求分别在测什么

每个地址一共发七次，各有分工，列出来方便你自己复现。

测法设计决定结论能不能用，三百个站实测出来的收录速度指标怎么读里有同一类的设计说明。

七次里前五次是这篇文章的主线，后两次是顺带。如果你只想自查，跑前三次就够了，两分钟。

换一种口径去看，缺口才会显形，日志里带人来的其实是另一批入口是同一种发现方式。

并发和礼貌

顺带说一句抓取礼仪。本次是二十多个并发跑完两百多个域名的七次请求，总请求量一千五百次左右，对每个站来说就是七次，负载可以忽略。

被防护层当成可疑流量是很常见的事，五种代码识别搜索引擎蜘蛛的实战指南从另一侧解释了判定逻辑。

但如果你要做更大规模的测量，请把并发限制在合理范围，并且给同一个域名的请求之间留间隔。本次有4个域名返回了限流状态码，说明防护层确实在盯着。被限流不只是拿不到数据的问题，它还会污染你的样本——被限流的站会掉出统计，而它们未必是随机掉的。

被排除的那69个是什么情况

211减去142，还剩69个没进统计。分布是：返回拒绝访问的34个、完全连不上的20个、停在跳转上的8个、被限流的4个，剩下几个是各种其它状态。

被排除的样本会悄悄改变结论边界，调研数据里没有一个非会员却写给非会员看是这一类的典型。

拒绝访问那34个绝大多数是人机验证——本次抓取用的是普通浏览器标识，被防护服务拦下很正常。这批站不是没做，是没让我测。它们对真实爬虫的行为可能完全不同，所以本文所有比例都只代表能被正常访问的那142个。

这个偏差的方向不好判断。一方面，上了严格防护的站通常技术投入更高，可能做得更好；另一方面，防护层本身也会改变缓存行为。说不清方向的偏差，就只能如实标出来，别假装它不存在。

结果

四成的站，连被问的资格都没有。爬虫想问一句“这页变了没有”，找不到任何可以引用的东西，只能整页重下。

这四成里大部分是主动放弃的

翻了一遍这57个站的响应头，发现一个很清楚的规律：其中相当一部分的Cache-Control里写着no-store或者no-cache。

保守策略是有代价的，支付页CSP实测五十三个站的出厂默认里有同一种权衡。

no-store的意思是“任何环节都不要存这份内容”。既然不让存，那也就没有“存着的那份还能不能用”这个问题，不给凭据在逻辑上是自洽的。这批站不是没做好，是明确选择了不参与这套机制。

这个选择通常出于两个理由：一是首页高度个性化，每个人看到的都不一样；二是安全或合规要求，不希望任何中间节点留存内容。理由都成立，但代价是每一次抓取都是全量。

剩下那部分才是真的漏了

另一部分站的Cache-Control写的是public加一个不小的max-age，明确表示这份内容可以被缓存很久——但它一个凭据都不给。

自相矛盾的配置该在上线前拦下来，新网站前十二周的技术地基清单里有对应的检查项。

这就自相矛盾了：你说这份内容可以存一个小时，可你没给任何办法让人确认这一个小时之后它还是不是原来那份。缓存到期之后，客户端只能整页重下，前面那个max-age相当于白设。

这一类才是真正意义上的疏漏，而且修起来最简单——绝大多数服务器和CDN都支持自动生成ETag，通常就是一个开关。

怎么区分自己属于哪一类

看两个头就够了。如果Cache-Control里有no-store，那是主动放弃，不用管；如果写的是public加一个max-age，或者干脆什么都没写，而同时又没有任何凭据，那就是疏漏。

一条记录背后的展开规则往往不由你定，SPF记录只有一行展开要查几次是别人定的是同一类隐性约束。

本次142个站里，没有Cache-Control这个头的有70个，接近一半。这一档最尴尬：它既没有明确说可以缓存，也没有明确说不要缓存，缓存行为完全交给各个客户端按启发式规则去猜。

猜的规则通常是这样：客户端拿最后修改时间和当前时间的差算一个比例，得出一个自己觉得合理的缓存时长。而如果你连最后修改时间也没给，那这套启发式也用不上，结果就是每次都重下。

顺带说说Vary这个头

还有一个容易被忽略的相关项。Vary声明的是“这份响应的内容会随哪些请求头变化”，比如随语言变、随设备变、随压缩方式变。

同一份内容对不同客户端呈现不同版本，浏览器自动翻译把选项改掉而问卷看不出异常是个极端案例。

它跟条件请求的关系是：如果你的内容真的会随某个请求头变，那就必须声明，否则缓存层可能把A用户的版本拿给B用户。但反过来，Vary声明得太宽也有代价——每多一个变量，缓存的命中率就降一档。

本次没有对Vary做详细统计，只在读头的时候顺带记录了。写在这里是提醒你，条件请求这件事不是孤立的，它和缓存策略、内容协商是同一套东西的三个侧面。

第二关：那张凭据稳不稳？

给了凭据只是第一步。如果同一个地址每次给的凭据都不一样，那这张凭据等于没有。

稳定性是很多机制生效的隐含前提，AI搜索可见性的五维度深层策略里也有同类前提。

连发两次，看凭据变不变

测法很简单：对同一个地址，间隔几秒钟连发两次普通请求，把两次拿到的ETag和Last-Modified并排比。中间没有任何人改过内容，所以理论上它们应该完全相同。

两次观测才看得出的问题，跟测试期外部扰动是同一类，测试赢了上线却掉的那二十六天值得对照。

有ETag的77个站里，16个的ETag在几秒钟内就变了，占21.9%。对这16个站来说，条件请求这套机制从一开始就不可能生效——爬虫拿着上次的凭据来问，服务端一比对发现对不上，只能返回200和全量内容。

这件事没有任何指标会报警

值得停下来想一想这个问题的性质。这16个站：有ETag、格式合法、响应正常、页面显示一切正常。任何一个只看单次响应的检查都会给它们打勾。

没有报警不等于没有问题，最佳实践清单里九条查得到出处八条数字对不上也是靠人工核对才发现的。

问题只有在把两次响应并排放的时候才会暴露，而这个动作不在任何一份标准检查清单里。需要两次观测才能发现的问题，几乎注定会被单次观测的工具全部漏掉。

为什么两次之间要留几秒

这个间隔的选择有讲究。间隔太短，可能命中同一个缓存条目，看不出问题；间隔太长，内容真有可能变了，那就分不清是随机值作祟还是真的更新了。

观测间隔属于测量设计的一部分，埋点之前先把测量框架设计清楚讲了这类前置决定的分量。

本次用的是几秒钟的间隔，理由是：几秒内一个电商首页的实质内容变化的概率极低，而缓存层的短时命中窗口通常也在这个量级之内。如果你自己测，可以试两个不同的间隔——几秒和几分钟各一次，结果一致就更放心。

Last-Modified那两个不一致的更奇怪

ETag变了还能理解，毕竟它算的是内容。最后修改时间在几秒钟内变了，那就意味着这个站在说“这份内容刚刚又改过一次”。

数字对不上往往指向连接键的问题，五个渠道加起来一百五十九个百分点是同一种反推。

本次首页这一层抓到两个，都是往回退的——第二次请求拿到的时间比第一次更早，一个退了三个小时，一个退了四分钟。这不可能是内容真的变了，只可能是两次请求落在了不同的节点上，而这些节点各自持有不同的版本。

这一条后面还会展开，因为在内页那一轮里，同类问题出现得更极端——有一个站的两次时间相差八个多小时，同样是往回退的。

节点不一致这件事的连带影响

时间倒着走这个现象，暴露的问题比条件请求本身大得多。它说明同一个地址在同一时刻，会因为落在不同节点上而返回不同版本的内容。

同一份规则在不同处理路径上行为不同，robots规则的星号对某些爬虫无效是另一个版本。

这件事的影响面很广。对用户来说，可能刷新一下页面内容就变了；对测量来说，你做的任何A/B测试都可能被这层不一致污染；对抓取来说，系统看到的这个地址是一个不稳定的东西，而不稳定的东西通常会被更谨慎地对待。

本次能看到它，纯属条件请求这套测法的副产品——因为只有连发两次并把响应头并排比，这个问题才会露头。如果只测一次，你看到的是一个完全正常的响应。

所以这条自检的价值可能超出条件请求本身：它顺带是一次很便宜的节点一致性探测。两次请求，如果拿到的凭据在格式或者时间上有系统性差异，那你的部署八成有问题。

从ETag的形状能读出什么根因？

这是本次实测最有意思的一段。把那16个站的两次ETag并排一放，成因几乎是明写在上面的。

从结构反推含义是通用手法，用SignificantLink和RelatedLink表达页面关系里的标记也是可读的。

第一类：长度段不变，哈希段在变

有五个站的ETag长这个样子：一个W斜杠前缀，然后一段十六进制数字，一个连字符，再接一段摘要。比如某个站两次拿到的分别是96c1d开头和96c1d开头，前面那段完全一样，只有后面的摘要不同。另外四个站分别是886f1、4295d、137cee、fa604开头，情况完全一致。

自动生成的字符串里藏着大量可读信息，Shopify的一百二十八种结构化数据类型怎么挑里也有靠结构判断的例子。

这种格式是很多服务端框架的默认实现：前半段是内容的字节长度，后半段是内容的哈希。那么这五个站的情况就变成了一句可以直接下结论的话——

页面的字节数一个都没多、一个都没少，内容却算出了不同的哈希。

能同时满足这两个条件的，只有一种情况：页面里嵌了一段长度固定、内容随机的字符串。最常见的就是防跨站请求的令牌、脚本安全策略里的一次性随机数、请求追踪编号、或者某个会话标识。

这个推断为什么可以直接用

因为它把排查范围从“整个页面”缩小到了“一段定长随机值”。你不需要逐行比对两次的HTML，只要去搜那几类常见的定长随机串，基本一抓一个准。

靠外部观测就能定位根因的手法很值钱，GEO投毒的三条攻击路径与三层防御也用了同一类推理。

这是一条完全靠观察响应头就能得到的诊断结论，成本是两次请求。保哥觉得这是本次实测里性价比最高的一个发现——它不需要访问服务器、不需要看代码、不需要任何权限。

第二类：整条ETag的格式都变了

另外两个站更奇怪。其中一个的两次ETag，第一次是十四个字符的短串，第二次是三十二个字符的长串。不但值变了，连长度和格式都变了。

同一站点不同版本共存会带来一堆隐性差异，网站无障碍访问怎么做的十八个改动里提过版本一致性的重要。

同一个地址，两次请求，返回了两种不同格式的ETag，最合理的解释是这两次请求被两台配置不同的节点分别处理了。可能是不同版本的服务在灰度共存，也可能是两个机房的配置漂移了。

这一类的性质跟第一类完全不同：第一类是内容里有随机值，第二类是基础设施本身不一致。修法也不一样——前者改页面，后者查部署。

第三类：缓存键相同但摘要不同

还有九个站的ETag是这样一种结构：一个固定的前缀词，一个数字编号，一个控制器名，最后是一段三十二位的摘要。两次请求里，前面三段一模一样，只有最后那段摘要在变。

缓存键与内容标识是两件事，混用会让整套机制失效，Schema聚合的五步接入方法里也有类似的键与值分不清的坑。

从结构能看出这是某套全页缓存的实现，前面几段是缓存条目的键。缓存键相同，说明系统认为这是同一个缓存条目；摘要不同，说明它每次都重新算了一遍渲染结果的哈希。

这类实现的问题在于，哈希算的是这一次渲染出来的字节，而不是这个缓存条目的身份。一个用来标识“是不是同一份内容”的东西，被拿去标识“这一次输出的字节”，两者在有随机成分的页面上永远对不上。

三类合起来的启示

同一个现象三种成因三个负责人，商品页推荐位两套报表打架的那次复盘也是这种局面。

三种成因，三个不同的负责人，而它们在监控面板上的表现完全一样：什么表现都没有。

这套读法可以推广到别处

从一个字符串的结构反推它的生成方式，这个手法本身比这次的具体结论更值钱。

拼出来的字符串都能这么读，UTM链接构建器的规范与避坑清单里那套参数就是典型的拼装结构。

能这么读的前提是：这个字符串是机器按固定模板拼出来的，而模板的每一段各有含义。符合这个条件的东西比你想的多——缓存键、构建产物的文件名、追踪参数、订单编号、日志里的请求标识，都是拼出来的。

读法也有固定套路：先找哪一段变了、哪一段没变，再问“什么情况下会只有这一段变”。这个问题往往只有一两个可能的答案，因为每一段的含义把可能性框死了。

本次那五个站就是最干净的例子：长度段没变、哈希段变了，那么“内容长度不变但内容变了”这个约束，直接把答案锁死在定长随机值上。不需要看代码，不需要问人，两次请求就够了。

顺便说一个反面教训

这个手法有个前提容易被忘：你得先确认那个格式的含义，别自己脑补。

先确认含义再解释样本，品牌词和非品牌词那条线画在哪记录过一次因为记错含义而全盘推翻的过程。

本次一开始我把某个站的ETag前半段当成了时间戳，推出一个完全错误的结论，后来对着另外几个站的样本才发现那是十六进制的字节长度。五个站的前半段分别是五个不同的值，而它们的页面大小也确实各不相同——这才是能确认含义的证据。

所以正确的顺序是：先收集足够多的同格式样本，用样本之间的差异去确认每一段的含义，再拿这个含义去解释单个样本。反过来做，你会得到一个自洽但错误的故事。

第三关：真发条件请求，回不回304？

前两关都是看响应头，这一关是真的把凭据带上重发一次。

做了一半的投入最容易被忽略，共识层六信号的九十天实战指南里也点过这类半成品。

拿ETag去问

对77个有ETag的站，带上If-None-Match重发一次，结果是这样：

逐项验证比一次性判断可靠，集合页分页的索引判断与canonical设置也是一项一项过的。

三成二的站，发了凭据却不认自己发的凭据。这个数字比前面两关都更让人意外——它们已经完成了最难的那一步，只差最后一步没做。

需要说明一下这个测法的一个边界：本次是把第一次拿到的ETag原样带回去问的。如果一个站的ETag本身就不稳定，也就是第二关没过，那它在这一关必然也过不了，两关的失败在统计上有重叠。所以第三关那25个里，有一部分其实是第二关的问题在这里再次显形。

把两关分开看仍然有意义，因为修法完全不同：第二关的问题在页面内容或者节点配置上，第三关的问题在比对逻辑上。但引用这两个数字的时候别把它们简单相加，那会把同一批站算两次。

这也是本系列反复出现的一条提醒：任何一个漏斗，都要先问相邻两级之间是不是独立的。不独立的话，累加、相乘、算转化率这些操作全都会失真，而失真的方向通常是把问题放大。

拿时间去问

对18个有Last-Modified的站，带上If-Modified-Since重发，14个返回304，占77.8%。成功率比ETag那条路还高。

精确的机制未必更稳，微软广告改UTM自动打标之后的归因影响里有类似的反直觉结果。

这个对比有点反直觉。ETag理论上更精确、更可靠，实际成功率却更低。原因在于精确本身就是负担：ETag要求内容一个字节都不能变，而时间戳只要求秒级不变。页面里那段随机令牌会毁掉ETag，却毁不掉Last-Modified。

不过这个对比要小心解读：Last-Modified的样本只有18个，而ETag有77个。十八个里成功十四个，跟七十七个里成功四十八个，前者的置信度低得多。这一条应该当成一个值得注意的方向，而不是一个可以直接引用的比例。

为什么样本这么不平衡，本身也说明了一件事：愿意给时间戳的站少得多，因为动态页面的框架往往不知道该填什么。而那些愿意填的，通常是真的想清楚了内容的更新时间从哪来——这批站本来就更用心，成功率高一点也在情理之中。

这是一个典型的选择偏差：不是这条路更好走，是走这条路的人本来就更强。看到两个成功率的时候，要先问一句“这两组样本是怎么进来的”，而不是直接比大小。

类似的陷阱在SEO数据里到处都是。比如“配了某项标记的站排名更好”，很可能只是因为愿意配那项标记的团队本来就更专业。相关不等于因果这句话人人会背，难的是每次看到数字的时候真的停下来问一句。

再补一个额外测的场景

顺手还测了一种情况：不管这个站给不给凭据，一律带上一个“一小时前”的时间去问。这相当于在说“我手上有一份一小时前的副本，还能用吗”。

多设计一个场景往往能挖出新结论，GEO到底怎么落地的实施策略里有几组类似的场景设计。

结果是142个站里只有10个返回304，占7.0%。这个数字低得符合预期——绝大多数站在这种情况下不敢说“还能用”，因为它们根本不知道自己一小时前是什么样。

这个测法的价值在于它模拟了一种真实场景：客户端手上的副本不是刚拿到的，而是放了一阵子的。能在这种情况下答得上来的站，说明它真的记录了内容的更新时间，而不只是把当前时间填了上去。那10个站，是这批样本里这件事做得最扎实的一批。

合起来看

把两条路合并，只要有任意一种条件请求能返回304就算通过：142个站里52个，36.6%。

把这个数字拆开看更清楚：四成的站没凭据，两成有凭据但凭据不稳或者不认，剩下三成六才是真正做到了。三道关卡，每一关都刷掉一批。

这个漏斗的形状值得看一眼

漏斗形状比单个数字更有信息量，砍掉虚荣指标只盯真信号讲了怎么读这类结构。

这个漏斗有个不太常见的特点：三关的流失率相当平均，没有哪一关是绝对的瓶颈。四成、两成、一成多，一路刷下来。

大多数漏斗不是这样的，通常有一个明显的卡点，你集中解决它就能大幅提升。而这个漏斗告诉你，这件事没有捷径，三个环节各有各的成因、各归各的负责人，得一关一关过。

好消息是每一关的修复成本都不高，坏消息是你得把三关都过一遍才有结果。只做第一关，也就是开个开关生成凭据，结果可能是从没凭据变成有凭据但不被认，通过率一点没涨。

这一点在实践中很容易踩到，因为“开启ETag”是搜索这个问题最容易搜到的答案，而且做完之后你去看响应头，确实多了一行，看起来像是成功了。只有真的带着凭据重发一次，才知道有没有用。

所以自检的顺序很重要：先测终点，再往回找卡在哪一关。直接发一次条件请求，回304就全通过了，什么都不用改；不回304，再往回查是没凭据、凭据不稳、还是没做比对。这个顺序能省掉大量无谓的排查。

那52个通过的站有共同点吗

翻了一遍这份名单，最明显的共同点不是品类，也不是体量，而是它们跑在哪套基础设施上。几类现代托管平台的站几乎全数通过，而某些传统加速服务上的站通过率明显偏低。

早期的技术选型会一路影响到很多年后，建一个大站还是多个小站的取舍里算的也是这类长期账。

这个观察跟后面那一节会讲的服务器分布是一致的，而且它有个不太舒服的含义：这批站里的多数，大概率并不知道自己做到了。它们通过，是因为服务商默认就这么做；那些没通过的，也是因为服务商默认不这么做。

换句话说，这条建议在实践中的落实情况，跟“有没有人读过那份文档”关系不大，跟“选了谁家的服务”关系很大。这正是亲自型规则最讽刺的地方——一件完全由你决定的事，实际上被你多年前的一次选型决定了。

这三成六该怎么解读

先说清楚它不是什么。它不是“三成六的站做得好、六成四做得差”，因为其中有一批是主动选择不参与的，那是业务决定，不是技术缺陷。

没人考核的事最容易一直不做，把品牌当权重的四大战略里也讲过这类长期没人认领的投入。

更准确的读法是：在一条Google明确写进官方文档的建议上，能被外部验证做到的，只有三分之一出头。而这条建议既不涉及内容决策、也不涉及跨部门协调、更没有任何反向风险。

这个对比才是真正值得琢磨的：一件几乎没有阻力的事，落实率也只有三成六。阻力不在难度上，在可见性上——没人查、没人报警、没人考核，于是它就一直没被排进任何一个人的待办里。

本次三篇文章量的三样东西，落实率分别是六成五、两成二、三成六，形态各异，但成因高度一致。它们全都属于那种“不做也不会有人发现”的事。

省下来的量有多大

那52个能回304的站，全量响应平均是798.6 KB，而304响应的响应体是零字节。省掉的是接近百分之百的传输量。

带宽与计算的账要分开算才知道优化落在哪一侧，网址用扁平还是层级在SEO上到底差在哪也是一笔要拆开算的账。

当然这是单次的账。实际能省多少，取决于爬虫来的频率和你内容的变更频率。内容越稳定、被抓得越勤，省得越多；一个每天都在变的页面，这条机制本来也帮不上什么忙。

那25个不认自己凭据的站最值得说

三成二这个比例，是本次实测里最出乎意料的一个数字。这些站已经跨过了最难的一关——它们生成了ETag，说明服务器或者框架已经算过内容的哈希了。

付出成本却没拿到收益是最亏的一档，阿里国际站五百九十万页面被清零的复盘也是这种结局。

差的只是最后一步：收到If-None-Match之后，把它跟当前算出来的ETag比一下，相同就返回304。这一步在多数实现里就是几行代码或者一个配置项。

为什么会差这一步？最常见的两种情况：一是ETag由某个中间层生成，而处理请求的应用层根本不知道有这回事，也就不会去比对；二是应用层为了避免缓存问题，主动把请求里的条件头剥掉了，比对逻辑收到的是一个空值，自然永远不成立。

无论哪种，特征都是一样的：这个站在这件事上花了成本，却一分收益都没拿到。而它自己完全不知道。

那4个返回跳转的又是另一回事

还有4个站，带上条件请求之后返回了301。这说明这几个地址在带条件头的情况下走了不同的路由分支——正常请求直接返回内容，带了条件头就变成跳转。

跳转链是抓取预算里另一条明确被点名的浪费，多域名301跳转到主域名的完整配置实战里有正确写法。

这种行为本身不算错，但它很怪，因为跳转目标通常还是同一个地址。更可能的解释是某个安全或者防护层把带有不常见请求头的请求当成了可疑流量，先跳一次再说。

这一类的影响是双重的：既拿不到304，还多了一跳。而抓取预算那份文档里，恰好有另一条建议是“避免重定向链”。一条建议没做到，顺带把另一条也违反了。

首页骗了你

做到这里我本来打算收工，直到想起一件事：Googlebot每天抓的绝大多数请求不是首页，是内页。于是又跑了一轮。

首页在很多维度上都是最不具代表性的一页，首页首屏的导航主Banner到分类区怎么设计讲了它的特殊性。

换一批地址重测

从这些站自己的站点地图里，每站挑一个有一定深度的具体页面，重复完全相同的七次请求。最后拿到90个可测目标，其中89个返回200。

换一批地址结论可能完全不同，一万个电商站的网址结构实测结论也是靠大样本才站得住。

差了将近一倍

同一批站，首页只有36.6% 能回304，内页有65.2%，差1.8倍。而ETag不稳定这个问题几乎只在首页出现：首页两成二，内页不到百分之五。

不同页面类型的表现差异往往被平均值掩盖，信息词流量过大的六大危害与破局是同一类分层问题。

成因不难想。首页是全站个性化程度最高的一页：推荐位、促销条、地区提示、购物车数量、A/B分桶、会话令牌，全都挤在这一屏。每一样都会让这一次输出的字节跟上一次不同。而一个具体的商品页或者文章页，内容天然稳定得多。

还有一层原因是缓存策略的差别。首页往往被单独配置成不缓存或者短缓存，因为它承载的信息最杂、出错代价最高；而内页通常走通用规则，缓存策略更宽松，凭据也就更容易被生成和保留。首页的谨慎是有道理的，只是这份谨慎顺带把这条省钱的路也关掉了。

这个差别对怎么排查有直接影响

如果你只测了首页、发现结果很差，正确的下一步不是大动干戈改首页，而是先去测几个内页，看看差距有多大。

本次数据里这个差距是1.8倍。如果你的站也是这个量级，那么结论就很清楚：首页那一层可能确实改不动（个性化是业务需要），但内页那一层大概率只差一个开关或者一段比对逻辑。

反过来，如果你测下来首页和内页一样差，那说明问题出在更底层——大概率是整站的服务器或者加速层配置，而不是首页的个性化。同一个测法，跑两类页面，就能把问题定位到不同的层。

为什么内页样本只有90个

首页那一轮有211个域名，内页这一轮只挑出90个可测目标，差距不小，值得交代一下。

站点地图的可达性直接决定了很多流程能不能跑通，怎么实时推送搜索引擎的三种做法也依赖同一份地址清单。

原因是内页地址来自各站自己的站点地图，而不是所有站都能顺利拿到。有些站的站点地图入口找不到，有些是索引文件套索引文件、展开层数不够，还有些返回的是压缩格式或者需要特定请求头。能拿到一个可用内页地址的，就这90个。

这个筛选是有偏的：站点地图规整、可公开访问的站，技术执行力大概率更强。所以内页那一轮65.2% 的通过率，很可能是高估。真实的全样本内页通过率应该低于这个数，但仍然会明显高于首页——因为首页与内页的差别是结构性的，不会被这个偏差抹平。

把两个方向的偏差都说清楚之后，能站得住的结论就只剩一条：首页和内页有系统性差异，测的时候必须分开。至于具体差多少，本次给出的1.8倍只能当参考量级，不能当精确数字。

顺带说说怎么挑内页样本

本次是从每个站自己的站点地图里，取中间位置的一个地址。为什么取中间不取第一个？因为站点地图的开头往往是首页、分类页这类特殊页面，取中间更容易拿到一个普通的内容页。

抽样方式决定了你测到的是哪一类页面，七步GEO实战的写作流程里也强调过样本选择。

这个细节看着琐碎，但它决定了你测的到底是不是有代表性的那一类页面。如果全取第一个，测出来的可能又是一批个性化重的页面，那这一轮对照就白做了。

这条对照给出的实操结论

第一，别拿首页去判断你的站支不支持条件请求。首页是全站最不具代表性的一页，用它测出来的结论会系统性地低估你。

抓的和看的往往不是同一部分，那几张没露出来的商品图说明了这个错位。

第二，反过来也一样，只测内页会高估你。正确的做法是两边都测，然后分开看：首页那一类页面本来就难做，内页那一类才是能真正省下量的地方。

第三，如果你只有精力修一边，修内页。因为内页数量多、被抓的总次数远超首页，而且它们本来就快做到了，往往只差最后一步。

这个对照也改变了整篇文章的结论

如果只跑首页那一轮，本文的结论会是“三成六，做得很差”。加上内页那一轮之后，结论变成了“首页三成六、内页六成五，问题集中在个性化最重的那一层”。

分母怎么选决定了结论的方向，流量下降不等于SEO失败的八维度实战里有一套换分母的思路。

后一句比前一句有用得多，因为它指向了原因，也指向了动作。而这个差别，完全来自于多跑了一轮不同类型的地址。

这也是本次三篇实测里反复出现的一条方法：任何一个比例，都要问一句“这个分母是怎么选的”。换一个分母，同一批站的表现可以差出接近一倍。

内页那一轮的另外两个发现

顺带记两个数。第一，内页的Last-Modified覆盖率反而更低，只有6.7%，比首页的12.7% 少一半。这说明动态生成的内容页更不知道该怎么填这个时间，索性不填。

内容页这一层往往比首页更容易做对，Shopify图片SEO从命名到压缩的完整清单里的动作也是这样。

第二，内页里两次ETag不一致的只剩3个，而且成因跟首页那批不同——其中两个是整条格式都变了，属于节点不一致，不是页面里有随机值。换句话说，内页那一层几乎没有随机值污染的问题，剩下的都是基础设施问题。

这两条合起来给出的判断是：内页这一层，只要把比对逻辑补上，通过率很容易再往上抬一截。它的障碍是配置层面的，不是内容层面的。

那个最后修改时间，填的到底是什么？

ETag那边讲完了，回过头来看时间戳这条路。它出问题的方式完全不同，但同样隐蔽。

站点地图里那个更新时间理论上该和响应头里的是同一个值，免插件sitemap的动态优先级与分页策略讲了那个字段怎么生成。

两次请求，时间倒着走

本次抓到几个很有意思的样本。有一个站的首页，第一次请求返回的最后修改时间是当天下午两点多，第二次请求返回的却是当天上午十一点多——晚发的那次请求，拿到了一个更早的时间。

时间口径出问题会污染一整套数据，GA4默认追踪不到GEO流量的补法是另一个时间维度的坑。

另一个站的内页更夸张，两次相差八个多小时，同样是往回退的。还有几个站的两次时间相差几秒到几十秒，方向是往前走的。

两种成因

时间往回退，说明两次请求被不同的节点处理了，而这些节点各自持有不同版本的内容或者不同的时钟。这跟前面ETag格式变化那一类是同一个根因：基础设施不一致。

同一个现象要分清是内容问题还是基础设施问题，类目导航改版三轮之后仍然没写清楚用户在哪是模板层的例子。

时间往前走几秒，成因完全不同：这个站把Last-Modified写成了当前时间。也就是说，它每次响应都在说“这份内容刚刚才改过”。

后一种的后果是致命的：如果最后修改时间永远是现在，那么任何一个If-Modified-Since都不可能通过，因为客户端手上那个时间永远比“现在”早。这个站永远不会返回304，无论爬虫问多少次。

怎么一眼看出自己有没有踩这个坑

方法只有一个，也很简单：请求你的页面，看返回的最后修改时间是不是接近当前时刻。如果是，那它写的是生成时间不是修改时间，这条路是断的。

一眼能看出来的自查最容易被坚持，结构化数据怎么配合SEO落地的完整指南里也有几条这样的检查。

正确的值应该是内容真正被编辑的那个时刻——文章的最后更新时间、商品信息的最后变更时间。对静态文件来说就是文件的修改时间，服务器会自动填对；对动态页面来说，得你自己从数据里取。

顺带提醒一个容易被忽略的关联：这个时间跟站点地图里那个更新时间字段，理论上应该是同一个值。抓取预算那份文档里另有一条建议是保持站点地图更新并用好那个字段，两条建议其实指向同一份数据。

实际情况往往是两边各填各的：站点地图那边由某个插件按发布时间生成，响应头这边由服务器按文件时间生成，两个值对不上。对不上的后果是系统收到两个互相矛盾的信号，只能自己挑一个信。能对上的话，两条建议一次就都满足了。

这也是为什么动态站的Last-Modified覆盖率只有12.7%——大多数框架不知道该填什么，索性就不填了。不填至少是诚实的，填一个当前时间才是最坏的选择。

动态页面该从哪取这个时间

取值的原则是：取这个页面所依赖的所有数据里，最晚被更新的那一个时刻。

商品页依赖的数据源比想象中多，电商产品评论的结构化与GEO联动列过其中几类。

对一篇文章页，就是文章记录的更新时间。对一个商品页，要考虑的更多：商品信息、价格、库存状态、评价数量，任何一项变了这个页面的内容就变了。取它们里面最晚的那个。

对一个分类页就更复杂：它依赖的是一批商品，其中任何一个变了都算。这时候要么取这一批里最晚的更新时间，要么干脆放弃这条路，只走ETag。

这里有个很实用的取舍：如果算这个时间的成本接近于渲染整个页面，那就别算了。这条建议的目的是省资源，为了省资源反而多花一倍计算，那就本末倒置了。

一个折中办法

有个成本很低的中间方案，值得一提：给不同类型的页面定不同的粒度。

商品数据的粒度选择直接影响维护成本，跨境电商GTIN怎么申请与收录里有类似的取舍。

文章、帮助文档、政策页这类内容，更新时间是现成的，直接用。商品页取商品记录的更新时间，忽略库存这类高频变动——代价是库存变了但时间没变，客户端可能拿到旧的库存显示；如果你的库存本来就是前端异步拉的，这个代价等于零。

分类页、搜索结果页这类聚合内容，干脆不给Last-Modified，只给ETag，或者两个都不给。不是每一类页面都值得为这件事花力气，挑那些量大又稳定的做就行。

说了别缓存，又给了凭据

还有一档自相矛盾的配置值得单独说，因为它反映的是一种很典型的配置方式。

说一套做一套的地方最容易长期没人管，页脚不是杂物抽屉该怎么设计也是一个长期没人认领的区域。

35个站里有6个前后不一致

142个站里，Cache-Control中写了no-store的有35个。no-store的含义非常强硬：任何缓存都不得存储这份内容的任何部分。

两层配置各说各的是很常见的故障形态，一键退订必须写两层少一层就限流是另一个双层不一致的例子。

可是这35个站里有6个，同时还给出了ETag或者Last-Modified。一边说别存，一边给一张用来判断存着的那份还能不能用的凭据。这两句话在逻辑上是互斥的。

这种矛盾是怎么来的

几乎可以肯定不是有人这么设计的，而是两层配置叠加的结果：应用层出于安全考虑加了no-store，而Web服务器或者CDN那一层默认会给静态化的响应自动生成ETag。两边各自都对，合起来就矛盾了。

每一层单独看都对，合起来才出事，AI内容披露里那份不做什么的清单也强调了整体核对。

这类问题在多层架构里非常常见，而且往往没人发现，因为每一层单独看都符合自己的规范。只有把最终那个响应头完整打印出来通读一遍，矛盾才会显形。

矛盾的实际后果是什么

说实话，后果不算严重。规范里no-store的优先级更高，合规的客户端会遵守它，那张凭据只是被忽略了而已。

矛盾信号会让系统对你整体降低把握，实体SEO的五阶段构建方法解释了这套信心机制。

但它有两个间接代价。第一，生成ETag是有成本的——服务端算了一遍哈希，而这个哈希不会被任何人用到。纯浪费，虽然不多。第二，也是更重要的：这个矛盾是一个信号，说明这个站的响应头是几层配置叠出来的，没人通读过最终结果。

而没人通读过最终结果，通常意味着别的地方也有类似的问题——多余的头、互相冲突的指令、过期的策略。这跟上一篇里那个把sizes当探针用的思路是一样的：找那些错了也没人管的地方，它们最诚实。

怎么快速看一眼自己的响应头

方法很土：从公网请求一次你的页面，把完整的响应头打印出来，从头到尾读一遍。不是查某一个字段，是通读。

通读比单查更容易发现叠加出来的矛盾，robots.txt的虚拟与物理优先级怎么排也是一个多层叠加的例子。

通读的时候问三个问题：有没有互相矛盾的两条、有没有明显是某一层自动加上而你并不需要的、有没有该有却没有的。本次实测里的绝大多数问题，都能在这三个问题下暴露出来。

这件事一年做一次就够，前提是这一年里没换过基础设施。它的价值不在于每次都能查出问题，而在于它是唯一能看到多层叠加最终结果的方法。

顺带一个更普遍的数字

142个站里，有70个压根没有Cache-Control这个响应头。接近一半。

默认状态往往就是最终状态，自建站谷歌SEO开发期的十大优化要点里列了要主动设定的项。

没有这个头不等于不能缓存，规范里有一套默认的启发式规则，但那意味着缓存行为由各个客户端自己猜。对一个电商站来说，把缓存策略交给别人猜，不是一个好的默认状态。

各条指令的实际使用分布

把142个站的Cache-Control拆成一个个指令统计，出现频次最高的几个依次是：带具体秒数的最大存活时长、必须重新验证、不要直接使用缓存副本、不要存储、公开可缓存、私有。

保守策略在结账链路上尤其常见，结账流程改了很多轮用户回头改一次地址就全丢是同一种谨慎的代价。

值得注意的是不要直接使用缓存副本和不要存储这两条加起来的覆盖面相当大，说明相当一批电商站在首页这一层选择了保守策略。这可以理解——首页往往带着购物车状态和个性化推荐，存错一份就是事故。

但保守策略也有分寸。不要直接使用缓存副本这一条，意思是每次使用前都要向服务端确认一遍，它恰恰是最需要条件请求配合的一档：既然每次都要确认，那就该给一张能用来确认的凭据。而本次数据里，这一档里也有相当一部分什么凭据都没给。

这两条指令经常被混用

顺带澄清一个高频误解：不要存储和不要直接使用缓存副本，字面看着像，含义差得很远。

相似的配置项含义差很远，付款回来购物车就空了那两分钟宽限也是一次配置含义的误解。

前者是彻底禁止任何环节留存这份内容，用于真正敏感的页面。后者允许留存，只是每次用之前必须向服务端确认一次。后者是条件请求最理想的搭档，前者则是把这条路完全关掉。

很多站把这两条一起写上，有时候还加上一个最大存活时长为零。这样写不算错，但它表达的是最保守的那一档，也就是不要存储那一档。如果你的本意只是想每次确认一下，那就别写不要存储，你把自己的路堵死了。

爬虫换一种方法问，你的站答得上来吗？

条件请求之外，还有一层很少被提起的东西：Google的爬虫并不只发普通的取内容请求。

换一种方法问答案可能完全不同，AI推荐机制与GEO实战策略里那组对照也是靠换问法问出来的。

官方确认过的方法清单

Google的工程师提到过，他们的爬虫会发出多种HTTP方法的请求，除了最常见的取内容之外，还包括只要响应头不要内容的那种、询问一个地址支持哪些方法的那种，甚至还有写入类的方法。这份方法清单的完整讨论当时引起过不少关注，因为大多数人从没想过爬虫会发这些。

爬虫的种类和行为都在变，Google-Agent是什么以及怎么识别和应对是另一条值得跟的变化。

既然爬虫会发，那就值得测一测你的站答不答得上来。

只要响应头的那种请求

对142个站各发一次，123个返回200，占86.6%。但其中94个没有返回内容长度。

这就有点尴尬了。这类请求的全部意义就在于用极小的代价拿到关于这份内容的元信息，而内容长度恰恰是最有价值的那一项——不给长度，等于把这种请求的主要收益去掉了一大半。

没返回200的那19个里，情况五花八门：有跳转的、有直接连不上的、有返回未找到的、还有两个返回了一个表示“继续等待”的中间状态码。同一个地址，用普通方式请求好好的，换一种方式就出岔子。

其中最值得注意的是那个返回未找到的站：用普通方式请求首页返回200，用只要响应头的方式请求同一个地址返回未找到。两种方式按规范应该返回完全相同的头，包括状态码。返回不同的状态码，说明这两条路径走的不是同一套逻辑。

还有几个返回跳转的，情况类似——普通请求直接给内容，换个方法就先跳一次。这类不一致对爬虫的影响是：它拿到的元信息可能跟真实内容对不上，于是它只能放弃这条省事的路，改回全量请求。

为什么不给内容长度是个问题

94个站不给内容长度，这件事需要辩护一句：如果响应是分块传输的，规范上确实可以不给这个头，这在动态生成的页面上很常见，不算违规。

知道内容多大是很多抓取决策的前提，让内容被主动引用的五个维度里也强调过让机器省力这件事。

但站在使用者的角度，结果是一样的：你发这个请求，本来是想用最小代价知道这份内容有多大、什么时候改的、标识符是什么；拿回来一个没有大小的响应头，收益就少了一块。

要不要为此专门改造，取决于你的场景。对绝大多数电商站来说，这一项优先级很低。本文把它量出来，主要是给“爬虫会发多种方法”这个说法配一个真实的分布，而不是让你去改配置。

询问支持哪些方法的那种请求

这一项的结果最难看。142个站的返回分布是：找不到的57个、跳转的41个、方法不允许的9个、正常返回的6个，剩下是各种其它状态。

量出真实分布比照着传言改配置有用，文章标题怎么写才有人点的十个技巧里那些公式也都配了实际数据。

而按规范应该在响应里列出支持方法清单的，只有5个站。这5个给出的清单也都很朴素，基本就是取内容和取响应头两种，个别加了提交表单那一种。

这一项要不要修，答案是通常不用。它对SEO几乎没有直接影响，本文把它量出来，是为了给“爬虫会发多种方法”这个说法配一个真实的分布。知道你的站在这一项上是什么表现，比盲目照着传言去改配置有用。

不过有一个细节值得留意：返回“方法不允许”的那9个站，其实是最规范的一档。它明确告诉对方“这个方法我不支持”，而不是含糊地返回一个找不到或者跳走。规范上，返回这个状态码的时候还应该附上支持的方法清单，而那5个给出清单的站基本都属于这一档。

那些写入类的方法要不要管

官方提到的方法清单里还包括几个写入类的方法。这一项本次没有测，理由很直白：对别人的站发写入类请求是一件不合适的事，哪怕只是探测。

不需要的方法就明确拒绝，这是基本的安全卫生，品牌被仿冒抢排名的五步应对实战里也有一批同样属于卫生级别的动作。

但可以给一条常识性的建议：如果你的站不需要接受这类请求，就在服务器或者网关层明确拒绝它们。这不是为了SEO，是基本的安全卫生——一个默认接受各种方法的服务端，暴露面比必要的大。

拒绝的时候记得返回“方法不允许”并附上支持的方法清单，而不是静默丢弃或者返回一个假的成功。诚实的拒绝比含糊的沉默好，这一条在本文里已经出现第三次了。

按服务器类型看这三关的通过率

把142个站按响应头里的服务器标识分组，条件请求的通过率差异非常明显：有几类现代托管平台的通过率在八成以上，有一类知名的加速服务通过率不到四成，还有一类是零。

托管选择带来的连带影响比想象中多，外贸独立站用国内主机还是国外主机里有一份对比。

这个差异说明一件事：你的通过率很大程度上不是你决定的，是你选的那套基础设施的默认行为决定的。好消息是，这也意味着修起来往往就是一个开关；坏消息是，如果你的服务商默认不做，你多半根本不知道。

基础设施决定默认值这件事的普遍性

这已经是这三篇实测里第三次撞到同一个现象了。上一篇量图标的时候，兜底路径能不能取到图，几乎完全由“是传统服务器直接托管静态文件还是前端框架接管路由”决定；再上一篇量名字的时候，多店铺场景下名字会不会分叉，由平台的店铺配置结构决定。

不同主机档位的默认行为差别很大，共享主机VPS还是独享该怎么算这笔速度账逐档比过。

这三件事的共同点是：团队从来没做过决定，最终结果是服务商替他们做的。而服务商的默认值是按通用场景定的，不是按你的场景定的。

这条观察有一个很实用的推论：当你接手一个新站、想快速判断它的技术底子的时候，与其看它做了什么，不如看它的默认值有没有被动过。有人调整过默认值，说明有人真的看过这一层；一切都是出厂设置，说明这一层从来没进过任何人的视野。

换服务商的时候尤其要重测

顺着这条往下推：既然通过率主要由基础设施决定，那么任何一次基础设施变更，都可能悄无声息地把这件事改掉。

迁移之后要重验的项目比清单上写的多，换域名之后后台跳转登不上的三种改法记录过一次迁移事故。

换CDN、换托管平台、在前面加一层防护、把静态资源迁到对象存储——这些动作的验收清单里，通常只有“页面能打开吗、速度快不快、证书对不对”。没人会去发一次条件请求。

建议是把这一条加进迁移检查表，成本是两次请求。它跟前两篇加的那两条检查项一样，都属于“加一行、几十秒、可能省掉几年的静默损耗”那一类。

三条检查项凑成一份迁移清单

这个系列做下来，正好攒了三条可以直接加进迁移检查表的项目，都属于工具查不到、出问题不报警、修起来很便宜那一类。

清单化是对抗没人认领的唯一办法，论坛和问答结构化数据怎么做里那套字段同样需要一份清单去维护。

三条加起来五分钟，覆盖的是三类完全不同的失败。共同点是它们都不会让页面显示出问题，所以标准的上线验收永远抓不到。

把它们写进迁移和发版清单，是这个系列最实际的产出。不是因为这三件事本身多重要，而是因为清单是唯一能对抗“没人认领”的机制。一件事只要没被写进任何一份清单，它就只能靠某个人碰巧想起来，而人是会离职的。

这三条也可以直接给外包团队或者服务商用。它们的判据完全客观，不需要解释上下文，验收的时候一看就知道过没过。这类可验收的条目，比一堆写着“优化性能”“完善结构化数据”的模糊要求管用得多。

保哥这些年给客户写技术需求，越来越倾向于这种写法：每一条都能在五分钟内被独立验证，而且验证方式写在需求里。做不到这一点的条目，最后八成会变成一场关于“到底算不算做完了”的扯皮。

这三条恰好都符合。第一条比对几个字段是否相同，第二条看几个地址返回的是不是图片，第三条看带凭据重发回不回304。没有一条需要解释、需要判断、需要讨论。

自检和修复一共几步？

亲自型规则的落地方式很直接：没人会告诉你结果，所以你得自己建立一次观测。

把动作写成可照做的顺序比讲道理有用，PAS公式在SEO内容写作中的进阶用法也是同一种编排思路。

三分钟的自检

第一步，请求你的一个典型内页，把完整响应头打印出来，看有没有ETag或者Last-Modified。一个都没有，这条路就是断的，跳到修复第一步。

自检之后要不要上工具，二十款GEO与AEO监控工具的评测与选型可以按预算挑。

第二步，再请求一次同一个地址，把两次的凭据并排比。不一样的话，看是长度段变了还是只有哈希段变了——只有哈希段变，说明页面里有定长随机值；整条格式都变，说明你的节点配置不一致。

第三步，带上第一步拿到的凭据重发一次，看返回的是不是304。是就通过了，不是就说明服务端没有做比对逻辑。

第四步，看Last-Modified的值是不是接近当前时刻。是的话，说明它写的是生成时间，这条路等于没有。

这四步全部只需要一个能发请求并打印响应头的工具，不需要登录服务器、不需要看代码、不需要任何权限。你甚至可以拿它去测竞争对手的站——本次这批数据就是这么来的。

测竞争对手这件事顺带说两句

这套方法最有意思的一点是它完全对外可用。你能测自己的站，就能测同行的站，而且拿到的是同样精度的数据。

同行对标要挑能从外部测准的指标，品牌权威度与域名权重的区别和提升方法讨论过这类指标的可得性。

这在SEO里不常见。绝大多数技术指标要么需要后台权限，要么只能看到很粗的外部近似值。而条件请求这件事，从外面看到的和从里面看到的是同一份事实。

实用价值在哪？如果你要说服团队做这件事，一份“同行里有多少家做到了、我们排在哪一档”的数据，比任何理论都好使。本次那52个做到的站里，有不少是各自品类里的头部品牌，这个名单本身就是论据。

顺带能测出来的其它东西

同样是这几次请求，还能顺带看到不少别的信息：对方用的是哪套加速服务、页面的真实体积有多大、缓存策略保守还是激进、有没有节点不一致的迹象。

同行数据是说服团队最省力的论据，SEO汇报怎么让不同部门看到同一份事实里有现成的表达方式。

这些信息在做技术选型的时候相当有参考价值。比如你在几个托管平台之间犹豫，与其看它们的宣传页，不如去测几个跑在上面的真实站点，看默认行为长什么样。本次数据里不同服务商之间的通过率差异，从零到百分之百都有。

当然要克制。几次请求是正常访问，成千上万次就是另一回事了。做同行对标的时候，挑十几个代表性的站、每个站测一遍，足够得出结论了。

这套自检有一个前提

一定要从公网发这几次请求，不要在内网或者本机测。原因是你的响应头是好几层叠出来的：应用层、Web服务器层、加速服务层，每一层都可能加东西、改东西、删东西。

观测点放在哪决定了你看到什么，用正则从GSC里挖AI搜索提问的五步实战也是换了观测点才挖出东西。

从内网测，你看到的是某一层的输出；从公网测，你看到的才是爬虫真正收到的那份。本次那6个自相矛盾的配置，全部只有在最终响应里才看得出来——单看应用层，它写的是不要存储，完全正确；单看服务器层，它自动生成了凭据，也完全正确。

这条原则可以扩展到所有的技术SEO排查：凡是要判断“搜索引擎看到了什么”，观测点就必须放在跟它一样的位置上。这也是本文所有数据都从公网单点发起的原因。

四种失败对应四种修法

把问题分类再排期，比一股脑全改高效，新网站SEO目标管理的三个里程碑有拆解方法。

每一类的实际改动长什么样

把四种修法再落细一点，免得看完还是不知道该跟谁说什么。

配置层的一个开关有时候比一堆内容动作更管用，GitHub Pages寄生SEO的借力实战也是靠现成能力省力气。

没有凭据这一类，去看你的Web服务器或者加速服务的配置文档，搜“实体标签”或者“自动生成校验”，绝大多数都有一个开关。开完之后立刻发一次请求确认响应头里真的多了那一行——有些服务只对静态资源生效，对动态响应不生效，光看配置看不出来。

凭据不稳这一类，先按前面那套读法判断是哪一种形状。如果是长度段不变哈希段变，去页面里找定长随机串；如果是整条格式都变，那是运维的活，跟部署一致性有关，跟页面没关系。

有凭据但不回304这一类，通常是在应用层或者网关层加一段比对：拿到请求里的条件头，跟当前算出来的凭据比，相同就返回304和一个空响应体。记得304响应里要带上凭据本身，否则客户端下一轮就不知道拿什么来问了。

时间戳填错这一类，得先确认你能不能取到内容的真实更新时间。取得到就换上；取不到，宁可不给这个头，也别给一个当前时间。这是唯一一个“不做比做错更好”的选项。

先修哪一类

按性价比排：先修“有凭据但不回304”那一类，因为它离终点最近，往往就差一段比对逻辑。再修“一个凭据都没有”那一类，因为它多半是个开关。最后才是“凭据不稳”，因为它要动页面内容，牵扯最多。

先修离终点最近的那一档，用Performance Max给零流量商品再来一次机会也是同样的优先级逻辑。

如果你的站声明了no-store且确实需要，那这套机制对首页就不适用，直接跳过，把力气放在内页上。本次数据已经说明，内页本来就是这条建议真正能省下量的地方。

修完之后怎么验收

验收方式跟自检完全一样，只是多一步：不只验你改的那个页面，验每一类页面各一个。商品页、分类页、文章页、帮助页，各挑一个跑一遍。

验收要覆盖每一类对象，五大策略让AI搜索主动推荐品牌里的落地检查也是分类做的。

为什么要分类型？因为这几类页面的数据来源、缓存策略、渲染路径往往完全不同，改好了商品页不代表分类页也好了。本次实测里首页和内页差1.8倍，就是最直接的证据。

还有一件事要验：改完之后确认内容真的变了的时候会返回200。只验304不验200，有可能改出一个永远返回304的实现，那比不做还糟——用户和爬虫都会一直看到旧内容。这个验法很简单：改一下页面内容，立刻再请求一次，看是不是200。

把它挂进哪个流程

建议挂进两个地方。一个是发布流程，每次发版之后跑一遍，成本是几秒钟。这条最重要，因为本次实测里那些节点配置不一致的问题，几乎肯定是某次发布带出来的。

把检查挂进既有流程比新建流程容易，大促与日常SEO的八维度差异与时间轴里有排期的做法。

另一个是基础设施变更流程：换CDN、加防护层、迁移托管平台的时候各跑一遍。这一条的必要性前面已经说过了——通过率主要由基础设施的默认行为决定，而默认行为会随着你换服务商而整个改变。

不建议挂成定时监控。这件事的状态很稳定，除非有人动了配置，否则它不会自己变；为一件不会自己变的事建一个每天跑的监控，只会制造噪声。

三个反直觉的判断

第一，做得最差的一关不是完全没做的那一关。四成的站没凭据，这不奇怪；奇怪的是有凭据的77个站里还有25个不认自己发的凭据——它们付出了成本却没拿到收益。

反直觉的结论往往藏在没人量的地方，被低估的九个反直觉UI设计杠杆是另一组同类观察。

第二，更精确的机制在真实环境里成功率更低。ETag比时间戳精确得多，实测成功率却低了十五个百分点，因为精确意味着更容易被一段随机字符串毁掉。

第三，这一整篇文章讲的所有问题，没有一个会触发任何报警。没有报错、没有报表、没有邮件，页面在浏览器里一切正常。这正是亲自型规则的定义——它把发现问题的责任，完整地留给了你。

三篇合起来的那条线

这是这个系列的第三篇，也是最后一篇。三篇量的是同一批国际化电商站的三样东西：名字、图标、以及服务器怎么回答“变了没有”。

平台介入方式的差别在专利文本里也有痕迹，从专利与专家访谈还原的GEO五步原理提供了另一个角度。

三格的中枢是同一句话：平台给你的每一条规则背后，都藏着一个没写出来的主语——这件事到底谁动手。认错主语的代价，是把力气花在别人已经替你做完的地方，或者在别人明令禁止的地方反复试探。

如果只能记住一件事

记住那个判据：有没有一个官方工具会告诉你做到了没有。

有没有官方反馈，是判断该投多少力气的关键，Schema对AI搜索到底有没有用的官方说法与实测也是按这个判据取舍的。

有，说明平台在意这个结果，也愿意给你反馈，那就照着它的反馈做。没有，那这件事就完全是你自己的，而且很可能已经坏了很久，没有任何人打算通知你。

平台管得越松的地方，越是没人替你兜底的地方。这句话是这三篇文章唯一想说的东西。

最后留一句给做技术SEO的人

这三篇量的东西——名字、图标、条件请求——有一个共同的尴尬：它们都不在任何一份标准的SEO检查清单里。

工具查不到的清单值得自己建一份，答案引擎优化怎么让内容被优先引用里也有一批标准工具不会检查的动作。

市面上那些站点体检工具，会查标题长度、会查图片替代文本、会查内链结构、会查页面速度。没有一个会告诉你“你的服务器不认自己发的凭据”，也没有一个会告诉你“你的组织名在德国站上多了一个后缀”。

原因不难猜：工具查的是有标准答案的东西，而这三件事各有各的上下文，没法用一条通用规则判定。但没工具查，不等于没有影响；恰恰相反，正因为没人查，这些地方才会一坏好几年。

保哥的建议是给自己建一份“工具查不到的清单”，把这类东西放进去，跟着发版流程走一遍。它不会带来立竿见影的排名变化，但它是那种做完之后你不用再担心的事——而这类事情在技术SEO里，其实是最稀缺的。

这三篇量下来，最有价值的可能不是那几个百分比，而是一个很朴素的习惯：凡是官方文档里出现“我们建议”而没有配套检查工具的地方，都值得你亲自去发一次请求确认一遍。

这样的地方不多，一只手数得过来。但每一个都符合同样的特征：便宜、没风险、没人查、可能已经坏了很久。把它们一次性过完，然后写进清单，这件事的收益会一直持续到有人把清单删掉为止。

这套自检值多少钱

算一笔粗账。四步自检，加起来三分钟。修复的时间差别很大：开个开关是五分钟，补一段比对逻辑是半天到一天，把随机值移出被哈希的部分可能要动模板、需要测试。

便宜且没有反向风险的动作该优先做，把旧内容更新成AI可信来源的十二步里有一批同类动作。

收益按前面那个口径算：假设你有十万个页面被规律抓取，平均每页300 KB，其中八成的抓取碰到的是没变过的内容。做到之后，这八成的传输量归零。具体省下多少钱要看你的带宽单价，但这是一笔按月复利的账，不是一次性的。

更重要的是它的下限：做这件事几乎没有风险。它不影响用户看到的内容、不影响收录、不影响排名，最坏的情况是白做一遍。这跟很多SEO动作不一样，那些动作往往有反向风险。

唯一需要留神的反向风险是前面提过的那一条：改出一个永远返回304的实现。那样内容更新之后爬虫和客户端会一直拿到旧版本，后果比不做严重得多。所以验收的时候一定要两头都验——没变的时候回304，变了的时候回200。

这个风险的概率不高，但值得写出来，因为它是本文唯一一个“做错了比不做更糟”的地方。其余所有情况，最坏结果都只是白做一遍。

跟别的抓取预算动作比，它排第几

抓取预算那份文档里九条建议，如果按性价比排个序，这一条大概在中间偏上。

排序取决于你手上有什么资源，八家龙头怎么抢AI流量的打法拆解里也是按各自的资源禀赋排的动作顺序。

比它优先的是那几条“别让爬虫抓不该抓的东西”——合并重复内容、屏蔽无意义的参数组合、给删掉的页面返回正确状态码。那几条省的是抓取次数，这一条省的是每次抓取的字节，前者的杠杆通常更大。

但这一条有个别的建议没有的优点：它是一次性的、配置层的、不需要任何内容决策。合并重复内容要跟运营和内容团队讨论，屏蔽参数要理清业务逻辑，而支持条件请求只需要改一处技术配置。

所以合理的排法是：如果你的技术资源比内容资源宽裕，先做这一条；反过来就先做那几条。两边都做当然最好，但排序取决于你手上有什么人。

什么情况下可以直接跳过

三种情况可以放心跳过。第一，你的站页面数很少、被抓的总量本来就不大，那这笔账省不出什么。第二，你的内容确实每次都在变——比如一个实时报价页，那这套机制本来就用不上。第三，你的页面已经很小，几十KB那种，省下来的绝对量有限。

知道自己现在是什么状态本身就有价值，AI搜索时代内容优化的底层逻辑五步里第一步也是先摸清现状。

但即便是这三种情况，花三分钟测一次也不亏，因为你至少会知道自己现在是什么状态。本次实测里最让人意外的不是做不到的比例，是那些做了一半的站——它们付出了成本却没拿到收益，而且完全不知道。

常见问题解答

支持304会不会让用户看到旧内容？

不会。内容有没有变是服务端判断的，变了就返回200和新内容，一秒钟都不会延迟。304只在内容确实没变的时候返回。真正决定“客户端会不会隔一段时间才来问”的是Cache-Control这类缓存策略，那是另一件事。这两件事经常被混为一谈，分清楚之后就会发现支持条件请求几乎没有风险。

我的站不大，值得做这个吗？

收益跟规模成正比，小站省不了多少带宽。但成本也几乎是零——大多数服务器和CDN只要开一个开关。判断标准可以是：如果你的服务器成本里带宽占比不低，或者页面平均体积偏大，那就值得。本次样本里首页平均707KB，这个体积下重复传输的浪费是相当可观的。就算你判断不值得做，也建议花三分钟测一次，至少知道自己现在是什么状态。

返回304的时候，响应头还要带哪些字段？

规范要求304响应里带上那些如果返回200时也会发送、且可能影响缓存判断的头，典型的是ETag、Cache-Control、Vary这几项。不需要带内容长度，因为响应体是空的。实践中最容易出错的是漏了ETag——客户端拿到一个不带ETag的304，下一次就不知道该拿什么去问了，于是又回到全量请求。

页面里有CSRF令牌，还能支持ETag吗？

能，但要处理一下。问题的本质是这个令牌每次都不同，导致内容的哈希每次都变。有三种处理方式：把令牌从页面里挪出去，改成前端异步获取；计算哈希的时候把令牌那一段排除掉；或者干脆不用ETag，改用Last-Modified，因为时间戳对这种字节级变动不敏感。本次实测里有五个站的ETag长度段完全不变、只有哈希段在变，几乎可以断定就是这类原因。

怎么判断我的ETag是渲染前算的还是渲染后算的？

从外部很难直接看出来，但有个间接的信号：观察返回304时的响应时间。如果304的响应明显比200快很多，说明服务端在返回304之前没有走完整的渲染；如果两者差不多，说明它渲染完了才发现可以返回304，那样只省了传输没省计算。后者也不算白做，因为带宽通常仍然是大头。

ETag和Last-Modified该给哪个，还是都给？

能都给就都给，客户端会自己挑。如果只能给一个，看你的内容性质：内容会字节级变动但语义不变的（比如页面里有随机令牌），给Last-Modified更稳；内容变更时间不容易取到的，给ETag更实际。本次实测里Last-Modified的成功率反而更高，正是因为它对字节级变动不敏感。

为什么我的ETag每次请求都不一样？

最常见的原因是页面里有长度固定、内容随机的字符串，比如防跨站请求的令牌、脚本策略里的一次性随机数、请求追踪编号。判断方法很简单：连发两次请求，如果两次ETag的长度段完全相同、只有哈希段不同，那基本可以确定是这个原因。另一种可能是两次请求被不同配置的节点处理了，这种情况下连ETag的格式和长度都会变。

Search Console里能看到这一项吗？

看不到。这正是这类规则的特点：它完全发生在你的服务器上，平台只能建议，没有提供任何检查工具。抓取统计报告里能看到抓取请求的总数和响应大小的趋势，但它不会告诉你有多少次本来可以是304。唯一的检查手段是自己发一次条件请求。

用了CDN，这件事还归我管吗？

归。CDN的默认行为差异非常大，本次实测里不同服务商之间的通过率从零到百分之百都有。而且CDN那一层的配置和你的源站配置会叠加，可能出现源站说别缓存、CDN却自动生成凭据这类矛盾。正确的做法是从公网发一次请求，看最终那个响应头长什么样，而不是看某一层的配置。

拿首页测出来的结果可信吗？

不可信，而且会系统性低估。本次实测里，同一批站的首页只有36.6%能回304，内页有65.2%，差1.8倍。首页是全站个性化程度最高的一页，推荐位、促销条、购物车数量、会话令牌都在上面，这些都会让每次输出的字节不同。测的时候两边都要测，修的时候优先修内页。

最后修改时间该填什么值？

填内容真正被编辑的那个时刻：文章的最后更新时间、商品信息的最后变更时间。最坏的做法是填当前时间——那样每次响应都在说这份内容刚刚改过，任何条件请求都不可能通过。自查方法是请求一次看返回的时间是不是接近当前时刻，是的话就说明填错了。取不到真实变更时间的话，宁可不填。

爬虫真的会发那些不常见的请求方法吗？

官方确认过会发多种方法，包括只要响应头的那种和询问支持哪些方法的那种。本次实测的分布是：只要响应头那种有86.6%的站正常返回，但其中大部分不给内容长度；询问支持方法那种，按规范应该列出方法清单的只有5个站。这一项通常不需要专门去修，量出来是为了给那个说法配一个真实的分布。

声明了no-store的站怎么办？

如果确实需要no-store，那首页这一层就不适用这套机制，直接跳过。但要注意别出现自相矛盾的配置：本次142个站里35个写了no-store，其中6个同时还给了凭据，那是两层配置叠加的结果，每一层单独看都对，合起来就矛盾了。另外，no-store通常只该用在真正含个人信息的页面上，别把它套在整站上。

权威参考资料

摘要：用一台普通服务器，把211个国际化独立站的首页各抓了一次，拿到132份能分析的HTML。里面有28份的正文可读字符不到1200个，其中14份是整整0个字符。最夸张的一份传了5146465字节，一个字都读不出来。这些页面并不是不管机器——93%写了标题，82%写了描述，57%放了结构化数据，只有1个站在noscript里留了正文。它们知道机器会来，只是没给机器留内容。文章后半段把无障碍树这一层也量了一遍，并记下一次尺子失效：把空壳页混进样本，无地标区域的比例会从3.6%虚高到22.9%。

先说一件反直觉的事。你打开一个独立站首页，满屏商品、导购文案、促销标语，看着热闹得很。同一个地址，我用命令行抓一次，得到2109539字节的HTML。把标签、脚本、样式全部剥掉，剩下的可读文字是：零。

不是少，是零。2兆的字节，一个字都没有。

这个站不是什么小作坊，是一个消费电子大牌。它的首页在浏览器里工作得很好，因为浏览器会执行那几十个脚本，然后把内容画出来。问题是，来读这个页面的不只有浏览器。

2026年8月，行业里有两条新闻在同一周出现，看着毫不相干。一条是内容分发网络的爬虫开关被一键关掉，两周流量归零；另一条是一篇讲无障碍树的技术文章，说AI代理读网页读的不是你的视觉设计，而是浏览器构建的那棵语义树。保哥把这两条并排放了几天，发现它们说的其实是同一件事的两个方向：你以为你发布了内容，其实你只是发布了一份让浏览器去生成内容的说明书。

说明书这个比喻可以再往下走一步。你把说明书交给一个会照着做的人，他能做出一桌菜；交给一个只会念字的人，他念完只知道有这么一份说明书。这两个人拿到的是同一份东西，得到的结果差着一整桌菜。

过去十年，来读你页面的基本都是"会照着做"的那种。这两年名单变了，而且新加进来的那批，大多数只会念字。

这篇文章只干一件事：把"东西到底在不在"这个问题，从感觉变成可以数出来的数字。前面是211个站的实测明细，中间是无障碍树这一层的量法，后面是一次尺子失效的完整复盘——同一批数据，混进错误样本之后，某个结论虚高了6.4倍，另一个虚高了11倍。

需要先说明一句：这套测量只看服务端交付的那一份字节，不看渲染之后的结果。所以下面所有"没有"的准确含义都是"在交付的那一刻没有"。这个边界很重要，文中会反复提到它。

抓下来的字节里，到底有多少字

先把测量方法交代清楚，因为这篇文章所有结论的可信度都挂在这一段上。方法说不明白，后面那些百分比就只是一堆漂亮的数字。

有些地址连head都没有，接口和feed拿什么说自己不想被收录是相邻的盲区。

测量口径怎么定的

样本是211个国际化独立站的域名，覆盖服饰、家居、消费电子、美妆、户外、母婴几个大类，绝大多数是有独立品牌、面向多国市场的品牌自营站。这批域名不是随机抓的，是按"有多语言版本、有独立品牌、体量在中大以上"三个条件筛出来的，所以它们代表的是行业里做得比较认真的那一批，不是平均水平。这一点在读后面的数字时要记住：这些不是随便找的小站，它们是很多人拿来当参照对象的站。

剥标签数字符这个动作，用现成的HTML转纯文本工具也能做，不必自己写脚本。

请求方式是最普通的一次GET，用桌面版Chrome的用户代理串，跟随跳转，开启压缩，超时30秒，不执行任何脚本。整个过程用二十条并发跑完，全部211个域名在同一个时间窗内完成，避免出现"这个站是早上抓的、那个是晚上抓的"这种时间偏差。

拿到HTML之后的处理只有三步：剥掉script和style的成对标签及其内容，剥掉noscript，然后去掉所有剩余标签，把连续空白压成一个空格。剩下的字符数，就是这一页"直接给出来的可读文字"。

这个口径故意定得很窄，窄到有点不近人情。它不认脚本里的JSON数据，不认结构化数据块，不认属性值里藏的文案，也不认注释里的东西。理由很简单：它模拟的不是浏览器，是一个只会读字节、不会执行代码的读者。这类读者今天有很多，而且这两年正在快速变多。

要给这个口径挑毛病也很容易。它会冤枉那种"内容在页面上但被写进了属性"的写法，也会把一些正当的懒加载算成缺失。但它有一个别的口径都没有的好处：任何人拿同样的三步，在任何一台机器上，都能得到同一个数字。做横向对比的时候，这个性质比精确更值钱。

211个域名，最后剩下132个

211个域名里，返回200并且正文超过3000字节的有132个。其余的要么连不上，要么撞上人机验证页，要么直接403。这79个的去向本身是另一篇文章的题目，这里先按下不表——只强调一点：后面所有的百分比都算在这132个身上，因为只有它们证明了自己愿意对一次普通请求给出一个真页面。

用什么身份去请求会改变结果，这份爬虫识别与UA分类把各家的串列全了。

这一步很重要，重要到值得多说两句。如果把连不上的站也算进分母，任何"缺失率"都会虚高，而且虚高的原因跟被测的东西毫无关系——一个站因为防护策略把我拒之门外，跟它首页有没有写标题是两回事。混在一起算，得到的数字既不能说明防护，也不能说明结构。

把基线定在数据内部、不从外面拍脑袋，是这一整套测量能站住的前提。这个原则在本文后半段还会再出现一次，而且那一次的教训要贵得多。

为什么先量"有没有字"，而不是先量结构

做技术审计的人有个通病，喜欢从精细的项目查起：结构化数据对不对、标题层级顺不顺、图片有没有替代文本。这些都该查，但顺序错了。

从粗到细的顺序，企业网站SEO审计框架里也是这么排的，先抓取后内容。

顺序应该是从粗到细，而且每一层都是下一层的前提。正文都不在，讨论标题层级毫无意义，就像检查一个空信封的折叠是否规整。本文后面那次尺子失效，根子就在于第一遍跑的时候没把这个顺序摆对。

所以整套检查的第一个问题永远是同一个：这次交付的字节里，有没有字。答案是"有"，才轮得到第二个问题。

正文长度的分布长什么样

正文字符和HTML字节是两件事，46个电商站的体积实测量的是后一件。

这张表最刺眼的不是中间那一大坨，是最上面那一行：18个站的首页，可读正文不到100个字符。一百个字符是什么概念？大概就是这句话本身的长度。

把不到1200字符的都算成"空壳"，一共28个，占132个的21.2%。这个1200的线不是随手划的，后面有一节专门讲它是怎么来的、以及划在别处会发生什么。

另一头也值得看一眼

表的最下面两行是另一个极端：14个站正文超过12000字符，其中4个超过25000。

内容铺太多也有上限，Googlebot的2MB抓取限制就卡在这里。

两万五千个字符的首页是什么样子？基本上是把整个商品目录、所有分类说明、全部页脚导航铺在一页上。这类页面在字节层面当然没有"内容不在"的问题，但它们有另一个问题：内容太多，重点在哪不清楚。

这就是为什么main标签和标题层级在后面会单独讲。当一页只有八百个字的时候，机器不用分区也能看明白；当一页有两万五千个字的时候，"哪一块是这页真正要说的事"就成了一个必须回答的问题，而回答它的方式只有语义标记。

内容太少和内容太多，需要的是同一套东西的两端：前者需要把内容交出来，后者需要把内容组织好。中间那一大坨表现正常的站，两件事都做对了，所以它们在后面的检查里通常也表现更好——这个相关性在数据里挺明显。

五兆的HTML里一个字都没有，这可能吗？

可能，而且不止一个。把这28个站按可读字符数从少到多排开，前14个是同一个数字：0。

字节多少还牵着首字节时间，多层缓存对性能与抓取的双向影响算过这笔账。

零字符俱乐部的成员名单

这批站多数跑现代前端框架，渲染模式选错就抓成空壳讲的正是这个成因。

注意这张表里的两种零。上面11个是"很大的零"：字节以兆计，内容为空。下面3个是"很小的零"：整个文件才几万字节甚至6千字节，摆明了就是一个跳转壳或者加载器。

很小的零是诚实的，很大的零才是麻烦的。6413字节的文件，任何工具扫一眼都知道有问题；5兆的文件在体积报表里排在最前面，看上去像是个内容极其丰富的重量级页面，实际上一个字都读不出来。

打个不太恰当的比方：这就像收到一个巨大的包裹，拆开是十七层气泡膜，中间什么都没有。你不能说人家没发货，运单上的重量是实打实的。

这五兆字节到底装了什么

既然不是文字，那总得是点什么。把这几个大文件拆开看，主要是三类东西：内联的样式表、内联的脚本代码、以及大段大段的状态数据——通常是一个巨大的JSON对象，里面装着这一页需要的所有商品信息，等着脚本把它渲染出来。

压缩只解决体积不解决内容，免插件压缩HTML的做法能减掉一部分冗余。

内容在标签里还是在变量里差别很大，语义化HTML对抓取的实际影响做过样本实测。

最后这类东西最有意思。商品名、价格、文案，其实全在这五兆字节里，只是它们被装在一个引号里，而不是装在一个标签里。一个不执行脚本的读者，理论上不是拿不到，是它没有义务去猜你那个JSON的结构。

这一点值得给做技术的同事说清楚，因为它经常引起争论。争论的焦点通常是"数据明明在HTML里"。数据确实在，但HTML是一个有语义的格式，标签就是语义。把内容放进一个属性值或者一个脚本变量，等于把它从有语义的部分挪进了无语义的部分。在有语义的地方它是内容，在无语义的地方它只是字符。

体积和内容的关系被彻底切断了

把28个空壳页和104个正常页的HTML体积中位数放在一起比，结果是这样：空壳页335662字节，正常页586994字节。

想快速量体积，抓取体积检查器能直接给出这一页有多大。

正常页确实更大，但只大了不到一倍。体积这个指标，在判断"有没有内容"这件事上，已经完全失效了。过去做技术优化，页面体积是个万能的粗筛指标——太大就是有问题。现在它只能告诉你传了多少字节，不能告诉你传的是什么。

保哥自己踩过这个坑。早年间审站，习惯先看一列体积排序，从大的往下看。这个习惯在服务端渲染的年代很好用，因为体积大基本等于内容多，排在最前面的往往就是那些堆了太多东西的页面。现在这个相关性断了，还按老习惯看，注意力会被系统性地引到错误的地方去。

更麻烦的是，体积这个指标还在各种报表里活得好好的，页面性能工具会报它，抓取诊断工具会报它，看板上通常有一格给它。一个已经失去解释力的指标，如果还挂在显眼的位置，比没有这个指标更糟——它会持续地把注意力吸走。

顺手记一个细节：这些页面的响应都很快

抓取的时候顺带记了每个请求的耗时。有点意外的是，这28个空壳页的响应速度普遍不慢，有几个还比正常页快。

想想也合理。服务端不用查数据库、不用套模板、不用拼字符串，直接把一份构建好的静态文件甩出来，当然快。所有的活都推给了浏览器，而浏览器那边的耗时不会出现在服务器的响应时间里。

这条值得记一笔，因为它意味着响应时间这个指标同样不能用来判断内容有没有交出去——跟体积一样，又一个看着很相关、实际毫无解释力的指标。

脚本数量也不站在你这边

还有一个更反直觉的对照：空壳页的script标签数中位数是22个，正常页是70个。

脚本多少还牵着首屏速度，关键渲染路径优化把阻塞机制讲透了。

正常页的脚本反而多三倍。原因不难想——那些正常吐HTML的站大多跑在成熟的电商平台上，平台自带的追踪、客服、评价、推荐插件一堆，脚本自然多。而空壳页往往是自研的单页应用，脚本少但每一个都是重量级的：一个框架运行时，一个应用包，一个状态数据块，齐活。

所以"脚本多的站更可能是空壳"这个直觉，方向是反的。这类反直觉的地方特别值得记一笔，因为它们正是经验会骗人的位置。凭直觉排查，你会先去查那些脚本一大堆的平台店，而它们恰恰是这一项上表现最好的。

顺着这条线还能得到一个更实用的判断：用自研前端的站，出这个问题的概率明显高于用成熟电商平台的站。不是因为自研团队水平差，恰恰相反，是因为自研团队有能力选择渲染方式，而选择往往发生在没有人代表机器读者说话的那个会议上。

这28个站是怎么走到这一步的

没有一个团队会在某次会上决定"我们不给爬虫留内容"。这件事是一步一步走过来的，每一步都很合理。

单页应用被AI爬不到的完整链路，SPA站被跳过的真相有四种渲染模式对比。

第一步，前端选了一个现代框架，因为它开发效率高、交互体验好、招人也容易。这个决定几乎没有争议。

第二步，框架默认是客户端渲染，服务端渲染需要额外搭一层服务、额外一套部署、额外的缓存策略。评估之后决定先不做，等有需要再说。这个决定当时也是对的，因为当时的"需要"确实还没出现。

第三步，站上线，搜索表现看着还行——因为主流搜索引擎会渲染。这一步进一步确认了第二步的判断。

第四步，两三年过去，读页面的程序名单变了。而没有人会在这个时候回头去复查第二步那个决定，因为那个决定当时被验证过是对的，而且验证的证据现在还在——搜索流量确实没出问题。

问题不在任何一步，问题在于没有一个环节负责在前提变化时重新审视旧结论。这个模式在技术决策里非常普遍，本文这28个站只是它一个特别容易量化的例子。

空壳页到底给机器留了什么？

如果这28个站是完全不管机器的，事情反而简单——那就是一个纯粹的技术选型问题。但数据不是这么说的。

平台站的字段入口分散，Shopify的128种结构化数据类型怎么选给了对照。

先说清楚这张表是怎么比的

下面这张表把28个空壳页和104个正常页放在一起，逐项比"页面里有没有这样东西"。要注意的是，这里比的是有无，不是好坏——一个只写了三个字的标题也算有。

之所以这么比，是因为想回答的问题很具体：这些站是不是压根没考虑过机器读者。要回答这个，看有没有就够了，写得好不好是下一层的问题。

还有一点要说明：这几项全部位于HTML的头部，是服务端直接输出的，不受渲染方式影响。所以它们在两组之间的差距，反映的是意识差距，不是技术差距。这一点很关键，也是这张表能说明问题的前提。

门面全在，正文全无

头部信息的完备度可以批量体检，Meta标签检测器的加权评分一次跑完整页。

这张表是整篇文章里保哥最想让你盯着看的一张。

头部信息的完备度，空壳页和正常页几乎没差别。标题93%对98%，描述82%对92%，结构化数据57%对74%。这些东西全都写在head里，全都是静态输出的，一个都没落下。

只有一行例外，而且例外得非常干净：noscript里有文字的，空壳页28个里只有1个。

这说明了什么

说明这些站完全知道有机器会来读它们。知道要给标题，知道要给描述，知道要给社交分享的卡片图，甚至知道要给结构化数据。这些工作没有一样是给人做的，全都是给机器做的。

中间那条缝要靠协作填，前端工程师SEO协作的7个动作点给了具体分工。

然后，在"要不要给这些机器留一份能读的正文"这个问题上，它们的答案是不留。

这不是疏忽，这是一个默认值。前端框架默认就是这么工作的，没人主动选择过它。团队里做SEO的那个人负责了标题和描述，做前端的那个人负责了渲染方式，两件事各自都做得挺对，中间那条缝没有人的名字写在上面。

这个判断有一条很硬的旁证：头部信息的完备度跟正文有没有输出，几乎不相关。如果这些站是"不重视机器"，那标题和描述也该一起烂掉。事实是它们的头部信息只比正常站低几个百分点，而正文的差距是从6539掉到14。一个指标掉了几百倍，相邻的指标纹丝不动，这只能说明它们由两拨人、两套流程负责。

noscript那一栏为什么是最关键的一栏

表里最后一行看着不起眼，其实是全表信息量最大的一行。

不执行脚本的读者拿到什么，CSR与SSR的引用率实测给过一组对照数字。

noscript这个标签的作用就一个：告诉不执行脚本的读者，这里有一份备用内容。它存在的唯一理由就是照顾那类读者。一个站在noscript里写了正文，等于明确表过态："我知道有人不执行脚本，这是给他们的。"

28个空壳页里，表过这个态的有1个。

而正常页里有17个（16%）写了noscript内容。有意思的是，正常页本来就不太需要它——正文已经在字节里了。该写的那批没写，不太需要写的那批反而写了。这个错位不是巧合，它说明noscript的使用跟"是否意识到有非浏览器读者"高度相关，而空壳页的团队恰恰是最没意识到这件事的那批。

结构化数据比正文长92倍的那个站

有两个例子值得单独拿出来。awaytravel.com的首页可读正文是145个字符，同一份HTML里的结构化数据是13423字节。avocadogreenmattress.com正文36个字符，结构化数据5159字节。

结构化数据到底有多大用，Schema对AI搜索的官方说法加实测说得比较克制。

这两个站给机器准备的专用数据块，比给所有人准备的正文长几十倍到近百倍。它们不是没为机器着想，它们只为机器准备了一份精装的名片，然后忘了带上要谈的事。

这个比例本身就是个很好的自查指标：把你首页的结构化数据字节数除以可读正文字符数，如果这个比值超过1，基本可以断定正文没有被服务端输出。这个指标的好处是不需要判断"多少字算够"，它是个相对值，任何品类任何规模的站都能用。

还要多说一句，这种配比本身在规范上就有风险。结构化数据的通行要求是它描述的内容要在页面上真实存在、用户看得到。当结构化数据里写着商品名和价格，而同一份字节里的正文是空的，这个对应关系严格说是断的。实际执行中很少有人因此被处理，但把它当成一个可以长期依赖的做法，并不稳妥。

为什么这种做法会流行起来

值得花两句话说说它的来路，因为理解来路才知道该怎么劝人改。

哪些类型值得做，Schema官方公开的全网使用数据比凭感觉堆类型靠谱。

过去几年，行业里关于结构化数据的讨论极其密集，各种指南、各种工具、各种检测器，都在告诉你"把这些字段填全"。填全之后工具会给你一个绿色的对勾，非常有成就感。而"页面上有没有正文"这件事，没有任何工具会给你一个红色的叉。

于是就形成了一个很自然的行为模式：大家都在做有反馈的那件事，没反馈的那件事没人做。这跟人的水平没关系，跟工具塑造的注意力有关系。

所以劝人改的时候，讲道理效果一般，给他看数字效果好得多。把他自己站的那个比值算出来——结构化数据多少字节，可读正文多少字符——这个数字一出来，通常不需要再多说什么。本次实测里那两个比值超过90倍的站，只要有人把这个数摆到会上，事情大概率就推动了。

无障碍树是什么，它凭什么跟抓取有关？

到这里为止讲的都是"有没有字"。接下来这一层更细：字有了，但字和字之间的关系在不在。

先把测量框架想清楚，别急着埋事件是同一个顺序问题。

先把这棵树说清楚

浏览器拿到HTML之后会构建两棵树。一棵是文档对象模型，也就是常说的DOM，它管的是元素怎么排布、样式怎么套用。另一棵叫无障碍树，它管的是每个元素"是什么、叫什么、现在什么状态"。

智能体读的到底是什么，AI浏览器读无障碍树而不是页面截图这篇讲得更细。

读屏软件用的是第二棵。一个盲人用户用读屏软件浏览你的站，软件念给他听的不是DOM，是无障碍树上的节点：这是一个按钮，它叫"加入购物车"，它现在可用。

这棵树的存在意义从一开始就跟搜索毫无关系。John McAlpin在2026年8月那篇讲无障碍树用例的文章里专门用一整段强调了这件事：这棵树存在的目的是让残障人士能用网络，SEO上的好处只能当作把无障碍做对之后的副作用，不能反过来当成设计的驱动力。这句话保哥完全同意，而且觉得应该抄一遍贴在工位上。

那为什么它跟机器读页面扯上了关系

因为一个不带眼睛的读者，和一个带眼睛但只能读结构的读者，需要的东西高度重合。

无障碍改造的完整清单，18个改动的实操指南可以直接照着走。

读屏软件需要知道"这个圆形图标是干什么的"，AI代理也需要知道。读屏软件需要知道"这一坨文字里哪块是主内容、哪块是导航"，抓取程序同样需要知道。无障碍树本来就是一份"把视觉信息翻译成语义信息"的产物，而所有不靠视觉理解页面的读者，用的都是同一份翻译。

这也是为什么这套检查特别值得做：它同时服务两拨人，而且其中一拨是法律和道德意义上你本来就该服务的。

状态那一层，很多人根本没意识到它存在

名字和角色比较好理解，状态这一项容易被忽略，但它在交互页面上出问题的概率最高。

折叠面板里的内容算不算数，内容折进标签页手风琴的处理有官方口径。

举个具体的：一个折叠面板，点一下展开，再点一下收起。视觉上一目了然，因为箭头会转、内容会出来。而在无障碍树上，这个"现在是展开还是收起"是靠一个属性表达的——aria-expanded，值是true或false。

最常见的缺陷是这个属性写死了。初始状态写了false，面板打开时脚本没有把它改成true。视觉上一切正常，树上永远是"收起"。对读屏软件用户来说，他点了展开，系统告诉他还是收起的，内容就在那儿但没人通知他。

这一层没法从静态HTML里查，因为它的错误恰恰发生在"应该变而没变"这个动作上。要查它只能真的去点一下，然后看树。所以本文的量化部分完全没有覆盖这一层——这不是漏了，是这个方法从原理上就够不着。把方法的边界说清楚，比多给几个数字重要。

可访问名是怎么算出来的

树上每个节点有三样东西：角色、名字、状态。角色是"这是个什么"，比如按钮、链接、标题；状态是"它现在怎么样"，比如展开还是收起、选中还是未选中；名字就是"它叫什么"。

名字来源里alt占很大比重，图片alt与属性的批量体检能一次扫完整页。

名字这一项有一套明确的计算顺序，不是随便取的：先看aria-labelledby指向的内容，再看aria-label属性，再看元素本身该用的原生属性（比如图片的alt、表单的关联label），再看元素内部的文字，最后才是title属性。

这个顺序有个很实用的推论：越靠前的方式优先级越高，也越容易把后面的盖掉。给一个已经有文字的按钮再加一个aria-label，实际生效的是aria-label，按钮上那行字反而不算数了。这是个常见的错误来源——两个人各写了一半，结果只有一半生效。

怎么在没有浏览器的情况下量这一层

严格说，无障碍树只有浏览器能构建，因为它依赖渲染后的最终状态。但上面那套计算顺序里，绝大多数来源是HTML里静态写着的：aria-label、aria-labelledby、alt、label的for关联、元素内部的文字。这些东西在字节里就能看到。

字节和渲染后的差异，渲染对比器能直接把两份结果摆在一起。

所以可以退一步：不去构建整棵树，只检查"这个元素有没有可能拿到名字"。一个button标签，里面没有文字，也没有aria-label，也没有aria-labelledby，也没有title，也没有带alt的图片子元素，那它渲染成什么样都不会有名字——除非脚本在运行时给它补一个。

"除非脚本补一个"这句是这套方法唯一的缺口，必须承认。所以下面所有数字的准确说法是：这些元素在服务端交付的那一刻是无名的。它们后来有没有被补上，只有真浏览器能回答。但对一个不执行脚本的读者来说，"后来"不存在。

本次量的是170份可解析首页快照。为了不让空壳页污染结果，先把它们剔掉了——这一步的重要性，后面有一整节专门讲，而且是这篇文章里最贵的一段教训。

页面上那个按钮，在机器眼里叫什么名字？

剔掉空壳页之后剩110个站，下面所有比例都算在这110个身上。

弹窗上的关闭按钮尤其常见，侵入式插页的真相与豁免说明了什么情况会出问题。

原生按钮的情况

110个站的首页一共有4876个button标签，其中401个（8.2%）拿不到任何名字。这401个分布在41个站上，也就是说每10个站里差不多有4个，首页上至少有一个按钮对机器来说是无名的。

这类结构短板可以批量扫，页面结构分析工具的六维体检覆盖H1层级和语义标签。

最集中的几个：philips.com的58个按钮里46个无名，allbirds.com的79个里41个，peakperformance.com的121个里34个，ritual.com的65个里30个，chubbiesshorts.com的62个里30个，dreametech.com的60个里27个。

这些按钮在浏览器里当然有样子——它们是购物车、搜索、菜单、关闭、上一张下一张。人一眼就认得出，因为人认的是图形。机器认的是名字，而名字这个字段是空的。

为什么偏偏是这几类按钮

把无名按钮挨个看过去，会发现它们高度集中在几个位置：轮播的左右箭头、弹窗的关闭叉、菜单的汉堡图标、搜索的放大镜、数量增减的加减号。

图标库的用法差别不小，Font Awesome各版本的语法与SVG渲染影响的正是这一层。

这几个位置有一个共同点：它们的含义完全靠一个约定俗成的图形来传达，而这个约定只存在于人的经验里。一个向右的三角，全世界的人都知道是下一个，但这个知识不在HTML里，它在你脑子里。

还有一个共同点更现实：这些控件通常来自组件库，是同一份代码在页面上重复了几十次。所以一个站的无名按钮数量往往不是"错了几十次"，而是"错了一次，用了几十次"。philips那46个，多半来自不到十种组件。

这是个好消息。它意味着修复成本跟数量不成正比。四十六个问题可能只对应五处改动，而且改完之后新写的页面自动就是对的。

图标是重灾区

把内联的svg单独拎出来数：110个站里有3906个svg，既没有aria-label，也没有内嵌title，也没有被标记成装饰性元素。87个站有这个问题，占79.1%。

图标这件事从来不只一处，Favicon生成器给出的十个文件真正生效的只有一张。

这个数字大到有点吓人，但要说句公道话：svg没名字不一定是错。如果它外面包着一个有名字的按钮，那这个图标本来就该被标成装饰性的，不该有自己的名字。这3906个里有相当一部分属于这种情况。

真正确凿的问题是另一种：图标是唯一的内容，外面那层也没名字。本次数据里，纯图标且拿不到名字的链接有264条。这264条是硬伤，因为它们对机器来说就是264个"点这里"，去哪里不知道。

用div假装按钮的那批

还有一类：给div或者span加上role="button"来模拟按钮。110个站里有171处这种写法，分布在32个站上，其中13处连名字都没有。

该用什么标签有明确答案，8类语义标签对SEO的真实影响逐个做过拆解。

这个写法本身不算错，但它是一个信号。能用button标签的地方用了div，通常意味着这个团队在按视觉需求组织标签，而不是按语义需求。顺着这个信号往下查，一般还能查出别的。

更值得注意的是它的近亲：直接给div绑点击事件，连role都不加。这种写法110个站里有115处，分布在10个站上。加了role的至少还告诉了机器"这是个按钮"，什么都不加的那种，在树上就是一段普通文字，只不过点它会有反应。键盘用户按Tab永远走不到它，读屏软件也不会提示它可以点。

链接这一层的数字被一个站带偏了

链接的整体数字是这样：110个站一共28747条链接，其中2359条（8.2%）拿不到可访问名。

内链本身也能被标记，用结构化数据标注重要内链是另一条思路。

但这个8.2%要打个折扣看，因为其中1855条来自同一个站。parachutehome.com的首页有2343条链接，其中1855条没有名字，占它自己的79%。一个站贡献了全样本无名链接的四分之三还多。

把它拿掉重算，剩下109个站的无名链接是504条，占比降到1.9%。两个数字都是真的，区别在于它们回答的问题不同：8.2%是"这批站的链接整体质量"，1.9%是"一个典型的站大概是什么水平"。

遇到这种被单个样本主导的指标，最好的做法是两个数都给出来，并且说清楚差在哪。只给8.2%会让人以为这是普遍问题，只给1.9%又会漏掉那个真正出了大事的站。保哥见过太多报告在这种地方偷偷选一个对自己论点有利的口径，这是很不体面的做法。

顺便说一句，一个站首页放2343条链接本身也值得看一眼。这个数量远超样本中位数，多半是把整个商品目录铺在了首页上。

一张图没有alt，和alt写成空字符串，差别在哪？

这是个特别容易被工具搞混的地方，而两者的含义正好相反。

同一份内容给人和给机器的写法可以不同，正文本地化而结构化数据写国际格式是个好例子。

三种状态，三个意思

alt写过头也有风险，图片alt关键词堆砌的新规解读附了处罚实例。

中间那一行是很多人误会的地方。alt=""不是"没写alt"，它是一句明确的话：这张图不承载信息，跳过去。装饰性的分割线、渐变背景、纯视觉的图形，就该这么写，HTML标准里关于替代文本的那一章把什么时候该写空字符串讲得比多数教程都细。写空的alt是尽责，不是偷懒。

最后那一行才是问题。没有alt属性意味着没有人表过态——它可能是重要商品图，也可能是背景纹理，读的一方只能自己猜。本次样本里有361张，涉及36个站，占110个站的32.7%。

72%这个数字该怎么看

72%的图有文字alt，听起来不算差。但这个数字是按图片张数算的，而首页上的图片张数分布极不均匀——一个站可能有200张，另一个只有15张。张数多的站会把整体比例拉向它自己的水平。

文件名、alt、WebP与懒加载怎么配合，图片SEO的完整落地讲得比较全。

所以更该看的是站的口径：110个站里有36个，首页上至少有一张图没有alt属性。这36个站不是alt写得不好，是这一项根本没进他们的检查流程。

这两个口径的差距，是所有横向审计都要面对的问题。个数口径回答"整体质量怎么样"，站数口径回答"这个问题普不普遍"。汇报的时候用站数口径，排期的时候用个数口径。反过来用，要么把问题说得太轻，要么把工作量估得太大。

那361张没有属性的图，都是些什么图

把这361张挨个看过去，来源比想象的集中。

最多的一类是脚本生成的图。购物车里的商品缩略图、推荐位里的商品图、评价区里的用户上传图，这些都是运行时插进来的，插的时候只带了地址没带说明。写这段脚本的人手上根本没有替代文本这个数据——后台的商品字段里没有这一栏。问题不在前端，在数据模型。

第二类是第三方嵌入的图。支付方式的标志、物流公司的标志、认证徽章、社交平台的图标，这些通常是从别人给的代码片段里复制过来的，原样贴上，没人会去改。这一类有个特点：它们往往集中在页脚，一排排挨着，缺一起缺。而支付方式那一排恰恰是转化路径上很关键的信任信号，读不出来等于这份信任没传达到。

第三类才是真正的疏忽：模板里手写的图，写的时候忘了。这一类数量最少，通常也最好改，因为它们就在模板文件里摆着，一个个补过去就行。

有意思的是，很多团队的注意力恰恰全放在第三类上——因为它最好找、最好改、改完最有成就感。而占比最大的第一类，因为要动后台字段、要拉上运营和产品，往往就一直挂在那儿。这个模式在技术优化里到处都是：先做完的总是最容易的那一件，不是最要紧的那一件。

知道来源之后，处理方式就清楚了：第一类要去后台加字段，第二类可以批量补上，第三类改模板。三件事的负责人不是同一个，工作量也差着量级。上来就说一句"我们有361张图缺替代文本"，谁也不知道该干什么。

第一类值得多说一句，因为它是最容易被误判的。前端同事看到这个问题，第一反应通常是"我加个默认值就行"，于是所有商品图的替代文本都变成了同一句"商品图片"。这确实让缺失率归零了，但信息量还是零，只是从"没表态"变成了"表了个没用的态"。真要解决，得让运营在上架时把那一栏填上，而那需要后台先有那一栏。

那24%的空alt里，有多少是真的装饰图

这个问题没法用抓取的方式回答，必须人看。保哥随手抽了几个站翻了翻，感觉大体是对的——那些空alt多数落在分割线、渐变块、图标背景这类元素上。

alt是不是排名因素，这个说法的真相跟很多人想的不一样。

但也确实见到写错的：有的商品列表里，商品主图的alt是空的，旁边一个装饰性的角标反而写了文字。这种颠倒比全部留空更麻烦，因为它会让读的一方得到一个错误的信息层次：装饰被当成了内容，内容被当成了装饰。

所以这一项没法完全自动化。能自动化的部分是"有没有表态"，表得对不对，还得人看。好在需要人看的量不大——把首屏那十几张图看一遍就够了，剩下的多半是同一套模板出来的。

写alt的一条实用判据

跟SEO没关系但很好用：如果这张图去掉之后，你需要用一句话补上它说的事，那句话就是alt。如果去掉之后什么都不用说，那就写空字符串。

非拉丁字母的站更麻烦，文件名和alt要用两套字母写同一个词是实测结论。

这条判据的好处是它自然地控制了长度。补一句话通常十几到三十几个字符，不会写成一段。见过最离谱的alt是把整段商品描述塞进去，那不是替代文本，那是把正文藏进了属性里。而藏进属性里的文字，前面刚说过，在语义上是不算数的。

表单里那个输入框，谁告诉机器它是干什么的？

表单这一项的数字，是整套检查里最糟糕的。

留邮箱那个框最典型，邮件弹窗的时机字段与合规把这一步拆开讲了。

四分之一的输入框没有标签

把隐藏域、提交按钮这类排除掉，110个站的首页一共有1192个真正需要用户输入的字段。其中291个（24.4%）拿不到任何形式的标签：没有label关联，没有aria-label，没有aria-labelledby，也没有title。

表单控件选错的代价，下拉框如何悄悄吃掉询盘是个很具体的例子。

受影响的站有44个，占40%。也就是说每5个站里有2个，首页上至少有一个输入框，机器不知道它要填什么。

为什么偏偏是表单最差

因为占位符太好用了。

首屏那一块的设计取舍，导航、主Banner到分类区的排布决定了标签放不放得下。

设计稿上一个干干净净的输入框，框里灰色小字写着"请输入邮箱"，视觉上非常清爽，不需要额外一行标签文字。前端照着实现，用placeholder属性，一切正常。

问题是placeholder不是标签。它是提示，是示例，是可以随时消失的东西——用户一开始打字它就没了。把它当标签用，等于把一块随时会掉的牌子挂在门上。

这件事的坏处不只在机器那边。用户填到第四格的时候想回头确认第二格填的是什么，看到的是一串已经输入的文字，但那一格要求填什么已经不在屏幕上了。这是个纯粹的可用性缺陷，跟搜索、跟AI、跟任何技术指标都没关系，它就是不好用。

本次数据里几个典型：ritual.com的22个输入框全部无标签，mejuri.com的14个全部无标签，allbirds.com的13个全部无标签，awaytravel.com的8个全部无标签。这种"全军覆没"的形态几乎可以断定是同一套组件出来的，改一处就能全好。

视觉上不想要标签，该怎么办

这是个真实的设计诉求，不能光说"你得加标签"就完事。实际有三种做法，各有适用场景。

视觉隐藏靠的是样式类，CSS的美化压缩与性能账顺带讲了这类工具链。

第一种，把标签留在HTML里但视觉上隐藏。用一个专门的样式类把它移出可视区域，而不是用display:none——后者会把它从无障碍树上一起拿掉，等于白写。这是最常用也最稳妥的做法，几乎所有成熟组件库都提供了这个类。

第二种，给输入框加aria-label，值就是那句标签文字。这种做法更简洁，适合搜索框这类只有一个输入框、上下文很明确的场景。

第三种，浮动标签——用户没输入时标签显示在框里，开始输入后缩小移到框上方。这种做法视觉效果好，标签也一直在，是这几年比较流行的方案。缺点是实现复杂，而且要注意别把标签做成一个纯视觉的div，那样又回到原点了。

三种做法的共同点是：标签这个东西一直存在，只是被安排到了不同的位置。而用placeholder代替，是让它彻底不存在。

一个反例说明这不是做不到

casetify.com的首页有591个输入字段，是全样本最多的，多半是筛选器和批量表单撑起来的。其中无标签的是121个，比例20.5%，低于平均。同一份HTML里有375个带for属性的label。

筛选器多的站字段自然多，分面导航的抓取预算治理是配套的另一半。

一个字段数量最多的站，标签覆盖率反而高于平均。这说明这件事跟站的复杂度没关系，只跟有没有把它写进组件规范有关。

反过来看那几个"全军覆没"的站，字段数都在十几到二十几个，规模小得多。不是因为难所以没做，是因为量小所以没人觉得需要立规矩。二十二个输入框，手写就手写了，等到有一天变成两百二十个，那套没有标签的写法已经复制了两百遍。

邮件订阅框是第二个

排在搜索框后面的是邮件订阅框，理由类似但不完全一样。

它同样出现在几乎每一页的页脚，同样是一个明确的转化动作，同样极少有人给它配标签——因为设计上那一块通常就是一行输入框加一个按钮，加一行标签文字会显得很笨重。

不一样的地方在于后果。搜索框填错了，用户马上知道，因为结果不对。订阅框填错了，用户什么都不知道，他以为自己订阅成功了。本次样本里有几个站，页脚同时有订阅邮箱和搜索两个输入框，都没有标签，光看字节完全分不出哪个是哪个。

顺带说一句，这一块的按钮也常常是无名的——很多站的订阅按钮就是一个箭头图标。一个没有名字的输入框，配一个没有名字的按钮，这个组合在树上就是两个匿名节点并排站着。

搜索框是最该优先修的那一个

如果只能改一个输入框，改搜索框。理由有三条。

搜索框值得单独设计，从入口到结果的四层拆解把这个高转化入口讲透了。

第一，它几乎在每一页上都有，一处改动全站受益。第二，它是站内转化路径上最短的一条——用户用搜索找东西，意图最明确、转化率通常最高。第三，它恰恰是最容易只写占位符的那一个，因为设计上大家都不想在搜索框旁边再摆一行"搜索"两个字。

本次样本里，无标签输入框里搜索框占了相当一部分。一个每页都出现、承担高价值动作、又系统性缺标签的控件，投入产出比高得不像话。这种机会在技术优化里不多见，通常一件事要么便宜要么有效，很少两者兼得。

标题层级跳一级，机器会怎么理解？

标题这一层的结论比较微妙，需要分开说。

改标题会不会掉排名，改动本身不被罚改错内容才掉澄清了这个担心。

h1的分布

110个站里，首页没有h1的有28个（25.5%），有且只有一个的58个（52.7%），有多个的24个（21.8%）。

标题本身怎么写，10个技巧加5类高点击公式是内容侧的功课。

关于h1数量的争论已经吵了十几年，这里不想再吵。只说一个事实：h1有几个不重要，重要的是有没有一个标题告诉读者这一页是关于什么的。那28个没有h1的站里，多数是有h2的，视觉上也确实有个大标题——只是那个大标题被写成了div加大字号。

跳级的比例是45.5%

这个数字比想象的高。110个站里有50个，标题层级出现过跳级：h2下面直接接h4，或者h1下面直接接h3。

层级关系也体现在面包屑上，四种类型与结构化数据实操可以对照着看。

跳级的实际危害没有很多文章渲染的那么大，机器不会因为你跳了一级就读不懂。但它是一个非常好的信号：层级跳了，说明标题是按字号选的，不是按结构选的。而按字号选标题的页面，一般还会有别的结构问题。

保哥审站的时候有个偷懒办法：只把页面所有h标签的数字按顺序列成一串。本次实测里抓下来的几串长这样——一个站是"2322322233"，另一个是"333333333333231222222232"，还有一个是"41323232333333333334"。

第一串是正常的：二级下面挂三级，起伏有规律。第二串一看就不对：十二个三级排在最前面，一个上级都没有，说明这一大片内容在结构上是悬空的。第三串更乱，四级开头，然后一二三四轮着来，基本可以断定是几套模板拼在一起的。

这一串数字不需要任何工具，看一眼就知道这页的结构是设计出来的还是长出来的。保哥现在审站基本都是先看这一串，比跑任何评分工具都快，而且它给的是结构的形状，不是一个分数。

那些被写成div的标题

110个站里有9个站用了role="heading"，一共117处。这个属性的意思是"这个元素虽然不是h标签，但请把它当标题看"。

标题标签在AI时代的作用变了，8类骨架加实体信号的实战给了新的写法。

用它不算错，但它的存在本身说明了一件事：这9个站里有117个位置，视觉上是标题、标签上不是标题，只好用属性补一句。而这只是那些补了的。没补的有多少，从抓取数据里看不出来——一个被写成div加大字号的标题，在字节里跟一段普通文字长得一模一样。

这就是本文那句"视觉标题"问题的真实形态。它是所有结构问题里最难自动检测的一个，因为判断它需要同时知道"看起来像什么"和"标记成了什么"，而抓取只能知道后者。目前唯一可靠的查法是人打开页面，把每个看起来像标题的东西点开看一眼标签。好在这活量不大，一页十几处顶天了。

地标区域的情况

地标区域是给页面分区的：header、nav、main、footer这几个标签，或者对应的role属性。它们的作用是让不靠视觉的读者知道"从这里开始是正文"。

分区之上还有整站结构，架构搭错爬虫找不到产品页讲的是更大的一层。

110个站里，四个齐全的76个（69.1%），有main的94个（85.5%），有nav的97个（88.2%），有footer的101个（91.8%），一个都没有的4个（3.6%）。

这一项的表现明显好于其他项，原因大概是这些标签写起来最省事——用header替代div不需要额外工作量，反而更短。凡是"做对不比做错麻烦"的事，行业整体表现就不会太差。这个规律在别的地方也成立，可以当成排优先级时的一条经验：那些需要额外动作才能做对的项，才是真正需要靠流程去保证的。

还有个细节：94个有main的站里，有7个不是用main标签，而是给一个div加了role="main"。这个写法完全有效，但它通常意味着这套模板的年纪比较大，是在语义标签普及之前写的，后来打了补丁。看到role属性替代原生标签，可以顺手估一下这套代码的年龄，往往能解释别处的一些奇怪写法。

主动把内容藏起来的那几个站

还有一个属性值得单独说：aria-hidden。给一个元素加上这个属性并设为true，等于告诉所有不靠视觉的读者"这块跳过，别读"。

跳过渲染也可能藏掉内容，content-visibility的机制实战说明了边界在哪。

它的正当用途很多——装饰图形、重复出现的图标、已经被别处描述过的内容，都该这么标。110个站里这个属性一共出现了4652次，绝大多数属于正当使用。

但有8个块不太一样：它们各自藏起了超过300个字符的纯文字。分布在5个站上。三百多个字符是什么概念？大概是一段完整的商品介绍，或者一条完整的促销说明。

这种情况通常有两个来源。一个是弹窗或者抽屉式导航——它在关闭状态下被整体标为隐藏，这是对的，但如果脚本在打开时忘了把这个属性改回来，那它就永远是隐藏的。另一个是某次为了解决读屏软件重复朗读的问题，粗暴地把一整块标了隐藏，把该读的一起带走了。

这一项特别值得查，因为它的性质跟别的都不一样：别的项是忘了给信息，这一项是明确下令不要读。一条主动发出的错误指令，比一个被动的遗漏危害大得多，而且它绝对不会出现在任何"缺失项"的报表里——从任何自动化工具的角度看，这块内容有标签、有文字、结构完整，一切正常。

main标签有一个被低估的用途

main这个标签除了给读屏软件分区，还有一个越来越重要的用途：它是"正文从哪开始"的最明确的一句声明。

让AI读得懂引得出，GEO技术端的抓取渲染提取三步把这条链讲全了。

任何一个想从你页面里提取内容的程序，都要先解决一个问题——满页的导航、页脚、推荐位、弹窗里，哪一块是这一页真正要说的事。没有main标签，它只能靠猜，常用的猜法是找文字最密集的那个块。有main标签，这个问题就没有了。

这是本文所有检查项里，成本最低、说明力最强的一个。加一个标签，把一个需要推断的问题变成一个可以直接读的事实。85.5%这个数字已经不低，剩下那16个站补上，是半天的活。

那次尺子失效是怎么被发现的？

现在讲这篇文章里最该被记住的一段。上面所有关于无障碍树的数字，第一版全是错的。

样本边界决定结论边界，调研数据里没有非会员结论却写给非会员是同一个病。

第一版的数字

第一次跑完170个站，结果是这样：一个地标区域都没有的占22.9%，没有h1的占47.1%，连一个标题标签都没有的占30.6%。

没有对照组就会虚高，74%的差异补上对照后只剩2.2%是同一类教训。

这三个数字，任何一个单独拿出来都够写一篇标题很吓人的文章了。三成的独立站首页连一个标题标签都没有，听着像行业末日。

发现问题的过程

保哥的习惯是在写结论之前，把最极端的那批样本逐个打开看一眼。这次打开的是"一个标题标签都没有"那52个，第一个是aesop.com，第二个是aliexpress.com，第三个是anker.com。

翻明细是唯一的防线，Google抓取报告里五类问题URL的排查顺序也强调这一点。

看到第三个的时候就不对劲了。anker.com刚刚在前半篇里出现过——它是那个2兆HTML零个字符的站。它当然没有标题标签，它连一个字都没有。

再往下扫，52个里有一大半是同一批空壳页。

问题出在哪

问题不在尺子的算法，算法是对的：这些页面确实没有h1，确实没有地标。问题在于这把尺子被用在了它不该量的对象上。

想知道谁真的来过，日志分析一步步挖真相比任何推断都实在。

量一个页面的语义结构，前提是这个页面有内容。一个还没渲染的空壳，它的语义结构不是"差"，是"还不存在"。把它算成"结构差"，等于批评一张白纸排版难看。

这个错误跟以前踩过的坑都不一样。以前的失效都是判据本身写错了——词表分不清、基准没定好。这次判据完全正确，错的是样本边界。一把准确的尺子用在错误的对象上，产生的错误数据比一把不准的尺子更难发现，因为每一条记录单独看都是对的。

三种尺子失效，三种不同的病

把这几年踩过的坑摆在一起，形态其实很清楚：

判断力比工具重要，只会蛮力的SEO为什么被淘汰说的是同一件事。

三种病的共同点是它们都让问题看起来更严重，从来没有一次是让问题看起来更轻的。这个方向性很值得琢磨。

保哥后来想明白了：因为尺子是奔着"找问题"做的，它的每一处模糊地带，默认都会倒向"这是个问题"。写规则的时候没有人会故意留一条"拿不准就算通过"的分支，于是所有拿不准的情况都堆到了"不通过"那一边。

所以有一条实用的自查：跑完一把新尺子，先看它有没有弃权的能力。一把只会说"通过"和"不通过"的尺子，一定在某个地方虚高。一把在没把握的时候会说"这个我判断不了"的尺子，才可能是诚实的。本次这把改完之后，空壳页就是它的弃权区——不是判它差，是判它不适用。

修正之后的对比

被广泛相信的数字未必成立，重复内容惩罚这个说法其实从来不存在。

最夸张的一条虚高了11倍。而且注意最后一行：好的结论被同样的机制压低了，方向相反，幅度也不小。

那一版差点就发出去了

说句实话：那三个虚高的数字，当时已经写进初稿了，而且写得挺顺手——三成的独立站首页连一个标题标签都没有，这句话既有冲击力又有数据支撑，读起来毫无破绽。

拦下它的不是任何工具，也不是复核流程，是一个习惯：在写结论之前，把最极端的那一批样本逐个打开看一眼。这个习惯很笨，很花时间，一次要看十几二十个页面，而且绝大多数时候什么问题都看不出来。

但它是唯一有效的。所有自动化的检查，检查的都是"计算过程对不对"，而这类错误发生在计算开始之前——发生在决定"哪些东西进入这次计算"的那一步。没有任何一个程序会质疑你给它的输入名单，它只会认认真真地把错误的输入算得一丝不苟。

这也是为什么保哥每次量完东西，都要留一节专门讲量的过程。不是为了显得严谨，是因为一篇只给结论不给口径的文章，读者没有任何办法判断它有没有犯这个错。而这个错，从数字表面是绝对看不出来的。

为什么这类错误特别难被发现

因为它没有任何异常特征。

看着整齐的高比例最该警惕，76%改写率那个数字也得看它怎么算出来的。

一把算错的尺子，通常会露马脚：某个站的数字大得离谱，某个分类一条都没有，某两项互相矛盾。这些都是可以被察觉的。而这次的每一条记录单独看都完美无缺——anker.com的地标数量确实是零，这个记录没有一个字段是错的。

错误不在任何一条记录里，错误在"这条记录该不该出现在这张表里"。而这个问题，表本身回答不了。

更麻烦的是，这类错误的方向是系统性的，不是随机的。随机误差会互相抵消，越多样本越准。系统性偏差不会——空壳页在每一项上都会算成"最差"，样本越多，偏差越稳定地把结论往一个方向推。看到一个特别整齐、特别符合预期、特别适合当标题的数字，反而应该警惕。

这条教训该怎么用

提炼成一句可操作的：在跑任何结构类审计之前，先问一句"这批样本里，有多少个根本不该被这把尺子量"。

回到基本盘，抓取、索引、排名三步是判断任何前提的起点。

判断方法也简单，跟这篇文章前半段是同一个动作：先量每个页面的可读正文长度，把明显不到线的挑出来单独成一组。它们不该被算成"结构差的站"，它们该被算成"另一个问题的站"。

再往上提一层，这其实是一条通用的经验：任何一把尺子都有一个默认前提，而这个前提一般不写在文档里。量结构的尺子默认页面有内容，量转化率的尺子默认流量是真人，量停留时长的尺子默认用户没开着标签页去吃饭。用尺子之前把这个默认前提找出来，然后去数有多少样本不满足它——这个动作花不了十分钟，但它是保哥吃过好几次亏之后唯一留下的防线。

那条1200字符的线是怎么划的？

上面反复用到"空壳"这个分类，判据是可读正文小于1200字符。这个数怎么来的，得交代一下，不然整篇文章的地基是虚的。

首页铺太多也会牵出URL问题，筛选器URL不爆炸的系统方案给了八步做法。

先看数据自己怎么说

把132个站的正文字符数排序，会看到一个非常明显的双峰：一堆挤在0到500之间，另一堆从1200往上一直铺到两万多，中间500到1200这一段只有3个站。

分布怎么看，服务器日志分析工具给了现成的分桶方式。

这条线不是我划的，是数据自己裂开的地方。1200这个数落在那道缝里，往左移到500或者往右移到2000，被分类的站只会变动两三个。一个稳健的阈值就该是这样——挪一挪结果不怎么变。

边界上那几个站

紧挨着线右边的几个：joolz.com正文1262字符，ecoflow.com 1464，nespresso.com 1503，peakdesign.com 1682。

边界情况最容易漏，抓取速率被调低却一条错误都没有就是这么发生的。

这几个都被算成了"正常页"，但说实话它们也没正常到哪去。1262个字符对一个电商首页来说，大概就是导航加页脚的量，商品区多半还是靠脚本画的。

所以这条线的正确读法不是"过线就没事"，而是"过线之后要看的是别的问题"。分类的作用是把不同性质的问题分开处理，不是发及格证。

如果换一个口径

值得说一句：如果不用字符数，改用"首屏商品名有没有出现在HTML里"这类内容级判据，分类结果会更贴近实际，但可复现性会大幅下降——不同品类的首页放什么根本不一样，一个家具站和一个美妆站的首屏完全没有可比的元素。

口径要能复现，一个尾逗号就让整页结构化数据失效说明细节有多要紧。

字符数这个口径粗，但它对所有站一视同仁，而且任何人拿同样的方法都能复现出同样的数字。在做横向对比的时候，可复现性比精确性重要。

这条原则值得展开一句，因为它经常被误解成"糙一点没关系"。不是的。它说的是：当你要比较很多个对象的时候，一把所有人都能拿到同样读数的粗尺子，胜过一把只有你能用好的精细尺子。因为横向对比的价值全在"可比"这两个字上，尺子一旦因人而异，所有排名都失去意义。

换成自己站的纵向监测，结论就反过来了：这时候没有可比性问题，用越贴近业务的判据越好。横向用粗尺子，纵向用细尺子，这是两种完全不同的测量任务，经常被混为一谈。

把这条线用在自己站上

如果你要照着这套方法量自己的站，1200这个数不要直接搬。它是从这批国际化独立站首页的分布里长出来的，换一批样本，那道缝的位置会变。

一个站两套技术栈很常见，插件和主题冒出两套标记怎么归一是同源问题。

正确的做法是：把你自己站上各类页面各抓十几个，量出正文字符数，画一下分布。如果分布是连续的，说明你的站在这件事上是一致的，那就不需要分类；如果出现明显的双峰，那道缝就是你的线。

多数站的结果是第一种——同一套模板出来的页面，输出方式是一样的。出现双峰通常意味着站上有两套技术栈，比如商品页是服务端渲染的老系统，而某个新做的活动频道是纯前端的。这种情况在做过几次改版的站上很常见，而且往往没人记得还有这么一块。

怎么判断一个缺失是真缺，还是只是没渲染？

这是整篇文章最实用的一节，因为两种情况的修法完全不同。

有一整类抓取器规则不同，Google不看robots.txt的那类抓取器值得单独了解。

三步判断法

第一步，把页面用命令行抓下来，看可读正文有多少。这一步决定了后面所有检查有没有意义。如果正文接近零，别的都不用查了，先解决输出问题。

抓取和渲染分几步，看懂才知道哪里丢内容把流程拆开了讲。

第二步，如果正文正常，那就在字节里找那个具体的东西。找按钮的名字，找图片的alt，找main标签。找得到就是有，找不到就是没有，不需要争论。

第三步，只有在字节里找不到、但你确信页面上有的时候，才需要区分"是不是渲染后才有"。这时候打开浏览器的开发者工具，在元素面板里找无障碍相关的那个窗格，把整页的无障碍树打开看，重点看这个节点在树上叫什么。

第三步的三种结果

第三步会得到三种结果，对应三种完全不同的处理方式。

调试这类问题的工具链，JSON格式化与结构化数据调试是常用的一环。

第一种，树上有名字。那说明脚本在运行时补上了。这种情况下，问题只对不执行脚本的读者存在，要不要处理取决于那类读者对你重不重要。这是唯一一种可以"知情之后选择不处理"的情况。

第二种，树上也没有名字。那就是确凿的缺陷，跟渲染没关系，读屏软件用户此刻正在遭遇它。这种要修，而且优先级不低。

第三种最有意思：树上有名字，但名字是错的。比如按钮上明明写着"加入购物车"，树上的名字却是"button-4"，或者是一串组件生成的编号。这种情况多半是有人给元素加了aria-label，而那个值是从代码里带出来的、不是给人看的。这一类比没有名字更糟——没有名字至少还能靠周围的上下文猜，一个错误的名字会把猜的路也堵死。

两种情况的修法是相反的

如果字节里就没有，那是内容交付问题，要动的是渲染方式——服务端渲染、预渲染、或者至少给一份能读的降级内容。这件事的成本按项目算，不按页面算。

JS渲染抓不到该从哪查起，这几种情况的排查顺序是现成的路线。

如果字节里有、渲染后反而没了，那是脚本把它改坏了，要动的是那段脚本。这件事的成本按缺陷算，通常改一处就好。

把这两件事搞混，最典型的后果是拿改缺陷的力气去解决交付问题，改了三个月发现指标一动不动。

反过来搞混也很常见，而且更浪费：把一个几行代码就能修的缺陷，当成架构问题上报，于是它进了一个需要评审、需要排期、需要跨部门协调的流程，半年之后还在待办列表里。判断成本高低的第一个动作，就是先分清它是哪一类。

一个具体的分诊例子

假设你发现商品页上的"加入购物车"按钮，在抓下来的HTML里找不到名字。接下来怎么走？

分诊之后怎么排优先级，从AI爬虫到无障碍的42步实战给了一份完整清单。

先看同一份HTML里有没有商品名和价格。如果有，说明这一页整体是服务端输出的，只有这个按钮出了问题——那就是个组件缺陷，去找那个组件，加一个名字，改动量大概一行。

如果连商品名都找不到，那这个按钮没有名字只是表象，真正的问题是整页都没输出。这时候去改按钮组件是白费力气，因为改完之后那个按钮照样不在字节里。

同一个现象，同一句"按钮没名字"，背后是两个成本差三个数量级的问题。区分它们只需要多看一眼旁边有没有商品名，十秒钟的事。这十秒钟省下来的力气，比这篇文章里任何一条建议都多。

关于执行脚本这件事的现状

需要说清楚一个事实边界：主流搜索引擎的抓取程序是会执行脚本的，这一点官方文档写得很明确，只是执行有排队、有资源上限，不保证每次都完整。而当下大量新出现的读取程序——各类AI训练与检索用的抓取器——多数不执行脚本，只读原始字节。

要不要拦这些程序，robots加UA加WAF的三层选型框架给了决策路径。

读你页面的名单变了多少，AI爬虫抓取量已超Googlebot 3.6倍有实测数据。

所以同一个空壳首页，对不同读者是两个完全不同的结论。这不是"要不要为SEO做服务端渲染"的老问题，这是"你的读者名单变长了"的新问题。名单变长的部分，恰好都是不执行脚本的那种。

这个变化的时间点很值得注意。服务端渲染这个话题在2016年前后吵得最凶，那时候的结论大致是"搜索引擎已经能渲染了，不必过度紧张"，这个结论在当时是对的。之后这件事就淡出了很多团队的检查清单，新一批前端工程师入行时，它已经不是一个需要讨论的问题了。

结论没变，前提变了。当年那个结论成立的前提是"读你页面的只有会渲染的搜索引擎"，这个前提在最近两年悄悄失效了，而失效的过程没有任何一次公告。这就是为什么值得重新量一遍——不是因为出了新规则，是因为老结论的地基被换掉了。

有个说法要澄清一下

经常听到一种说法：既然那些程序不执行脚本，那它们本来也读不好网页，不用太在意。

这个说法把因果搞反了。它们不执行脚本，不是因为技术做不到，是因为不划算。执行一整套前端脚本的成本，是纯读字节的几十倍，还要维护一整套浏览器环境。当抓取量以亿为单位的时候，这个差价决定了谁能活下来。

换句话说，这不是一个会随时间自动改善的问题。成本结构不变，行为就不会变。指望对方升级，比自己多输出一份HTML要难得多。

还有一种说法是"重要的内容它们会想办法拿到"。这个也不太站得住。对一个批量抓取的程序来说，判断哪一页重要本身就需要先读懂这一页，而读不懂的页面连进入这个判断的资格都没有。它不是把你排在后面，是根本没把你放进队列。

怎么估自己站受影响的程度

不用猜，日志里有答案。把最近一个月的访问日志按用户代理串分组，把那些明确自报家门的抓取程序挑出来，看它们各自的请求量占比。

日志里怎么分类，8类UA实测与22周访问账本给了可照搬的方法。

然后做一个简单的判断：这些程序里，有多少是会执行脚本的。搜索引擎的主抓取程序会，绝大多数其他的不会。把不会的那部分请求量加起来，除以总抓取量，就是你这个空壳问题的实际影响面。

这个比例在不同行业差别很大。内容型站点通常高，因为它们的文字更容易被这类程序盯上；商品型站点低一些，但也在涨。关键是这个数字你自己算得出来，不需要相信任何人的估计。

如果短期内改不了渲染方式

把整站改成服务端渲染，是一个按季度算的工程，很多团队短期内确实做不了。这种情况下有几件成本低得多的事可以先做，效果不如根治，但比什么都不做强很多。

预渲染这条路怎么走，Speculation Rules API的机制实战是相邻的技术选项。

第一件，把最重要的那几类页面单独做预渲染。首页、主要分类页、销量最高的那批商品页，加起来可能就几百个地址。预渲染只需要在构建时把这些页面跑一遍存成静态文件，不需要改运行时架构。这件事通常是一两周的量。

第二件，用noscript留一份精简正文。这个做法有点土，但它诚实、有效、几乎零成本。里面不需要放完整页面，放清楚"这一页是什么、有哪些主要内容、去哪能看到"就够了。本次样本里只有1个空壳站这么做了，说明这条路基本没人走——不是因为不好用，是因为没人想起来。

第三件，检查一下你的站点地图和结构化数据有没有把这些空壳页当成正常页在推。如果一个页面在字节层面是空的，把它推给更多程序去抓，只是让更多程序确认了它是空的。先把内容补上，再谈推广。

这三件事有个共同点：都不需要动前端架构，都可以由做技术优化的人独立推动。在等待架构排期的那几个月里，它们能把损失控制在一个可接受的范围内。

这套自查要花多久，从哪一步开始？

把上面所有东西收成一个能在一个下午跑完的清单。

批量打开页面手工看一眼，网址批量打开工具的实测说明了它能和不能做什么。

第一个动作：三分钟

用命令行抓一次你自己的首页，把标签剥掉数字符。如果这个数小于1200，后面的检查全部暂停，先去开会讨论渲染方式。

把HTML转成可读文本，Markdown与HTML双向转换也能顺手完成这一步。

如果这个数正常，顺手再抓一个商品页和一个分类页。首页往往是全站最特殊的一页，别拿它代表全站。这个教训保哥在别的检查里反复吃过。

第二个动作：十分钟

在HTML里数四样东西：有没有main标签，h标签的数字序列长什么样，有多少img没有alt属性，有多少input拿不到标签。

同一趟还能顺手查结构化数据，一次扒清五种格式的字段缺漏省一遍功夫。

这四样都能用最朴素的方式数出来，不需要任何工具。数出来之后跟本文的数字对一下，下面这张表可以直接当参照：

你比这几个数好，说明这一项不是你的优先项；比它差，说明这是个能低成本拉平的地方。注意这批站是行业里做得比较认真的一批，所以这些数字更像是及格线而不是优秀线。

第三个动作：半小时

打开浏览器开发者工具，把首页的完整无障碍树导出来看一遍。重点看四个位置：主要的行动按钮有没有描述性的名字，导航有没有被包在导航地标里，主内容区在树上是不是可读的文本，以及有没有大块内容被标成了隐藏。

想边改边看效果，三栏实时预览的HTML编辑器比来回刷新快得多。

这一步是唯一需要真浏览器的，也是唯一能看到"渲染后真相"的。前两步可以排除大部分问题，这一步用来确认剩下的。

看的时候有个小技巧：不要顺着树从上往下读，那样很容易被结构带着走。换个方式——先在页面上挑五个你最不想让用户点错的元素，比如加入购物车、结算、提交、切换规格、关闭弹窗，然后逐个到树上去找它们叫什么。五个都对，这一页基本没大问题；有一个叫不出名字，那多半是一整类组件的问题。

如果要把它变成常态检查

上面三个动作是一次性的排查，做完能知道现状。要让它不再退化，得挑一两项做成自动的。

常态检查还该包含链接健康，改版后全站404与重定向链的排查是配套项。

推荐做成自动的只有两项：关键页面的可读正文字符数，和关键控件的可访问名。前者用一个定时抓取加字符统计就够，掉到阈值以下告警。后者需要在自动化测试里加一条断言，把首页的无障碍树快照存下来，之后每次改动跟它比一下，有节点丢了名字就报出来。

其余各项不建议做成自动检查。它们的误报率高到会让人很快学会忽略告警，而一个被忽略的告警比没有告警更糟——它会让所有人以为这件事已经被监控了。

一个容易被跳过的动作：换个身份再抓一次

上面三个动作都是用普通浏览器的身份去请求的。有一件事值得顺手做：把请求的身份换成一个抓取程序的标识，再抓一次，看两次拿到的字节是不是一样。

这个动作的成本几乎为零，就是加一个参数。但它能查出一类前三步完全看不见的问题：你的服务器或者前面那层防护，可能对不同身份给出了不同的答案。本次实测里确实有站是这样，而且差异大到不可能是偶然。

如果两次结果不一样，接下来要判断的是哪一边不对。给浏览器的多、给程序的少，那是内容没交出去；反过来给程序的多、给浏览器的少，那通常是某种为抓取做的特殊处理，风险更大一些。

这件事跟本文主题只沾了一半的边——它查的不是"东西在不在"，而是"东西有没有被送到"，那是另一层问题。但既然抓都抓了，多抓一次几乎不费什么事，顺手排除掉一整类可能性。

把这次的数字存下来

做完前三步，一定要把结果存成一份带日期的记录，哪怕就是一个表格文件。这一步经常被跳过，但它决定了这次排查有没有长期价值。

记录要带时间，从sitemap的lastmod到结构化数据日期都得靠时间戳对齐。

原因很实际：这些指标的绝对值意义有限，变化才有意义。你的首页正文有5800个字符，这个数好不好？不知道。但如果三个月后变成了1200，那就是一件必须立刻查清楚的事，而且几乎可以肯定跟某次改版有关。

存的时候记得连口径一起存——用了什么用户代理串、哪一天抓的、剥标签的规则是什么。半年后重跑一次，如果口径变了，两次的数字就没法比，这份记录也就白存了。保哥吃过这个亏，翻出一份两年前的审计表，数字都在，但当时怎么算的一个字都没写，只能从头再来。

还有一个小建议：把行业参照值也记在同一份表里。这样下次看的时候，不用再去翻文章找那几个百分比。

把结果说给不同的人听

这套检查跑完，会得到三堆完全不同性质的问题，而它们需要说给三拨人听，说法还不能一样。

沟通方式也是能力的一部分，给SEO人的个人审计五步法里有相关的提醒。

正文输出问题要说给做技术决策的人听，因为它涉及架构选择和排期，说法应该是"我们有多少页面对不执行脚本的读者是空白的，这些读者占抓取量的多少"。不要说"我们没做服务端渲染"，那是手段不是问题。

组件层的问题——按钮名字、表单标签——要说给做前端的人听，说法应该是具体的组件名和具体的改法。这类问题的沟通成本最低，因为它们是明确的、可验证的、改完立刻能确认的。

内容层的问题——图片替代文本写得对不对——要说给做内容和设计的人听，而且要给判据不要给清单。给清单会得到一堆敷衍的填空，给判据才会得到能用的文字。

不建议做的事

不建议一上来就跑一个综合评分工具，然后照着分数改。这类工具会把上面说的三层问题混在一起给一个总分，而三层的修法完全不同、成本差几个数量级。先分类，再打分，顺序反了会浪费很多力气。

综合评分工具的局限，AMP验证器的八大类规则是个可对照的例子。

也不建议把这些检查项变成一张需要人工填写的上线检查表。人工检查表的寿命通常是三个月，之后它会变成一个所有人都勾但没人看的仪式。能自动检测的就自动检测，检测不了的就写进组件默认值，两条路都走不通的才写进检查表。本文这些项里，前两类能覆盖绝大部分。

把无障碍当成SEO手段，这条线该画在哪

最后必须说一段立场，因为前面全篇都在用"机器读不读得到"当理由，这个理由本身是有边界的。

动机和后果要分开谈，AI写的内容会被惩罚吗也是在澄清因果。

顺序不能颠倒

无障碍这套东西的存在理由是残障人士的使用权，这一点跟搜索、跟AI、跟流量都没关系。它在很多国家和地区是法律要求，在所有地方都是基本的产品责任。

无障碍不止网页，PDF的标签结构与阅读顺序是同一套思路在另一种格式上。

因为机器读得到所以去做无障碍，这个动机会在某一天失效——某天机器变强了，能靠视觉理解页面了，按这个逻辑就该不做了。而那一天到来的时候，需要读屏软件的人一个都没有减少。

那这篇文章的立场是什么

是这样：这些检查项你本来就该做，做了之后顺带会让机器也读得懂。顺序是"做对了，所以机器也能读"，不是"机器要读，所以做一下"。

把内容当结构来生产，内容工程这套新手艺说的是流程而不是清单。

实际操作上这两个顺序的产出会不一样。按第一个顺序做，会把整个流程改掉，组件规范里加上标签要求，以后新写的页面自动就是对的。按第二个顺序做，会挑几个重要页面手工补一遍，三个月后新上的页面又是老样子。

差别的根源在于覆盖范围。为机器做，只需要覆盖那些机器会去的页面；为人做，得覆盖所有页面。前者的终点是一份清单，后者的终点是一套默认值。而只有默认值才不会退化。

顺便说一个容易被忽略的事实

需要无障碍支持的人，比多数人想象的多得多，而且不只是完全失明的用户。

看不见的流失最难发现，那排标签让用户没法把两块信息放进同一屏也是这一类。

视力低下需要放大、色觉有差异需要靠文字而非颜色区分、手部不便只能用键盘、在嘈杂环境里只能看不能听、临时性的比如手上打着石膏或者抱着孩子只能单手操作——这些人在任何一个电商站的日活里都占着相当可观的一块，而且他们中的绝大多数不会告诉你他们遇到了困难，他们只会离开。

一个没有名字的按钮不会产生任何一条报错，也不会出现在任何一张转化漏斗的报表上。它只会表现为某一小撮用户在那一步的流失率略高一点，而那一点会被淹没在噪声里。这可能是本文所有内容里，唯一一条跟机器完全无关、但比所有机器相关的理由都更该被听见的。

一个现实的建议

如果你在一个把商业指标看得很重的团队里，很难只靠"这是应该做的"推动这件事，那么本文这些数字可以当成一个补充论据，不是唯一论据。用它去争取排期，别用它去定义目标。

排期时需要一份完整的说法，GEO从AI搜索到结构化数据的实施策略可以当框架用。

这两者的区别在验收的时候会显出来。用它定义目标，验收标准会变成"无名按钮数降到多少以下"，团队会去做那些数字上最划算的改动，而真正影响用户的那几个控件可能一个都没动。用它争取排期，验收标准还是"这些控件能不能被读屏软件正常使用"，数字只是排期时的说服材料。

如果站点规模大，或者所在行业有明确的无障碍法规要求，请找专业的无障碍顾问，别拿这篇文章当验收标准。这篇文章量的只是那些能从字节里看出来的部分，它离一次真正的无障碍审计还差很远——真正的审计要看键盘能不能走通全流程、对比度够不够、动效能不能关掉、读屏软件实际念出来是什么，这些都不是抓一次HTML能回答的。

最后回到那个五兆的页面

写到这里，可以把开头那个例子的完整含义说清楚了。

把地基打对，实体主页与品牌身份的搭法是这套思路的另一面。

那个站传了两兆多字节，一个字都读不出来，同时它写了标题、写了描述、放了结构化数据。这不是一个不专业的站，恰恰相反，它每一样单独看都做得挺规范。

问题出在没有人问过那个最笨的问题：我们发出去的东西里，到底有没有字。所有人都在检查各自负责的那一项，没有人负责检查这些项加起来是不是构成了一个能读的页面。

这篇文章从头到尾其实只在推荐一个动作：抓一次，剥掉标签，数一下。三分钟，不需要工具，不需要权限，不需要跟任何人商量。三分钟之后你会知道，接下来该讨论的是哪一层的问题。

常见问题解答

我的站是单页应用，是不是一定有问题？

不一定，关键看有没有做服务端渲染或者预渲染。单页应用只是描述前端架构，不决定输出什么字节。本次样本里跑单页框架但正常输出HTML的站不少，也有用传统模板引擎却把内容全塞进脚本的。架构名词说明不了任何事，字节能。判断方法只有一个：抓一次，数字符。这个动作三分钟，比在群里讨论半小时有用得多。

PWA也有类似问题，8类抓取与索引影响的实战可以对照判断。

Google能渲染脚本，那我是不是不用管？

如果你的目标只有搜索引擎，风险确实小一些，但也不是零——官方明确说过渲染有排队、有资源限制，不保证每一页都能完整执行。页面越多、更新越频繁的站，排到的概率越不确定。

渲染要排队，抓取预算优化的12项实操解释了资源是怎么分配的。

而现在来读你页面的不止搜索引擎，各类AI检索与训练用的抓取器大多不执行脚本。所以这个问题的答案在这两年变了：以前是"影响有限"，现在是"影响取决于你在乎哪些读者"。要把这个问题变成一个可以决策的问题，去日志里数一下不执行脚本的那类请求占多少。

那我把内容塞进结构化数据是不是就行了？

不行，这是本次数据里最明显的一个误区。有几个站的结构化数据比正文长几十倍，看起来很努力，但结构化数据的作用是描述实体和关系，不是承载正文。它是目录，不是书。

结构化数据该怎么配合，Schema的落地方式与常见避坑说得比较清楚。

而且这么做在规范上是有风险的：结构化数据描述的内容通常要求在页面上真实可见。当结构化数据里写着商品名和价格，同一份字节里的正文却是空的，这个对应关系严格说是断的。实际执行中很少有人因此被处理，但把它当成长期依赖的做法并不稳妥。

alt到底该写多长？

写到"这张图去掉之后你需要补的那句话"为止，通常十几个到三十几个字符。太短的问题是没信息量，比如写"图片"、"banner"、"product"；太长的问题是变成了正文，那些话该写在正文里。

文字进图片这件事也有坑，OG图生成器把emoji切成方块是个具体教训。

装饰性的图直接写空字符串，这是明确表态，不是偷懒。本次数据里24.1%的图是空alt，这个比例本身很健康。需要警惕的是另一种情况：商品主图空着、旁边的装饰角标反而写了字，那是信息层次被写反了。

placeholder能不能代替label？

不能。placeholder在用户开始输入的那一刻就消失了，它是提示不是标签。用户填到第三个字段忘了这一格填什么，只能全部删掉重看一眼——这个体验问题跟机器读不读得到无关，它本身就是个缺陷。

这类细节的收益常被低估，被低估的9个反直觉杠杆收集了不少类似的。

如果设计上确实不想显示标签文字，正确做法是保留label但在视觉上隐藏它，或者给输入框加aria-label。本次样本里有好几个站是整套表单组件全部无标签，ritual.com的22个、mejuri.com的14个、allbirds.com的13个都是这种形态。整齐的全军覆没说明它是组件层面的选择，改一处就能全好。

首页测完了，其他页面要不要都测？

不用全测，但一定要测不同类型的各一个：商品页、分类页、内容页各取一个。首页在很多站上是最特殊的一页，用的模板跟别的页面完全不同，往往还是改版时最先被重做的那一个。

分类页最容易被忽略，用户点进来那一屏没有一个字写着他在哪就是实例。

更值得测的是那些"不太起眼但流量不小"的页面：搜索结果页、筛选后的分类页、专题活动页。这几类最容易由不同的人在不同的时期用不同的方式做出来，也最容易游离在所有检查流程之外。

为什么无名按钮的比例只有8.2%，但受影响的站有37%？

因为分母不同。8.2%是按按钮个数算的，37.3%是按站算的——只要一个站有一个无名按钮就计入。这两个数不矛盾，它们回答的是两个问题：整体质量怎么样，和这个问题普不普遍。

口径这件事在别处也一样，13种Schema类型该怎么选同样要先分清对象。

用哪个口径取决于你要干什么。做横向对比、判断一件事值不值得关注，看站的口径；给自己的站排改进优先级，看个数的口径。本文所有指标都同时给了两个口径，就是因为这两个问题经常被混在一起问。

svg没名字算不算错？

要看它在哪。如果外面包着一个有名字的按钮或者链接，那这个svg本来就该被标成装饰性的，没名字是对的，甚至可以说是正确做法——图标和它所在的控件不该各有一个名字，那会被读两遍。

图形处理的基本功，8种按比例缩放的前端方案是相邻的实务。

如果它是唯一的内容、外层也没名字，那就是硬伤。本次数据把这两类分开数过：前一类数量很大（3906个）但多数无害，后一类264条是确凿的问题。汇报的时候只报后一类，报前一类会被技术同事当场问倒，而且他们是对的。

这套检查多久做一次？

触发式比定期式实用。换模板、上新的组件库、大改导航、迁移前端框架，这四件事之后各做一次。它们是结构问题最容易被批量引入的时机——一次组件改动能同时影响几十个页面上的几百个元素。

配置每次都通过不代表没事，每8次抓取有1次撞在301上是同类的隐形退化。

如果一定要个周期，配合改版节奏走就行，为它单独排期通常排不上。更省事的办法是把最粗的那一项——正文字符数——做成一个定时任务，掉到线以下就告警，剩下的靠触发。

团队里这件事该归谁？

这是本次数据背后最真实的一个问题。标题和描述归做搜索的人，渲染方式归做前端的人，两边各自都做得对，中间那条缝没人负责。本次那张头部信息完备度的表，实际上就是这条缝的照片。

设计侧也有对应的动作点，从IA到Figma落地的7个协作动作能补上另一半。

比较务实的做法是把几条检查写进组件规范和自动化检测，让它变成默认行为，而不是靠某个人记得去查。靠人记得的事，撑不过一次人员变动。

我该先修哪一项？

按成本和影响排：正文输出问题排第一，它决定别的检查有没有意义；表单标签排第二，因为它一般是组件级的、改一处全好，而且直接影响真实用户；图片alt排第三，工作量大但可以分批做，而且可以跟内容更新一起做；标题层级和地标排最后，它们的实际危害最小，通常在改版时顺手就修了。

排优先级要看影响面，URL结构与slug的9个细节也是这么权衡的。

如果只有半天时间，就做两件事：给搜索框加标签，给页面加main标签。这两件加起来不到一小时，覆盖的是所有页面。

权威参考资料

摘要：把87个电商与DTC站的站点地图全量拉下来，21.9万个网址逐个拆词归一，找出那些“用词完全相同、只是拼法不一样”的网址组。76个站里都有，占87.4%，一共2390组、6109个页面。其中六成是同一个名字后面挂着1、2、3的序号，两成是多一个词少一个词，还有130组是把同样几个词换了个顺序重写了一遍。

先说这批数据是怎么来的。有人问过一个很实际的问题：手上有个关键词，跟现有页面挨得很近，到底该不该单独开一页。这个问题的标准答法是做一次页面独立性测试——比对搜索结果、比对内容大纲、确认站点结构里有没有它的位置。

这套方法没问题，但它有个前提：你得先知道自己现在有多少页面已经在干同一件事。而这个前提，多数站是不成立的。

你以为在决定要不要多开一页，实际上你的站上可能已经有三页在讲同一件事了，只是它们的网址长得不一样，所以你没发现。这篇文章要量的就是这个数。

一个关键词该不该有自己的页面，这个判断卡在哪？

先把那套方法说清楚，因为后面的数据是给它补前提的。

三步走的判定流程

第一步查现有覆盖：翻后台数据，看哪些页面已经在这个词上拿到了展示，顺便找出互相打架的网址。第二步跑独立性测试。第三步根据结果选动作：新建、扩写、合并，或者做成可复制的模板。这套三步判定法的原文写得比我这里细，值得对着自己的站读一遍。

一个页面能吃下多少词，次要关键词怎么布局才不堆密度讲过一次。

核心的判断标准是一句话：一个词值得单开一页，当它能带来一组区别得开的查询、能支撑起真正不同的内容、并且在站点结构里有位置。三个条件缺一不可。

三个条件里，第一个最难自己判断，因为它取决于引擎怎么看；第二个最考验诚实，因为写的人总觉得自己能写出不一样的；第三个最容易被跳过，因为它牵涉到导航和内链，动起来麻烦。

这三个条件的顺序有讲究

看起来是并列的三条，实际上有先后。结构位置应该最先确认，因为它是唯一一个不满足就直接否决的条件。一个在站点结构里没有位置的页面，即使查询区分得开、内容也写得出来，它上线之后也是个孤岛。

结构位置这一条最实在，架构搭错爬虫根本找不到产品页。

查询区分度排第二，因为它决定了这一页有没有独立存在的外部理由。内容差异排最后，因为它是你可以通过努力去创造的——前两个不行，后一个再努力也没用。

实操里我见到的顺序常常是反的：先想到一个内容角度，觉得能写，于是决定建页；建完才发现放不进导航，也没有页面愿意链它。这个顺序一反，整套判断就变成了给一个已经做出的决定找理由。

独立性测试具体测什么

比搜索结果：把候选词和最接近的现有页面各查一遍，记下前十条自然结果，看重合度。重合高，说明引擎把这两个查询当成一回事；再看引擎偏爱什么类型的页面，是品类页还是产品页。

意图会漂移，关键词没动排名却掉多半是意图变了。

建内容大纲：在动手写之前先把标题层级列出来，跟现有页面的大纲摆在一起比。这一步的意义在于，它能在还没花成本的时候暴露重合。

确认结构位置：这一页的上级是谁、从哪些页面能链过来、用户在导航里能不能找到它、背后有没有稳定的内容或者库存支撑。

四种动作各自的适用场景

更新、合并还是删除，老文章的4步SOP给了判断路径。

这套方法缺的那一块

它假设你清楚自己现有的页面盘子。实际情况是，一个跑了三五年的电商站，网址数量早就超出任何人的记忆范围，而且大部分增长不是决策带来的，是各种批量操作的副产品。

盘子大了会拖垮流量，索引膨胀的诊断与处置。

所以在做“要不要开新页”这个决定之前，更该先做一次“现在有多少页在重复”的盘点。后者的成本比前者低得多，而且它经常直接把前一个问题回答掉了。

为什么这个盘点没人做

因为它看起来不产生价值。合并两个重复页面，短期内不会带来流量增长，还要花时间做跳转和内链调整。而开一个新页面，至少看起来像是在扩张。

按性价比排一排，11个速赢清单里也有这一类活。

这个偏好非常顽固，我在不少团队里见过：页面数量是个能写进汇报的数字，页面重复度不是。于是站越做越大，重复越攒越多，直到某天流量掉了才开始查。

更根本的原因是，重复这件事没有一个天然的责任人。建页面的人只对自己那一页负责，运营只对商品负责，技术只对系统能不能跑负责。没有人的职责范围里写着“确保整站不重复”，于是这件事就悬着。

反过来看那些做得好的站，通常不是因为有人特别负责，而是因为流程里恰好有一道自动的检查。把责任落到流程上，比落到人身上可靠得多——人会离职，流程不会。

而且清理这件事有个尴尬的性质：做得好的时候，什么都不会发生。流量不涨，排名不动，只是抓取分布干净了一点，报表准确了一点。一个成功的清理，看起来跟没做过一模一样。

所以它需要一个别的理由来支撑。我通常给的理由是数据可读性：合并之前，同一件商品的数据被拆在五个网址上，任何一份报表都是错的；合并之后，你才第一次看到这件商品真实的表现。这个理由比“对SEO好”管用得多，因为它指向一个所有人都能验证的具体后果。

Google那边怎么说这件事

官方文档的措辞一向克制：一组被判定为重复的网址会被合并成一个规范网址，其余的成为这一组里的成员。关于合并重复网址的那份说明没有说重复会被惩罚，它只是说重复会被合并。

它自己怎么挑规范页，9大决策逻辑与排查实操列得很细。

这个区别很重要。重复的代价不是罚分，是选择权的转移——你不合并，引擎替你合并，而它选中哪一个作为规范页，未必是你希望的那一个。本次样本里那些一件商品五个网址的情况，就是把这个选择权完全交了出去。

我从87个站的站点地图里找同一件事的两个网址

下面是这次的做法和结果。

样本和抓取

从一批公开可访问的DTC品牌站、电商站和几个平台型站点里，取到182份站点地图，其中72份是索引文件，展开一层拿到398份子地图。合并去重之后，91个站有可用网址，其中87个站的网址数在40以上，进入分析。

批量拿地址，6种格式解析与URL提取更省事。

总网址数21.9万。最大的一个站单站1.6万，最小的四十几个。这个规模差异后面会影响结论的读法，我会单独说。

为什么用站点地图而不是自己爬？两个原因。一是快，一份文件几秒钟就下来了，爬一个万级站点要几小时。二是站点地图代表的是站长自己认为值得被收录的那批网址，这个口径比爬虫爬到的更有意义——爬虫会爬到一堆站长自己都不想要的地址。

代价是漏掉了那些没进站点地图的重复页面。所以我这次量的是“连站长自己都承认应该收录的网址里有多少重复”，这个口径比全站爬取严格得多，数字自然也小得多。

索引文件那一层的处理

72份站点地图是索引文件，也就是里面装的是别的地图文件的地址。我对每份只展开一层，且每份最多取前6个子文件。

站点地图怎么写才不出错，2400站踩过的坑都在。

这个限制会漏掉大站的一部分网址——一个有30个子地图的站，我只看了6个。这是个刻意的取舍：宁可每个站少看一点，也要多看几个站，因为本文要回答的是“这个问题有多普遍”，不是“某个站有多严重”。

按 站点地图协议的定义，索引文件本身可以嵌套，但实践中很少有人做两层以上。所以展开一层基本够用，漏掉的主要是横向的宽度，不是纵向的深度。

怎么定义“同一件事的两个网址”

判据是这样：取网址路径的最后一段，转小写，按非字母数字切成词，去掉停用词和平台通用词，做一次粗糙的单复数还原，然后把剩下的词排序拼成一个指纹。指纹相同但原始拼法不同的网址，就是一组。

slug里的门道，影响抓取与排名的9个细节。

举个例子：baby-blankets-heathered-oatmeal-ribbed-knit 和 ribbed-knit-baby-blanket-heathered-oatmeal，切完排序之后完全一样，是一组。

为什么用词集而不用别的

因为它便宜、可复现，而且不需要抓取正文。抓21.9万个页面的正文来算相似度，成本高到没法做；而词集只需要站点地图，一份文件就够。

重复的六类成因，同域跨域参数变体全排查有对照表。

代价是它只能发现“用词层面的重复”，发现不了“说的是一件事但用词完全不同”的那类。所以这次量出来的所有数字都是下限，真实的重复只会更多。

这个取舍值得多说一句。一个粗糙但便宜的判据，最大的价值不在于它有多准，在于它能被真正跑起来。一个需要抓全站正文、跑相似度模型的方案，在方案阶段就会死掉；一个只要一份站点地图和二十行脚本的方案，今天下午就能出结果。

我的经验是：先用便宜的判据把最明显的一批捞出来处理掉，处理完之后再看剩下的问题值不值得上更贵的手段。多数时候，便宜那一轮就把八成的量解决了。

单复数还原为什么只做粗糙版

我用的还原规则很土：结尾ies变y，结尾es且前面不是特定辅音的去掉s，结尾单个s且不是ss的去掉。这套规则会犯错，比如把glass之外的一些词处理错。

停用词清洗那一套，URL slug优化器怎么用。

没上正经的词形还原库，一是环境限制，二是更精确的还原会带来一个副作用：它会把更多本来不同的词合并到一起，制造新的假阳性。在这个场景里，宁可漏掉一些也不要多抓一些。

这个取向贯穿了整套判据的设计：所有拿不准的地方，一律选择更保守的那一边。这也是为什么最终的数字比第一版小了一半。

停用词表里放了什么

除了常规的英语虚词，还放了一批平台通用路径词：collections、products、product、page、category这些。它们出现在几乎每一个电商网址里，留着的话所有网址都会互相“相似”。

路径结构本身也有讲究，10000个站的实测结论。

这一步是必须的，但它也带来一个副作用：路径结构的差异被抹掉了。一个在collections下、一个在blogs下的同名页面，在我的判据里算同一组。这个选择是有意的，后面有一节专门讲它。

先看结论

电商重复怎么治，8类成因加canonical全清单。

87.4% 这个数是本文最该记住的一个。它的意思是：如果你随机挑一个电商站，它的站点地图里几乎肯定存在至少一组“同一件事的两个网址”。这不是个别站的毛病，是这个业态的常态。

而2.78% 这个数是另一回事：它说明就总量而言，这个问题并不大。绝大多数网址是干净的。普遍但不严重，是这批数据最准确的一句概括。

这两个数放在一起，正好解释了为什么这件事长期没人管：因为按比例算它显得微不足道，2.78% 听起来完全可以忽略。但按站算，它几乎无处不在，而且那6109个页面是实打实在消耗抓取和分散信号的。

那11个没有重复的站是什么样的

87个里有11个一组都没找到。翻了一下，共同点是网址数都不大——多数在两三百以内，最大的也就八百。它们要么是品类少、上新慢的品牌，要么是主要靠一个大目录页承载所有商品的站。

扁平还是层级，SEO上到底差在哪。

这印证了前面的判断：重复不是能力问题，是规模和节奏的必然产物。页面越多、上新越频繁、参与建页的人越多，重复就越难避免。指望靠“大家仔细一点”来解决，基本没戏——这件事我在三个不同规模的团队里都验证过，结论一致。

不过这11个站也不能简单当成“做得好”。它们中有几个的问题其实在另一头：网址少到品类都铺不开，用户想找一类东西只能在一个大列表里翻。没有重复，有时候只是因为还没长到会重复的规模。

所以这个指标要配着规模一起看。三百个网址零重复，正常；一万个网址零重复，那说明这个站的建页流程里一定有某种约束在起作用，值得去问问是什么。

规模差异怎么影响这批数字的读法

最大的站单站1.6万个网址，最小的四十几个。如果按网址数加权，那几个大站几乎决定了2.78% 这个总占比；如果按站平均，得到的又是另一个数。

我报的2.78% 是全样本的总占比，也就是被大站主导的那个版本。按站取中位数的话，这个数会低不少——因为多数站的重复量很小。两个算法都对，只是回答的问题不同：一个是“这批网址里有多少是重复的”，一个是“典型的站有多严重”。

写结论的时候我选了前者，因为本文关心的是抓取和信号的浪费总量。但如果你是拿它来评估自己的站，该对标的是后者。这类差别不说清楚，读者很容易把一个总量指标当成个体基准去比。

这个数字会不会被建站平台影响

会，而且影响很大。用同一类平台的站，重复的形态高度一致，因为它们的网址冲突处理逻辑是同一套。本次样本里用某一类平台的站占了大头，所以序号型才会占到六成。

平台自带的分页逻辑，索引判断与canonical设置是个参照。

换一批用别的系统的站，形态分布肯定不一样，但“重复普遍存在”这个结论应该是稳的，因为它的成因是流程性的，跟具体用什么系统关系不大。

第一次算出来的数字，为什么有一半是假的？

这一节讲我自己的错误，它比上面那个百分比更值得记。

第一版跑出来4532组

我第一次做归一化的时候，做了一件看起来很合理的事：把所有纯数字的词删掉。理由是网址里的数字大多是商品ID、页码、序号，属于噪声。

自己划的及格线不算数，那个95%是怎么来的。

结果是4532组、12541个页面，占全部网址的5.7%。数字很漂亮，比最后的结论大了将近一倍。

然后我去看具体案例

翻到第三页就不对劲了。一组是 classic-5-inch-chefs-knife 和 classic-7-inch-chefs-knife，5寸和7寸的厨刀。另一组是2人帐篷和3人帐篷。还有一组是14盎司、30盎司、40盎司的三个保温杯。

口径一变结论就变，前1%是4家还是51家。

这些根本不是重复，它们是不同规格的商品。而我的归一化把区分它们的唯一信息——那个数字——当成噪声删掉了。

数字在网址里其实分两类

变体该合该拆，几十个URL的取舍正是这个问题。

四类里只有后两类该删，而我一刀切全删了。一个词该不该删，取决于它在这个位置承担什么功能，不取决于它长什么样。

修完之后掉到2390组

新的规则是：数字一律保留，只处理结尾那个孤立的纯数字——五位以上当商品编号，整条排除；1900到2100之间当年份，删掉并标记；12以内当变体序号，删掉并标记；其余的模棱两可，整条排除。

分母没说清就会出这种事，92%只覆盖了7.4%的买家。

改完之后组数从4532掉到2390，虚高了1.9倍。页面数从12541掉到6109，占比从5.7% 掉到2.78%。

这次失误和上次是同一类

它和把常用词误当特征词是一个毛病：用一个形式上的规则去近似一个语义上的判断。“纯数字是噪声”这个规则在很多场景下成立，恰好在商品网址这个场景下不成立，因为商品的核心区分点经常就是数字。

一条趋势线上三处口径变更，跨年数据能不能直接比。

而这类错误的共同后果，还是让问题看起来更严重。两次测量，两次虚高，方向完全一致。这已经不像巧合了，更像是这类粗糙判据的固有偏向。

怎么在下次提前发现

办法只有一个，而且很笨：把结果随机抽二十组，逐组用眼睛看一遍。我两次都是靠这一步发现问题的，没有任何统计指标提醒过我。

对不上账的时候，三家数据的对账方法。

抽样看的时候有个诀窍：不要只看那些明显对的，要专门去找“看起来最不像重复的那几组”。错误总是藏在边界上，而边界上的样本一眼就能看出不对。

为什么第一版的结果读起来那么合理

这才是最值得警惕的地方。4532组、5.7%、87个站里79个有问题——这组数字放在一起完全说得通，甚至比修正后的版本更符合“电商站重复很严重”这个预期。

合理的东西也可能是错的，换一个主语答案差16个点。

一个符合预期的错误结论，比一个反直觉的正确结论更难被发现。因为前者不会触发任何怀疑，你会直接开始想怎么把它写出来。

我这次能发现，纯粹是因为写作时需要举例子，于是去翻具体案例。如果这批数据只是用来出个报表、画个图，那个虚高一倍的数字会一路走到最后。

这个经验后来变成了我的一条固定动作：任何一个准备用出去的统计结论，先给它配三个具体例子。配不出来说明你还不理解这个数；配出来了，多半也就顺便发现问题了。

两个数字的差别有多大

虚高之后怎么修，对接一年的口径修正。

最后一行有意思：站数几乎没变。因为那些被误判进来的规格差异，绝大多数发生在本来就有真重复的站上。所以“87.4% 的站有这个问题”这个结论，在错误的版本里也是对的。

这提醒了另一件事：同一批脏数据，对不同的结论污染程度完全不同。算比例的结论全毁了，算覆盖面的结论基本没事。所以发现数据有问题的时候，别急着把所有结论都推翻，先分清哪些依赖被污染的那一部分。

修好之后，2390组是什么形态？

把这2390组按产生方式分了个类。

四种形态的成因完全不同

序号型是系统自动生成的：建站平台在检测到网址冲突时自动往后加数字。增减词型和词序型是人写的：不同的人、不同的时间，给同一个东西起了不同的名字。年份型是有意的：做了一个新版本，保留了旧的。

筛选器最容易爆网址，不爆炸的系统方案。

成因不同，处理方式也完全不同，这是把它们分开数的全部意义。系统生成的可以批量清理，人写的必须一个个看，有意保留的可能根本不用动。

集中度也很不一样

76个有重复的站里，前5个站贡献了1300多组，超过总数的一半。最多的一个服装品牌550组，1771个页面，占它自己网址总数的47%。

聚合口径怎么看，3类站点的实测。

换句话说，这不是一个均匀分布的问题，而是少数几个站问题极其严重，多数站有一点点。所以“87.4% 的站有这个问题”这句话，要配上“但多数站的量很小”一起读才准确。

占比高的站有什么共同点

翻了一下前十名，共同点挺明显：都是上新频繁的服装或者快消品牌，而且都在用同一类建站平台。上新频繁意味着不断有新商品要建页，用同一类平台意味着遇到网址冲突时的处理方式一样——自动加序号。

平台侧的治理，EAV与参数白名单是另一套解法。

这两个条件凑在一起，重复就会稳定地按周积累。它不是某一次操作失误，是一个每周都在运转的生产流程的固有产出。

把它换算成时间会更直观

那个550组的服装品牌，假设它做了五年，平均下来每周新增两组。两组听起来完全不值得管，也确实没人会为一周两组去开会。但五年之后就是1771个页面。

日志里能看出累积效应，爬虫到底抓了什么。

所有的技术债都是这个形状：单次增量小到不值得处理，累计总量大到不敢处理。而中间那个从“不值得”变成“不敢”的转折点，从来没有人注意到它什么时候发生的。

这也是为什么我更愿意推事前的那道闸而不是事后的审计。一道闸拦住的是每周那两组，成本几乎为零；审计要处理的是累计的1771个，成本高到要立项。

小站现在做，比大站将来做便宜一百倍

本次那11个一组重复都没有的站，网址数都在八百以内。它们现在加一道重名检查，等于用零成本锁定了一个干净的起点。

怎么讲这笔账，用商业语言把钱说清楚。

而那几个已经积累到几百组的站，现在要做的是一个跨越好几个季度的清理项目，还要协调投放、内容、开发三方。同一件事，早做是加两行代码，晚做是立一个项目。

如果你现在管的站还不大，这一篇里最值钱的一句话就是这个：趁现在。等到你觉得有必要认真处理的时候，成本已经翻了两个数量级。

序号型占了六成，这意味着什么？

这一档值得单独说，因为它数量最大，也最容易处理。

它是怎么产生的

典型场景：一个商品下架了，过一阵又上回来，或者换了个款号重新录入。系统检测到网址已被占用，就在后面加个1。再来一次，加个2。

下架再上架的处理，301、410与库存信号决策。

本次样本里见过最夸张的一组，同一件女式卫衣有五个网址，后缀分别是空、2、3、4、5。五个网址，五个页面，一件衣服。

这五个页面上都有什么

我抽查了几组，情况分三种：有的旧网址已经跳转到新的，那问题不大；有的旧网址还能正常打开，卖的是同一件商品；还有的旧网址打开是缺货状态，页面还在，但买不了。

404被抓不全是坏事，软404修复指南说得更细。

第二种和第三种都会进站点地图，也都会被抓取。第三种最伤：它既占抓取预算，又给用户一个买不到东西的落地页。

更麻烦的是，缺货页往往还保留着完整的商品信息和结构化数据，所以它在搜索结果里看起来跟正常商品页没有区别。用户点进来才发现买不了，而这个体验的损失不会记在任何一份SEO报表上。

站点地图里该不该放这些页面

不该。Google关于站点地图的建议里说得很清楚，放进去的应该是你希望被收录的、有价值的网址。一个跳转的、缺货的、或者已经被别的页面取代的网址，三条都不占。

导出逻辑要加条件，怎么只输出该收录的。

但实际情况是，很多站的站点地图是从数据库里全量导出来的，只要商品记录还在就会被写进去。这等于每天都在向引擎重申一批你自己都不想要的网址。

修法很简单：导出逻辑里加一个条件，只输出当前在售且状态码为200的商品页。这一行改动的效果，比清理一百个历史网址还明显，因为它一次性停止了信号的持续发送。

缺货商品页本身怎么处理

这是另一个大话题，简单说三种情况：短期缺货，页面留着，明确标注补货时间；永久下架但有替代品，跳转到替代品或者所属品类；永久下架且无替代，返回410让引擎尽快移除。

301、404和410怎么选，状态码怎么影响SEO。

最差的做法是留着页面什么都不说。用户不知道能不能等，引擎不知道该不该继续抓，而这个页面还在你的站点地图里占着一行。

为什么没人清理

因为清理它需要判断，而判断需要知道哪个是当前有效的。系统不知道，只有运营知道。而运营的日常工作里没有“清理历史网址”这一项。

改版后的死链，一次揪出来。

更现实的原因是：这些页面在后台是看不见的。商品列表里显示的是商品，不是网址；只有导出站点地图或者跑一次爬虫，它们才会浮出来。

怎么批量处理

这一档是四类里唯一适合批量处理的。做法：把所有结尾带序号的网址挑出来，按去掉序号后的名字分组，组内比较状态码和上架状态，保留一个，其余的做跳转。

这类活挂cron上，备份与sitemap一条龙。

有个前置检查别忘了：确认这些序号确实是系统加的，不是商品名字的一部分。办法是看这一组里有没有一个不带序号的版本。有，那序号八成是自动加的；只有 -1和 -2没有裸版本，那可能是别的意思，得人工看。

本次样本里我遇到过一组，三个网址分别以 -1、-2、-3结尾，没有裸版本。点开看是同一个产品的三种包装规格，序号是内部编号。差一点就把三个不同的商品页合成了一个。

整个过程可以脚本化，只在“保留哪一个”这一步需要人确认，而这一步通常有个简单规则：保留当前在售的那个，都不在售就保留最新的那个。一个500组的站，半天能清完。

清完之后能看到什么

最直接的是抓取分布的变化：原本分散在五个网址上的抓取，会集中到一个上。其次是内部报表变干净——同一件商品的数据不再被拆成五份。

抓取预算怎么分，2026年的12项实操。

顺带说一句，抓取这一侧还有别的省法。Google建议用304状态码节省抓取预算这条最近被重提过：内容没变的页面返回304，爬虫就不用再下载一遍正文。清理重复是减少要抓的地址数，304是减少每次抓取的字节数，两件事可以一起做。

至于排名，别期待立刻变化。这类清理的价值是止损和让数据可读，不是提升。把它当成打扫房间，不是当成装修。

跳转该怎么写才不出事

清理序号型的时候，跳转的写法有讲究。最稳的是一对一映射，每个旧网址明确指向一个新网址，写在配置文件或者数据库里。最危险的是用正则批量匹配——比如把所有结尾带 -1到 -9的都跳到去掉后缀的那个。

双向跳转很容易绕圈，Apache与Nginx双向实战。

为什么危险？因为有些商品的正式名字里就带数字后缀。一个叫 tumbler-30 的商品，被规则匹配成 tumbler-3 的变体，就跳到了一个完全不同的商品页上。这类错误上线之后很难被发现，因为跳转本身是成功的。

Google关于永久跳转的说明里也提到，跳转链要尽量短、映射要尽量明确。一条规则少写一分钟，出错之后排查要花一天。

清理之前先备份一份清单

把要处理的网址、它们当时的状态码、以及跳转的目标，全部存成一份表。这份表在两个时刻会救你：跳转配错要回滚的时候，以及三个月后有人问“那个页面去哪了”的时候。

跟开发怎么配合，后端协作的7个动作点。

这件事听起来是常识，但实际操作里经常被省掉，因为脚本跑完了、结果对了，谁还愿意再导一份表。而恰恰是那些一次跑成的操作，最后最没人说得清当时到底改了什么。

词序颠倒的那130组，是怎么产生的？

这一档数量最少，但它最能说明问题。

先看几个真实例子

一个服装品牌有两个网址，一个叫 womens-hammered-satin-popover-shirt-bone-black，另一个叫 womens-hammered-satin-popover-shirt-black-bone。同一件衬衫，两个颜色词换了个顺序。

命名这件事，7维设计与上线后铁律。

一个家居品牌，一个叫 baby-blankets-heathered-oatmeal-ribbed-knit，另一个叫 ribbed-knit-baby-blanket-heathered-oatmeal。同样几个词，重新排了一遍。

一个个护品牌，两顶联名帽子，一个叫 dad-hat-tushy-x-narragansett，另一个叫 dad-hat-narragansett-x-tushy。连联名双方的顺序都换了一次。

这说明了什么

说明这个站上没有一份“东西该怎么命名”的约定。两个人、或者同一个人在两个时间点，面对同一件商品，写出了两个名字。

一份能交接的规范，内容简报怎么写。

而且这两个名字都不算错。“骨白黑”和“黑骨白”，谁也说不出哪个更对；“婴儿毯 罗纹针织”和“罗纹针织 婴儿毯”，两种说法在中文和英文里都成立。没有对错的地方，就是最容易分叉的地方。

这也是为什么这一档虽然只有130组，但它最值得引起注意：它证明了这个站的内容生产没有任何一致性约束。今天能在颜色顺序上分叉，明天就能在别的地方分叉。

那两顶帽子的例子最能说明问题

一个联名系列的两顶帽子，网址一个是“甲乘乙”，一个是“乙乘甲”。这不是两个人写的——同一批上架的商品，多半是同一个人在同一个下午录进去的。

商品侧的结构化，Schema结构加GEO联动。

连同一个人在同一段时间里，都没有保持一致的顺序。这说明这件事根本没进入过意识层面：录商品的时候，他想的是把信息填全，不是想网址会长什么样。

指望通过培训解决这个是不现实的。人在做重复性录入工作的时候，注意力不在这些细节上，这是人的正常状态，不是失职。所以答案还是那个：把约束放进流程，别放进人的自觉。

这类重复不可能靠系统避免，因为系统看不出这两个名字说的是一件事。它只能靠一份命名规范，或者一次发布前的重名检查。

词序为什么会影响这么大

对搜索引擎来说，网址里的词序影响很小，两个网址的语义几乎一样。问题不在引擎那边，在你自己这边：两个名字意味着两条数据线、两份统计、两个可能被分别优化的对象。

内链上的参数也伤信号，流量分析与抓取的取舍。

更麻烦的是内链。有人链了第一个，有人链了第二个，本该集中的信号被劈成两半。这一点在站内搜索和推荐位上也一样。

怎么防

最有效的一条是发布前的重名检查：新建页面时，把标题拆成词、排序、跟已有页面比一遍，命中就提示。这个检查的实现成本非常低，就是我这次用的那套逻辑。

蚕食怎么修，5维度信号区隔实战。

把一次事后审计变成一次事前提示，是这批数据里性价比最高的一个改法。它每次只拦一个页面，但一年下来能省掉几百组。

提示该说什么

不要只说“检测到重复”，那样的提示三次之后就会被无视。要说清楚三件事：撞上的是哪一个页面、它现在是什么状态、以及给一个可以直接点的链接过去看。

告警怎么分级，三平台诊断与90天闭环。

让人一秒钟就能判断“哦这个我知道，确实不一样”或者“咦这个页面还在？”。一个能被一秒钟处理掉的提示，才有可能被长期保留；一个需要花五分钟去查的提示，很快就会被关掉。

这道提示还能顺便解决另一个问题

它其实是一个轻量的站内检索：建页的人在写标题的时候，就能看到站上已有的相关页面。这个信息对他有直接价值——他可以顺手加个内链，或者调整角度让两页更互补。

顺手能看到相关页，两套标注怎么归一也是靠同一份索引。

换句话说，这道闸对建页的人不是阻碍，是帮助。这一点很重要，因为任何一个被当成阻碍的检查，最终都会被绕过去。让它同时提供价值，是让它活下来的唯一办法。

如果暂时加不了这道闸

退一步的做法是每月跑一次审计，只看新增的部分。把这个月新建的页面拿出来，跟历史指纹比一遍。量小，几分钟就能看完。

批量监控可以用接口，2000条配额下的管线。

这比季度全量审计好得多，因为新建一个月内的页面最容易处理——还没积累外链，还没被大量内链指向，改名字或者删掉的成本都很低。等到半年后再发现，处理成本就完全不一样了。

命名规范该写多细

不用很细，三条就够：属性的固定顺序（比如先品类后颜色再材质）、单复数的统一约定、以及联名或者组合类商品的书写顺序。剩下的交给重名检查兜底。

写法上的规矩，8大实战技巧也是越少越好记。

写太细的规范没人看，也执行不了。三条能记住的规则，加一道自动检查，比一份二十页的文档管用。

已经存在的词序型怎么处理

这一档没法批量，只能一组一组看，因为你得判断哪个名字更好。判断标准建议只用一条：哪个更接近用户会怎么说。不是哪个更符合内部命名习惯，也不是哪个更早创建。

合并与权重回收，完整打法。

比如那件衬衫的两个网址，一个是“骨白黑”，一个是“黑骨白”。用户在描述这件衣服的时候会先说哪个颜色？通常是主色。那就保留主色在前的那个。

这类判断做起来其实很快，一组十几秒。130组也就半小时。真正花时间的不是判断，是判断完之后改内链和跳转。所以这一档我建议攒够一批一起做，别零散处理。

还有一种更省事的处理：如果这两个网址的流量和外链都可以忽略不计，那不用做跳转，直接把其中一个改成不索引，然后从站点地图和内链里拿掉就行。跳转是为了迁移价值，没有价值可迁的时候，跳转纯属增加复杂度。

怎么判断有没有价值可迁？看两件事：过去半年有没有自然流量，有没有外部站点链接过来。两个都是零，直接下线；任意一个不是零，老老实实做跳转。

增减词型那459组更值得先看

它数量是词序型的三倍多，而且成因更多样：有的是加了个修饰词做了个新页面，有的是漏了个词，有的是一个带品牌名一个不带。这一档里混着真重复和真差异，不能一刀切。

哪些词值得单独打，9大挖掘策略。

快速分辨的办法：看多出来的那个词是不是实质性的。多出来的是best、guide、how这类，多半是同一件事的不同表达；多出来的是尺寸、材质、人群这类，那可能真是两个不同的东西。

本次样本里两种都有。一个3C品牌的 100w-gan-charger 和 100w-gan-chargers 只差一个复数，肯定是重复；而另一个站的两个网址一个带人群词一个不带，那是真的分了两页在做。

同一个话题横跨博客和品类页，算不算重复？

这是这批数据里最有意思的一类，也是最接近原始问题的一类。

先看这一组

一个3C品牌，同一个话题下有四个网址：一个是英国站的博客文章，一个是德国站的博客文章，一个是波兰站的品类页，还有一个是英国站的品类页。四个网址，讲的都是“给某类电脑用的某种扩展坞”。

内容型页面的索引控制，工程化怎么做。

另一个音频品牌，一个是西班牙站的品类页，一个是博客里的选购文章，两者的词集完全相同。还有一个护肤品牌，一个是标签聚合页，一个是文章页，同样的词。

标签聚合页那一组特别典型。很多内容管理系统会自动为每个标签生成一个聚合页，而标签名往往就是文章标题里的关键词。于是一篇文章上线，同时诞生了一个跟它同名的聚合页。这个聚合页里可能就只有这一篇文章。

标签聚合页该不该被收录

看它里面有几篇。一篇的时候它就是这篇文章的一个影子，应该不索引；累积到五篇以上、且这几篇确实构成一个话题的时候，它才开始有独立价值。

分类和标签怎么分工，索引治理与着陆页打法。

这个判断可以自动化：聚合页里的条目数低于阈值就加不索引标记，超过阈值自动放开。这一条规则能一次性解决掉很多站的一大批重复，而且几乎没有副作用。

阈值定几合适？我的习惯是五，跟品类页的八不一样，因为聚合页的价值来自话题密度而不是选择余地。五篇文章已经能构成一个像样的话题入口，而五件商品撑不起一个品类页。

还有一个细节：放开索引之后，聚合页最好加一段导语，说清楚这个话题是什么、这几篇文章分别解决什么问题。光是一串标题列表的聚合页，即使条目够多，也很难有独立价值。这段导语通常一百来字，写一次管很久。

标签和分类别同时开放

很多内容管理系统同时生成分类页和标签页，而运营给文章打标签的时候，标签名经常跟分类名重合。于是同一批文章在两个地方各聚合了一次。

这一类重复比单个标签页更麻烦，因为两边的条目数可能都不少，看起来都够格独立。解法是选一边开放：内容以分类为主的站关掉标签页索引，以标签为主的站反过来。两边都开，就是主动制造一批同词集的页面。

本次样本里我没有专门统计标签页的比例，因为很多站的标签路径被我当成通用路径词过滤掉了。但从抽查的印象看，这一类在内容型电商站上占的比重不小。

这也是这套判据的一个局限：我为了让不同站之间可比，把平台特有的路径段抹掉了，代价是丢掉了页面类型这个维度。如果只分析一个站，反而应该保留路径段，因为同一个站内部的路径含义是稳定的。

换句话说，做横向对比和做自查，判据的设计原则是不一样的：前者要抹掉个体差异才能比，后者要保留个体特征才能用。照抄一份为横向对比设计的判据来自查，往往会漏掉最该看的那一类。

跨地区站那几组的正确处理

英国站和德国站各有一篇同话题博客，处理方式不是合并，是让它们互相声明语言地区关系。这一层做对了，两篇内容各自服务各自的市场，互不干扰。

那些语言版本网址的真实身份，多数只是规范页的别名。

做错的话有两种后果：要么引擎在两个市场之间挑一个展示，另一个市场的用户看到不合适的版本；要么两篇被当成重复，其中一篇被合并掉。两种后果都比“什么都不做”更糟，因为你已经付出了做两篇的成本。

这算不算重复

严格说不算，它们的页面类型不同、用户处在的阶段不同、转化路径也不同。品类页给的是商品列表，博客给的是判断依据。这正是“一个词值得单开一页”的合理场景之一。

用户旅程分六段，关键词布局与内容策略。

但它有条件：两个页面得真的在做不同的事。如果那篇博客文章的内容，本质上就是把品类页上的商品又列了一遍加几句评价，那它就没有独立存在的理由。

怎么判断这一对该不该都留

用那个大纲比对法，但简化一下：把两个页面的主要标题各列出来，看有几条是对方没有的。少于三条，合并；三到五条，考虑把博客那篇改成更明确的角度；五条以上，两个都留。

话题入口页怎么做，从内链中转站到被引用。

这个阈值不是什么标准，是个经验值，但它至少给了一个能操作的判断，而不是停留在“看情况”。

跨地区站的那种更麻烦

英国站和德国站各有一篇同话题博客，这在多语言站里太常见了。它们之间不是重复，是不同市场的版本，正确的处理是让它们互相声明语言关系，而不是合并。

同语言多地区怎么不打架，美英澳那一套。

问题出在同一个市场内部：英国站既有博客又有品类页，两个网址盯着同一簇词。这一对才是需要判断的。

我的判据抹掉了路径差异

前面提过，我把collections、blogs这类路径词放进了停用词表，所以一个在博客下、一个在品类下的同名页面，在我这里算同一组。

目录层级的影响，6招优化实战。

这是个有意的选择：我想找的是“讲同一件事的网址”，不是“路径相同的网址”。但它带来的后果是，这2390组里混着一部分本来就该分开的合理组合。

混进来的比例大概是多少

我抽了40组人工看，其中6组属于这种跨类型的合理组合，占15%。按这个比例外推，2390组里大概有三百多组不该算作问题。

数据信谁，6场景选型与三源校准。

这个误差我没有从最终数字里扣掉，因为抽样只有40组，扣掉反而是假精确。读的时候心里减掉一成半就行。

那六组合理组合长什么样

四组是品类页加同话题博客，一组是标签聚合页加文章页，还有一组是产品页加使用教程页。共同点很清楚：两个页面在用户旅程上处在不同位置，一个负责让人了解，一个负责让人买。

内容页怎么承接，FAQ段落8步实战。

这类组合不但不该合并，做得好的话它们之间还应该互相链接：博客文章链到品类页承接购买意图，品类页链到博客文章承接犹豫的用户。本次抽到的那六组里，只有两组做了这层互链。

剩下四组是各做各的，互相不认识。这其实比重复更可惜——你已经付出了做两个页面的成本，却没拿到两个页面配合的收益。

跨类型的组合怎么判断该不该留

三个问题。第一，这两个页面的用户处在同一个决策阶段吗？同一个阶段，合；不同阶段，留。第二，它们的转化目标一样吗？都是加购，那多半该合。第三，有没有互链？没有的话，先补互链再观察，别急着合。

信息词流量过大有代价，6大危害与破局。

第三个问题最实用，因为补互链的成本远低于合并，而且效果往往立竿见影。很多看起来该合并的页面，补上互链之后各自的表现都变好了，因为它们终于开始互相导流而不是互相竞争。

那套三步判定法，落到电商站上怎么用？

回到最初的问题。有了前面这批数据打底，这套方法可以用得更具体。

第一步不该是查数据，该是查重名

原方法的第一步是去后台看哪些页面已经在这个词上有展示。这一步没错，但它有个盲区：那些一次展示都没拿到的重复页面，在这一步里是隐形的。

先过硬闸，可索引性一键体检。

所以我建议在它前面加一步：把候选词拆成词集，跟站点地图里所有网址的词集比一遍。这一步不需要任何后台权限，一份站点地图加二十行脚本就够。

命中了怎么办

命中说明你要建的这一页，站上可能已经有了。先去看那个页面：它现在是什么状态、有没有内容、是不是序号型的历史遗留。三种情况三种处理，但都轮不到新建。

按症状分诊，不被收录的急救手册。

没命中再走原来的三步

没命中，说明这个词在你站上确实是新的，这时候再去比搜索结果、建大纲、看结构位置。顺序这样排，是因为查重名的成本远低于跑独立性测试。

候选词哪来的，一个主题挖50个问题。

电商站的一个特殊判据

原方法里有一条是“确认有稳定的库存或者足够的支撑内容”，这条在电商站上要加重。因为品类页的价值直接跟商品数挂钩：一个只有三件商品的品类页，无论词多好，都撑不起来。

商品侧的排序因素，6大因素与流量提升。

我的经验阈值是八件。低于八件，这个词就先做成筛选条件或者塞进更大的品类页里，等商品数上去了再独立。提前建好的空品类页，最后都会变成需要清理的对象。

八这个数不神圣，你完全可以按自己的品类调。定它的逻辑是：一屏能看到的商品数，加上一点余量。用户点进一个品类页，第一屏只看到三四件东西，他会立刻退回去——这个页面在他眼里就不是一个品类，是一个凑数的集合。

客单价高的品类可以往下调。卖大型家具或者定制类产品的，五件甚至三件都能撑得住，因为用户本来就预期选择不多，而且每一件都会看得很仔细。反过来，服饰配件这类品类，八件都嫌少。

真正该问的不是“几件够”，是“用户看到这一屏会不会觉得来错地方了”。八只是一个方便记住的起点。

那些低于阈值但词很好的怎么办

做成一个带筛选的入口：让这个词指向大品类页并预置筛选条件，网址上带一个可读的参数或者路径段。这样既接住了这个词，又不用维护一个空页面。

等这个筛选条件下的商品数长起来了，再把它升级成独立页面，把原来那个带参数的地址跳过去。先做轻的，够格了再做重的，比一上来就建页然后等它慢慢空掉要稳。

商品数会掉下去怎么办

这是空品类页的主要来源：建的时候有二十件，两年后季节过了、款式下架了，只剩三件。而没有人会回头去检查一个两年前建的品类页现在还剩几件商品。

空品类怎么处理，分类树清理那一套也是同一个思路。

解法是给品类页也加一个定期检查：商品数低于阈值的页面，自动列出来给人看一眼。处理方式有三种，合进上级品类、改成筛选条件、或者暂时下线等补货。三种都行，最差的是放着不管。

本次数据里那些重复率高的站，我抽查过几个品类页，确实有商品数只剩个位数的。它们还在站点地图里，还在被抓取，还在参与内链，唯独没有内容。

另一个电商特有的判据：季节性

有些词的搜索量高度集中在一年里的两三个月。为这类词单独建页，一年里有九个月它是空的或者过时的。更合理的做法是做成一个长期存在的页面，内容随季节更新，而不是每季建一个新的。

季节曲线怎么量，提前布局的做法。

本次数据里的年份型那98组，有相当一部分就是这么来的：每年做一个新版本，旧的留着。五年之后同一个主题有五个页面，其中四个是历史文物。

模板化那一条要格外小心

原方法建议对可复制的结构做模板，先上试点页再全量。这条在电商站上尤其重要，因为电商的模板化能力太强了——一个品类乘一个颜色乘一个尺码，轻松生成几千页。

筛选页要不要Disallow，三类判别法。

本次数据里那几个重复率接近一半的站，多半就是模板化没收住。模板化是把双刃剑：它让你能低成本铺开，也让你能低成本地铺错。

试点页该怎么设计才算数

原方法说先上几个试点页，看索引情况、查询覆盖和用户互动，再决定要不要全量。这条很对，但实操里试点经常做成了走过场：上三个页面，两周后看一眼，觉得还行就全量了。

试点最怕外部冲击，上线掉5%出在那26天。

试点要算数，得满足三个条件。第一，试点页要覆盖最好和最差的情况——不能只挑商品最多、词最热的那几个组合，那样结论必然是乐观的。至少要有一个商品数刚够线的、一个词很冷的。

第二，观察期不能少于六周。索引本身要两三周，有了索引之后还要几周才能积累出可读的查询数据。两周就下结论，你看到的只是抓取速度，不是效果。

第三，要提前说好什么算通过。比如：三分之二以上的试点页被索引、每页至少覆盖三个不同查询、平均停留时间不低于同类页面的七成。不提前定标准，事后一定会找到理由说通过。

全量之后还要留一道闸

模板化最麻烦的地方是它会持续生产。今天铺了两千页，明天新增一个品类，自动又多出两百页。所以全量之后必须留一个持续的检查：每个新生成的页面，商品数够不够线、有没有和已有页面撞词集。

哪些页该屏蔽，这7类加实操。

这道闸的实现很简单，就是在生成逻辑里加两个条件判断，不通过就不生成、或者生成为筛选参数而不是独立网址。加这两行的成本，比事后清理两千个页面低两个数量级。

什么样的组合最不该独立成页

按本次样本的观察，有三类基本不该独立：颜色单独成页、尺码单独成页、以及价格区间单独成页。这三类的共同点是它们描述的是筛选条件，不是一类东西。

站内搜索页那一类，4种方案对比。

用户搜“蓝色连衣裙”确实存在，但他要的是一个能筛蓝色的连衣裙列表，不是一个只有蓝色的孤立页面。前者可以用筛选参数配合可索引的筛选页解决，后者会在换季之后变成一个空页面。

反过来，材质、场景、人群这三类通常值得独立，因为它们背后有真实不同的选购逻辑。判据不是搜索量，是“这一页能不能写出别的页写不出的内容”。颜色写不出，材质能写出。

搜索结果重合度这一步，没有工具怎么办？

三步里最难落地的就是这一步，因为它需要看搜索结果。

手工做一次要多久

两个词各查一次，记下前十条结果的域名和网址，算重合数。熟练的话一对五分钟。听着不多，但如果你有三十个候选词，就是两个半小时。

要省时间就上工具，三条路的横评。

可以省掉的部分

其实不需要完整记十条。只看前五条，而且只记域名不记完整网址，重合度的判断结果在绝大多数情况下不变。这样一对能压到两分钟。

粗一点的口径够用，3平台300站实测。

另外一个省事的做法：先看两个词的结果页里，有没有对方的页面。你自己的页面同时出现在两个查询的结果里，这本身就是一个很强的“引擎认为它们是一回事”的信号，比数重合度直接得多。

重合度多少算高

常见的经验线是前十条里重合六条以上算高、三条以下算低。中间那一档最难判，得靠下一步的大纲比对来定。

结果每天都在变，波动还是真掉了。

这个阈值不必太较真，因为搜索结果本身每天都在变。它的作用是把候选词粗分成三堆，不是给出一个精确判断。

结果页类型比重合度更有信息量

如果一个词的结果页里全是品类页，另一个词的结果页里全是长文指南，那即使重合度不低，这两个词也大概率该分开做——因为引擎对它们的期待不一样。

意图有五种，对应的内容策略。

看类型不看重合，这是我从这一步里学到的最实用的一条。类型的差别一眼能看出来，重合度还得数。

类型有哪几种要认

电商相关的查询，结果页大致就四种形态：商品列表页占主导、单品页占主导、长文指南占主导、以及混合型。前两种是交易意图，第三种是了解意图，第四种通常意味着这个词的意图还没稳定下来。

结果页形态在变，引用与排名脱钩之后。

混合型的词是最值得做的，因为它还没被谁占死；也是最容易做砸的，因为你可能选错形态。遇到混合型，看排在最前面那两三条是什么形态，跟着它们走。

形态不匹配的代价

如果一个词的结果页全是长文指南，你却建了个品类页去打，那这一页大概率进不了前列——不是因为它质量差，是因为它给的东西不是这个查询要的。

写之前先定形态，7步GEO实战流程。

反过来也一样。这类错配在电商站里特别常见，因为电商的默认反应是“建个品类页”。而有相当一部分品类词，用户要的其实是先弄明白怎么选。

这一步和词集检查的分工

词集检查回答的是“我站上是不是已经有了”，结果页类型回答的是“外面期待的是什么形态”。两个问题都过了，才轮到大纲比对回答“我能不能写出不一样的”。

技术审计分几层，42步实战列过。

三步的成本递增，所以顺序不能变。词集检查几秒钟，结果页看一眼两分钟，大纲比对要半小时。把最便宜的放在最前面，是任何一套筛选流程的基本原则。

三步的淘汰率也不一样。词集检查大概能淘汰掉两成的候选——那些你站上已经有了的。结果页类型再淘汰一成左右——形态完全不对的。剩下的七成才进大纲比对，而大纲比对通常还会再刷掉一半。

算下来，一百个候选词最后真正值得建页的大概三十几个。如果你的团队现在是候选词有多少就建多少页，那这套流程能立刻把工作量砍掉三分之二，而产出的页面质量还更高。

被刷掉的那些词去哪了

不是丢掉，是分流。词集命中的，去合并或者扩写已有页面；形态不对的，换一种内容形态重新考虑；大纲撑不起来的，作为一个小节并进相关页面。

一个词被判定为不值得单开一页，不等于这个词没价值。它只是不值得为它做一个独立的容器。这个区别很重要，否则这套流程会被理解成砍掉七成的机会，而实际上它是把七成的机会用更省的方式接住。

实际操作里，我会给每个被刷掉的词标一个去向：并入哪一页、以什么形式。这份记录本身就是下一轮内容排期的素材，比一份光有词没有去向的清单有用得多。

本地做不了怎么办

用国内网络查国外搜索结果，结果本身就不准，还会被地域和个性化影响。可行的替代是用后台的查询报表反推：把这两个词各自带来展示的页面列出来，看是不是同一批。

看后台数据前，网域还是网址前缀资源要先选对。

是同一批，说明引擎在用同一批页面回应这两个词，等价于高重合度。这个信号来自你自己的数据，比抓搜索结果稳定得多。

还有一个更强的信号：互相替换

如果你发现某个查询在不同时间由不同的页面来承接——这周是A页出现，下周换成了B页，再下周又换回A——那基本可以确定引擎认为这两页在做同一件事，只是拿不准该给谁。

后台数据有黑洞，1000行与阈值过滤怎么补。

这种反复替换是最明确的合并信号，比任何重合度计算都直接。因为它不是你在猜引擎怎么想，是引擎自己在反复表态。

怎么看到这个现象？在后台按查询筛选，把时间范围拉长到半年，看这个查询下的页面列表。稳定只有一个页面，说明分工清楚；两个页面轮流出现，说明它们在互相顶替。

这个信号的另一面

反复替换还有一个后果，很多人没意识到：每次替换，这个查询的排名都会重新洗一次。因为换了个页面就等于换了一组信号，之前积累的表现数据没法完全继承。

收录排名流量是三件事，先分清卡在哪。

所以两个页面互相顶替的时候，它们的排名通常都不如合并之后的那一个。这不是玄学，是很直接的道理——你把本来能集中的东西分成了两半，还让它们轮流上场。

如果实在拿不准

有个折中做法：先不合并，而是把其中一个明确降级——把它从主导航里拿掉、减少指向它的内链、在内容上把它改成更窄的角度。观察四到六周，看另一个页面的表现有没有变好。

可逆的动作先做，按性价比排的清单。

变好了，说明确实在互相抢，可以放心合并；没变化，说明它们各自有各自的用户，留着。这个做法比直接合并可逆，代价只是多花一个月。对拿不准又不敢动的情况，值得。

大纲重合度才是真正的判据吗？

我认为是，而且它比搜索结果那一步更值得花时间。

为什么它更可靠

因为它测的是你能不能写出不同的东西，而这件事完全由你决定，不受引擎、地域、时间影响。搜索结果告诉你引擎现在怎么看，大纲告诉你你有没有本事让它改看法。

一稿多发怎么不被反超，归属机制。

怎么快速比

把两个页面的二级标题各列一行，摆在一起。然后问两个问题：新页面有几条标题是老页面完全没有的；这几条能不能各自撑起三百字以上的实质内容。

提纲阶段能省很多事，写作流程7步。

两个问题都过关，才值得新建。只有第一个问题过关，说明你想到了不同的角度，但没有对应的材料，写出来还是水。

一个更狠的检验

把新页面的大纲拿给一个不了解这个业务的人看，问他：这两页读起来是不是同一篇文章的两个版本。如果他说是，那基本就不用建了。

让机器读得懂，5维度写作法。

这个检验之所以有效，是因为写的人总能看出区别，读的人往往看不出。而搜索引擎在这件事上更像读的人。

大纲比对什么时候会误判

两个页面的大纲差别很大，但内容实际重合——这种情况常见于把同一批信息用不同的标题重新组织了一遍。防它的办法是看证据：两个页面里引用的数据、案例、来源，是不是同一批。是同一批，那大纲再不同也是一件事。

看证据不看结构，事实密度7招。

反过来的情况也有

大纲高度相似，但内容完全不同——比如两个市场的同类内容，结构一样但数据和案例都是本地的。这种该留，而且该用语言地区关系把它们串起来，而不是合并。

本地化不是翻译，原生再创作的生产线。

把大纲比对做成一张表

实操上我习惯做成两列的表：左边是老页面的二级标题，右边是新页面的。能对上的放在同一行，对不上的单独占一行。做完之后一眼就能看出有多少行是单边的。

往上讲的时候，6步翻译成业务语言。

这张表还有个额外用处：它直接就是合并时的施工图。如果最后决定合并，那些单边的行就是要搬过去的内容，能对上的行则要挑一个更好的版本保留。判断和执行用的是同一份材料，省掉一次重新梳理。

三百字这个阈值怎么来的

不是什么行业标准，是个经验数。三百字大约是把一个具体问题说清楚所需要的最小篇幅：给出结论、说明适用条件、举一个例子。少于这个数，通常意味着这一节只有观点没有支撑。

篇幅和深度的关系，怎么量才算数。

用它做判据的好处是可操作：你不用去评价内容“有没有深度”，只需要问自己“这一节我能不能写满三百字而不注水”。能不能写满，比够不够深刻，是一个诚实得多的自问。

大纲之外还该比一样东西

比这两页各自打算引用什么材料。数据来源、案例、图表、工具，这些是内容的骨头。两个页面如果计划引用同一批材料，那它们大概率就是同一篇文章的两种排法。

实体这条线，AEEBM五阶段。

这一条尤其能挡住一种常见的自欺：把同一份调研数据换个角度再写一遍，标题全不一样，读起来却处处眼熟。搜索引擎在这件事上比人敏感得多，因为它比对的正是那些具体的实体和数字。

一个反向的检查

做完前面所有比对，还可以反过来问一句：如果这两页只能留一个，留哪个？如果这个问题很好回答，说明它们本来就分了主次，那就该合并，把次的并进主的。

留一个还是留两个，更新合并删除的SOP。

如果这个问题很难回答，两个都觉得该留，那才是真正值得分成两页的情况。这个问法的好处是它绕开了所有技术判据，直接逼你做一次价值判断。

为什么大纲这一步经常被跳过

因为它发生在动手之前，而动手之前的所有工作在感觉上都像是拖延。写大纲不产生页面，比对大纲更不产生页面，两件事加起来要花半小时，而这半小时里什么都没做出来。

把它做成必填项，可交接的生产规范。

但这半小时挡住的，是几天的写作外加之后一直存在的一个多余页面。投入产出比高到离谱，唯一的问题是它的收益是隐形的——你永远看不到那个没被创造出来的重复页面。

这跟前面说的清理是同一类问题：做对了什么都不会发生。所以我更倾向把它做成流程里的一个必填项，而不是一个靠自觉的好习惯。提纲不填不给排期，是最简单有效的一条规矩。

大纲比对还能顺便定内链

比对完之后，那些“两边都有但角度不同”的部分，天然就是互链点。老页面在这一节提一句“更详细的做法见新页”，新页在对应位置回指老页。

互链点怎么找，内链网络的织法。

这一步在比对的当下做，成本几乎为零；等到两个页面都上线之后再回头补，就要重新读一遍两篇文章。顺手能做的事一旦拖到以后，多半就不会做了。

该合的时候怎么合，才不丢转化？

判断完是一回事，动手是另一回事。合并做砸的成本比不合并高得多。

先定保留哪一个

三个判据按优先级排：哪个有更多的自然流量、哪个有更多的外部链接、哪个的网址结构更符合你现在的规范。前两个看数据，第三个看规范。

信任怎么继承，6信号实战。

不要按“哪个内容写得好”来选。内容可以搬过去，流量和链接搬不过去——或者说搬过去要付跳转的损耗。

这一条经常被推翻，因为写内容的人会强烈主张保留自己那一版的网址。可以理解，但账不是这么算的：一个有三年历史、攒了几十条外链的网址，它的价值不在于上面写了什么，在于外面有多少地方指着它。

折中的办法是：保留旧网址，把新版内容整个换上去。这样既拿到了更好的内容，又保住了地址的历史。唯一要注意的是内容换掉之后，原来那些外链指向的说法可能已经不在页面上了，最好在文中保留一小节承接。

三个判据打架的时候

流量多的和外链多的不是同一个，怎么办？优先外链。因为流量是可以通过内链和曝光重新导过去的，外链不行——你没法让别人改他们的链接。

权重怎么传，子域还是子目录算过账。

如果两者都指向同一个，但那个网址的结构很难看（比如带着一串序号），要不要为了规范去换？不要。网址好不好看的收益，远低于换地址的成本。规范是给新页面用的，不是用来改造历史的。

合并之后旧网址还要留多久

跳转至少留一年，有条件的话永久留着。有人觉得跳转规则积累多了会影响性能，实际上除非规模到几万条，否则完全不用担心。

移除要多久，6大场景实测给了参照。

过早撤掉跳转，是我见过最可惜的一类操作。辛辛苦苦合并完，攒了半年的信号迁移，一撤跳转全断。撤跳转唯一合理的场景是这个地址已经很久没有任何请求了，而这件事需要查日志确认，不能靠感觉。

内容怎么并

不是简单地把两篇拼起来。正确的做法是先列出两边的大纲，去掉重复的部分，把保留页缺的那几节补进去，然后重新调整一遍顺序。

旧内容怎么翻新，12步实战。

拼起来的页面会很长而且逻辑断裂，用户读得出来。合并的目标是一个更好的页面，不是一个更长的页面。

判断有没有并好，有个简单办法：把合并后的页面通读一遍，看有没有哪两段在说同一件事。有，就说明只是拼在了一起。真正并好的页面读起来应该像一开始就是这么写的。

还有一个容易忽略的：标题也要重新想。两个页面各有一个标题，合并后不能简单选一个，因为新页面覆盖的范围比原来任何一个都大。标题不改，等于用一个更窄的说法去承接一个更宽的内容。

合并之后页面变得很长怎么办

这是常见结果，两篇各三千字，并完六千字。太长会影响读完率，但直接删内容又可惜。

长内容怎么排，7种结构化格式。

可行的做法是把合并后的页面重新分层：主线保留在页面上，那些只有少数人需要的细节部分抽出来做成折叠区块，或者干脆拆成一个更专门的子页面——注意这里的拆和之前的重复不是一回事，这次拆出去的是明确更窄的一个话题，有自己的独立角度。

拆的时候记得从主页面链过去，并且在子页面回链。合并加拆分听起来矛盾，其实是同一件事的两步：先把散的收拢，再按合理的边界重新切开。

区别在于切的依据。原来那种重复是按“谁建的、什么时候建的”这类偶然因素切开的；重新拆是按话题的实际边界切。同样是两个页面，一个是历史遗留，一个是设计结果，它们在数据上的表现会完全不同。

怎么确认拆得对不对？拆完之后看两个页面各自能不能拿到自己那一簇查询。能，说明边界找对了；如果子页面拿不到任何独立查询，那它其实不该被拆出来，应该作为主页面里的一节存在。观察周期同样是四到八周，跟合并一样。

跳转怎么做

被合并的网址做永久跳转指向保留页。别用软跳转，别直接删掉返回错误码，也别只在页面上放个链接说“已搬家”。

跳转配置抄这份，多域名跳主域实战。

跳转做完之后还有两件事经常被忘：把站内所有指向旧网址的内链改掉，把站点地图里的旧网址去掉。不改内链，你就在持续地给一个跳转喂流量；不改站点地图，你就在持续地告诉引擎这个已经作废的网址还很重要。

转化路径要单独检查

这一条是电商站特有的。两个页面可能挂着不同的营销活动、不同的推荐位、不同的加购按钮配置。合并之后，被去掉的那个页面上的这些东西，得有地方接。

落地页那一侧，30个A/B测试方案。

最常见的翻车是：某个广告投放的落地页正好是被合并掉的那个，跳转虽然没断，但落地页的内容跟广告文案对不上了，转化直接掉。合并之前先查一遍有没有付费流量指向它，是个五分钟能做完但经常被跳过的动作。

合并之后多久看效果

四到八周。前两周通常会有一段波动，甚至短暂下降，这是正常的。在两周内因为数据难看而把合并回滚，是最糟糕的操作，因为你会同时承担合并和回滚两次的成本。

抓取报告怎么读，五类问题URL的排查顺序。

为什么前两周一定会掉

因为跳转生效需要时间：引擎要重新抓取旧网址、发现跳转、更新映射、把信号迁过去。这个过程中，旧网址已经不返回内容了，新网址还没继承到信号，中间有一段真空。

分层索引那套，Base还是Landfill也影响恢复速度。

这段真空的长度取决于旧网址被抓取的频率。被抓得勤的页面恢复得快，冷门页面可能要一两个月。所以合并的时候，先合那些流量大的、被抓得勤的，恢复周期短，也更容易看出效果。

合并做完要通知谁

至少三方。投放那边，确认没有广告落地页指向被合并的网址。内容那边，让他们知道以后写这个话题该链哪一页。数据那边，在报表里标一个断点，否则下个月做同比的时候没人说得清为什么某个页面的数据翻倍了。

跨部门怎么打招呼，协作7动作。

第三条最容易漏，后果也最长久。一次没标记的合并，会在之后一年里持续制造无法解释的数据跳变，而每一次跳变都要有人花时间去查。

一次合并多少组合适

建议一批不超过二十组，而且同一批里最好是相似的类型。分批做的好处是出了问题好定位——一批二十组，如果数据不对，排查范围是二十个；一次性合了两百组，你根本不知道该从哪查起。

点了不等于复核，验证修复在验什么。

批次之间隔两周，等上一批的数据稳定了再动下一批。一个五百组的站，这样做要半年。听起来慢，但它是唯一一种每一步都可回滚的做法。

什么情况下不该合并

三种。一是被合并的那个页面上有活跃的付费流量，且落地页内容和广告文案强绑定；二是两个页面服务的是不同市场或者不同语言；三是其中一个页面正在被大量外部站点引用，而它的内容跟保留页并不完全等同。

有付费流量要先对齐，联盟客那一课。

第三种最容易被忽略。一个被很多人引用的页面，它的价值不只在于内容，还在于它是一个稳定的地址。合并它意味着所有那些引用都要多走一跳，而且引用它的人当初引的是那个具体说法，未必是保留页上的版本。

还有第四种，比前三种更常见但更少被提起：两个页面的转化率差别很大，而你不知道为什么。这时候合并等于用一个未经验证的假设去覆盖一个已经在跑的结果。

正确的做法是先搞清楚差别从哪来——是流量来源不同、页面结构不同、还是商品陈列不同。搞清楚之后再决定：如果差别来自可复制的东西，把它复制到保留页上再合并；如果来自流量结构，那这两个页面服务的可能本来就是不同的人。

合并之前的最后一道自问

动手之前问一句：如果三个月后有人问我为什么合并了这两个页面，我能不能用一句话说清楚。说不清楚的，先别动。

这个自问能挡住相当一部分“看着重复所以合了”的操作。重复是一个观察，不是一个理由；理由必须是合并之后会变好，而且能说出好在哪。观察和理由之间隔着一次判断，而这次判断经常被省略掉，因为观察本身看起来已经足够有说服力了。

反过来，那些能一句话说清楚的合并，做起来也顺——因为理由本身就指明了该保留哪一个、该搬走哪些内容、以及合完之后该看什么数据。说不清理由的时候，通常是判断还没做完，不是执行还没开始。

本次数据里那2390组，如果真要一组组问这句话，能一句话说清楚的可能只有序号型那六成。剩下的四成，多数需要先弄明白它们各自在做什么。这也是为什么我一直建议从序号型开始。

一套可以直接跑的自查动作

最后把这一整篇压成能执行的东西。

三十分钟版本

下载你的站点地图，把所有网址导进表格。用公式把每个网址的最后一段取出来，替换掉连字符，转小写。然后排序，肉眼扫一遍相邻的行。

网址处理的小工具，编解码与乱码还原。

相邻的行长得几乎一样的，就是重复组。这个土办法能找出序号型和增减词型，也就是本次数据里的八成。词序型找不出来，那得靠脚本。

三十分钟版本能查出多少

按本次数据的形态分布，排序扫一遍能覆盖序号型的61.9% 和增减词型的19.2%，合计八成。剩下的词序型和其他类型，排序之后不会相邻，肉眼扫不出来。

批量查这类问题，检测分类到提交一条龙。

八成对第一次做的人来说完全够了。先把这八成看见，比一次做到位重要得多——因为这八成里就已经包含了那些一件商品五个网址的极端情况，处理完之后你对自己站的状况会有一个完全不同的认识。

而且这个土办法有个额外的好处：因为要用眼睛扫，你会顺带看到很多别的东西——命名不一致的地方、路径结构混乱的段落、以及一些你完全不记得建过的页面。自动化脚本只会报它被要求报的东西，人扫一遍能看见的比那多得多。

两小时版本

写个脚本做词集指纹，就是我这次用的逻辑：取末段、切词、去停用词、单复数还原、排序、拼指纹。注意保留数字，只处理结尾的孤立序号。

脚本自己写也不难，用Claude Code做报表。

跑完之后按组数排序，先看最大的那几组。一个站的重复问题通常高度集中，处理掉最大的十组，能解决一半的量。

常态化版本

把词集指纹这套逻辑接进内容发布流程，新建页面时自动比一次，命中就提示。这是一次性投入，之后不需要再做审计。

接进流程里，自动化运维一条龙。

盘点表该有哪几列

表怎么设计，从指标体系到异常诊断。

处理顺序建议

先处理序号型，因为它量最大且能批量做；再处理年份型，因为它判断简单；然后是增减词型，需要逐组看；最后才是词序型和其他，它们量小但每一组都要判断。

先做便宜的，按性价比排序的清单。

做完之后该盯什么

盯两个数：站点地图里的网址总数，和重复组的数量。前者应该在清理后下降然后平稳增长，后者应该降到低位并且不再涨。如果重复组数量在清理之后又开始涨，说明生产流程里的那个源头没堵上，审计做多少次都是白做。

监控要多源，5步SOP与替代方案。

源头通常在哪几个地方

按本次数据反推，源头集中在三处。第一处是商品重新上架的流程：下架再上架时系统自动加序号。堵法是在上架逻辑里加一步，检查这个名字的历史网址，能复用就复用。

换基建要重搭，sitemap与重定向自己来。

第二处是多人协作建页：没有命名约定，也没有重名检查。堵法是发布前的词集比对提示。第三处是模板批量生成：没有商品数下限，也没有撞词检查。堵法是在生成条件里加两个判断。

三处堵法的共同点是它们都在生产环节，不在治理环节。这也是我做完这批数据最强的一个体会：重复不是清理不够勤，是生产没设闸。清理是把水舀出去，设闸才是把龙头关小。

一份可以照抄的检查清单

1. 下载全量站点地图，索引文件展开一层
2. 取每个网址的末段，切词、去停用词、单复数还原、排序，生成指纹
3. 数字一律保留，只删结尾孤立的短序号和年份，五位以上整条排除
4. 指纹相同但原串不同的，归为一组
5. 随机抽二十组人工确认，重点看最不像重复的那几组
6. 按形态分类，序号型走批量，其余逐组判断
7. 合并前查一遍有没有付费流量指向
8. 跳转、改内链、清站点地图，三件一起做
9. 把这套逻辑接进发布流程，做成事前提示
10. 每季度重跑一次，只看重复组数量的变化

做完第一轮之后的常见反应

多数人的第一反应是“怎么这么多”，第二反应是“这些页面原来还在”。这两个反应本身就说明了这件事的价值——它让一批你以为不存在的东西重新出现在视野里。

顺手也查一下体积，2MB抓取上限。

更全的一份，42步审计清单。

至于处理，不用一次做完。把清单跑出来，先处理序号型那六成，剩下的按季度慢慢消化。重要的不是一次清干净，是从此以后你知道这个数是多少，以及它是在涨还是在降。

回到最初那个问题

一个关键词值不值得单开一页？这批数据没有直接回答它，但它把这个问题往前推了一步：在问“要不要多开一页”之前，先问“我现在有几页在做这件事”。

选题从哪开始，先挖词再定题。

87.4% 的站里，这个问题的答案不是零。而只要它不是零，前一个问题的答案就大概率是“不用开，先去把已有的那几页理清楚”。

这两个问题的成本差得很远。开一页要写内容、配图、排期、上线、进导航；查一次已有的重复，一份站点地图加二十行脚本，半小时出结果。用半小时的动作，去挡住一次几天的投入，这笔账在任何时候都划算。

最后留一句

做完这批数据我最大的感受不是“重复真多”，而是这些重复几乎全部是流程的自然产出，没有一个是因为谁不认真。系统在网址冲突时自动加序号，是为了不让上架失败；两个人给同一件商品起了不同的名字，是因为没人告诉他们该叫什么；模板铺了两千页，是因为它本来就该铺。

少生成一页也是收益，从页面碳足迹到抓取经济。

每一步都合理，合起来产生了一个没人想要的结果。这类问题不能靠更努力来解决，只能靠在某个环节加一道便宜的检查。本文里所有的方法，说到底都是在找那道检查该加在哪。

常见问题解答

词集完全相同的两个网址，一定是重复吗？

不一定。本次抽样里大约有一成半属于合理组合，最常见的是一个品类页加一篇同话题的博客文章，两者面向的用户阶段不同。判断方法是比大纲：新页面有三条以上老页面没有的实质内容，就该留。

两个标记能不能同用，9种场景怎么判断。

结尾带 -1、-2的网址可以直接批量跳转吗？

基本可以，但要先查两件事：这些网址各自的当前状态码和商品在售状态，以及有没有付费流量正指向它们。前者决定保留哪一个，后者决定动手之前要不要先跟投放的人打个招呼。

规则写在哪一层，6层综合治理。

合并之后排名没涨，是不是白做了？

合并的主要价值是止损和让数据可读，不是提升排名。它解决的是抓取被分散、内链信号被劈开、报表数据被拆成几份这些问题。如果原来的重复页面本来就没什么流量，合并之后自然也不会凭空多出来。

数字不好看怎么讲，8维度的说法。

一个词值得单开一页的最低标准是什么？

三条同时满足：它能带来一组和现有页面区别得开的查询；你能写出至少三条现有页面没有的实质内容，每条撑得起三百字；站点结构里有它的位置，有上级页面和内链能指过去。电商品类页还要再加一条：至少八件商品。

一页吃一簇词，怎么布局。

没有工具能看搜索结果重合度，怎么办？

用后台的查询报表反推：把这两个词各自带来展示的页面列出来，看是不是同一批。是同一批，说明引擎在用同一批页面回应这两个词，等价于高重合度。这个信号来自你自己的数据，比抓取搜索结果稳定。

后台数据怎么读，从配置到诊断。

跨地区站的同话题页面要不要合并？

不要。它们是不同市场的版本，正确的处理是让它们互相声明语言地区关系。需要判断的是同一个市场内部的重复，比如英国站既有博客又有品类页盯着同一簇词。

关系怎么声明，return tags与x-default。

模板化生成的页面算不算重复？

取决于每一页有没有独立的内容和足够的支撑。品类乘颜色乘尺码这类组合页，多数情况下只有前几层值得独立成页，越往下越应该做成筛选条件。判断的锚点是商品数和内容差异，不是词的搜索量。

变体的三层治理，Schema、canonical与URL。

发布前的重名检查具体怎么实现？

逻辑就是本文用的那套：把新页面的标题或者拟定网址拆成词、去停用词、单复数还原、排序拼成指纹，跟已有页面的指纹表比一次。命中就提示，不强制拦截。

不同页面类型怎么配，5类页面的差异。

指纹表可以在每晚从站点地图重建一次，几秒钟的事。提示而不拦截，是因为确实存在合理的同词集组合，强制拦截会挡住正常业务，几次之后就会有人来要求关掉这个功能。

清理之后网址总数下降，会不会影响收录量？

收录量会降，这是预期内的，因为被合并的那些网址本来就不该单独占一条记录。要看的不是收录总数，而是有流量的页面数——这个数在清理之后应该持平或者上升。用收录总数考核SEO，本身就会激励制造重复。

用什么当考核指标，实测数据参照。

词集判据会不会漏掉最重要的那类重复？

会。它只认用词层面的重复，说的是一件事但用词完全不同的那类完全看不见，而那类往往是最值得处理的——比如一篇叫“怎么挑登山包”的文章和一篇叫“背包选购指南”的文章。要抓这一类，得比内容或者比查询覆盖，成本高得多。所以这套方法的定位是低成本的第一道筛，不是全部。

语义层面的判断，从关键词到意图理解。

这批数据能代表所有电商站吗？

不能，它有三个明确的偏差。样本偏向欧美中大型DTC与电商品牌，用同一类建站平台的占比很高；只看了站点地图里的网址，没进站点地图的重复页面完全没被统计；判据只认用词层面的重复，说的是一件事但用词不同的那类全部漏掉了。这三条都让数字偏保守。

同一批数据的另一面，品牌词那条线怎么画的。

权威参考资料

摘要：把211个国际化电商域名的图标全部抓了一遍。兜底路径 /favicon.ico只有59个能返回一张真图标，其余要么是空的，要么返回一整张网页——最夸张的一个返回了4.5 MB的HTML，状态码还是404。页面里主动声明图标的有133个站，平均每站声明3.4个，最多的声明了22个，而Google明说每个站只用一个。名字那一半同样乱：98个有三个以上名字来源的站里，只有22个的四个来源完全一致。

2026年8月11日，有人拍到Google搜索结果里的赞助位在做一个新测试：广告上方多出一条摘要行，里面放着广告主的名称和它的网站图标。同一周，本地包和Discover的广告位上也出现了新的标识。

这类变化的共同点是，展示层多出来的东西不是你填的，是系统替你取的。你在广告后台里找不到一个字段叫“广告主名称”，也找不到一个上传入口叫“图标”。它去你的站上拿。

那就有一个很自然的问题：它能拿到吗，拿到的是哪一个。保哥把手上那批国际化电商站的图标和名字全量抓了一遍，答案比预想的难看不少。光是那个最基本的兜底路径，211个域名里就有152个拿不到一张能用的图。

这篇文章的前半段讲机制：这类“平台替你决定”的规则长什么样、你手上还剩下什么牌。后半段是实测：图标那一半和名字那一半各自出了什么问题，以及一份能在半小时内跑完的收敛清单。

广告位上多出来的那一行是什么？

先把这次变化本身说清楚，因为它决定了后面所有排查的优先级。

广告产品的形态变化通常先在小范围测试，Google砍掉Lead Form五万美元门槛的机会是另一次改动。

被拍到的那个测试

被拍到的那个测试形态是：在赞助结果的上方，加一条摘要行，左边是广告主的网站图标，右边是广告主的名称。它看起来很像自然结果里早就有的那一行——搜索结果的标题上方，一直有站点名称加图标的组合。

广告位的展示形态变了，出价目标那套账并不会跟着变，目标ROAS到底该定多少的四步算法还是老规矩。

换句话说，广告位正在向自然结果的展示形态靠拢。这件事对投放的直接影响是，你的品牌识别度第一次开始影响广告位的点击率，而这部分识别度不是由你的广告文案决定的，是由你的站决定的。

对投放团队来说这是个陌生的位置。以往广告位上的每一个像素都能在后台找到对应的输入框：标题、描述、显示网址、附加信息、素材。这条摘要行是第一个例外——它长在广告位上，配置却不在广告后台里。

为什么这个测试值得当回事

单看一次界面测试，确实没必要紧张，Google每年做几百个这样的试验，多数不会全量。但这一条有两个特别之处。

上一篇量的是同一批站的名字字段，商家名称禁令当尺子量出来的那份结果可以接着这一篇一起看。

第一，它复用的是已经成熟的能力。搜索结果里的图标行和站点名称行早就上线好几年了，机制稳定、覆盖面完整。把一个成熟能力搬到另一个位置，落地阻力很小。

第二，它改变的是归属感。广告位上出现你的图标和名字，等于把“这是谁投的”这件事前置了。对认知度高的品牌是加分，对认知度低的是减分，而对图标或名字取不到的站，是直接的空白。

同一周还有另一条相关变化

本地包和Discover的广告位上也开始出现新的标识行。这两条放在一起看，指向同一个趋势：展示层的信息密度在增加，而新增的那部分信息全部来自平台自己的抓取，不来自你的投放设置。

展示层多出来的文案同样来自抓取，广告系列自动升级后文案原料全在落地页上讲的是同一个机制。

这就是为什么值得现在就排查一遍。等到这个测试全量上线，你再去改图标，中间还隔着几天到几周的重新抓取时间。这类事情没法临时抱佛脚，只能提前把料备好。

它跟自然结果里的那一行是同一套数据吗

官方没有明说，但从形态判断，大概率共用同一套。自然结果里的图标行，走的是搜索的图标抓取机制；站点名称行，走的是站点名称系统。两者都只认主机名，也都只取一个结果。

自然结果与广告位共用的是同一份身份数据，实体主页怎么搭才算把品牌身份立住里有这套数据的全貌。

这个判断有一个很实际的推论：你为自然结果做的图标和名字优化，会顺带影响广告位；反过来也一样。所以这不是一件属于投放团队或者SEO团队某一方的活，它属于谁维护站点的模板，谁就得管。

这个归属问题在实际团队里挺麻烦的。投放的人看到广告位出了问题，第一反应是去广告后台找原因，找不到就报给平台；做SEO的人不看广告位，不会主动去查。结果就是一个明明五分钟能修的问题，在两个团队之间来回传了两周。

保哥去过一个做家用医疗器械的客户，他们的搜索结果里一直显示一个灰色的默认图标，投放和SEO各自查了一轮都说不归自己管。最后是前端同学随口一句“那个文件上次发版好像被清了”，问题当场定位。展示层的问题，根子往往在构建流程上。

为什么这类事你在后台找不到开关？

找不到开关，不是功能没上线，是它压根不以开关的形式存在。这一类规则值得单独归一类。

后台里找不到的设置往往是被合并进了别处，本地服务广告并进Performance Max之后就是一次入口消失。

平台介入的第二种方式

上一篇讲过第一种：禁止型，平台立规矩，你只能删，违反了要挨罚。这一篇讲第二种，可以叫代劳型——平台自己算出一个结果并展示，你只能影响输入，不能指定输出。

平台代劳的比例这两年明显在升高，GEO到底怎么落地的实施策略里对这个趋势有更完整的判断。

三十秒的判据

判断一件事是不是代劳型，只需要问一个问题：后台里有没有一个字段，能把这个结果直接写死。

官方措辞的细微差别决定了规则的效力，robots规则的星号对某些爬虫无效就是一次典型的误读。

有，那就不是代劳型，照着填就行。没有，那就是——而且你会发现官方文档在描述这类功能时，措辞非常一致。站点名称那份文档的原话是“要表明你的站点名称偏好，请在首页添加WebSite结构化数据”，用的词是偏好。图标那份文档说的是“把图标链接添加到首页”，然后紧跟一句“搜索只按主机名定义一个站点，也只支持一个图标”。

偏好、支持、考虑——这三个词一出现，基本可以确定你面对的是一台会自己做决定的机器。

代劳型的投入曲线是钝的

禁止型是阶跃：过线之前收益为零，过线之后不再增长。代劳型不一样，它是一条很快就平掉的曲线。

标题被系统重写也是代劳型的典型，Google用AI重写标题的改写率与应对给出了具体比例。

前半段很陡：从“候选一团乱”到“候选收敛成一个”，系统挑错的概率大幅下降。后半段几乎是平的：你把那一个候选做得再精致，也改变不了它有可能被拒绝、被替换、被截断的事实。

所以这一类事情的正确姿势是把候选收敛到一个，确认那一个是好的，然后停手。本次实测里出问题的站，绝大多数不是候选做得不够好，是候选太多、且其中一部分是坏的。

代劳型和禁止型的处理顺序不一样

禁止型规则要先做，因为它的下行是断崖式的。代劳型排第二，理由是它的收益虽然有上限，但相当确定：候选收敛之后，系统挑对的概率立刻上去，不需要等算法更新，也不需要积累权重。

短平快的活该排在前面，新网站前十二周的技术地基清单里的排期逻辑就是这么定的。

还有一个实际考虑：代劳型的活通常很短。本文后面那张核对表，一个人一下午能把一个站跑完。一下午能做完、收益确定、不需要跨部门审批的活，在任何排期里都该排在前面。

怎么判断自己是不是已经收敛了

有个很省事的自测：把你觉得系统会用的那个答案写下来，然后去源码里找证据。如果你能指着某一行说“就是这个”，那你收敛了；如果你得说“大概是这几个里的一个”，那你没有。

能不能指着一行说就是它，是个很好的自测，Schema对AI搜索到底有没有用里也用了同一种验证方式。

本次样本里七成七的站属于后者。不是他们填错了，是他们填了好几个，然后默认系统会挑对那个。

Google对图标的硬要求一共有几条？

要判断一个站的图标能不能被取到，得先知道判据。官方文档写得比大多数人以为的短。

官方要求逐条摆出来才好逐条核对，Shopify博客多级面包屑的三种方案也是按这个结构写的。

逐条摆出来

图标和名字都属于展示层的结构化声明，结构化数据怎么配合SEO落地的完整指南里有整套字段的配法。

最容易被误传的那一条

网上流传最广的一个说法是“图标必须是48的倍数”。查了原文，这条不成立。原文写的是必须是正方形、至少8×8，然后建议使用大于48×48的图标以获得更好的效果。

被广泛转述的数字往往对不上原文，最佳实践清单里九条查得到出处八条数字对不上就是一次系统核对。

这个区别很重要，因为它把两件事分开了：一条是硬门槛（正方形、8×8），不满足就用不了；一条是效果建议（大于48×48），不满足只是不够清晰。前者决定有没有，后者决定好不好看。

顺带说一句，保哥在动手之前也以为是48的倍数，是查原文的时候才发现记错了。这类被广泛转述的“硬要求”，动手前一定要回原文核一遍。因为你的整套判据都会建立在它上面，判据错了，后面所有数字都得推翻。

这次幸好是在写代码之前查的。如果按48倍数那个口径跑完，得出的结论会是“128个站里只有59个合格”，一个听起来很惊人、实际上完全错误的数字。误传的判据不会让你的数据变脏，它会让你的数据变得毫无意义——每一条记录都算对了，只是拿错了尺子。

这一类风险有个共同特征：它发生在动手之前，所有事后检查都抓不到。你可以复查代码、复查样本、复查统计口径，但如果最初那条规则记错了，这些复查一次都不会亮红灯。唯一的防线是回原文。

顺手核了另外两条流传的说法

既然回了原文，就把另外两条常听到的说法一起核一遍。

核对原文之外也可以借工具看别人怎么配，十款网站技术栈检测扩展的实测对比里有能直接看head的。

一条是“图标必须是ICO格式”。原文说的是任何有效的图标格式都受支持，并给了一个格式清单的外部链接。所以PNG、SVG、GIF都行。本次样本里PNG占了345个，是绝对主力，ICO只有41个——如果这条传言是真的，那市面上绝大多数站的图标都该是无效的，显然不是。

另一条是“图标必须放在根目录”。原文说的是把图标链接添加到首页的head里，并没有要求物理位置。本次样本里56个站的图标托管在站外主机上，包括大量电商平台自带的CDN，这个做法本身没有问题。

两条传言的共同来源大概是十几年前的浏览器行为——那时候确实只认根目录下的ICO。技术传言的保质期通常比技术本身短得多。

“只支持一个”这句话的分量

这是整份文档里最有信息量的一句，可惜它写得太轻描淡写。原文的意思是：搜索按主机名来定义一个站点，一个站点只支持一个图标。

按主机名收敛这件事在多语言场景下更明显，hreflang备用网址被当成规范页别名是另一次收敛。

把它翻译成人话：不管你在页面里声明了几个图标、多少种尺寸、多少种格式，最后被用的只有一个，而挑哪一个是系统的事。你能做的是让它的选择空间尽可能小，且每一个选项都不出错。

这句话还有一层含义容易被忽略：既然一个站只有一个图标，那么你没法给不同栏目、不同语言目录配不同的图标。整个主机名共用一个，这是一个比多数人以为的更强的约束。有些团队想给博客目录换个图标区分内容类型，这条路是不通的。

“按主机名定义站点”这半句也值得留意。它意味着www和裸域、主域和二级域，在这套机制里是不同的站——各自有各自的那一个图标。如果你的站有多个可访问的主机名，每一个都得单独准备。这一点在做多国站的时候特别容易漏：de.example.com和example.com是两个站，它们的图标是两回事。

那条关于内容的规则很少有人知道

文档末尾还有一条：Google不会展示任何它认为不适宜的图标，包括色情内容和仇恨符号，遇到这类会替换成默认图标。

不做什么的清单常常藏在文档末尾，AI内容披露里那份不做什么的清单也是这么被翻出来的。

对正经品牌来说这条基本用不上，但它透露了一个信息：这套机制里存在一个审核环节，也就是说你的图标不是被机械地取走，它会被看一眼。这也解释了为什么抓取周期是几天到几周，而不是几小时。

133个站声明了451个图标，可最后用得上几个？

知道了判据，就可以看实测了。先看声明这一层。

堆数量不解决问题，这在商品侧同样成立，用Performance Max给零流量商品再来一次机会是另一种解法。

声明数量的分布

170个可解析首页里，133个声明了图标，37个一个都没声明，占21.8%。声明的那133个站一共给出451个文件，平均每站3.4个。

声明越多越保险这个直觉在很多地方都不成立，Googlebot抓取2MB限制的八步优化是另一个例子。

一多半的站只声明一个，这是最健康的做法。但另一头也很显眼：有两个站各声明了22个图标。22个文件，系统只用一个，剩下21个的唯一作用是给浏览器和移动端设备用——这本身没错，错的是很多团队以为多声明几个能提高被正确抓到的概率。

那些rel值都是干什么的

451个声明按rel拆开，分布是这样的：icon 207个、apple-touch-icon 171个、shortcut icon 59个、apple-touch-icon-precomposed 38个、mask-icon 15个。

link和rel这层标记同时服务于无障碍，网站无障碍访问怎么做的十八个改动里有相关的取值说明。

这几个取值的含义在 HTML规范里link元素与rel的定义那一节有正式说明，而各取值在实际浏览器里的行为差异，可以对照 rel属性各取值的说明。其中真正被搜索用到的是前四类。apple-touch-icon系列加起来209个，比标准的icon还多。这说明大量声明其实是为iOS主屏图标准备的，跟搜索结果里的展示是两回事，只是恰好也在候选池里。

mask-icon那15个是Safari固定标签页用的单色矢量图，跟搜索完全无关。它们在候选池里的唯一作用是增加噪声。

还有一个细节值得注意：shortcut icon这个写法有59个站在用。它是历史遗留——早年的IE只认这个写法，官方文档里说明保留支持是出于历史原因。今天写它没有坏处，但也没有必要，纯标准的icon就够了。

把这几类的用途列成一张表，你就知道自己该留哪几个了。

按这张表清一遍，多数站的图标声明能从五六个降到两三个。这不是为了省几行代码，是为了让剩下的那几行有人真的会去检查。

还有一类声明本次没统计

除了link标签，现在还有一条路可以声明图标：网页应用清单文件。它是一个单独的JSON，里面可以列一组不同尺寸的图标，主要服务于把网站装到桌面或手机主屏的场景。

多处声明无人统一是个通用病，网址用扁平还是层级在SEO上到底差在哪里也有一份同源的取舍。

本次没有统计这一类，原因是它需要多请求一个文件、再解析里面的图标列表，工作量翻一倍，而它对搜索结果里的图标展示影响不明。写在这里是提醒你：如果你的站配了这个清单，那它也是一处需要保持同步的声明位置。

实际见过的坑是这样的：团队换了图标，把head里那几行都改了，唯独忘了清单文件里那一组。结果浏览器标签页上是新标志，装到主屏上是旧标志。这类不一致跟本文讲的其它问题同源——多处声明、无人统一。

顺着这条线索还能想到别的地方：邮件模板里的品牌图标、社交平台的头像、应用商店的图标、后台登录页的标志。这些位置各自独立、各自维护，而它们对外呈现的是同一个品牌。没有哪一个系统会替你检查它们是不是一致，唯一的办法是自己列一张清单，改标志的时候照着过一遍。

这张清单的价值不在技术层面，在于它把一件本来分散在四五个人手上的事，变成了一张有人负责的表。身份这件事的所有麻烦，归根到底都是同一件：说的地方太多，管的人太少。本文量的两样东西，图标和名字，正好是这句话最典型的两个样本——平均每站声明三点四个图标，四个来源里只有两成二说的是同一个名字。这两个数字都不是能力问题，是没有任何一个岗位的职责说明书里写着“确保这几处对得上”。补上这一句职责，比补任何一个文件都管用。而且这句职责挂在谁头上其实不重要，重要的是它得有人认领——本次样本里做得最好的那批站，共同点从来不是技术更强，而是有人把这件事当成了自己的活。

声明多了到底有没有害

直说结论：声明多本身无害，声明多而其中有坏的才有害。本次数据里11个站的声明里含取不到或者不是图片的文件，其中5个站的所有声明全部不可用。

候选多了没人逐个检查，这跟报表口径打架是同一类管理问题，商品页推荐位两套报表打架的复盘值得对照。

换个角度看这件事：如果你只声明一个，你会盯着它；声明22个，你不会去检查每一个。候选数量和检查密度是反比关系，这才是多声明的真实代价。

那37个一个都没声明的站怎么办

它们不是没有图标，是把这件事完全交给了兜底路径。这个做法在十年前很安全——那时候所有站的根目录下都真的躺着一个favicon.ico文件。

建站方式直接决定了静态资源放哪，SaaS托管自建与纯代码的选型全拆解里有各类栈的差别。

现在不一样了。现代的建站方式里，静态资源往往走独立的构建目录或者CDN，根目录下什么都没有，请求会掉进前端路由。那个曾经最可靠的兜底，正是今天最不可靠的一环。下一节的数据会把这一点量出来。

格式混用的34个站

还有一个数字顺手记一下：34个站在自己的图标声明里混用了多种格式，比如同时给PNG和ICO，或者同时给PNG和SVG。最热闹的一个站一口气用了四种：PNG、GIF、SVG、ICO。

多种格式并存最怕不同步，Shopify图片SEO从命名到压缩的完整清单里有统一产出的做法。

混用本身不违规，官方明说任何有效格式都支持。但它会带来一个隐蔽的后果：不同格式的文件往往由不同的流程产出，它们很容易在某次改版之后变得不一致。你换了PNG那一版的设计，ICO那一版还是老图，而系统可能恰好用了ICO那个。

所以混用的前提是有人负责让它们保持同图。做不到的话，宁可只留一种。

兜底路径那个文件，211个域名里只剩59个还在

就算你一个都不声明，浏览器和抓取程序也会去试根目录下的那个默认文件。这是最后一道兜底，它的可用率决定了那37个不声明的站还有没有救。

主机名与静态资源的路由规则挨得很近，多域名301跳转到主域名的完整配置里有对应的写法。

结果比预想的差

同一批电商站的另一项体检也是七成不合格，四十六个电商站的页面体积实测可以并排看。

211个域名里，只有59个能从这个路径拿到一张真图标，占28%。剩下152个，兜底这条路是断的。

先说清楚这批数字怎么来的

做法很直接：对211个域名逐个请求根路径下那个默认文件，跟随跳转，记录状态码、返回字节数和内容类型，然后把文件下载下来读它的头几个字节判断真实格式。

读原始响应比读报表可靠，日志分析一步步挖出AI爬虫真相用的是同一种从底层数据反推的路子。

判断格式用的是文件签名而不是响应头声明的内容类型，因为后者不可信——本次就有一批响应声称自己是图片，实际返回的是HTML。凡是能从文件本身读出来的东西，就别信别人怎么说。

这一步还有个小坑：ICO文件的宽高字段只有一个字节，256这个尺寸被编码成0。不处理这一条的话，256×256的图标会被读成0×0，然后当成解析失败扔掉。这类编码约定造成的“假缺失”，在数据处理里比真缺失更危险，因为它不会引起任何怀疑。

那50个返回网页的最有意思

返回HTML，说明这个路径命中了站点的通用路由，被当成一个普通页面处理了。绝大多数返回的是404页面，少数几个甚至返回200。

该返回空的地方返回了正常页面，四十个电商站的站内搜索页实测记录的是同一类假成功。

按字节数排一下，前几名相当惊人：

最上面那个值得念一遍：请求一个几KB的图标文件，收到4.5 MB的HTML，而且状态码是404。这意味着每一个访问过这个站、或者抓取过这个站的客户端，只要去试一次那个路径，就要为一张不存在的图片下载四兆多的网页。

返回200的那两个更麻烦

swarovski.com和deuter.com的兜底路径返回的是200加一整张网页。404至少还诚实地说了“没有”，200是在说“有，就是它”。

状态码说的话和事实不符会带来一连串误判，已收录页面加noindex后多久消失的实测里有类似的观察。

这属于软404的一个变种，只是发生在一个几乎没人检查的路径上。任何一个按内容类型判断的程序，拿到一个声称成功、实际是HTML的响应，都只能自己去猜发生了什么。

软404这件事本身在SEO圈里被讲了很多年，但讨论几乎全部集中在内容页上——商品下架了返回200空白页、分类页没有商品还照样返回200。没有人去查静态资源路径上的软404，因为那不是内容，不影响收录。

可现在它开始影响展示了。图标是展示层的一部分，而展示层的抓取同样要判断“这个地址给的到底是不是我要的东西”。一个在收录这件事上完全无害的问题，换个场景就变成了有害的。

按服务器类型看这条路的通过率

把211个域名按响应头里的服务器标识分组，通过率的差异非常明显。传统的nginx、Apache这类直接托管静态文件的，兜底路径可用率明显更高；而各类现代托管平台和前端框架的默认部署，可用率显著偏低。

服务器配置差异对SEO的影响面比想象中大，服务器配置对SEO影响的二十项清单逐项列过。

这不是说哪种技术更好。差别的根源是“根目录下有没有一个物理文件”，跟性能、安全、开发体验都没关系。传统栈天然有，现代栈天然没有，除非你专门放一个。

这条观察的实用价值是：如果你的站是这几年新建的、跑在现代托管平台上，那么你的兜底路径大概率是断的，不用查也能猜个八九不离十。去查一下，然后花五分钟补上。

补的方式有两种，选一种就行。一种是在构建输出目录的根下真的放一个物理文件，这样请求会命中静态资源，不进路由。另一种是在服务器或者托管平台的路由规则里，给这个路径单独加一条，让它直接返回文件或者返回一个干净的404。第二种更彻底，因为它顺带把“返回4.5 MB网页”这个副作用也消掉了。

怎么快速自查这一条

一条命令就够：请求你自己的 /favicon.ico，看三样东西——状态码是不是200、内容类型是不是图片、字节数是不是几KB到几十KB。三样里有任何一样不对，这条兜底路径就是断的。

批量检测地址可用性有现成的做法，网站死链怎么批量查出来的一条龙流程可以直接改来用。

把这三样连起来判断很重要。只看状态码会漏掉那50个返回200或404却给了HTML的；只看内容类型会漏掉那些声称是图片实际不是的；只看字节数会把一张几百KB的设计稿当成正常。三样一起看，才是一次可靠的判断。

如果你想更省事，可以只看字节数这一项做初筛。一个正常的图标文件通常在1 KB到50 KB之间，超过100 KB基本可以断定出事了。本次样本里返回超过50 KB的那14个，无一例外全是网页。

断了要不要修，取决于你有没有正确声明。如果head里的声明是好的，兜底断了影响有限；如果你什么都没声明，那这条路断了就等于没有图标。本次样本里37个站属于后者。

为什么这条路会断得这么普遍

把返回情况按站点技术栈分一下就能看出规律。返回真图标的那批，绝大多数是传统服务器直接托管静态文件的站；返回HTML的那批，几乎全部是走前端框架加通配路由的站。

前端路由接管一切是现代栈的默认行为，搜索引擎抓取和渲染DOM分几步解释了它带来的连锁反应。

成因是这样的：现代前端框架的路由规则通常是“任何没匹配到静态资源的路径，都交给应用处理”。而根目录下如果没有那个物理文件，请求就落进了这条规则，应用当然只会渲染一个页面出来。这不是谁写错了配置，这是默认行为撞上了一个历史约定。

知道成因，修法就明确了：在构建输出的根目录里真的放一个文件，或者在服务器层给这个路径加一条专门的规则。两种都行，成本都是几分钟。

一个容易被忽略的连带影响

兜底路径返回一整张网页，除了图标拿不到之外，还有个副作用：浏览器每打开一个标签页就会去请求一次这个地址。

为不存在的资源反复付带宽是抓取预算里的老问题，抓取预算优化的十二项实操指南里有对应的排查。

对那个返回4.5 MB的站来说，这笔账值得算一下。假设一天有十万次页面访问，浏览器缓存不命中的比例哪怕只有百分之一，那也是一千次4.5 MB的传输，接近4.4 GB。为一张不存在的图付这么多带宽，而且没有任何监控会告诉你这件事正在发生。

这个估算是粗的，实际数字取决于缓存策略和客户端行为，但量级足以说明问题。

你声明的那些图标，有多少其实是坏的？

声明得对不对，比声明得多不多重要得多。这一节量的是那451个文件里，有多少根本取不回来。

素材层的坑往往不在策略上而在文件上，PMax六个月实战避坑的信号源与素材记过一批类似的。

坏文件的分布

451个文件里，24个取不到或者返回的不是图片，涉及11个站。乍看比例不高，但按站看就不一样了：其中5个站的所有声明全都不可用。

按站看和按文件看得出的结论可以差很远，阿里国际站五百九十万页面被清零的复盘也是这个道理。

stokke那四个410值得单独说

410这个状态码的含义是“这个资源曾经存在，现在被永久删除了”，它比404更明确。四个图标文件全部返回410，说明这些文件确实曾经在那儿，后来被清理掉了，而首页里的声明没跟着改。

构建产物路径与模板写死的链接容易撞车，自建站谷歌SEO开发期的十大优化要点里列了要盯的位置。

从路径能看出成因：那几个地址里带着一段版本号一样的数字。这是典型的构建产物路径——每次发版生成一个新目录，旧目录被清掉，而head里的链接指向的还是旧目录。

这类问题在做前端发布流程的时候特别常见，而且它不会影响页面显示，因为浏览器拿不到图标只是不显示而已，不会报错。一个不报错的失败，可以安静地存在很多年。

再往下想一层：410是一个需要服务端主动配置才会返回的状态码，默认行为通常是404。这说明那个站的运维是认真做过资源清理的——他们知道这些文件被删了，也告诉了客户端。问题不在删得对不对，在于删的人和写head的人不是同一拨。

这个案例的可迁移之处在于，构建产物路径带版本号是现代前端的标配，而head里的图标链接往往写死在某个模板里，不参与构建。一边每次发版都换路径，一边永远不变，撞车只是时间问题。解法是让那几行链接也走构建变量，或者干脆把图标放到一个不带版本号的固定路径下。

mango那五个返回HTML的成因不一样

mango.com的五个图标地址全部返回HTML。看路径能发现，它们都带着构建工具生成的哈希段。这类地址通常是有效的，返回HTML说明请求根本没落到静态资源服务上，而是被前端路由接管了。

同一个地址对不同客户端返回不同东西是常见设计，用内容协商给AI交付Markdown的实操讲了它的正确用法。

更可能的解释是这些地址需要特定的请求头或者会话才能命中真实资源，直接请求会掉进兜底页面。对抓取程序来说，结果是一样的：它拿不到图。

notino那四个又是另一种情况

notino.com的四个图标全部返回了无法识别的内容——状态码200，但文件头既不是PNG也不是ICO，读不出来是什么。

中间层悄悄改写内容这件事不止一次出现，浏览器自动翻译把选项改掉而问卷看不出异常是另一个版本。

这种形态最可能的解释是响应经过了某层加工：可能是被压缩了但没声明编码，可能是被某个安全或加速服务包装过，也可能是内容协商出了岔子返回了一个占位。对客户端来说，结果和拿到一张坏图没有区别。

它跟前面几个的区别在于排查难度。410和HTML都很好定位——一看状态码或者一看开头几个字节就明白了。而这种“是200、有内容、但内容认不出来”的情况，只有真的去读文件头才会暴露，任何只看状态码的检查都会放行。

五个站全坏这件事说明了什么

把arcteryx、mango、notino、stokke、swarovski这五个站放在一起看，有个共同点：它们都是有一定体量的品牌，站做得不差，页面显示一切正常。

没有报错的失败最难被发现，用户扫完一整屏一个都没点开这件事也是一次静默流失。

坏掉的只有那几个不影响显示的地址。浏览器拿不到图标，只是标签页上少一个小图；没有报错，没有控制台警告，没有任何一个监控会告诉你这件事。

这类问题的分布特征很有意思：它跟团队水平几乎没有相关性，跟“有没有人专门检查过这几个地址”高度相关。而“有没有人检查过”这件事，在绝大多数团队的流程里根本没有位置。

自查的口径要定在哪

不要只看状态码。本次样本里，返回200却不是图片的有一批，返回图片却是空文件的也有。正确的判据是三件事同时成立：状态码200、文件头是已知的图片格式、能解析出宽高。

判据定得松，结论就没意义，三百个站实测出来的收录速度指标怎么读里有口径设计的思路。

最后那条最关键。有些文件状态码正常、内容类型也写着image，但文件本身是截断的，解析不出尺寸。这种情况只有真的去读文件头才能发现。

怎么读ICO文件的真实尺寸

顺手记一个技术细节，因为它在这次测量里踩过坑。常见的图片处理函数大多不支持ICO格式，直接调用会返回失败，容易被误判成“文件坏了”。

读字节而不是读声明，这条原则在识别请求来源时同样适用，五种代码识别搜索引擎蜘蛛的实战里有对照。

ICO的头部结构其实很简单：开头四个字节是固定标记，接着两个字节写明这个文件里打包了几张图，然后每张图各占十六个字节的目录项，其中头两个字节就是宽和高。有一个反直觉的地方：宽高字段只有一个字节，所以256这个尺寸被记成0。不知道这条的话，一张256×256的图会被读成0×0。

这个坑很典型：一个看起来是“数据缺失”的值，实际上是编码约定。本次统计里有几个256×256的图标，如果没处理这一条，它们会被当成解析失败扔掉，结果就是尺寸分布的高位档被少算。

SVG的尺寸怎么算

SVG是矢量图，严格说没有固定尺寸。本次的处理办法是读它的viewBox属性，取里面的宽高值当作名义尺寸；读不到就只记录它是SVG，不参与尺寸统计。

测不出就标测不出，比编一个数字强，测试赢了上线却掉的那二十六天也是靠承认边界找到原因的。

这个处理在官方口径下是安全的，因为文档明说SVG这类矢量格式不受具体尺寸限制。把测不出的东西诚实地标成测不出，比给它编一个数字强。本次451个文件里有32个SVG，它们在尺寸那张表里全部被排除。

尺寸这一关，多少站过不去？

拿到了文件，接下来看它够不够格。判据是官方那两条：正方形，至少8×8，建议大于48×48。

图片资源的呈现细节很容易被长期忽略，那几张没露出来的商品图是同一类问题。

整体尺寸分布

451个文件里能解析出宽高的，按尺寸出现次数排，前几名是32×32出现95次、16×16出现61次、180×180出现39次、48×48出现29次、192×192出现23次、96×96出现22次。

尺寸与格式的取舍在图片SEO里是老话题，图片SEO的文件名与WebP懒加载怎么落地可以顺带过一遍。

32和16加起来占了大头，这是历史习惯——早年的浏览器标签页图标就是这两个尺寸。180×180那一档是iOS主屏图标的标准尺寸。真正为搜索结果准备的尺寸，反而不多。

这个分布本身讲了一个故事：这些图标当初是为浏览器和手机做的，不是为搜索结果做的。16和32这两个尺寸的存在理由，是十几年前浏览器标签页的物理像素；180的存在理由是iOS主屏。而搜索结果里的图标展示尺寸，在高分屏上远超这两档。

所以那47.7% 不是懒惰的结果，是历史的结果。这批文件当年做得完全正确，只是使用场景后来变了，而没有人回头重做过。这类问题的特征是：不做任何改动，它会随着时间自动变糟。

48×48那29次出现值得看一眼

尺寸分布里，48×48出现了29次，排第四。这个尺寸既不是浏览器标签页的传统尺寸，也不是iOS主屏的标准尺寸——它出现在这里，说明有一批站是照着搜索的建议来做的。

照着建议做和刚好卡在线上是两回事，FAQPage结构化数据的八步实战里也强调过留余量。

但48×48只是官方所说的“大于48×48”那条线上的临界点，严格说它并没有超过。如果你要照建议做，直接给一张96或者192更稳妥，不多花什么成本。

另外提一句，图标这件事上没必要追求极致清晰。它最终显示成一个十几到几十像素的小方块，源文件超过512像素之后再往上加，肉眼看不出任何差别，只是白白多传几十KB。够用就停，这也是代劳型规则那条钝曲线的具体表现。

本次样本里超过256像素的有19个站，这一档在任何屏幕上都够用。文件大小也不是问题——一张192×192的PNG通常只有几KB到十几KB。没有理由为了这点体积去用一张16像素的图。

那9个只有16像素的站

brooklinen、hellotushy、innisfree、nespresso、stanley1913、untuckit、uniqlo、zalando、weber——这九个站声明的所有图标里，最大的一张只有16×16。

品牌体量和执行细节之间没什么相关性，品牌权威度与域名权重的区别里有类似的观察。

看这份名单就知道这跟品牌体量无关。里面有全球快时尚巨头，有百年厨具品牌，有欧洲最大的时尚电商平台之一。它们的图标不是做得差，是做于很多年前，从此再没动过。

16像素在2010年前后是完全正确的选择——那时候标签页图标就是这么大，多做也没用。今天的高分屏上，同样一张图会被放大好几倍来显示，结果就是一团马赛克。这不是一次错误的决定，这是一次正确的决定过期了。

顺带说，这一类问题的修复成本可能是全文最低的：让设计部门重新导一张192或者512的PNG，替换文件，改一行sizes。半小时的活，而且不需要任何人做决策。

按站看最大边长

分档统计要先想清楚档位怎么划，一条五年趋势线上有三处口径变更记录过一次分档带来的误导。

把前三行加起来：128个有可测文件的站里，61个的最大图标不超过48像素，占47.7%。它们全部满足硬门槛，但全部没到官方建议的那一档。

最极端的是9个最大只有16像素的站，里面不乏一线品牌。16像素在今天任何一块屏幕上都是一个模糊的小方块。它能用，只是好不到哪去。

那11个不是正方形的文件

正方形是硬要求，不是建议。本次抓到11个非正方形的文件，分布在10个站上。

差一点点也是不合格，判据不该模糊，调研数据里没有一个非会员却写给非会员看就是判据松了的后果。

最有教学价值的是最后两个。32×31只差一个像素，但它已经不是正方形了。这种偏差几乎肯定来自一次自动裁剪或者压缩，没有任何人是故意把图导成32×31的。

而mejuri那个1587×1123完全是另一回事——那大概率是一张设计稿或者宣传图，被误当成图标挂了上去。一百多万像素的文件，为的是显示成一个十几像素的小方块。

为什么会差那么一两个像素

32×31、46×35、180×167这几个，共同点是差得很小但确实差了。这种偏差有三个常见来源。

自动化流程产出的东西最容易在细节上跑偏，Shopify的一百二十八种结构化数据类型怎么挑里也提过同类问题。

一是设计稿的画板本身就不是正方形，导出的时候按内容边界裁剪，边缘留白不对称就差了一两像素。二是走了自动压缩或者格式转换，某些工具会在转换时按内容裁掉透明边。三是从一张大图缩放而来，缩放比例不是整数，取整之后宽高各自舍入到了不同的值。

三种成因的共同点是没有人做过决定。这跟上一篇里名字被机器改坏的那几个案例是同一类问题：语法完全合法、页面显示正常、没有任何报错，只有真的去读文件才能发现。

正方形这条到底会不会被严格执行

官方把它列成了要求而不是建议，所以合理的假设是会被执行。但具体是直接弃用、还是自动补边裁成正方形，文档没说。

不对称的赌局不值得参与，给那条建议配一个注定无效的对照组讲的就是怎么判断值不值得试。

保守的做法是别去赌。把图标导成严格的正方形，成本是一次导出；赌错了的成本是展示位上一个灰色的默认图标，而且你还不会收到任何通知。这类不对称的赌局，不值得参与。

声明的尺寸和文件的真身对得上吗？

声明里的sizes属性写的是这个文件多大，抓取程序会拿它做初筛。如果它跟文件真身对不上，初筛就是错的。

声明与实际对不上会一路污染下游，微软广告改UTM自动打标之后的归因影响是另一个例子。

9条对不上的记录

声明与实物对不上在商品数据里同样高发，跨境电商GTIN怎么申请与收录里有核对的办法。

nike那两条是互相错位的

看清楚这两行：声明128的那个文件实际是192，声明192的那个文件实际是120。两条声明像是被交换过，而且交换之后两条都不对。

两条记录被调换过的痕迹很有诊断价值，五个渠道加起来一百五十九个百分点也是靠痕迹反推的。

这种形态说明什么？说明这两个link标签的href或者sizes在某次改动里被挪动过，改的人只调了顺序没核对内容。它不是一次疏忽，是一次操作留下的痕迹。

typology那两条是最离谱的

一个文件声明自己有76和120两档，实际是512×512；另一个声明自己有16、32、96三档，实际是196×196。声明和真身差了四倍以上。

换了内容不换标记是通病，用SignificantLink和RelatedLink表达页面关系里有维护的建议。

这种情况通常出现在换图但不换声明的时候：设计师给了一套高清图，工程师换了文件，head里那几行sizes原封不动。文件是新的，标签是旧的。

sizes写错到底有多严重

说实话，不算致命。抓取程序拿到文件之后可以自己读真实尺寸，声明只是一个提示。但它有两个真实代价。

指标要分清是结果还是信号，埋点之前先把测量框架设计清楚讲了这两类的区别。

第一，浏览器和设备会按声明去挑，挑错了就会拿一张不合适的图去缩放，显示效果打折。第二，也是更重要的一条：sizes对不上是一个信号，说明这个站的图标声明缺乏维护。本次数据里，sizes出错的站，往往同时还有别的问题——比如fahertybrand那个既写错尺寸又不是正方形。

把它当成一个探针来用

这一条其实是本次实测里最好用的一个诊断指标，价值不在它本身，在它的相关性。

低代价字段当高信号探针，这套思路在共识层排查里同样好用，共识层六信号的九十天实战指南有更多例子。

逻辑是这样的：sizes属性是纯声明，写错了没有任何直接惩罚，没有报错，没有告警，页面显示也完全正常。一个错了完全没有代价的字段，如果它是对的，说明有人真的核对过；如果它是错的，说明这一块从来没人管。

所以拿它当探针非常合适：三十秒就能查，查出问题基本可以断定这个站的图标链路缺乏维护，值得整体过一遍。反过来，如果一个站的sizes全部准确，那它的其它环节大概率也没问题。

这类“低代价字段当高信号探针”的思路，在很多排查场景里都成立。找那些错了没人管的地方，它们最诚实。

要不要干脆不写sizes

可以。sizes不是必填的，不写的话抓取程序和浏览器会自己读文件。对于只声明一两个图标的站，不写反而更省事，因为少了一处需要同步维护的地方。

能少维护一处就少一处，新网站SEO目标管理的三个里程碑里有怎么砍任务的判据。

什么时候该写：当你声明了多个不同尺寸、希望设备按需挑选的时候。这时候sizes是有价值的，但前提是它必须准。要么准，要么不写，最差的选择是写一个错的。

名字那一半，系统到底从哪几个来源里挑？

图标讲完了，回到广告位上那一行的另一半。名字这件事的机制和图标几乎一样，只是候选来源更多。

同一套系统在别处也是自己改写你的输入，品牌词和非品牌词那条线画在哪记录了改写的全过程。

官方说它会看哪几处

站点名称那份文档写得很明确：要表明你的偏好，在首页加WebSite结构化数据；系统同时也会考虑og:site_name、标题、标题类元素以及首页上的其它文本；其中结构化数据最重要。

多来源汇总成一个实体是整套语义体系的基本动作，实体SEO的五阶段构建方法讲得更系统。

还有一句更该被记住：如果系统对你提供的名字不够有把握，它可能会用其它来源生成一个站点名，或者直接显示你的域名甚至子域名。

把这两句连起来读，整个机制就清楚了：你给的是候选，它做的是选择题，而且它保留了交白卷的权利——交白卷的答案是你的域名。

还有一个层级关系不能忽略：文档明说WebSite结构化数据最重要。这意味着四个来源不是平权的，而是有优先级的。如果你只想改一处，改那一处。本次样本里，恰恰是这一处的完成率最低——大量站有og:site_name、有标题，就是没有WebSite结构化数据。

为什么会有四个来源这么怪的设计

站在系统的角度想一下就明白了。它要给互联网上每一个站都算出一个名字，而绝大多数站不会主动声明任何东西。如果只认结构化数据，那么绝大多数站的名字栏都会是空的。

降级链路的存在解释了很多看似奇怪的展示结果，AI搜索可见性的五维度深层策略里有相关分析。

所以它必须有一套降级链路：最好的情况读结构化数据，读不到就看og标签，再读不到就从标题和正文里猜，全都猜不出就用域名。这套设计对整个互联网是合理的，对认真填了字段的站却有个副作用——你的正确声明，要和那些兜底来源一起参与竞争。

竞争的结果取决于系统对每个来源的把握。如果你的结构化数据写了A，标题尾段写了B，og写了C，那么它面对的是三个互相矛盾的信号，把握自然低。这就回到那句话：不是你说得不够，是你说了三种不同的话。

四个来源实测对不对得上

本次把每个站的四个名字来源抠出来对比：域名主体、标题尾段、og:site_name、结构化数据里的组织名。归一化处理是统一转小写、去掉所有非字母数字字符，这样大小写和标点差异不会算成不一致。

同一批国际站还被用来量过网址结构，一万个电商站的网址结构实测结论是另一次大样本抓取。

在至少三个来源有值的98个站里，四者归一后完全一致的只有22个，占22.4%；不一致的76个，占77.6%。

这个比例值得停一下。七成七的站，在“我叫什么”这个问题上，给出了不止一个答案。而这还是在忽略了大小写和标点差异之后的结果。

22个完全一致的站有什么共同点

先看好的那一批。22个四来源完全一致的站，共同点相当明显：它们的品牌名短、只有一个词、而且域名就是这个词加后缀。

起名时的选择会一路影响到展示层，独立站起名的命名策略与SEO避坑里有前置的判断。

这不是因为它们更用心，而是因为它们没有分叉的空间。当品牌名等于域名主体的时候，模板默认值填出来的东西恰好就是对的；标题尾段随手写品牌名，也自动一致。一致性在这批站上是免费的。

这条观察有个实际推论：如果你的品牌名和域名天然一致，这件事你大概率不用管；如果不一致，那就得主动管，而且没人会提醒你。这套机制对起名幸运的人是白送的，对起名不幸的人是要交作业的。

不一致都长什么样

翻了一遍具体记录，形态可以归成四类。

第一类是标题尾段写的不是名字，是一句卖点。aloyoga.com的标题尾段是一整句“从工作室到街头的瑜伽服饰与配件”，avocadogreenmattress.com是“有机无毒床垫”，cotopaxi.com更直接，是“订单满99免运费”。把促销信息放在标题尾段，等于往名字候选池里扔了一句广告。

cotopaxi那条尤其值得说，因为它是有时效的。免运费门槛会变，大促期间会调整，甚至可能某天取消。一个会变的字符串，被放进了一个需要长期稳定的位置。而站点名称这件事的价值几乎全部来自稳定——系统要能反复确认“这个站还是那个站”。

公平地说，标题尾段放卖点在点击率上是有道理的，这是几十年的老做法。问题在于它现在多担了一个职责。解法不是把卖点删掉，是把结构化数据填上——让系统有一个明确的、优先级更高的来源可以读，标题尾段爱写什么写什么。

第二类是og和结构化数据各说各的。casper.com的og:site_name是Casper Sleep，结构化数据里是Casper；baseus.com的og是Baseus US，结构化数据也是Baseus US，但域名是baseus；cybex-online.com的结构化数据是CYBEX Online Shop，og是空的。

这一类的成因在上一篇里分析过：结构化数据通常来自SEO插件或专门的开发任务，og标签通常来自社交分享需求、由市场部门提。两条链路、两个部门、两次各自的填写，天然容易不一致。

casper那个还有一层：Casper Sleep是公司的正式名，Casper是品牌名。两个都对，只是该出现在不同的字段里。正式名进legalName，品牌名进name和og:site_name，这样两边都能说自己填的是对的，而系统只会看到一个答案。

第三类是把网址写进了名字。traeger.com的og:site_name直接是完整网址，nike.com的og:site_name写的是Nike.com——带着域名后缀。

这两个案例的性质不太一样。写完整网址那个几乎肯定是模板默认值没改，属于纯事故。写Nike.com的那个更可能是有意为之——早年的品牌传播里，把域名后缀带上是一种做法，用来提示“我们有网站”。这个习惯在今天成了负担：它让你的名字里多了一段跟名字无关的字符。

顺便说，这两条都会被上一篇提到的商家资料禁令直接判违规，那一条叫“电话号码或网址”。同一个写法，在有执法的地方会被处罚，在这里只会让系统多一次犹豫。

第四类最普遍，也最值得单独用一节讲：域名本身跟品牌名不是一回事。

归一化口径先说清楚

这个77.6% 是在做了相当宽容的归一化之后得出的。具体做法是：全部转小写、删掉所有非字母数字的字符，然后比对。

口径放宽还是收紧直接决定数字大小，用正则从GSC里挖AI搜索提问的五步实战里也先花了篇幅交代匹配口径。

也就是说，Boll & Branch和bollbranch会被算成一致，Ice-Watch和icewatch会被算成一致，Béis和beis也会被算成一致。大小写、空格、连字符、重音符号造成的差异，全部不计入不一致。

这个口径是刻意放宽的，因为那些差异对系统来说通常不构成障碍。放宽之后还剩七成七不一致，说明剩下的都是真正意义上不同的字符串，不是格式问题。这一步值得强调，因为如果不做归一化，比例会高得没有信息量。

另外还有一个统计口径要交代

只有至少三个来源都有值的站才进入这次比对，一共98个。为什么不是四个都要有？因为要求四个全有会把样本砍掉一大半——很多站压根没有结构化数据或者没填og:site_name。

汇报数据的时候先讲口径，SEO汇报怎么让不同部门看到同一份事实里有现成的模板。

放宽到三个的代价是：缺失最多的那一档站没有被统计，而它们大概率问题更多。所以77.6% 这个数字，更可能是低估而不是高估。

兜底显示的那个域名，往往不是你的名字

官方说得很清楚，把握不足时它会显示域名。那就得问一句：你的域名，配当你的名字吗。

域名与品牌名之间的缝隙也会被别人利用，品牌被仿冒抢排名的五步应对实战记录过一次。

先确认一下这条兜底真的会发生

这不是推测。站点名称那份文档的原话就是：如果系统对你提供的名字信心不足，它有时会用其它来源生成站点名，或者显示域名或子域名。域名兜底是官方写明的行为，不是极端情况。

域名本身携带的识别信号有多重，GitHub Pages寄生SEO的借力实战是个极端一点的例子。

那什么叫信心不足？文档给了几个原因：结构化数据有错误、没有遵循指南、首页无法被抓取，以及名字过于通用。前三条是技术问题，最后一条是命名问题。而本节要说的是第五种情况——技术没错、名字也不通用，但四个来源各说各的。

一批对不上的样本

域名形态带来的连带成本值得单独算一笔，带连字符的域名到底伤不伤SEO是同一类问题。

这批域名是怎么变成这样的

原因几乎都一样：品牌名本身太短、太常见，对应的域名早就被注册走了。OLIPOP拿不到olipop.com，就在前面加个drink；quip拿不到quip.com，就加个get。这是DTC品牌起名的常规操作，本身没什么问题。

域名策略从来不只是选个好听的，建一个大站还是多个小站的取舍里有更长期的账。

问题出在下游。当系统对你的名字没把握、退回去显示域名的时候，用户在广告位上看到的是drinkolipop.com，而你的品牌叫OLIPOP。这一步不是名字被写错了，是名字压根没被采用。

而且这个损失是双向的。一方面，看到广告的人可能认不出这是他知道的那个品牌；另一方面，那些搜索品牌名而来的人，看到的展示信息里没有出现他刚才输入的那个词。品牌词搜索的转化率之所以高，很大程度上依赖那一瞬间的确认感，而域名替代品牌名，正好把这份确认感抽掉了。

顺手数一下这批站有多少

在211个域名里粗略过一遍，域名主体明显不等于品牌名的至少有二三十个，形态基本就是那几种：前面加动词、加招呼语、加介词，后面加品类词。这个比例在DTC品牌里明显高于传统企业，原因也不难理解——DTC品牌普遍起名晚，好域名早就被占完了。

名字与定位的清晰度是同一件事的两面，AI搜索时代品牌定位清晰度的四个动作讲了怎么收敛。

这条观察对正在起名的团队有直接价值：如果你不得不用一个带修饰的域名，那么从第一天起就要把品牌名在结构化数据里写清楚。这不是可选项，是这个起名决定带来的连带成本。

所以这批站更该把名字说清楚

结论有点反直觉：域名和品牌名差得越远的站，越不能让系统去猜。

品牌词流量值不值得单独拆开看，GSC品牌词过滤器的五步使用指南给了方法。

因为对于域名等于品牌名的站，猜错的代价很小——猜到域名也差不多对。而对于drinkolipop这类站，猜错就是把一个不存在的品牌名摆到用户面前。

具体动作是把WebSite结构化数据填上，名字写OLIPOP，然后确保og:site_name和标题尾段说的是同一个词。这三处一致之后，系统就没有理由退回去用域名了。

还有一个更麻烦的变体

比域名多几个词更麻烦的，是域名和品牌名之间隔着一次重音符号。beistravel.com的品牌名写作Béis，带一个尖音符；域名里当然没有这个符号，写作beis。

别名与变体写法都该主动登记，五大策略让AI搜索主动推荐品牌里有对应的动作。

这一类在欧洲品牌里很常见。前面提过的归一化会把它们算成一致，但那是我为了让统计有意义而做的宽容处理，系统那边未必这么想。一个带重音的名字和一个不带重音的域名，在字符层面是两个不同的字符串。

处理办法是把不带重音的写法也登记进别名字段。这样两种写法都有明牌，无论用户怎么搜、系统怎么读，指向的都是同一个实体。

通用名那一条也别忽略

官方文档里有一句提醒：避免使用通用名称，它举的例子是“爱荷华州最好的牙医”这类，说这样的名字不太可能被选中。

通用词品牌名的识别负担只能靠周边信号补，把品牌当权重的四大战略讲了这笔投入怎么算。

这条对独立站的意义在于，你的名字如果听起来像一个品类描述，系统会倾向于不采用它。上一篇量到的那几个把组织名写成“优质厨具”“选购刀具与厨房用具”的站，正好撞在这条上——它们不但没帮上忙，还把系统推向了退回域名那条路。

判断自己的名字算不算通用，有个粗糙但好用的办法：把它放进搜索框，看结果里出现的是不是你。如果出来的是一整页别人家的商品，那这个名字对系统来说没有识别价值。

这里有个两难：很多DTC品牌的名字本来就是常用词——On、Away、Native、Purple、Ritual、Quince、Seed。这些名字在品牌传播上很有优势，好记好念；在机器识别上却是负担，因为它们跟无数普通语句撞车。起名时的优点，在这一层变成了缺点。

这类品牌能做的，是把周边信号补齐：结构化数据里把组织的地址、成立时间、社交资料链接都填上，让系统有更多依据把这个常用词跟一个具体实体绑起来。名字本身不能改，但它周围的证据可以加。

名字和图标该保持什么关系

最后补一条容易被忽略的：这两样东西会一起显示，所以它们该讲同一个故事。

视觉一致性最终服务于识别效率，电商网站UI设计七条经验法则背后的认知逻辑里有原理。

实际操作里最常见的脱节是图标用的是简写标志、名字用的是全称，两者放在一起用户认不出是一家。这不是技术问题，是品牌资产管理的问题，但它的表现落在技术层面：图标文件是设计部门给的，名字是运营在后台填的，两边各自更新，从来没有并排看过。

这件事在改版之后尤其容易脱节。品牌换了新标志，官网首页的logo换了，社交账号的头像换了，唯独那几个图标文件因为藏在head里没人想起来。结果就是搜索结果和广告位上还挂着上一版的旧标志，而且可能一挂就是几年。

做一次核对的成本极低：把图标缩到16像素，跟名字并排放在一起，看一眼像不像同一个品牌。这一步花三十秒，但它是整套排查里唯一一个真的在看用户会看到什么的动作。

把候选收敛到一个，需要几个动作？

代劳型规则的落地方式只有一条主线：减少候选，确保剩下的那个是对的。下面是可以照着做的顺序。

收敛完之后要不要上监控，二十款GEO与AEO监控工具的评测与选型可以按预算挑。

图标那一半的四步

第一步，数一数你的首页head里有几个图标声明。超过四个的话，先问自己每一个是给谁用的——搜索、浏览器标签、iOS主屏、Safari固定标签，超出这四个用途的可以删。

把流程写成可照做的步骤比讲道理有用，七步GEO实战的写作流程也是同一种编排方式。

第二步，逐个请求这些地址，检查三件事：状态码200、文件头是已知图片格式、能解析出宽高。任何一条不成立，这个声明就是坏的，先修再说。

第三步，确认形状和尺寸。正方形是硬要求，本次样本里有站因为一像素的偏差不合格。尺寸建议至少准备一张大于48×48的。

第四步，把兜底路径修好。请求你的 /favicon.ico，如果它返回的是网页，那这条路是断的——它不一定致命，但没有理由让它坏着。

名字那一半的三步

第一步，在首页加WebSite结构化数据，把名字填上。官方明说这个来源最重要，而这一步在本次样本里的完成率并不高。

结构化数据的注入方式决定了改起来方不方便，Schema聚合的五步接入方法可以先看这一步。

第二步，把og:site_name和标题尾段调成同一个词。特别注意标题尾段——那是最容易被塞进卖点和促销语的位置。

第三步，如果你的域名和品牌名对不上，把这件事当成高优先级。域名不像名字的站，是这套机制里最吃亏的一批。

这两半活加起来要多久

按本次跑数据的经验估一下。图标那四步，一个站二十分钟——大头在逐个请求那些地址并读文件头，如果你会写点脚本，一分钟就跑完了。名字那三步，十分钟，主要是查源码和改模板。

半小时能做完的活该怎么排进优先级，信息词流量过大的六大危害与破局里有排期的思路。

这个估算里没算的是沟通成本，而在多数团队里这才是大头。查出来的问题往往横跨设计、前端、运维三方，光是把结论讲清楚、把工单派到对的人手上，就可能比排查本身更花时间。所以查完之后最好直接给出可执行的动作，而不是给一份问题清单。

可执行的意思是：不写“图标尺寸不合规”，写“把这个地址的文件换成一张192×192的正方形PNG，同时把head第14行的sizes改成192x192”。前者会被讨论一周，后者半小时就上线了。

加起来半小时，还不算修的时间。修的时间取决于问题的性质：改一个sizes是一分钟，改构建流程里的图标路径可能要半天。但至少你能在半小时内知道自己要修什么。

如果有多个语言版本或者多个主机名，把这半小时乘以主机名数量。这也是为什么本文一直建议把主机名收敛——每多一个可独立访问的主机名，这套活就多跑一遍。

做完之后怎么记录

建议留一份很简单的记录：每个主机名一行，写清楚它的图标文件地址、尺寸、名字字段的值。这份记录的作用不是给别人看，是下次发版之后，你有一个可以对照的基准。

留基准和留凭证是同一种习惯，SEO服务合同里的达标定义与纠纷案例讲的是更正式的一版。

没有基准的话，你只能每次都从头查一遍，而且查完也不知道跟上次比有没有变。有了基准，比对一遍是几十秒的事。

这套动作和上一篇的名字盘点是同一张表

如果你上一篇的名字盘点已经做过了，这一篇的名字那三步其实是重合的——同一批字段、同一张表，只是这次多看一栏图标。

同一批模板输出的东西该一次改完，类目导航改版三轮之后仍然没写清楚用户在哪也是模板层的活。

这不是巧合。名字和图标是同一套身份声明的两个字段，它们由同一批模板输出、在同一个位置被消费、出问题的时点也一样（发版、换主题、开新市场）。把它们分开做两次，纯属浪费。

所以实际操作里，建议把这两篇的核对表合成一张：每个主机名一行，横向依次是组织名、og:site_name、标题尾段、图标地址、图标尺寸。一行填完，两件事一起收工。

为什么第一步是数数量而不是看质量

这个顺序是本次数据教的。如果先看质量，你会盯着那张主图反复调尺寸调清晰度，而真正让站出问题的是那些你根本没在看的声明。

先看结构再看细节，跟先定北极星再看分指标是同一个次序，砍掉虚荣指标只盯真信号讲了这套逻辑。

那5个所有声明全部不可用的站就是例子。它们的问题不是图不好看，是没有一个能被取到。而这件事只要把地址列出来逐个请求一遍，五分钟就能发现。

同样的逻辑也适用于名字：先数你在几个地方声明了名字，再看每处写的是什么。数量问题是结构问题，质量问题是细节问题，结构错了，细节做得再好也白搭。

删的时候要注意什么

收敛候选主要靠删，但有几处不能乱删。apple-touch-icon删掉之后，iOS用户把你的站加到主屏会拿到一张自动截图，视觉上很难看；mask-icon删掉之后，Safari固定标签页里会显示一个字母缩写。

删东西之前先问它是给谁用的，页脚不是杂物抽屉该怎么设计用的是同一条判据。

所以正确的做法不是删到只剩一个，而是每个用途留一个，删掉重复的和没用途的。一个站合理的图标声明大概是这样：一个标准icon、一个apple-touch-icon，加上根目录那个物理文件。三个足够覆盖绝大多数场景。

超出这三个的，问自己一句“这个是给谁用的”，答不上来就可以删。本次样本里那些声明十几二十个的站，绝大多数是历史累积——每次适配一个新设备就加一行，从来没有人回头清理过。

一张可以直接抄的核对表

把核对表挂进发布流程比靠记忆可靠，集合页分页的索引判断与canonical设置里也是一张逐项核对的表。

代劳型规则上最容易犯的错是什么？

最后收一下，把这一类事情的常见误区列清楚，比再多列几个数字有用。

平台替你决定的比例还会继续升高，AI Agent时代品牌信任取代排名的四条策略讲了应对方向。

三个最常见的误判

第一个是找开关。团队会花好几天翻后台、翻文档，想找一个能把展示结果写死的设置项，找不到之后得出结论说这个功能还没做好。它不是没做好，它就不打算给你开关。

找不到开关就以为功能没做好，这类误判在汇报时特别费口舌，流量下降不等于SEO失败的八维度实战有应对说法。

第二个是靠数量取胜。声明二十个图标、在五个地方写名字，以为覆盖面越广越保险。实际效果相反：候选越多，你越不可能逐个检查，坏掉的那个就越可能被选中。

第三个是改完立刻验收。图标的重新抓取，官方明说要几天到几周。改完当天去搜自己的品牌，看到没变就再改一次，这是最坏的做法——反复改会让系统一直处在低把握状态，而低把握的默认行为就是退回去用域名。

还有一个常见的误判：把它当成设计问题

图标这两个字容易让人联想到视觉，于是排查的时候第一反应是找设计部门要一张新图。但本次数据里，真正让站出问题的几乎全是工程问题：文件被清理了、路径写死了、路由把请求吃了、尺寸导出的时候差一像素。

设计与技术的协作边界值得提前划清，网页设计师SEO协作的七个动作点里有一份分工清单。

设计能解决的只有“图好不好看”，而绝大多数站卡在的是“图取不取得到”。这两件事在流程上归属完全不同，找错人就会白等一轮。

正确的顺序是：先由懂技术的人确认那几个地址都能返回可解析的图片，再由设计确认尺寸和视觉。顺序反了，你会拿到一张很漂亮的、但依然取不到的图。

三个反直觉的判断

第一，兜底路径的可用率只有28%，可这件事对大多数站并不致命——因为它们的head里有正确声明。一个指标难看，不代表它是瓶颈；判断瓶颈要看链路上有没有别的路可走。

反直觉的杠杆往往藏在没人看的地方，被低估的九个反直觉UI设计杠杆是另一组同类观察。

第二，出问题最狠的不是那些什么都没做的站，是那些做了很多的站。声明22个图标的站，比只声明1个的站更可能有坏文件。投入和正确率之间不是单调关系。

第三，这一类规则最值钱的动作是删，不是加。删掉多余的声明、删掉标题尾段的促销语、删掉名字里的地区后缀——你在替系统减少选择题的选项，而它的正确率跟选项数量成反比。

把三类规则的处理方式并排放一次

平台介入方式的差别在专利文本里也能看出痕迹，从专利与专家访谈还原的GEO五步原理提供了另一个角度。

最后一行是三类里差别最大的一栏。禁止型有通知，代劳型至少还能肉眼看出来，亲自型从头到尾没有任何反馈。下一篇讲的就是第三类，它量的是同一批站的服务器在被问“变了没有”的时候，答不答得上来。

顺带回答一个可能有人想问的问题

有人会问：既然平台迟早会替我算，那我索性什么都不做，等它算出来再说，行不行。

不做也是一种选择，只是你得接受默认值，答案引擎优化怎么让内容被优先引用里有同样的取舍讨论。

行，但你要接受它的默认答案。图标那边的默认是灰色的通用图标，名字那边的默认是你的域名。对于域名就是品牌名、图标一直没问题的站，这个策略确实没什么损失。

问题在于你并不知道自己属不属于这一类。本次数据里，那5个所有图标声明全部不可用的站，团队大概率都以为自己是有图标的。“不做”和“做了但不知道坏了”，在结果上一样，但后者会让你误以为这件事已经完成了。

这一批数据最让我意外的一条

不是那个4.5 MB的404，也不是四个410。最意外的是兜底路径的可用率只有28%，而这件事居然没有造成任何可见的后果。

容错好的系统会把中间状态的失败全部藏起来，日志里带人来的其实是另一批入口也是一次被藏住的缺口。

七成的站在这条路上是断的，可它们的搜索结果里照样有图标、广告位上照样有图标——因为head里的声明救了它们。这说明这套机制的容错做得相当好，一条路断了还有别的路。

但容错好也有副作用：它让所有中间状态的失败都不可见。你不知道自己是靠第一条路走通的，还是靠第三条路勉强兜住的，直到某一天最后那条路也断了，你才发现前面几条早就没了。

这正是代劳型规则最难受的地方。禁止型至少会给你一封通知，亲自型至少你自己心里有数，而代劳型是你在一个多路径容错的系统里，永远不知道自己现在靠的是哪一条。

所以最后落到一句话

图标和名字这两件事，做对的成本是半小时，做错的成本是展示层上一个灰方块加一串域名，而且没人会告诉你。

便宜且确定的活该先做，把旧内容更新成AI可信来源的十二步里有一批同样便宜的动作。

这个不对称本身就足够构成理由。不是因为它多重要，是因为它太便宜了。在一份排期表里，凡是半小时能做完、收益确定、不需要审批的事，都该排在最前面——哪怕它看起来一点都不性感。

下一篇讲第三类，也就是亲自型：平台只会建议、没有任何工具告诉你做到没有、而这件事完全发生在你自己的服务器上。量的还是同一批站，问题是它们在被问“这个页面变了没有”的时候，答不答得上来。那一篇的数字比这一篇更难看，因为那一层连兜底路径都没有。

如果只做一件事

逐个请求你首页head里声明的每一个图标地址，看它们是不是都返回了一张能读出宽高的图片。就这一件。

一次性排查完就能安心很久，让内容被主动引用的五个维度里也有这类一次到位的动作。

它能一次性排除本文里最严重的那一类问题——声明存在但文件不可用。本次样本里5个站的所有声明全部不可用，这5个站在展示层上的表现，跟一个图标都没声明是一样的，甚至更差，因为它们的兜底路径同样是坏的。

这批数据还有哪些没量

把没做的部分写出来，读者才知道哪些结论可以引用、哪些还得自己验。

抓取路径被挡住这类风险值得单独排查，GEO投毒的三条攻击路径与三层防御里有相关的检查项。

第一，没有比对同一个站的多个图标是不是同一个图案。理论上可以做图像相似度，但那需要另一套处理流程，本次没做。所以“多个候选长得不一样”这个风险，本文只能定性提，给不出比例。

第二，没有测这些图标地址会不会被robots规则挡住。如果一个图标放在被禁止抓取的目录下，它对浏览器可用、对抓取程序不可用，而这种差异本次的抓法看不出来。

第三，也是最实际的一条：没办法知道系统实际选了哪一个。官方没有公开这个信息，搜索结果里也只显示最终结果。所以本文能给的是“候选池干不干净”，给不了“它到底选了谁”。

这一层限制其实正是代劳型规则的本质：你能观察输入，能观察输出，但中间那一步永远是黑的。所以最优策略只能是把输入收敛到唯一，这样输入等于输出。

第四，本次的抓取是从单一网络环境发起的，没有做多地区对照。有些站会按访问来源返回不同的资源路径，理论上图标也可能不同。上一批做多语言实测的时候就撞到过按IP换内容的情况，所以这条不是空担心。如果你的站有地区分流逻辑，这套排查得在每个地区各跑一遍。

第五，样本本身是有偏的。211个域名全部是有一定规模的国际化电商与DTC品牌，不包含小站、不包含内容站、不包含B2B。所以本文所有比例只能代表这一类站，不能外推到整个互联网。但对读这篇文章的人来说，这个偏差方向大概率是有利的——你的同行就在这个样本里。

把限制写出来有什么用

有人会问，把这么多做不到的事写出来，不是在削弱自己的结论吗。恰恰相反。

交代口径的内容更容易被引用，七万五千条答案实证的引用偏好给出了数据支持。

一份数据的可信度，不取决于它覆盖了多少，取决于它有没有诚实交代自己没覆盖什么。本文那些能站住的结论——五个站的图标全坏、六成一的站兜底路径断了、四成八的站图标不到48像素——都是在明确的边界内测出来的，边界之外的部分我一句都没说。

反过来，那些不写限制的调研，你根本没法判断哪句能用。看到一份没有交代口径和缺口的数据，正确的态度不是相信，是先问它没量什么。

常见问题解答

图标必须是48的倍数吗？

不是。这是一个流传很广的误传。官方原文写的是必须是正方形、至少8×8像素，然后建议使用大于48×48的图标以获得更好的效果。硬门槛是正方形和8×8，48×48是效果建议。本次实测里有61个站的最大图标不超过48像素，它们全部满足硬门槛，只是清晰度不够。顺带提醒，另外两条常听到的说法也是误传：图标不必是ICO格式，任何有效图标格式都受支持；也不必放在根目录，链接写在首页head里就行。

我声明了好几个图标，系统会选哪一个？

官方没有公布挑选规则，只明说了按主机名定义站点、每个站只支持一个图标。可以确定的是，你无法指定它选哪个。可控的部分是让候选变少、让每一个候选都可用、并保证它们视觉上是同一个图案。本次样本里平均每站声明3.4个，最多的两个站各声明了22个。合理的配置大概是三个：一个标准icon、一个apple-touch-icon，加上根目录那个物理文件。

www和裸域需要各配一套吗？

需要。官方说的是按主机名定义站点，所以www和裸域在这套机制里是两个站，各有各的那一个图标。多国站用二级域名分市场的，每个二级域名同理。实际操作中如果你已经做了统一跳转，这个问题会自动消解，因为访问哪个最终都落到同一个主机名上。但如果两个主机名都能独立访问并各自返回内容，那就得各自准备。

同一个站的几个图标必须长得一样吗？

官方没有这条要求，但强烈建议一致。因为你无法指定系统选哪一个，如果几个候选的图案不同，那用户在不同位置看到的可能就是不同的标志。本次实测没有做图像相似度比对，所以给不出这一项的比例，但从格式混用的34个站来看，风险是存在的——不同格式的文件往往由不同流程产出，容易在某次改版之后不同步。

/favicon.ico返回404要紧吗？

如果你的首页head里有正确的图标声明，影响有限，因为抓取程序会优先用声明。但如果你什么都没声明，这条兜底路径就是唯一入口，断了等于没有图标。本次样本里37个站没有任何声明，而211个域名里152个的兜底路径拿不到真图标。更需要注意的是返回一整张网页的那50个站，其中最大的一次返回了4.5 MB。

换了图标之后多久生效？

官方的说法是几天到几周不等，取决于系统判断你的内容更新频率。这期间最重要的一条是不要反复改。每次改动都会让系统重新评估，而在它没把握的时候，默认行为是使用其它来源或者直接显示域名。改完之后确认文件本身可用，然后等。

标题尾段写卖点会影响站点名称吗？

会。官方明说系统会考虑标题、标题类元素以及首页上的其它文本。标题尾段是名字的候选来源之一，写成一句促销语或者品类描述，等于往候选池里扔了一个不是名字的选项。本次样本里有站的标题尾段是订单满多少免运费，也有站是一整句产品描述。

为什么我的品牌名不显示，显示的是域名？

最可能的原因是系统对你提供的名字把握不足。官方文档明确写了这种情况下它会用其它来源生成，或者直接显示域名甚至子域名。排查顺序是：先确认首页有没有WebSite结构化数据，再确认og:site_name和标题尾段跟它一致，最后检查是不是用了过于通用的名字。本次样本里有大量域名和品牌名并不相同的站，这一批最容易被显示成域名。

非正方形的图标会被直接拒绝吗？

正方形是官方列出的硬要求，不满足就有被弃用的风险。本次抓到11个非正方形文件，最典型的是一个32×31的——只差一个像素，几乎肯定来自一次自动裁剪。还有一个16×20的竖长方形，以及一个1587×1123的大图。检查方法是读文件真实宽高，不要相信声明里的sizes。

把图标放在CDN上有问题吗？

本次样本里56个站的图标托管在站外主机上，其中绝大多数是电商平台自带的CDN。这本身不是问题，只要那个地址稳定可达。需要注意的是两点：一是那个地址不要被robots规则挡住，二是发版换目录的时候别忘了同步更新head里的链接。本次有一个站的四个图标全部返回410已删除，路径里带着构建版本号，正是这个原因。

apple-touch-icon和搜索里的图标是一回事吗？

不完全是。apple-touch-icon主要给iOS主屏用，但它也在官方列出的受支持rel取值里，所以同样是候选之一。本次统计里apple-touch-icon系列一共209个声明，比标准的icon还多。这说明大量声明其实是为移动端准备的，只是顺带进了候选池。至于mask-icon，那是Safari固定标签页用的单色矢量图，跟搜索没关系。

这套排查多久做一次？

跟发布流程绑定比定期做更有效。每次前端发版、每次换主题或模板、每次调整站点名称设置，跑一遍那几个地址就行。本次数据里最典型的两类问题——文件被清理而声明没改、换了图但sizes没改——都发生在发版这个时点上。如果一定要一个周期，季度一次足够，但前提是这个季度里没动过前端。

广告位这个测试还没全量，现在做是不是太早？

不早。原因有两条。第一，同一套数据早就在自然结果里被使用了，你现在做的任何改动，在自然结果里立刻有价值，广告位只是顺带。第二，图标的重新抓取需要几天到几周，等测试全量再动手，中间那段时间就是空白。这类事情的成本是固定的、收益是持续的，越早做越划算。

我的sizes写错了，需要马上修吗？

单看这一项不算紧急，抓取程序会自己读文件真实尺寸。但它是个很好的信号：sizes写错了完全没有惩罚，所以它如果是错的，基本可以断定这个站的图标链路很久没人维护过。建议把它当探针用——发现sizes对不上，就把整条链路都过一遍。本次数据里sizes出错的站，往往同时还有别的问题。

图标和名字这两件事归谁管？

归谁维护站点模板，谁就得管。这在实际团队里是个真问题：投放的人看到广告位不对会去广告后台找原因，做SEO的人不看广告位，而根子往往在前端构建流程上。最省事的做法是把本文那张核对表挂到发布检查清单里，让发版的人顺手跑一遍，不需要任何一方专门立项。

权威参考资料

摘要：把170个国际化独立站的首页和297个语言版本页面拉下来，从里面抠出结构化数据和og标签里的品牌名，一共162个不重样的写法，覆盖112个域名。用Google商家资料那张名称禁令清单当尺子量了一遍，第一版量出38个域名有问题，换了个量法之后只剩17个，虚高了2.2倍。真正扎实的结论是另外两条：能装第二个名字的那个字段，90个站里只有7个用了；而112个域名里有86个从头到尾只给出一个名字形态，尺子对它们根本无话可说。

2026年8月10日，Google在商家资料的呈现指南里加了一条新规矩，位置在“名称”那一节，写得很短：不允许把同一个商家名用多种文字或多种语言重复写一遍。它给的反面例子是Kafiex／カフィエクス 和Burger King バーガーキング，正面例子就是把后半截删掉，只留Kafiex和Burger King。

这条规则真正扎人的地方在后半句：就算你的实体店招牌上确实是这么写的，也不行。过去很多店主拿门头照片去申诉，理由是我招牌上就这么印的，这条路从这一天起走不通了。

看到这条更新的时候，保哥的第一反应不是去改客户的商家资料，而是打开了自己手上那批国际化独立站的抓取数据。因为这条禁令背后那张完整的清单，可以当成一把现成的尺子，去量一件完全不同的事：你的独立站，到底对外声明了自己叫什么名字，声明了几个。

量完的结果比我预想的复杂。它不只是一个百分比，中间还塞进了一次尺子失效——第一版结论把问题放大了两倍多，而失效的原因不是数据脏，是这把尺子分不清一个词是名字的一部分，还是被加到名字上去的。

这篇文章讲三件事。前面讲禁止型规则长什么样、怎么一眼认出来；中间是那把尺子和它失效的全过程；后面是112个域名的实测明细，以及一份能在发布前跑完的名字盘点动作。

Google这次到底禁掉了什么？

先把新规原文的位置和分量说清楚，因为它写在哪一节，决定了你该用什么态度对待它。

不做什么的清单往往比做什么的更好核查，AI内容披露里那份不做什么的清单是同一种表达方式。

新增的那一行写在哪

这条更新出现在商家资料呈现指南的名称一节，与它并列的是另外六类被明令禁止的成分。整节的总原则写在最前面：你的名称应当反映商家在现实世界中的真实名号，也就是你门店上用的、网站上用的、信纸上用的、顾客口口相传的那一个。

名称字段属于结构化数据体系的一部分，整套配法可以对照结构化数据怎么配合SEO落地的完整指南看，里面有各类型的取舍。

这句总原则里有一个词特别关键，叫“一致地使用”。它的意思不是你有一个名字就行，而是你在所有这些场合用的是同一个。规则要的不是名字正确，是名字唯一。这一点后面会反复被验证——本次实测里绝大多数问题，都不是某个名字写错了，而是同时存在好几个都不算错的名字。

新增那一条的完整表述是“重复双语名称／文字音译”，括号里的解释是：把同一个商家名用多种文字或语言重复书写，即便实体店招牌上就是这么呈现的，也不允许。这条更新最早由Barry Schwartz记录下来，他还引了日本本地搜索从业者的一段补充：例子虽然用的是日语，但这条规则对任何多文字并用的市场都成立，阿拉伯语、中文、西里尔文一样受管。

为什么招牌照片这条路被堵死了

过去申诉名称问题，最常用的证据就是门头照片。逻辑很朴素：我招牌上印的就是这两行字，我照抄有什么错。审核那边通常也认这个证据，因为“真实名号”的定义本来就指向线下。

线下招牌与线上身份的分工，本质上是实体主页那一套地基问题，实体主页怎么搭才算把品牌身份立住里有更完整的拆解。

这次更新把这条路明确堵上了。原文里“即便它在实体店招牌上是这样呈现的”这半句，是专门写给这类申诉的。它等于宣布：招牌是招牌，字段是字段，两者不必一一对应。

这个变化的道理其实站得住。招牌是给站在门口的人看的，它同时承担识别、装饰、告知三重功能，两行字并排是排版选择；名称字段是给一台机器读的，它只承担识别一种功能，第二行字对识别没有增量，只增加歧义。同一段文字，在两个媒介上的职责根本不一样。

顺带说一句，这条规则对中国出海做本地业务的团队影响不小。中英并列的店名在国内是常态，很多人第一次做海外本地资料的时候会习惯性照搬，而这类写法从这次更新起属于明确违规。

那张完整的禁令清单

把这一节里所有“不允许”的成分列成一张表，你会发现它们的共同点非常清晰：凡是加在真实名号之外的信息，一律不许进名称字段。

七条禁令的底层逻辑是实体识别，想把这套语义网络理清楚可以看实体SEO的五阶段构建方法。

看出规律了吗。这七条没有一条在说“你不能有这些信息”，它们说的都是“这些信息不该待在名称字段里”。名称字段只装名字，别的信息各回各家。这是一条关于字段职责的规则，不是一条关于内容的规则。

把最右边那一列竖着读一遍，你会发现每一条被禁的成分，在这套资料体系里都有一个专属的容身之处：地址有地址字段，营业时间有营业时间字段，电话有联系方式字段，品类有类目字段，法人信息有单独的认证流程。七条禁令背后是七个已经存在的字段，规则不是在剥夺你表达的机会，是在拒绝你把它们全挤进同一个格子。

这个视角很重要，因为它决定了你的改法。如果你以为规则在禁止某类信息，你会纠结“那我怎么让用户知道我在这个城市”；如果你知道规则只是在指定位置，你就只需要把那段文字挪个地方。删掉不等于丢掉。

违规的后果不是排名下降

这一节的结尾有一句话，比前面七条加起来还重要：在商家名称里包含不必要的信息是不被允许的，并且可能导致你的商家资料被暂停。

资料被暂停之外，品牌名还有另一类下行风险，品牌被仿冒抢排名的五步应对实战记录过一次完整的处置过程。

请注意这个词，暂停。不是排名下降，不是展示机会减少，不是效果打折。是这份资料整个从系统里下线，你得走申诉流程才能拿回来。而申诉需要材料、需要时间，中间那段空窗期你在地图上就是不存在的。

这个后果的形状跟你熟悉的那些SEO后果完全不同。排名下降是连续的，你可以看着它一点点掉，可以边观察边调整，最坏情况也还有流量。暂停是二值的，前一天还在，后一天整条不见，中间没有过渡。连续的风险你可以管理，二值的风险你只能规避。

更麻烦的是这类处罚的触发时机。它不跟着算法更新走，而是跟着审核走——可能是一次用户举报，可能是一次例行复查，也可能是你自己动了某个无关字段触发了重审。所以“已经这么写了三年都没事”这句话，在禁止型规则面前完全没有说服力。没被抓到不是通过了，只是还没轮到你。

什么样的规则算禁止型规则？

把这条新规看成一次孤立的政策更新，你能做的只有改一次名字。把它看成某一类规则的样本，你才能在下一条更新出来的时候，第一时间知道该拿多大力气去应对。

同一份文档里不同段落的效力差别很大，robots规则的星号对某些爬虫无效就是一次误读官方措辞的代价。

平台介入你这件事，一共有三种方式

翻遍这些年的官方文档，你会发现平台跟你之间的每一条规则，背后都藏着一个没写出来的主语：这件事到底谁动手。答案只有三个。

这三类介入方式在AI搜索时代表现得更明显，GEO到底怎么落地的实施策略里能看到平台代劳的比例在变高。

这条商家名称规则是标准的禁止型。判据只有一个：违反它的后果是处罚，而不是效果差。效果差是一根连续的曲线，你可以选择投入多少；处罚是一条线，过线和不过线之间没有中间态。

这个三分法不是我发明的分类癖。它的实用价值在于回答一个每天都要回答的问题：这条新出的规则，我该派几个人、花几天、做到什么程度算完。三种类型给出的答案完全不同，而把类型认错，代价就是把力气花在收益为零的地方。

三十秒就能分辨的两个信号

不用把整份文档读完，看两个地方就够。

官方文档的措辞差异同样体现在结构化数据上，Schema对AI搜索到底有没有用的官方说法与实测对照过两种表述。

第一个信号是这段话住在哪一栏。写在“政策”“指南”“要求”下面的，通常是禁止型；写在“最佳实践”“建议”“提示”下面的，通常不是。Google的文档结构对这一点相当讲究，同一件事写在两个位置，力度完全不同。举个具体的：结构化数据那套文档里，“必需属性”和“推荐属性”是分开列的两张表，前者缺了整段结构化数据作废，后者缺了只是少一点信息量。

第二个信号是措辞。禁止型规则会出现“不被允许”“不得”“可能导致”这类词，而且后面往往紧跟一个具体的后果名词，比如暂停、拒绝、移除。只要看到一个具体的处罚名词，基本可以断定是禁止型。建议型的措辞则是“我们推荐”“考虑使用”“有助于”，后面跟的是收益不是后果。

还有一个更省事的土办法：搜这段文档里有没有出现“申诉”这个词。有申诉流程，说明有处罚；有处罚，说明是禁止型。建议型规则不需要申诉，因为没人罚你。

把三类规则各举一个你熟悉的例子

禁止型：商家名称不许加地区词，违反会被暂停。你唯一能做的动作是删。

代劳型最典型的另一个例子是多语言别名，hreflang备用网址被当成规范页别名这件事就是系统自己决定的。

代劳型：搜索结果里显示的站点名称。官方文档写得明明白白，它会参考结构化数据、og:site_name、标题以及首页上的其它文本，最后由系统挑一个。你没有一个字段可以把它写死，你只能让候选变少、变一致。

亲自型：服务器该不该支持条件请求以省下抓取预算。这件事百分之百发生在你的机器上，平台只能建议，而且没有任何一个官方工具会告诉你你做到了没有。做与不做，只有你自己知道。

禁止型规则的性价比长什么样

这是最容易被误判的一层。很多团队把合规当成优化在做，投入了大量工时想“做到最好”，可禁止型规则根本没有最好这一档。

把合规动作排进上线流程比事后补更省事，新网站前十二周的技术地基清单里有可以直接抄的排期。

合规不是优化，它没有上不封顶的收益，只有一条及格线。过了线，多做一分钱的收益都没有；没过线，前面做的所有优化一次归零。所以它的正确姿势是尽快过线，然后把力气挪走，而不是在这里精雕细琢。

保哥去年带过一个做户外装备的客户，团队在商家资料上花了三周，反复打磨描述文案、补图片、调品类，唯独名称字段里那个多出来的城市名一直没动，因为“大家都这么写”。结果资料被暂停，申诉走了十一天。那三周的打磨，在那十一天里一分价值都没产生。

这件事之后我们换了个做法：任何一批优化动工之前，先花两小时把所有禁止型的点位过一遍，确认没有一个踩线的，再开始做别的。这两小时不产生任何可见收益，它买的是后面那三周不会归零。

为什么“大家都这么写”是最贵的一句话

禁止型规则里有一类特别隐蔽的风险，就是行业惯例跟规则本身冲突。名称里加城市名这件事，在很多品类里是几十年的老习惯，同行都这么写，看起来风险很低。

行业惯例撞上平台清理是什么后果，阿里国际站五百九十万页面被清零那次的复盘是个规模足够大的样本。

但禁止型规则的执行不看密度。一百家都违规，不等于罚不到你；它只等于还没轮到。真正决定你会不会被抓的，是有没有人举报你、有没有触发复查，而这两件事跟同行怎么写完全没有关系。

更现实的一点是，这种时候你反而应该更早改。因为一旦平台开始集中清理某一类违规，同行会一批一批地掉，而你的申诉会排在那一批的队伍里。抢在集中清理之前改完，成本是零；等清理开始，成本是排队。

为什么一条本地商家的规则值得独立站主看？

你的独立站没有商家资料，这条规则管不到你。但它背后那张清单，管的是一件所有站都在做的事。

线下与线上的经验可以互相搬，把线上SEO思维搬到实体店的做法是反方向的一次迁移。

你的站也在声明自己叫什么名字

只要你的首页里有结构化数据、有og标签、有标题，你就已经在对外声明自己的名字了，而且不止声明了一处。常见的至少有四处：结构化数据里的组织名、og:site_name、页面标题的尾段、还有域名主体本身。

品牌名的一致性最终会体现在品牌权威度上，品牌权威度与域名权重的区别和提升方法讲了这套指标怎么读。

这四处任何一处都可能被系统拿去用。Google自己在站点名称的文档里说得很清楚，它会同时参考结构化数据、og:site_name、标题和首页上的其它文本，而且明确写着“表明你的站点名称偏好”——用的是偏好这个词，不是设置。你只能表达偏好，最后显示哪一个，不是你说了算。

同一份文档还有一句话更值得记：如果系统对你提供的名字不够有把握，它可能会用其它来源自己生成一个站点名，或者直接显示你的域名甚至子域名。不确定的代价不是空白，是它替你决定。而让它不确定的最常见原因，就是你在这四处给了它四个不一样的答案。

那张禁令清单可以直接搬过来当尺子

既然商家资料那边已经把“名称字段里不该有什么”写成了七条明文，那这七条就是一把现成的、有权威出处的尺子。把它拿过来量独立站的名字字段，等于是在问一个从来没人量过的问题：

借用别处的清单当尺子有风险，最佳实践清单里九条查得到出处八条数字对不上记录过一次核对过程。

在一个没有执法的地方，人们会往名字里塞多少不属于名字的东西？

这个问题值得量，因为它的答案关系到一件很实际的事：当AI系统需要把你的品牌跟一个实体对应起来的时候，它面对的是几个名字。名字越多、越不一致，它越可能挑一个你不想要的，或者干脆退回去显示你的域名。

这种“借一个产品的执法清单，去审另一个没人执法的地方”的做法，本身就值得说一句。平台的各条产品线共享的是同一套关于实体识别的底层判断，只是执法力度不同。有执法的那条线，通常把话说得最明白——因为它必须写清楚才能罚人。所以那份写得最狠的文档，往往就是理解整套系统的最好入口。

这批数据是从哪来的

样本是211个国际化的独立站与电商品牌域名，覆盖北美、欧洲、北欧、日韩以及中国出海品牌，品类横跨服装、户外、家居、母婴、美妆、3C与食品饮料。抓下来的东西有两层：170个域名的首页可解析，另外从这些站的hreflang表里挑出297个语言版本页面，也逐个抓了正文。

同一批国际站还被用来量过别的东西，一万个电商站的网址结构实测结论是另一次大样本抓取。

从每一份HTML里抠三样东西：结构化数据里所有组织类节点的name、legalName、alternateName；meta标签里的og:site_name和application-name；还有页面标题。组织类节点这个范围包括Organization、Corporation、OnlineStore、WebSite、Brand、LocalBusiness、Store以及各类具体门店类型，因为实际站点用哪一个的都有。

全部去掉多余空白之后，按“域名加名字”这个组合去重，最后剩下162条不重样的记录，覆盖112个域名。之所以按这个组合去重而不是按名字去重，是因为同一个写法在同一个站上出现十次和出现一次，说明的是同一件事，不该被计十次。

这套采样有哪些先天缺口

写在前面，免得后面的数字被过度解读。第一，能抓到的语言版本数量取决于该站hreflang表的完整度，声明得少的站自然暴露得少，所以“形态数”这个指标对不同站不是等价的。第二，有41个域名的首页拿不到可解析内容，其中相当一部分返回的是人机验证页，这些站完全没进统计。

只看初始HTML会漏掉脚本注入的内容，搜索引擎抓取和渲染DOM分几步解释了这两层的差别在哪。

第三，也是最重要的一条：本次只看声明，不看渲染。有些站的名字是前端脚本运行之后才写进结构化数据的，直接抓HTML拿不到。所以“没有结构化数据”这一档里，混着一部分其实有、只是不在初始HTML里的站。这条缺口会让“声明率”偏低，但不影响“同一个站给了几个形态”这个核心指标——因为那是在已经拿到的样本内部做的比较。

把缺口写出来还有一个用处：它决定了哪些结论可以引用、哪些不可以。“有多少站声明了结构化数据”这个数字，因为渲染缺口的存在，只能当下限用；“给出多少个名字形态”这个数字，因为是站内比较，可以直接用。同一批数据里，不同结论的可靠度是不一样的，这一点在引用别人的调研时也值得多留个心眼。

为什么选“同一个站给了几个名字”当核心指标

本来可以有很多种量法：量名字长度、量有没有品类词、量和域名的相似度。最后选定“形态数”，理由有三条。

指标能不能被读者自己复现很关键，三百个站实测出来的收录速度指标怎么读也是按这个标准挑的。

第一，它不需要任何外部知识。判断一个名字对不对，你得知道这家公司真名叫什么；判断一个站给了几个名字，只需要数一数。不依赖外部知识的指标，才可能在几百个域名上跑得动。

第二，它直接对应规则要保护的东西。商家资料那条总原则说的是“一致地使用”，形态数就是一致性的直接度量：形态数等于一，一致；大于一，不一致。

第三，它对读者可复现。任何人打开自己的站，把几个语言版本的名字抄下来，五分钟就能算出自己的形态数。一个读者算不出来的指标，写进文章里只是装饰。

结构化数据里的名字字段，大家都填了什么？

在动尺子之前，先看一眼这批站的基本盘。这一步没有判断，只有清点。

字段填得对不对决定别人怎么认你，GitHub Pages寄生SEO的借力实战里身份声明同样是关键一环。

三个数字先摆出来

层级与身份这两类结构化数据常常一起配，Shopify博客多级面包屑的三种方案可以顺手一起做掉。

组织类节点该选哪个类型是个高频困扰，Shopify的一百二十八种结构化数据类型怎么挑给了一张选型表。

第一个值得停下来的数字是alternateName那一行。90个站里只有7个用了这个字段。而这个字段的官方定义特别直白，就一句话：这个东西的一个别名。Google的组织结构化数据文档里也把它列在推荐属性清单的第二位，说明是“如果适用的话，你的组织常用的另一个名字”。

第二个值得停下来的是最上面那一行：能被解析的170个首页里，只有90个带了组织类的结构化数据。剩下80个站在这个层面上，压根没有正面声明过自己是谁，系统只能从标题、og标签和正文里去猜。这批样本全是有一定规模的国际品牌，不是小站。

没人用别名字段，别名都跑哪去了

别名当然是存在的。一个品牌在日本市场被写成片假名、在中国市场被写成中文、法务上还有一个带后缀的公司全称——这些都是真实存在的第二个名字。

把分散的结构化数据聚合成一份是解法之一，Schema聚合的五步接入方法讲了具体怎么合并节点。

问题是它们没被放进那个专门装别名的字段。它们跑到了标题里，跑到了og:site_name里，跑到了不同语言版本页面的组织名里。人们不是不需要第二个名字，是没把它放进该放的地方。

这句话正好是商家资料那条新规的另一面。商家资料那边禁止你把第二个书写形态塞进名称字段，是因为它有单独的位置管这件事；独立站这边没有执法，于是第二个形态就自由生长到了每一个能放文字的地方。

把两边并排看，会得出一个有点反常识的结论：同一家公司，在有执法的那个产品里名字规规矩矩，在没执法的自家站上反而一团乱。这不是因为团队水平不同，往往就是同一批人；区别只在于一边有人查、一边没人查。

legalName那17个站在干什么

17个站填了legalName，这个比例比alternateName高一倍多。原因不难猜：法人全称是财务和法务流程里必然存在的信息，模板里加一行成本很低；而“我们的另一个常用名是什么”这个问题，没有任何一个内部流程会逼你回答。

法人与商品标识分属不同体系，跨境电商GTIN怎么申请与收录是另一个容易被混进错误字段的例子。

值得注意的是，填了legalName的站，name字段普遍是干净的。这两件事是因果关系：有了专门放法人名的地方，法人名就不会去挤主名。反过来，那几个把S.r.l、LLC、Inc写进name的站，无一例外都没填legalName。

这条经验可以直接迁移到别名上——你之所以把片假名写进主名，很可能只是因为你没意识到有个字段专门装它。字段的存在感，很大程度上决定了它会不会被填对，而结构化数据里那几十个推荐属性，绝大多数都栽在这一点上——不是不该填，是没人知道它在那儿。想验证这一点很容易：打开官方那份推荐属性清单，逐条问自己“这个字段我们填了吗”，你会发现绝大多数字段你连听都没听过，而它们各自都在替某个本来会产生歧义的信息兜底。

同一页出现多个name的那9个站

还有一个数字容易被跳过：9个站的首页上，组织类节点给出了不止一个name。这跟“不同语言版本不一致”是两回事——这是同一个页面、同一次加载里，就存在多个身份声明。

同一页面多个节点之间该怎么互相引用，用SignificantLink和RelatedLink表达页面关系里有对应的写法。

成因通常有三种。一种是页面上同时挂了Organization和WebSite两个节点，两边的name填得不一样；一种是插件和主题各自注入了一段结构化数据，互相不知道对方的存在；还有一种是像avocadogreenmattress那样，本身就有多家门店节点。

前两种是需要修的。同一个页面上给出两个不同的身份，比在两个页面上给出两个不同的身份更糟，因为它连“不同市场用不同名字”这个借口都没有，纯粹是内部冲突。

排查方法：把首页的所有ld+json块拿出来，逐个看它的类型和name。如果发现两个块的类型不同但都算组织类，先确认它们是不是在描述同一个实体；是的话，把name统一，或者干脆合并成一个节点用 @id互相引用。

og:site_name的填写率也值得看一眼

78个站填了og:site_name，比例45.9%，比结构化数据组织节点的52.9% 略低。这两个数字放在一起看，会发现一个有意思的分布：并不是所有填了结构化数据的站都填了og:site_name，也不是所有填了og:site_name的站都有结构化数据。

两个部门各填一遍是典型的协作问题，SEO汇报怎么让不同部门看到同一份事实提过一套对齐办法。

这说明这两处的填写是由不同的原因驱动的。结构化数据往往来自SEO插件或者专门的开发任务；og:site_name往往来自社交分享的需求，是市场部门提的。两个部门、两条链路、两次各自的填写，天然容易不一致。

这也是为什么本文一直强调把它们抄进同一张表——它们在组织架构里本来就不挨着，只有在你的表格里才会挨着。

先看一个最直接的对照

在这批数据里，只有一条名字记录同时含两种书写系统：innisfree的组织名写成“이니스프리 (innisfree)”，韩文加括号加拉丁文。这就是商家资料新规禁掉的那个形态，一字不差。

标题会被系统重写这件事已经有实测，Google用AI重写标题的改写率与应对给出了七成以上的改写比例。

但如果把范围放到页面标题，混两种书写系统的一下子变成9个站：DJI写成“DJI大疆创新 - 官方网站”，Nike中国站写成“耐克Nike-耐克(Nike)中国官网-NIKE中文官方网站”，一个标题里“耐克”出现两次、Nike出现三次；HAY丹麦站写成“HAY品牌官网”；Swarovski的标题里同时出现了汉字、假名和韩文。

同一件事，在名称字段里几乎绝迹，在标题里遍地都是。这不是巧合，这是因为标题从来没有人管。

要给标题说句公道话：标题的职责本来就包含吸引点击，两种写法并排能同时接住两拨搜索词，这个做法在中文市场是有依据的。问题不在标题本身，在于站点名称系统会去读标题。你为搜索结果标题优化的那一串字，会顺带成为“这个站叫什么”的候选来源之一。

这就是为什么把alternateName填上很划算：你把片假名和中文名正式登记在别名字段里，标题里写什么就不再是唯一的线索了。明牌一出，猜测的空间就小了。

顺手记一个细节：Nike那个标题

“耐克Nike-耐克(Nike)中国官网-NIKE中文官方网站”这一串，值得单独看两眼。它里面的Nike出现了三次，大小写还不一致——两次首字母大写、一次全大写；“耐克”出现两次，其中一次带括号跟在Nike后面。

标题要同时接住点击和识别两件事，文章标题怎么写才有人点的十个技巧里有兼顾的写法。

如果把商家资料那七条禁令套上去，这一串至少踩中三条：重复双语名称、地点信息、营销语。当然它不在商家资料里，没人会罚它。但把它当成“这个站叫什么”的输入信号，系统能从里面读出的候选就有好几个：耐克、Nike、耐克中国官网、NIKE中文官方网站。四个候选里，只有前两个是名字。

那把尺子第一次给出的数字为什么是错的？

接下来是本次最值得写下来的一段。我把七条禁令写成七个匹配规则，跑完162条记录，拿到了第一版结果——然后花了半小时把它推翻。

两套口径算出相反结论而且都没算错，商品页推荐位两套报表打架的那次复盘值得对照着读。

第一版结果长这样

一张自洽的表最容易骗过自己，调研数据里没有一个非会员却写给非会员看是同一类陷阱。

38除以112，得33.9%。三分之一的站在名字字段里塞了不该塞的东西。这个数字看着就很适合当标题。

而且它内部的结构看起来也很合理：地点信息排第一，符合国际化品牌的直觉；两套文字并列只有2条，符合“这条规则刚出、还没人踩”的预期。没有任何一项显得离谱。这正是最危险的地方——一张自洽的表，比一张离谱的表更难被怀疑。

然后我去翻了具体例子

这一步是上一批批次留下来的规矩：任何一个准备用出去的统计结论，先给它配三个具体例子，而且专门去找看起来最不像的那几组。这次翻出来的第一组就出事了。

翻具体案例是发现口径问题的唯一办法，一条五年趋势线上有三处口径变更也是这么被翻出来的。

被判“地点信息”的记录里，有Flying Tiger Copenhagen、Audo Copenhagen、Typology Paris。这三家公司的注册名字里本来就带着这个城市名，Flying Tiger Copenhagen就叫这个，不叫Flying Tiger。被判“产品或服务信息”的里面有Avocado Green Mattress、Chubbies Shorts、Outdoor Voices、Columbia Sportswear、Brooklyn Bedding、Function of Beauty——每一个都是完整的注册商号。

换句话说，尺子把品牌名本身当成了违规。它看见Copenhagen就判地点，看见Mattress就判品类，完全不管这个词是不是名字的一部分。

顺带说个题外话：Outdoor Voices这个名字里的Outdoor，既是品类词又是品牌名的一半，这种情况在DTC品牌里特别常见——大家起名的时候就爱用品类词，因为好记好搜。所以任何一把靠词表判品牌名的尺子，在这个人群上的误报率注定高得离谱。

失效的根子在哪一层

回头看商家资料那一节的原话，它说的是“在商家名称里包含不必要的信息”。不必要，意味着有一个必要的基准存在——那个基准就是商家的真实名号。规则判的从来不是词本身，是这个词相对真实名号是多出来的还是本来就有的。

同一批数据里另一把尺子也出过类似问题，品牌词和非品牌词那条线画在哪记录了检测器被单个停用词压垮的过程。

我的第一版尺子里根本没有这个基准。它是一把只认词表的尺子，而词表分不出“名字里的词”和“加在名字上的词”。这是本次测量的核心教训，也是三个批次以来第三次撞上同一类问题：指标本身没有任何异常，报警的只有具体案例。

前两次的失效方式跟这次不一样，但结果的方向惊人地一致——都是让问题虚高。第一次是语言检测器里放了一个跨语言撞车的停用词，把分数表整个压垮；第二次是把网址里的纯数字一律当噪声删掉，结果把五寸刀和七寸刀判成了同一件商品。三次失效，三种成因，同一个方向。

这个方向性偏差本身就值得警惕。它大概率不是巧合：一把粗糙的尺子倾向于把“不确定”当成“命中”，因为命中需要一个匹配，而不命中需要证明所有匹配都不成立。宽松的匹配天然产出更多的阳性。

换一个基准重新量，结论变成什么？

修法其实很朴素：不给每个名字单独判分，而是先给每个域名找一个属于它自己的基准，再看别的写法相对这个基准多出了什么。

换个连接键结论就变了，五个渠道加起来一百五十九个百分点是同一类基准问题。

基准怎么定

对每一个域名，把它所有出现过的名字形态收集起来，全部切成词序列，取这些序列的最长公共开头，就是这个站的基线名。

基线名和域名主体常常不一致，独立站起名的命名策略与SEO避坑解释了这两者该怎么协调。

Flying Tiger Copenhagen在样本里只有这一个形态，公共开头等于它自己，多出来的部分是空，不判。Brompton有五个形态，公共开头是Brompton，那么UK、USA、Deutschland、France、日本 这五个尾巴就是多出来的，判。同一个词Copenhagen，在一个站上不判，在另一个站上要判，判据是这个站自己的其它版本。

这里有一个必须承认的设计取舍：取最长公共开头，意味着这把尺子只认前缀式的增量。如果某个站的两个形态是Brompton和UK Brompton，公共开头就是空，它会掉进另一类。实际数据里这种情况极少，因为品牌名加尾巴是压倒性的习惯——但这个假设写在这里，读者才知道结论的边界在哪。

顺带解决了一个更难的问题

这个改法还带来一个我没预料到的好处：只有一个名字形态的站，尺子会自动说测不出。

承认测不出比硬给结论重要，测试赢了上线却掉的那二十六天也是靠承认边界才找到原因。

112个域名里，有86个从头到尾只给出一个写法。对这86个站，我没有任何基准可以对照，也就没有任何依据说它多写了东西。第一版尺子会硬判，第二版尺子直接弃权。

上一批的教训里有一句话：一把诚实的尺子应该在没把握的时候说没把握。这次它自己做到了，而且弃权率高达76.8%。这个数字本身就是一条结论：绝大多数站根本没暴露出足够的信息，让任何人能判断它的名字对不对。

弃权率高到这个程度，其实说明了尺子的另一个特性：它只在你自己给出对照组的时候才工作。这跟人工审核完全相反——人工审核可以拿外部知识来判断“Flying Tiger Copenhagen是不是真的叫这个”，而一把只用站内数据的尺子做不到，它也不该假装做得到。

为什么不干脆去查一次工商注册

这是我认真考虑过又放弃的方案。理论上，拿每个品牌的注册商号当基准，比拿站内公共开头当基准准确得多。

一个品牌几十个注册主体是常态，建一个大站还是多个小站的取舍里讨论过主体分散带来的代价。

放弃的理由有三条。第一，跨国品牌的注册主体往往和消费者认知的品牌名不是一回事，Away的注册主体是JRSK Inc.，拿它当基准的话，Away这个名字本身反而成了违规。第二，一个品牌在几十个国家有几十个注册主体，选哪个当基准本身就是个判断题。第三，也是最实际的：这条路没法自动化，而一个只能手工做的判据，写进文章里对读者没有价值。

拿站内数据当基准的最大好处是，读者能自己复现。你不需要任何外部数据库，把自己所有语言版本的名字字段抠出来排一列，公共开头一眼就看出来了。

两版结果并排放

两版结论并排放是最好的自证方式，给那条建议配一个注定无效的对照组用的是同一种做法。

分项差得更狠。“产品或服务信息”第一版是12条8个域名，第二版只剩1条1个域名，虚高8倍，因为这一项几乎全是把品牌名本身当成了品类词。“营销标语”从8条掉到1条，理由一样：Mango Shop、On Shop、NARWAL Official这些，在第一版里被当成加了修饰，第二版里发现它们各自都是那个站唯一的写法，判不了。

有一件事在两个版本里是一样的

这一点值得单独说，因为它跟上一批得到的教训完全吻合：同一批脏数据，对不同结论的污染程度差别巨大。

排序类结论比比例类结论更抗误差，埋点之前先把测量框架设计清楚讲了指标选型的次序。

受影响最狠的是所有的比例类结论——三分之一变成七分之一，某一项虚高八倍。但有一条结论在两个版本里岿然不动：地点信息是最主要的附加成分，遥遥领先其它各项。第一版是33条排第一，第二版是26条排第一，占比从56% 升到70%，排序一次都没变过。

这告诉我们一件很实用的事：如果你的结论是“哪一类最多”，它对测量误差的抵抗力，比“有百分之多少”强得多。做数据的时候，能用排序说清楚的事，尽量别用绝对比例说。排序需要的只是误差在各组之间大致均匀，比例需要的是误差接近零。

这次失效有什么可固化的动作

把它写成三条，都是下次动手前能直接照做的。

把验证动作固化成流程比记在脑子里可靠，日志分析一步步挖出AI爬虫真相里有一套可复用的核对顺序。

第一，任何一把靠词表判断的尺子，先问自己有没有基准。如果规则原文里出现了“不必要”“多余”“额外”这类相对性的词，那它一定需要基准，而基准必须从数据内部生成，不能从词表里来。

第二，抽样验证的时候不要随机抽，专门去找那几组“看起来最不像违规的”。随机抽三十条，你大概率抽到的都是真阳性；专挑最可疑的抽五条，一条就能把尺子打回去。

第三，两版结论并排放进文章，而不是只保留正确的那一版。读者需要知道的不只是答案，还有这个答案差点错成什么样。

17个域名到底加了什么在名字上？

现在可以放心地看第二版明细了。19个域名能定出基线，其中17个的名字上确实挂了基线之外的东西，一共37条。

用户和系统看到的信息不是同一份，用户扫完一整屏一个都没点开这件事说明了默默流失的部分。

分项分布

分项集中在少数几个站上是常见分布，信息词流量过大的六大危害与破局也遇到过同样的集中度。

地点一项占了26条，是绝对主力，而且分布高度集中在几个站上。加国家和地区，是国际化品牌给名字加尾巴的默认做法。

为什么会这样，其实一点都不难理解。运营一个多国站的团队，最日常的困扰就是分不清自己在看哪个市场的后台。给每个站的名字后面加个国家代码，是内部辨识的最省事的办法——它解决的是团队自己的问题，代价却由外部系统承担。那个后缀是给你自己看的，可它被写在了一个对外声明的字段里。

三个把这件事做到极致的站

Brompton是最典型的一个。这家做折叠自行车的英国品牌，在五个语言版本页面上给了五个不同的组织名：Brompton UK、Brompton USA、Brompton Deutschland、Brompton France、Brompton日本。一个品牌，五个名字，其中日本那一个还顺带把书写系统也换了。如果这五个名字出现在商家资料里，五条全部违规，其中一条同时违反两项。

多市场品牌的命名习惯值得单独看，带连字符的域名到底伤不伤SEO也是同一类历史包袱。

IKEA给出的是IKEA Denmark、IKEA Estonia、IKEA Portugal。Jackery更全：Jackery Deutschland、Jackery Australia、Jackery EU，还有一个Jackery korea——首字母是小写的，说明这一条是拼出来的，不是人写的。

那个小写的korea很有信息量。人在手写名字的时候不会把国名首字母写成小写，只有把语言代码直接拼在品牌名后面的程序会这么干。一个字母的大小写，泄露了整条数据的生成方式。顺着这条线索去看，Jackery那四个名字大概率出自同一段模板逻辑：品牌名加空格加地区标识，而地区标识取自站点配置里的原始值，没有做首字母大写处理。

这类细节的价值在于，它把“该改哪儿”从二十个页面收窄到了一段代码。你不需要一个个改名字，你需要改那段拼接。

还有一批加得更含蓄的

不是所有的尾巴都是国家名。样本里还有几个是别的东西：casper.com除了Casper还给出Casper Sleep，Sleep是品类也是品牌曾用名的一部分；monos.com给出Monos United Kingdom，把国名写全了；menuspace.com给出Audo Copenhagen U.S.，缩写带点；stanley1913.com给出Stanley 1913 CA；untuckit.com给出UNTUCKit Canada和UNTUCKit UK；wusthof.com的爱尔兰站给出WÜSTHOF Germany。

产地与品类信息该放哪个字段有讲究，Shopify图片SEO从命名到压缩的完整清单也强调过字段职责。

最后这个特别值得玩味：爱尔兰站的组织名里写的是Germany。它想说的大概是“德国的双立人”，是一种产地背书。但站在系统的角度，这就是一个在爱尔兰目录下、自称德国的组织。产地信息有专门的表达方式，塞进名字里只会制造混乱。

rab.equipment则给出了五个带注册商标符号的形态：Rab® US、Rab® CA、Rab® UK、Rab® EU、Rab® NO。商家资料那七条禁令里，特殊字符是明确被点名的一类，而注册商标符号正是典型的特殊字符。它同时踩了地点和特殊字符两条。

还有一个特别的：avocadogreenmattress.com的首页上，同一个页面里挂了四个本地商家节点，名字分别是Avocado Green Mattress - Hoboken、- Orange County、- La Jolla、- Santa Monica。这四个名字在商家资料那边全部违规（地点信息），但它们出现在自家首页上，作为四家实体门店的标注，逻辑上完全说得通。同一个写法，换个位置，一个合规一个违规。

这个案例值得多想一层。它之所以说得通，是因为那四个节点的类型是本地商家，不是组织——本地商家天然是按门店分的，加城市名是识别不同门店的必要手段。类型对了，加词就不算多余。换句话说，判断一个词该不该在名字里，还得看这个名字挂在哪个类型下面。

反过来，如果同样这四行挂的是Organization类型，那就真的乱了：一家公司同时叫四个名字，而这四个名字只差城市。所以做结构化数据的时候，选类型这一步的分量，比大多数人以为的重。

另一类：名字被机器改坏了

有两条特别值得单独拎出来，因为它们不是人的选择，是系统的事故。

机器无声改动内容这件事不止一次出现，浏览器自动翻译把选项改掉而问卷看不出异常是另一个版本。

rothys.com给出的两个形态是Rothy's和Rothy's。第二个里的那串字符是HTML实体，本该被解码成一个撇号，结果原样进了字段。这个站的名字之所以有两个形态，纯粹是因为某个模板少调了一次解码。

swarovski.com的两个形态是Swarovski和Swarovski Organization。后面那个Organization是结构化数据里的类型名，不是名字的一部分。这是把schema的类型字段写进了值字段。这一类错误不会有任何报表提醒你，因为语法完全合法。

还有一条同类的：delonghi.com的两个形态里，一个是De'Longhi Appliances S.r.l，另一个是DeLonghi——撇号没了，空格也没了。这两个字符串在任何一台机器眼里都是两个完全不同的名字，而它们出自同一家公司的两个页面。

这三个案例有一个共同点：没有任何一个人做过“把品牌改名”这个决定。名字长出第二个形态，靠的是一次没解码的模板、一次填错的字段、一次不同实现之间的字符处理差异。这也是为什么这类问题只能靠并排看发现——它没有决策记录，没有变更工单，没有人知道它什么时候出现的。

三条长出第二个名字的路径

模板与服务器层的默认值都会埋雷，服务器配置对SEO影响的二十项清单可以一起过一遍。

三条路径的处理成本递增。第一条改一次模板变量就好；第二条要先搞清楚这个字段该填什么，往往需要跟法务或者品牌部门确认；第三条得先找到那段生成代码，而它可能藏在某个插件里。

还有七个站，两个名字之间毫无关系

26个可测域名里，除了19个能定基线的，还剩7个。这7个的情况更极端：它们给出的几个名字之间连一个公共开头都没有。

实体识别错乱会直接影响被推荐的概率，ChatGPT品牌推荐机制的六十八次实测给过量化结果。

七个站的名字清单

品牌名混乱最终损耗的是品牌资产，把品牌当权重的四大战略解释了这笔账该怎么算。

三种完全不同的成因

第一种是把法人实体名当成组织名。awaytravel.com的加拿大版给的是JRSK Inc.，那是Away这个品牌背后的注册公司。买家不认识JRSK，他认识Away。delonghi.com的西班牙版给的是De'Longhi Appliances S.r.l，法律术语和撇号一起进了字段，而它的另一个形态干脆连撇号都没有，写成DeLonghi。

身份声明混乱在智能体时代成本更高，AI Agent时代品牌信任取代排名的四条策略讲了原因。

第二种是把关联品牌或母公司的店名串了进来。soundcore.com的阿联酋版给出的组织名是ankerstore——那是母公司Anker的店名。一个用户在soundcore的站上，被告知这个站属于一个叫ankerstore的组织。这条不是加尾巴，是换了个实体。

第三种是字段用错了位置。traeger.com的og:site_name直接写成了https://www.traeger.com，一个完整的网址塞进了名字字段。商家资料那边有专门一条禁令管这个，叫“电话号码或网址”。cybex-online.com更热闹，把CYBEX Gold和CYBEX Platinum这两个产品线名当成了组织名。

把网址写进站点名这件事，其实有个很朴素的来源：很多模板的默认值就是站点地址。建站的时候没人去改那一栏，它就一直是网址。默认值是最容易被忽略的一种错误，因为它从来没有被人做过决定。

为什么这七个站的问题比前面17个严重

加尾巴至少还认得出是同一家。名字完全不同就不一样了：系统要么把它们当成两个实体，要么挑一个当主名把另一个丢掉。无论哪种，你都失去了对这件事的控制。

实体被拆成两个的后果是可见性下降，AI搜索可见性的五维度深层策略里有对应的诊断路径。

更麻烦的是，这类问题极难自查。你在浏览器里看自己的站，看到的是渲染后的页面，标题和logo都是对的；那个写着JRSK Inc. 的字段藏在结构化数据里，只有查看源码或者用测试工具才看得到。

再往下想一层：这七个站里，有几个的名字冲突发生在不同的语言版本之间。也就是说，你在本国站上看源码，一切正常；问题只存在于那个你半年不打开一次的市场站上。自查的盲区，恰好和运营的盲区重合。

母公司这一类要怎么表达才对

soundcore那个案例其实提出了一个真问题：品牌确实属于某个母公司，这层关系该不该说、怎么说。

关系类属性有专门的表达方式，论坛和问答结构化数据怎么做是另一组关系字段的用法示范。

答案是该说，但不该说在name里。结构化数据里有专门的属性表达这层关系——parentOrganization表示上级组织，subOrganization表示下级，sameAs用来把同一个实体在别处的资料页链过来。关系有关系的字段，名字只管名字。

把母公司名写进name的实际后果是：系统读到的是“这个站的组织叫ankerstore”，而不是“soundcore隶属于Anker”。前者是一次错误的身份声明，后者是一条有价值的关系信息，两者的差别不是措辞，是语义。

产品线名的边界在哪

CYBEX Gold和CYBEX Platinum这两个是产品线，不是公司。但边界确实不总是那么清楚——有些品牌的子系列做大了，会独立成品牌，比如很多运动品牌旗下的高端线。

产品与品牌该分别挂哪些字段，电商产品评论的结构化与GEO联动给过一张对应关系表。

判据可以简单一点：这个名字有没有自己独立的官网首页。有的话，它可以在自己那个站上当组织名；没有的话，它就只是产品属性，应该出现在产品结构化数据的brand或者model里，而不是首页的组织名里。

这条判据的好处是它可执行。你不需要跟品牌部门讨论定位，只要看一眼有没有独立域名或独立目录就行。

七个站里最值得学的那个反例

七个站里，traeger.com那条最有教学价值，因为它的错误最容易复制。把网址填进名字字段，这个动作本身没有任何主观判断，它只是没人去改默认值。

默认值是上线检查清单该管的事，自建站谷歌SEO开发期的十大优化要点里列了要逐项确认的字段。

类似的默认值陷阱在建站过程中到处都是：站点标语默认是“又一个网站”、作者名默认是admin、商品图片的替代文本默认是文件名。这些默认值有一个共同特征——它们在页面上不显示，或者显示得很不起眼，所以永远没人发现。

应对办法只有一个，就是在上线检查清单里给它们留一行。不是靠记忆，是靠清单。保哥这些年见过太多站，页面做得漂亮，源码里一堆默认值原封不动，其中最常见的就是站点名称那一栏还是安装时自动填的域名。

这七个站的另一个共同点

把七个站的名字清单再看一遍，会发现一件事：每一个站的“主名”都是对的，出问题的都是第二个、第三个形态。Away是对的，JRSK Inc. 是多的；soundcore是对的，ankerstore是多的；Traeger Grills是对的，那个网址是多的。

知识没传到执行位置是管理问题，新网站SEO目标管理的三个里程碑里有拆解任务的办法。

这说明问题的性质不是“不知道自己叫什么”，而是“在某些位置上，负责填这个字段的那个人或那段代码，不知道该填哪个”。知识是有的，只是没传到那个位置。

这正好回到前面说的单一事实来源：如果名字只在一个地方定义，其它位置全部引用，那么“不知道该填哪个”这个问题从一开始就不会出现。

把名字数清楚，需要几个动作？

禁止型规则的落地方式跟其它两类不一样。它不需要你设目标、不需要你做实验、不需要你追踪效果，它只需要你把不该在的东西拿掉，然后确认它真的不在了。

盘点类的活最怕漏掉边缘页面，四十个电商站的站内搜索页实测也是靠逐个页面看才发现的。

第一步：把所有声明位置列全

先做一张表，把你的站上所有会说出“我叫什么”的位置写下来。一般至少这么几处。

不同建站方式的字段入口差别很大，SaaS托管自建与纯代码的选型全拆解可以先确认自己属于哪一类。

第二步：定一个基线名，然后做减法

选一个名字当基线，判据只有一个：顾客口头提起你的时候说的是哪个。不是法务上最完整的那个，不是域名去掉后缀的那个，是顾客嘴里的那个。

基线名其实是品牌定位的一次收敛，AI搜索时代品牌定位清晰度的四个动作讲了怎么收。

这个判据有个很好用的验证方式：去翻客服工单和站内搜索词。用户在工单里怎么称呼你、在搜索框里输入的是哪几个字，那就是你真实的名字。这批数据里那些名字最干净的站，用的基本都是这个逻辑——名字短、无修饰、和域名主体一致。

另外提醒一句：基线名一旦定下来就别轻易动。名字这件事的价值几乎全部来自稳定，改一次名字的代价，远高于当初起对名字的收益。所以这一步宁可慢，也别边做边改。

然后把所有位置上的名字跟基线对齐。多出来的每一个词，按下面这张表分流。

第三步：验一遍，而且要在所有语言版本上验

最容易漏的就是这一步。这批数据里26个有多形态的域名，绝大多数的问题只出现在非主站的语言版本上——首页干干净净，德国站的组织名后面挂了个Deutschland。

多版本核对最容易漏掉非主站，集合页分页的索引判断与canonical设置也是同一类逐版本的活。

验的方法很土但很有效：把每个语言版本的首页源码拉下来，把所有名字字段抠出来放进一张表，肉眼扫一遍。不需要工具，需要的是把它们并排放在一起。分散在二十个页面上的时候你看不出问题，放进一列里三秒钟就看出来了。

如果你的站有hreflang表，这一步可以省一半力气——那张表本身就是所有语言版本的清单，照着它一个个抓就行。多语言标注和名字一致性这两件事，用的是同一份地址列表，顺手一起做完最划算。

一张能直接用的盘点表

抄源码这件事有工具可以省力，十款网站技术栈检测扩展的实测对比里有能直接读结构化数据的。

最后一列是整张表的重点，前面五列都是为它服务的。填完这一列，你的改造工单就写完了。

表格填完之后还有一个动作值得做：把“与基线的差”那一列去重，看看一共有几种不同的多余成分。这批数据里，17个有问题的域名加起来只产生了六类多余成分——地点、法律术语、营销词、另一套文字、产品词、其它。问题的种类远比问题的数量少，这意味着一次修改往往能解决一整类。

改的时候按什么顺序

如果多余成分不止一类，按这个顺序处理性价比最高。

一次改模板清掉多处问题是最划算的，类目导航改版三轮之后仍然没写清楚用户在哪也是模板层的活。

先改那些出现在最多语言版本上的。一个尾巴挂在五个市场上，改一次模板就能一次清掉五处；另一个尾巴只在某一个市场上，那是单点问题，可以晚一点。

然后改那些跟主名差别最大的。Away和JRSK Inc. 之间的距离，比Brompton和Brompton UK之间的距离大得多，前者更可能被系统当成两个实体。差别越大，消歧的代价越高。

最后改那些机器生成的。这类改起来最麻烦，因为你得先找到生成它的那段代码；但它也最不容易复发，因为改完之后模板就对了。

改完怎么确认真的生效了

只看浏览器里的页面是不够的，那一层看不到结构化数据。可靠的确认方式有三种，按可信度排序：直接看每个语言版本的初始HTML源码；用富媒体测试工具跑一遍，它会把解析出来的字段列出来；等系统重抓之后看搜索结果里显示的站点名称。

改完之后要等多久是个高频问题，已收录页面加noindex后多久消失的六大场景实测给过量级参考。

第三种最慢，官方对图标这类资源的重抓给出的说法是几天到几周，名字大概率也在这个量级。所以别改完当天就去搜自己的品牌名，看到没变化就再改一次。反复改是这件事上最坏的做法，它会让系统对你的名字一直保持低把握。

还有一个细节值得强调：第三、四、五列一定要原样抄，不要顺手把首字母改成大写、不要把全角空格换成半角。Rothy's那个案例之所以能被发现，就是因为没有被整理过。你在誊抄的时候做的每一次“修正”，都是在把证据擦掉。

为什么单是删掉不够，还要主动填别名？

做完减法，名字干净了，但你损失了信息。日本市场的片假名写法、中文市场的中文名，这些是真实存在的、用户真的会拿去搜的东西。它们不该消失，只是不该待在name里。

主动声明比等着被理解有效得多，答案引擎优化怎么让内容被优先引用讲的是同一件事。

那个没人用的字段是干什么的

alternateName的定义只有一句话：这个东西的一个别名。它属于Thing这个最顶层的类型，所以任何类型都能用，组织能用，产品能用，文章也能用。

推荐属性填不填直接影响信息量，FAQPage结构化数据的八步实战也是一个填了才有用的字段。

Google的组织结构化数据文档里对name和alternateName的说明是连在一起写的：使用你在站点名称上用的那同一组name和alternateName。官方文档明确把这两个字段当成一对来看待，而实测90个站里只有7个把这对填全了。

填了别名，实际上换来什么

换来的不是排名，是消歧。当系统需要判断“这个中文名和那个拉丁名是不是同一家”的时候，你的alternateName就是那张明牌。没有这张明牌，它得靠上下文猜，猜错的成本你来承担。

消歧本质上是在共识层留证据，共识层六信号的九十天实战指南解释了这些证据怎么被汇总。

这件事在跨语言市场上尤其值钱。上一批做多语言标注的时候我们已经见过一次同类现象：系统能不能把两个地址认成一件事，取决于你有没有明确说出来，而不是取决于它们看起来像不像。名字这件事是一模一样的逻辑。

还有一个更具体的收益场景：品牌词的搜索需求往往分散在几个写法上。用户可能搜拉丁写法，也可能搜本地文字写法，还可能搜一个通俗简称。你把这几个都登记成别名，等于告诉系统这几拨需求指向同一个实体。不登记的话，它们在系统那边可能是几件不相干的事。

别名该写几个，写哪些

三条建议，都来自这批数据里的反例。

别名写什么会影响品牌被怎么描述，AI品牌情感优化五个月的操作手册记录过一次调整过程。

第一，写真的被用的，不写你希望被用的。片假名写法如果日本用户确实在用，写；某个内部代号没人在外面用，不写。第二，别把地区变体写成别名。Brompton UK不是Brompton的别名，它是Brompton加了个尾巴，删掉就好。第三，别名字段不是关键词字段，塞品类词进去没有任何用，反而会让系统对你的主名更不确定。

这个字段的价值来自它的克制。填两三个真别名的效果，远好过填十个凑数的。

哪些东西看起来像别名，其实不是

品牌词的几种写法可以在后台拆开看，GSC品牌词过滤器的五步使用指南讲了怎么按写法分组。

这张表里最容易搞错的是最后一条。很多站把域名当别名填进去，理由是“大家也这么叫我们”。但域名有专门的url字段，重复声明不增加信息，只增加一个需要被消歧的字符串。凡是已经有专属字段的东西，都不该再进别名。

那86个测不出的站，真的没问题吗？

这是本次数据里最需要小心解读的一块。76.8% 的域名只给出一个名字形态，尺子对它们弃权——但弃权不等于合格。

让机器读得懂的前提是你先说清楚，让内容被主动引用的五个维度里有可执行的写法。

弃权的三种可能

只有一个形态，可能对应三种完全不同的现实。

看不见不等于不存在，日志里带人来的其实是另一批入口就是一次典型的统计盲区。

第一种是真的规范：全站上下只用一个名字，各语言版本一致，这是最好的状态。第二种是信息量不足：这个站压根没做多语言，或者它的语言版本页面没被我抓到，所以看不出漂移。第三种最隐蔽：这个站的唯一一个形态本身就是错的。比如它只在一处声明了名字，而那一处写的是法人全称，全站再没有第二处可以对照。

规则够不着你，取决于你暴露了多少

这一层是这次量完之后最让我在意的东西。能被这把尺子判的，只有那些自己给出了不止一个版本的站。换句话说，你得先自曝，规则才够得着你。

暴露面与风险面往往是同一件事，GEO投毒的三条攻击路径与三层防御从另一侧讨论过这个平衡。

这个结论对禁止型规则是普遍成立的。商家资料那条新规能执行，是因为名称字段是明牌，谁都看得见。而结构化数据里那些名字，除非你自己给出多个版本、被人并排一看，否则没有任何机制会发现不一致。

所以那86个站不是安全，是没被看见。没被看见和没问题之间，隔着一整个语言版本目录。

暴露多少这件事，你其实是可以选的

顺着这条思路往下走会得到一个有点危险的推论：既然规则够不着不暴露的人，那少声明一点是不是更安全。

说得少而准是内容层同样适用的原则，AI搜索时代内容优化的底层逻辑五步里有一致的取舍。

这个推论在合规层面成立，在效果层面完全不成立。不声明的代价是系统只能靠猜。官方文档已经明说，把握不足的时候它会自己生成一个名字或者直接显示域名——你规避掉的那点风险，换来的是对呈现结果的失控。

正确的姿势不是少说，是说得少而准：只在必要的几个位置声明，每个位置说同一句话，别名放进别名字段。这样既没有不一致的风险，也没有信息缺失的代价。

这一点跟很多技术类规则的处理逻辑是一致的：模糊不会保护你，模糊只是把决定权交出去了。

给那86个站的一份三分钟自检

如果你的站也属于“只声明了一个名字形态”这一类，下面三个问题能在三分钟内告诉你是哪一种情况。

自检之后要不要上监控工具，二十款GEO与AEO监控工具的评测与选型可以按预算挑。

第一个问题：你有几个语言版本或国家站。如果只有一个，那你天然没有不一致的机会，这一项可以过；如果有好几个，但抓下来只有一个名字形态，先确认是不是别的版本压根没有结构化数据。

第二个问题：你唯一那个名字，是从哪来的。是有人专门决定的，还是模板默认的，还是从店铺设置里带出来的。只要不是有人专门决定的，就有必要看一眼它到底写的是什么。

第三个问题：把那个名字念给一个没见过你品牌的人听，他会不会觉得那是一家公司的名字。念出来像地址、像广告语、像网址、像法务文件的，都需要改。

三个问题都过了，你可以放心地把力气挪到别处。这正是禁止型规则该有的收尾方式：确认过线，然后离开。不需要每季度回来看一眼，也不需要建监控，只要在下次动模板的时候顺手再过一遍这三个问题就够了。

顺便说一句，这三个问题里最容易翻车的是第二个。很多团队从没想过“这个名字是谁定的”这种问题，因为它看起来太基础了。但本次样本里那些最离谱的值——写成网址的、写成一整句瑞典语的、带着未解码实体的——无一例外都属于“没人做过决定”这一类。基础问题之所以出错，恰恰是因为没人觉得它需要被检查。

如果你正在开新市场

开新站的那一刻，是这件事成本最低的时候。新市场上线之前花十分钟确认三件事，能省掉后面几年的对账。

新市场上线前的这半小时，回报周期比多数投放都长，八家龙头怎么抢AI流量的打法拆解里有类似的前置动作清单。

第一，新站的组织名和主站完全一致，一个字符都不差。第二，市场归属由页面语言声明、地址字段和货币来表达，不写进名字。第三，如果这个市场确实需要一个本地写法，它进alternateName，不进name。

这三条加起来不到半小时的工作量，但它们决定了三年后你要不要做一次跨二十个站的名字对账。这类事情的性价比永远在开头，不在中间。

还有一个容易被忽略的场景：换建站平台或者换主题的时候。迁移过程中所有字段都会被重新映射一遍，而名字这类字段往往没人专门盯，映射错了也不会有任何报错。本次样本里那几个明显是模板事故的案例，时间点大概率就落在某次迁移上。迁移清单里加一行“核对组织名与站点名”，成本是一分钟。顺手把各语言版本也带上，因为迁移往往是一次性把所有站都动一遍，正好是并排核对最省事的时机。

怎么让自己从测不出变成能自查

方法很简单，而且是免费的：把你所有语言版本的名字字段主动收集到一张表里。这张表不需要给任何人看，它的唯一作用就是让不一致暴露出来。

把分散数据收进一张表是通用手法，用正则从GSC里挖AI搜索提问的五步实战也是这个思路。

这批站里有几个已经在这么做了——它们所有语言版本给出的是同一个组织名，地区信息全部靠页面语言和地址字段表达。这不是运气，这是有人维护着一份单一事实来源。

顺便说说“单一事实来源”这四个字

这个词在工程团队里很常见，但在名字这件事上它有一层特殊含义：你的品牌名应该只在一个地方被定义，其它所有位置都引用它。

同一份内容供多种消费方式，用内容协商给AI交付Markdown的实操是单一来源多种输出的另一个例子。

实际做法通常是在站点配置或者环境变量里放一个常量，模板里的组织名、og:site_name、标题后缀全部引用这个常量。这样做的好处不是省事，是让不一致在物理上不可能发生——你想让德国站叫一个别的名字，得先改配置，而改配置这个动作有记录、有人看得见。

反过来，如果每个语言版本的模板里各自硬写了一遍名字，那么不一致的出现只是时间问题。这批数据里那26个有多形态的站，绝大多数属于后一种结构。

那几个把名字换成一句话的站

最后补一类特别的样本，它们不在前面的统计里，因为它们的名字压根不是名字。

广告语和名字被混为一谈很常见，PAS公式在SEO内容写作中的进阶用法里区分过这两种文案的职责。

vaude.com的法比版组织名叫FR Shop，美国版叫Mountain & Bike Sports；zwilling.com的美国版叫Premium Kitchenware，葡萄牙版叫“厨房必备品”，瑞典版直接是一整句“选购刀具、厨房用具、餐具和锅具”。insta360.com的德语版叫VR Kameras。

这些字段里装的是品类描述和广告语，不是名字。它们大概率来自同一个原因：模板把某个用于展示的字段接到了名字字段上，比如接了页面标题、接了导航栏文案，甚至接了SEO描述。

这一类问题的自查方式最简单：把你的组织名念出来，如果它不像一个名字，那它就不是。“选购刀具、厨房用具、餐具和锅具”，念一遍就知道出事了。

禁止型、代劳型、亲自型，力气该怎么分？

回到最开始那个三分法。认出规则的类型，是为了决定投入多少，以及投在什么形态上。

平台的介入方式在专利里能看到痕迹，从专利与专家访谈还原的GEO五步原理提供了另一个观察角度。

三种规则的投入曲线完全不同

投入产出曲线该怎么跟老板讲，流量下降不等于SEO失败的八维度实战有一套现成的说法。

名字这件事其实横跨了前两类。删掉不该有的，是禁止型；剩下那个到底会不会被系统采用，是代劳型。你能做完的只有前半段，后半段你只能把原料摆对。

先做哪个

顺序上，禁止型永远排第一，因为它的下行风险最大且不可预测。代劳型排第二，因为它的收益虽然有上限但确定。亲自型排第三，但它是唯一一个长期复利的——这一点下一篇会专门讲。

排在禁止型后面的往往是技术底座，四十六个电商站的页面体积实测是一次典型的亲自型排查。

保哥这两年给客户做诊断，第一天永远只做一件事：把所有可能触发处罚的地方过一遍。不是因为它最重要，是因为它最便宜——一个下午能做完的事，做完之后你就再也不用担心某天早上醒来资料被暂停。

三类规则各自最容易犯的错

禁止型最容易犯的错是把它当优化做，前面已经说过了。还有一个变体：把它无限期推迟，理由是“又不影响排名”。不影响排名是对的，但它影响存在。

等平台通知是亲自型规则上最贵的错，抓取预算优化的十二项实操指南里全是没人会提醒你的事。

代劳型最容易犯的错是找开关。团队会花好几天翻后台、翻文档，想找一个能把站点名称写死的设置项。找不到之后，往往得出的结论是“这功能还没上线”，而真相是它根本就不以开关的形式存在。

亲自型最容易犯的错是等通知。因为平台从不报警，没有报表，没有邮件，也没有一项检查会亮红灯，所以团队默认“没消息就是没问题”。而实际情况是，这类事情永远不会有消息。

三个反直觉的判断

第一，名字字段里多写的每一个词，都在替系统做一次“这是不是同一家”的判断题，而它答错的概率比你以为的高。页面上多一个词是丰富，字段里多一个词是歧义。

多说一个词未必是丰富，七万五千条答案实证的引用偏好也得出过类似的克制结论。

第二，没有执法的地方问题更多，不是更少。商家资料那边名称字段规规矩矩，是因为违规会被暂停；独立站这边一片自由，于是标题里的品牌名可以出现三次。

第三，这批数据里最干净的那批站，不是最讲究的，是最懒的——它们只在一个地方写了名字，所以不可能不一致。维护多份声明的成本，总是比你预算的高。

如果只做一件事，做哪件

把所有语言版本的组织名、og:site_name和标题尾段抄进一张表，然后看它们是不是同一个字符串。就这一件。

一次盘点能带出一批改动，把旧内容更新成AI可信来源的十二步可以接在这次盘点后面做。

这件事不需要任何工具、不需要预算、不需要跨部门协作，一个人一下午能做完一个二十语言的站。而它能一次性暴露本文提到的绝大多数问题：加尾巴的、填错字段的、被模板改坏的、以及被接成一句广告语的。

名字这件事的所有麻烦，都源于它被写在了太多地方；所有的解法，也都始于把这些地方并排放在一起看一眼。

最后回到那条新规

商家资料这次加的那一行，站在独立站主的角度看，其实是一份免费的提醒。它告诉你平台在意什么：不是名字好不好听，不是名字有没有关键词，而是一个实体在系统里能不能收敛成一个名字。

实体收敛这件事在渠道层同样成立，Reddit成了新型GEO引擎源之后官网怎么起量里能看到同一个实体在多个渠道的一致性代价。

本次样本里，能被判的26个域名中有17个没做到，比例六成五；而那86个测不出的站，只是没给出足够的证据，不代表它们在别的位置上没有分叉。把这两个数字合起来看，“一个实体一个名字”这件事，在国际化独立站里远没有成为默认。

好在它的修复成本极低。不需要预算，不需要排期，不需要说服任何人——把几个字段抄进一张表，删掉多余的词，把别名归位。整件事的难点从来不是执行，是意识到那几个字段之间本来就该一致。

下一篇会接着讲第二类，也就是代劳型：当平台不是禁止你、而是替你决定的时候，你手上还剩下什么牌。那一篇量的是同一批站的另一样东西——搜索结果和广告位上显示的那个小图标，以及系统究竟从哪几个来源里挑出你的名字。名字和图标是同一个问题的两半：一半是你不该多说，一半是你说了也不算。

最后留一句可能有点扫兴的话。这批数据里做得最规范的那些站，没有一个是靠工具做到的。它们靠的是有人在某一天决定了“我们叫什么”，然后把这个决定写进了配置文件，让所有模板去引用它。技术手段能帮你发现不一致，但消除不一致靠的始终是一个决定，而不是一个脚本。

常见问题解答

我的独立站没有商家资料，这条新规跟我有关系吗？

直接关系没有，这条规则只管商家资料的名称字段。但它背后那张七条禁令清单，是目前能找到的、最明确的一份“名字字段里不该有什么”的官方说明，可以直接拿来审你自己站上的结构化数据和og标签。如果你同时在做本地业务、有实体门店，那就是直接相关，需要在被暂停之前主动改掉。另外还有一种常见情况：品牌方自己没开商家资料，但线下经销商开了，而经销商往往会把品牌名加上自己的城市和门店编号。这种资料出问题的时候，被搜索的人找不到的仍然是你的品牌。

不同国家站用不同的组织名，到底有什么实际损害？

最直接的损害是消歧成本转嫁给了系统。当有人问某个品牌怎么样、系统需要把你的几个站聚合成一个实体的时候，五个不同的名字意味着它要多做四次判断。判断结果不透明，也不会有任何报表告诉你它判成了几个实体。次一级的损害是站点名称的显示：官方文档明说，如果系统对你提供的名字不够有把握，它可能会自己生成一个，或者干脆显示你的域名。

legalName和name到底该怎么分？

name写顾客口头说的那个，legalName写工商登记的那个。判据很简单：如果一个陌生顾客在电话里对你说出这个名字，你会不会觉得奇怪。会觉得奇怪的，就是legalName。这批数据里17个站填了legalName，做法都是对的；有问题的是那几个把法人名直接写进name的站，比如把Away写成JRSK Inc.。

把中文名和英文名一起写进name，真的会被判违规吗？

在商家资料里会，这正是新增那条规则明说的形态，而且明确写了即使实体招牌上就是这样也不允许。在独立站的结构化数据里不会有人罚你，但会有另一个后果：系统需要自己判断这两段文字是同一个名字的两种写法，还是两个不同的东西。正确的做法是主名只留一个书写形态，另一个放进alternateName。

为什么第一版尺子会把品牌名本身当成违规？

因为它只有词表没有基准。规则原文说的是不必要的信息，不必要意味着存在一个必要的基准，也就是商家的真实名号。只按词表判，Copenhagen这个词在Flying Tiger Copenhagen里是名字的一部分，在Brompton Copenhagen里就是加上去的，而词表分不出这两种情况。修法是给每个站找一个属于它自己的基线，只判基线之外的增量。

只有一个名字形态的站，是不是就一定没问题？

不一定，只能说测不出。可能是真的规范，可能是没做多语言所以没暴露出漂移，也可能是它唯一那个形态本身就写错了、而站上没有第二处可以对照。本次样本里112个域名有86个属于这一类，占76.8%。想从测不出变成能自查，唯一的办法是把所有语言版本的名字字段主动收集到一张表里。

alternateName填多了会不会被当成关键词堆砌？

目前没有任何公开说明表示会因此受罚，但填多了确实有害。这个字段的作用是消歧，填进去的每一个别名都在告诉系统“这也是我”。塞品类词进去，等于告诉系统你的名字里包含这个品类词，反而降低了它对你主名的把握。建议只填真实被用的别名，一般两三个足够。

这套盘点多久做一次比较合适？

触发式比定期式更实用。每次新开一个语言版本、每次换模板、每次上新的结构化数据插件，做一次。这三件事是名字长出第二个形态的主要场景。这批数据里那个把HTML实体原样写进名字的站，几乎可以肯定是某次模板改动带出来的，而这种问题不会有任何报表提醒。如果一定要一个周期，半年一次足够，但前提是这半年里没发生上面那三件事。

改了名字之后，多久能在搜索结果里看到变化？

没有确定的时间表，官方也没给过承诺。可以参考的是同类抓取行为的节奏：图标的重新抓取，官方明说需要几天到几周，取决于系统判断你更新的频率。名字这类信息的更新节奏大概率同一个量级，因为它同样只需要重抓首页。所以合理的预期是几天到几周，期间不要反复改——每改一次，系统对你的把握就低一分。

用了Shopify这类平台，这些字段还能自己控制吗？

大部分能，但入口分散。组织类结构化数据通常由主题模板输出，改主题文件或者用应用注入都行；og:site_name一般跟着店铺名称走；标题后缀在SEO设置里。本次样本里有大量站跑在这类平台上，出问题的位置高度集中在多店铺场景——同一个品牌开了几个国家店，每个店的店铺名各自填了一遍，于是名字就分叉了。这种情况下最省事的办法是把店铺名统一，把国家信息交给货币、语言和地址去表达。

把品牌名换成一句品类描述，会有什么后果？

后果是系统失去了你的名字这条线索，只能从别的地方找。官方文档写过，当它对你提供的名字不够有把握时，可能会用其它来源生成一个，或者直接显示域名。本次样本里有几个站的组织名被填成了品类描述甚至整句广告语，比如“选购刀具、厨房用具、餐具和锅具”。自查方法很简单：把那个字段的值念出来，不像名字就是不对。

权威参考资料

摘要：把169个DTC品牌的名字逐个丢进英语词表里查，27个整体就是一个英语常用词，46个能在词典里查到，64个至少有一个词是日常用语。也就是说每六个品牌里就有一个，它的名字和普通名词长得一模一样。而AI分析面板里那条“品牌词还是非品牌词”的分界线，恰恰是靠字符串匹配画出来的，画在一句你根本看不到的检索词上。

Microsoft Clarity在2026年8月给AI引用面板加了一组新东西：给检索查询打上品牌与非品牌的标签，可以按这两类筛选，分别看引用次数，还分别算了一个权威占比。

这个更新本身是好事。以前所有AI引用混在一个数字里，现在至少能分成两堆看。问题出在这条分界线是怎么画的，以及它画在了什么东西上面。

它不是画在用户问的那句话上，而是画在模型自己拼出来的那条检索词上。而判断那条检索词算不算品牌词的办法，说到底就是看里面有没有出现你的品牌名。

这篇文章分两半。前半段说清楚这条线的位置和它中间隔着几层；后半段是我拿169个真实DTC品牌名做的一次测量，用来回答一个很实际的问题：你的品牌名，到底是不是一个能被字符串匹配可靠识别出来的东西。

Clarity把AI引用拆成品牌词和非品牌词，这条线画在哪？

先把这次更新的内容摆清楚，再说它的边界。

新增的四样东西

一是给相关的检索查询打上品牌标签；二是可以按品牌和非品牌两类做筛选；三是每一类各自给出引用计数；四是每一类分别计算权威占比。这次更新的完整报道里把这四项列得很清楚，也提到了它的几处限制。

同类工具还有不少，20款GEO与AEO监控工具的选型可以对着挑。

这四样凑在一起，等于把原来的一个总数拆成了两条线。对做品牌的人来说，这两条线的含义差得很远，能拆开当然比混着看强。

值得一提的是，这个面板本身是免费的。Clarity这个产品从热图和会话回放起家，这两年一路往AI可见度这边加功能，对预算不多的独立站团队来说是个挺实在的选择。它的官方文档更新得也算勤快。

但免费和好用是两件事，好用和读得对又是另外两件事。这篇的重点全在最后那一层。

品牌检索和非品牌检索，各自意味着什么

品牌检索指的是那条检索词里直接出现了你的品牌名，这时候模型往往会去找你的产品文档、价格页、帮助文章和评测。也就是说，AI已经把你当成了一个待考察的对象。

这两类流量的结构差别，品牌词与非品牌词怎么读怎么经营里拆得更细。

非品牌检索是更宽的品类或话题查询，里面没有直接提到任何品牌，比如“适合零售商的邮件营销工具”这类。这时候你能被引用，说明你在这个话题上被当成了可用的材料。

为什么现在才拆

因为在此之前，AI引用这件事本身还太新，能有个总数看就不错了。工具方先解决“有没有”，再解决“是什么”，这个顺序很正常。

但顺序正常不代表使用者可以跟着这个节奏走。一个刚拆出来的维度，最容易被当成一个成熟指标来用，因为它长得跟那些用了十几年的指标一模一样：一个名字、一个数字、一条曲线。

越是新拆出来的维度，越该先问它是怎么拆的。这个习惯我建议固定下来：任何一个新增的分类维度，第一次看到它的时候，先花十分钟搞清楚分类依据，再开始用它做判断。

为什么这两条线的含义差得远

非品牌那条线涨，说明你在品类层面的存在感在变强，这是最难做也最值钱的一段。品牌那条线涨，可能是因为你最近做了投放、上了新闻、或者刚发生了什么事——它更多是别的动作的回声。

为什么它们得当两件事做，拆分、防御与归因讲过一次。

两条线混在一起看，最常见的后果是把一次公关事件的余波，当成了内容策略见效。这也是这次更新真正的价值所在。

反过来的误判同样常见。一个团队踏踏实实写了半年品类内容，非品牌引用慢慢在涨，但总数被品牌那侧的自然回落盖住了，看上去像是原地踏步。半年之后这条内容线被砍掉，理由是“数据上看不出效果”。

这类事我见过不止一次，而且它有个共同特征：被砍掉的总是那条慢的、需要拆开才看得见的线。因为快的那条不用拆就能看见，会议室里谁能被看见谁就活下来。

拆开之后，两条线各自该跟什么比

品牌那条线该跟你的品牌动作排期比：这个月投了什么、上了什么新闻、发了什么产品。对得上，说明它在正常反应；对不上还涨了，值得去看是不是出了什么你不知道的事。

指标体系怎么搭，从指标到异常诊断有一套现成框架。

非品牌那条线该跟你的内容排期比：这个月覆盖了哪几个品类问题、发了几篇、深度如何。它的反应会滞后几周，所以比的时候要往前错一到两个月。

这两条线的对照物不同，考核它们的团队也应该不同。把它们放进同一个KPI里，最后一定是内容团队替品牌团队的波动背锅，或者反过来。

那这条线是怎么判定的

官方的说法是给“提到你品牌名的相关检索查询”打上品牌标签。剥掉措辞，实现上就是在一条字符串里找另一条字符串。

自己写规则是什么体验，GSC品牌词过滤器的5步用法可以对照看。

这个做法在绝大多数分析工具里都一样。Search Console的品牌词过滤器也是这个原理，只不过那里的过滤规则是你自己写的，你知道自己写了什么。这里的规则不在你手上。

差别看着不大，实际影响很大。自己写规则的时候，你会主动处理各种变体：常见拼写错误、加不加空格、英文名和中文名、子品牌算不算。这些判断都记录在那条正则里，随时能翻出来看。

而一个第三方工具给你的品牌标签，你既不知道它用的是精确匹配还是包含匹配，也不知道它处不处理大小写、复数和词边界。你能看到的只有结果，看不到判据。这正是这一整篇要处理的问题。

为什么不能指望它公开这套规则

因为公开了就会被针对。任何一个可见的判定规则，只要它连着一个大家在乎的数字，就会有人去迎合它。这不是恶意，是自然反应。

规则一公开就会被迎合，对抗式优化为什么注定失败说的是同一件事。

所以这类规则天然倾向于不公开，而不公开的规则天然无法被外部验证。你能做的不是要求它透明，是估计它的偏差有多大、往哪个方向偏。后面那批数据就是在做这件事。

这条线以前是怎么画的

在传统搜索这一侧，品牌词和非品牌词的拆分已经做了十几年，方法也是字符串匹配，但有两个关键区别。

传统那一侧的打法，品牌词的SERP六位与三层防御。

第一，那边匹配的是用户真实敲进搜索框的词，中间没有改写。第二，规则是你自己写的，写多写少你自己负责。这两条加起来，让那边的拆分虽然也粗糙，但至少是可控的粗糙。

到了AI这一侧，两条都不成立了。匹配对象变成了模型生成的中间产物，匹配规则变成了第三方的黑盒。同一个概念，同一个方法，可靠性掉了不止一个档次。

这不是说不该做这个拆分——该做，而且必须做，因为混着看更糟。只是从传统搜索那边带过来的解读习惯，得改一改。

具体要改的有三条：别把品牌词占比当健康度指标，别拿这两个数跟同行比，别用单月数据下结论。这三条在传统搜索那边都是可以做的，在这边都不太行。

三条背后是同一个原因：那边的误差来自你自己的规则，这边的误差来自一个你看不见的黑盒加一个你十年前起的名字。前者可以修，后者只能估。

最该改的一个习惯

传统搜索里，品牌词占比是个挺有意义的健康度指标：品牌词占比太高，说明获客过度依赖存量认知；太低，说明品牌没建起来。很多团队养成了盯这个比值的习惯。

该淘汰的旧指标不止这一个，9个指标的替代方案列了一份。

这个习惯在AI这边要慎用。因为这个比值的分子分母，各自带着一个方向相反、大小不明的误差。两个误差一除，得到的东西已经很难说代表什么了。

如果实在想看这个比值，至少做一件事：把它和传统搜索那边的品牌词占比放一起看。两边差得太远的时候，差额里有多少是真实差异、多少是口径差异，值得单独查一次。

一个只有你自己能回答的问题

所以真正该问的问题变成了：你的品牌名，是不是一个足够独特、能靠字符串匹配可靠认出来的东西。

品牌定位这件事，四个动作重塑清晰度从另一个角度谈过。

如果是，这条线基本可信；如果不是，这两个数字都会带上一层你看不见的误差，而且方向还不一定。后面那批数据就是为了回答这个问题。

你在报表里看到的那句查询，不是用户问的那句话

这是理解整件事的关键一层，官方文档里也明确提示过。

检索词是模型自己拼的

用户在对话框里打了一句话，模型不会拿这句话原样去检索。它会先理解、拆解、补全，然后生成一条或几条自己认为合适的检索词，再拿这些检索词去找资料。

这条检索词怎么反推，Clarity反推AI引用的实战里有做法。

你在面板里看到的，是后面这些检索词，不是用户打的那句话。这中间隔着一次改写，而这次改写你既看不到也管不了。

改写会往哪个方向偏

常见的几种：把口语化的问题改写成更书面的表述；把一个含糊的需求补上限定词；把一个长问题拆成几条短的分别去查；在用户提到某个品牌时，把品牌名带进检索词，也可能不带。

改写敏感性可以测，5步测品牌引用稳定性是一套现成方法。

最后这一种直接决定了标签。同一个用户问题，模型这次把品牌名带进去了就算品牌检索，下次没带就算非品牌检索。

还有一种改写特别值得注意：把品牌名替换成品类描述。用户问“某某牌的箱子结实吗”，模型可能生成的检索词是“硬壳行李箱 耐用性 评测”。用户问的是一个明确的品牌问题，落在面板上却是一次非品牌检索。

反过来也有：用户问“有哪些好用的行李箱”，模型可能先检索一遍品类，再针对排在前面的几个品牌各查一次。于是一次非品牌提问，生成了一条非品牌检索词加三条品牌检索词。一次提问在面板上留下了四个印记，分属两个类别。

一个问题会产生几条检索词

没有定数，取决于问题的复杂度和模型的策略。简单事实问题可能一条都不检索，直接答；复杂的对比类问题可能拆出五六条。

用户到底问什么，12类查询分类与内容布局做过归类。

这意味着面板里的引用计数，分母是不稳定的。同样是一百次用户提问，这个月可能产生两百条检索，下个月可能产生三百五十条，而变化的原因在模型那边。

这一点在做同比环比的时候尤其要小心。曲线的斜率里混着两样东西：你的可见度变化，和模型检索策略的变化。它们分不开。

官方自己也提醒了这一点

那篇报道里引用的原话大意是：一条带品牌名的检索查询可能只是说明模型选中了这家公司去做进一步了解，它既不能确认用户知不知道这个品牌，也不能说明他处在什么购买阶段，更不能预测他会不会买。

监测提示词有几个误区，AI可见度监测的4大误区点过名。

这句提醒很实在，但它容易被忽略，因为面板上那个数字看起来太像一个可以直接汇报的指标了。

为什么模型要做这次改写

因为用户的话往往不是一条好的检索词。日常提问里有大量指代、省略和口语，直接拿去检索命中率很低。模型把它改写成一条结构清楚、关键词明确的查询，是为了提高找到有用材料的概率。

关键词研究要转向需求研究，六步转向的做法。

从产品角度看这是对的，用户也确实受益。问题只出在下游：这个为了检索质量而做的改写，被下游当成了用户意图的代表。它本来不是为这个用途设计的。

这类事在数据里很常见——一个为了A目的产生的中间数据，被拿去回答B问题。中间数据本身没错，错在它被赋予了它承担不了的含义。

这一层带来的第一个后果

你没法用这两个数字去回答“有多少人主动搜了我的品牌”。能回答的只有“模型在多少次检索里用上了我的品牌名”，这是完全不同的两件事。

想从后台挖提示词，GSC正则的5步追踪是个入口。

第二个后果更麻烦

这两个数字的比值会随模型行为变化，而模型每次更新都可能改变改写策略。这个月非品牌占比涨了十个点，可能是你的内容起作用了，也可能只是模型这一版更倾向于先做宽查询再收窄。

引用机制本身在变，2万条数据揭示的5条规律可以当参照。

你没有办法把这两种情况区分开，因为改写这一步不在任何一份报表里。

那有没有办法间接看出改写在变

有一个粗糙但可用的信号：看检索词的平均长度和结构。如果某个月开始，面板里的检索词普遍变长、开始出现更多限定词，多半是改写策略变了，而不是用户问法变了。用户的问法在几周内不会集体改变，模型的会。

查询变长这个趋势，8词查询暴涨7倍量过一次。

另一个信号是检索词的重复度。同一条检索词反复出现，说明模型对这类问题有了固定的检索模板；重复度突然下降，说明它开始更多地按具体语境生成。这两种状态下，你的引用机会分布是不一样的。

这两个信号都不精确，但它们至少能让你在解释一次波动时多一个候选原因。一个只有单一解释的波动，通常说明你还没看够。

我把169个DTC品牌名放进英语词表里查了一遍

讲到这儿都还是机制。下面这部分是我自己动手量的。

样本怎么来的

我手上有一批公开可访问的DTC独立站、品牌自营站和几个平台型站点，一共211个域名，逐个抓首页，从og:site_name和标题里取品牌名，取不到的用域名主体兜底，最后人工校准了58个明显提取错的。

另一种一手挖法，从日志看爬虫到底抓没抓。

校准这一步不能省。有14个站抓到的是人机验证页，标题写着“请稍候”，还有几个站的标题是“免运费”“官方网站”这种，直接拿来当品牌名就全错了。清洗环节多花的半小时，决定了后面所有数字算不算数。

那14个挡住抓取的站占抓取成功数的8.3%。它们不是坏数据，是看起来像数据的非数据——有标题、有正文、结构完整，只是内容跟这个品牌毫无关系。不做这一步清洗，我的常用词品牌名单里就会冒出“请稍候”和“安全检查”两个词条。

另一类更隐蔽：品牌名提取出来是对的，但带了尾巴。Casper Sleep、Baseus US、Nespresso China、Brompton UK，后面那个词是地区或品类后缀，不是名字的一部分。不切掉这些尾巴，多词品牌的比例会虚高，常用词命中率会虚低。

校准了58个，这个数本身说明什么

169个里改了58个，超过三分之一。这个比例高得有点吓人，但它说明的其实是另一件事：从页面上自动提取品牌名这件事，本身就不可靠。

自动识别的准确率有多虚，那个95%是自己划的及格线。

如果我这个明确知道自己要什么的人，自动提取的准确率只有三分之二，那一个通用工具在没有人工校准的情况下能有多准？这个答案我不知道，但它至少提醒一件事：别把任何自动识别出来的品牌相关数据当成精确值。

那58个改动我是逐条对着域名和页面看的，没有用任何自动规则。这是全流程里唯一一处纯手工的环节，也是最花时间的环节。数据工作里最贵的部分往往不是算，是确认。

用哪几份词表

三份公开词表：一份37万词的全量英语单词表，一份2.5万词的常用词表，一份1万词的高频词表。判定分三档，从宽到严。

词表这东西哪来的，十种挖词渠道里有更实用的来源。

第三份词表是自建的

把169个站的标题和描述合在一起，统计每个词在多少个不同的站上出现过，出现在5个站以上的留下，得到53个词。这就是这批站所在行业的品类词表。

从一个主题长出一批词，5种实战方法。

排在前面的是discover、accessories、designed、products、clothing、gear、apparel、outdoor、sustainable这些，很符合直觉。用样本自己长出来的词表，比我拍脑袋列一份要靠谱得多。

自建词表还有个副作用挺有意思：它顺带量出了这个行业的话术密度。169个站的首页标题描述里，有23个站用了discover这个词，19个用了accessories，16个用了designed。一个词能出现在四分之一的同行首页上，说明它已经不携带任何区分信息了。

这跟本文的主题没有直接关系，但它提醒了一件事：如果你的品牌名或者品牌标语里恰好含着这类高频词，那它在任何一次基于文本的识别里都会更容易撞车。

门槛为什么定在5个站

定3太松，会把一些巧合放进来；定10太严，只剩下十几个最泛的词。5这个门槛下来的53个词，肉眼扫一遍基本都认，说明它落在一个合理的位置。

阈值怎么定才有用，低竞争词挖掘的9大策略也绕不开这个问题。

这类阈值没有标准答案，我的做法是先试三个值，把结果各打印二十个词看一眼，选那个人读起来最像“这个行业的词”的。能被人一眼认出来的阈值，比一个理论上更优但结果读不懂的阈值有用。

为什么不用维基百科去判

本来的计划是查每个品牌名在维基百科上有没有同名条目、有没有消歧义页，这个判据比词表更贴近“这个词在世界上不止指你”。可惜从我的抓取环境访问不到，只好换成词表方案。

维基百科在AI推荐里的位置，别刷Reddit和维基百科了说过。

换方案是有损失的：词表能告诉你这个词是不是普通词，但没法告诉你它同时是不是另一个知名实体的名字。所以后面的数字应该理解成一个下限。

损失有多大，可以估一估。样本里像Columbia、Pandora、Weber、Philips这类，本身既是常用词又是别的知名实体，词表能抓到；而像Bershka、Cotopaxi、Kotn这种在词表里查不到、但在别处可能有同名地名或人名的，词表完全看不见。所以真实的“名字不止指你”的比例，只会比我算出来的高。

把这一层说清楚，是因为一份数据的可信度不取决于它有多干净，取决于它的脏在哪一侧。这批数字的脏全部偏保守，那结论方向就是稳的。

用了两份现成词表，一份自建

两份现成的都是公开数据。那份37万词的全量表负责回答“它是不是一个英语单词”，那份一万词的高频表负责回答“它是不是日常用语”。两份词表口径差得很远，正好用来分档。

实体这条线怎么建，AEEBM五阶段语义网络是另一套办法。

用现成词表的好处不只是省事，更重要的是可复现：任何人拿同样两份表跑同样一批品牌名，得到的结果应该一样。一个别人复现不了的数据，说服力要打对折。

怎么切词的

品牌名转小写，按非字母切成词，然后分三种口径统计：整个名字去掉空格之后是不是一个词，每个词单独看是不是普通词，以及有没有词命中品类词表。三种口径回答的问题不一样。

切词和停用词清洗，URL slug优化器里也做同样的事。

为什么整名要去掉空格再查？因为有些品牌名写成两个词，但连起来是一个词，比如Flying Tiger这类。不去空格会漏掉一批；只看去空格的结果又会漏掉像Peak Design这种两个词各自都常见的情况。所以两个口径都要跑。

撇号和连字符做了统一处理：Rothy's、Arc'teryx这类先去掉撇号再判，ice-watch这类按连字符切成两个词。这些细节看着琐碎，但它们决定了几十个样本落到哪一档，而每一档的占比都是我要报出去的数字。

没做的两件事

一是没做词形还原。Rituals这个名字我是按原样查的，没有还原成ritual。如果做了还原，常用词命中率会更高一点。不做的理由是：面板那边的匹配大概率也不做词形还原，我要模拟的是它的行为，不是语言学上的正确。

口径不同就对不上账，三家数据的对账方法。

二是没考虑大小写。所有比对都在小写下进行。这一点跟真实匹配可能有出入——有些实现会区分大小写，那样On这个词的误匹配会少很多，因为句中的on通常是小写。这是我这套测量里最大的一处不确定，它会让16% 这个数字偏高。

把这两件事写出来，是因为一个数字的可信度取决于读它的人能不能知道它是怎么算的。藏起方法的数字看起来更权威，但它经不起任何一次追问。

品牌名本身就是普通词的，占多少？

直接上数。

四个口径的结果

换个口径结论就变，3类站点的聚合流量实测也说明这一点。

怎么读这张表

六行数字里，最该先看的是第二行和第三行的差：46个能在词典里查到，27个是常用词。中间那19个是生僻词品牌，它们在绝大多数场景下不会出问题，只在特定话题下撞车。

其次看第四行和第五行的关系：64个至少有一个词是常用词，50个每个词都是常用词。这两个数挨得这么近，说明多词品牌名很少是“一个生僻词加一个常用词”的搭配，要么全是常用词，要么全不是。这大概也符合起名时的直觉——两个词的风格不统一，念起来会别扭。

最后一行的4个看着少，但它是唯一一个真正会造成品类混淆的档位，其余几档最多是被无关句子误伤。误伤是噪声，品类混淆是系统性偏差，后者要严重得多。

噪声和偏差的区别值得多说一句：噪声让你的数字上下抖，样本一大就被平均掉了；偏差让你的数字整体偏向一侧，样本再大也不会消失，反而越大越确信一个错的结论。这两样在报表上长得一样，处理方式完全相反。

16% 这个数是什么概念

169个品牌里有27个，它的名字本身就是一个英语日常词。每六个品牌里就有一个。这些名字包括：Article、Away、Canyon、Chewy、Columbia、Native、Nike、Nomad、On、Otto、Prose、Purple、Quince、Ridge、Ritual、Rituals、Seed、Weber、Yeti。

名字里塞关键词有没有用，这个问题2012年就定了。

看着这份名单会有一种熟悉感：这正是最近十几年DTC品牌起名的主流审美——短、好念、有画面感、容易注册社交账号。而这套审美恰好和“能被字符串匹配可靠识别”是矛盾的。

这个矛盾不是谁的失误。2015年前后决定叫Away的那个团队，考虑的是这个词有没有画面感、域名能不能拿到、读起来顺不顺口。当时没有任何一个理由让他们去想“十年后一个AI分析面板会不会分得清这个词”。

一个当年完全正确的决定，在一套十年后才出现的度量方式下变成了噪声来源。这类事在做数据的时候会反复遇到：你手上的历史数据，是按当时的目的攒下来的，不是按你现在的问题攒的。

单词品牌名占了四分之三

169个里129个只有一个词，占76.3%。这个比例本身就说明了起名风格的集中程度。单词名字好记、好念、logo好做，但它也意味着这个名字必须独自承担全部识别负担——没有第二个词来帮它把上下文钉死。

起名和选域名是一件事，8步决策路线。

两个词的名字在这件事上明显占便宜。Warby Parker这样的组合，两个词都不算生僻，但连在一起几乎不可能是别的意思。识别可靠性来自组合的稀有度，不是单个词的稀有度。

最极端的几个

一家跑鞋品牌叫On。两个字母，英语里最高频的介词之一。任何一条包含这个词的检索查询，从字符串上看都命中了这个品牌名。

一个词重复几次有用，答案是一次就够。

一家旅行箱品牌叫Away。一家宠物电商叫Chewy。一家床垫品牌叫Purple。一家户外品牌叫Columbia，同时还是一个国家、一所大学、一条河和一个电影公司。

把这几个放进真实的检索场景里看，问题就具体了。“best purple mattress”这条检索词，到底是在问那个叫Purple的品牌的床垫，还是在问紫色的床垫？从字符串上看没有区别，从语义上看是两回事，而打标签的那一步只看字符串。

Away更极端一点。“best carry on away from home”这样的句子在英语里再自然不过，而它包含了一个完整的品牌名。越是高频的日常词，被卷进无关句子的概率就越高，而且这个概率随检索词变长而上升。

前面说过模型改写倾向于把检索词写得更完整、更长。这两件事叠在一起的后果是：检索词越长，日常词品牌被误匹配的机会越多。而检索词变长这个趋势，最近两年一直在持续。

为什么受影响的往往是最成功的那批品牌

这一点挺讽刺。能拿到on.com、away这类域名的，往往是融资早、动作快、品牌意识强的团队；而一个短小的日常词做品牌名，本身就是一种自信的表达——我有能力让这个普通词跟我绑定。

品牌本身的问题SEO补不上，流量暴跌的7大元凶。

他们大多也确实做到了。在用户心里，Away就是那个旅行箱，Purple就是那个床垫。但在一个只做字符串匹配的系统眼里，这份认知资产完全不存在。系统看到的还是一个普通英文词。

这可能是这批数据里最值得记的一点：品牌建设的成果存在于人的认知里，而这套度量方式读不到人的认知，它只读字符。两者之间的差距，就是你在这两个数字上要打的折扣。

还有一类更隐蔽的

名字不是常用词，但由常用词组成：Peak Design、Outdoor Voices、Peak Performance、Faherty Brand。这几个的名字里直接含着这个行业的品类词。

品类词带来的流量未必是好事，信息词过大的6大危害。

Outdoor Voices这个名字，出现在一条关于户外装备的检索查询里的时候，你几乎没法判断它是在说这个品牌，还是在说“户外的声音”。只有4个品牌落在这一档，但它们受的影响是最直接的。

为什么只有4个？因为我的品类词表是从这批站的首页文案里长出来的，只有53个词，覆盖面不大。如果换一份更全的品类词表——比如从这个行业的搜索词库里长出来的——落进这一档的品牌肯定不止4个。

所以这个2.4% 要理解成一个下限里的下限。它的意义不在数值本身，在于告诉你这一档确实存在，而且判断自己在不在里面很简单：把品牌名拆成词，看有没有哪个词是你这行的常用词。

顺带一提，品牌名里含品类词在营销上其实是有好处的：用户一看就知道你是干什么的，认知成本低。这又是一个当年正确、如今变成噪声源的决定。这类取舍在这批数据里反复出现，几乎构成了一个模式。

反过来看，哪些品牌不受影响

造词类的名字完全不受这个问题困扰：Allbirds、Bellroy、Bombas、Brooklinen、Casetify、Cotopaxi、Curology、EcoFlow、Everlane、Fiskars、Glossier、Mejuri、Ruggable、Warby Parker。

品牌身份的地基怎么搭，实体主页怎么做。