favicon要上广告位，211个站有152个拿不出图标

摘要：把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的人不看广告位，而根子往往在前端构建流程上。最省事的做法是把本文那张核对表挂到发布检查清单里，让发版的人顺手跑一遍，不需要任何一方专门立项。

权威参考资料