SEO2026第241期 | 谷歌8月28日文档更新解读!

索未 · SEO ｜ SEO 深度解读

SEO 自动化实践 · 索未

Google Search Central 在 2026 年 8 月 28 日更新了 favicon 官方文档。

表面看，这次变化很小。

Google 只是第一次在 favicon 文档中直接写明，Google Search 当前支持的 favicon 文件格式为：

BMP、GIF、ICO、PNG、JPEG、PPM、TIFF。

但如果只把这次更新理解成"Google 公布了 7 种 favicon 格式”，其实低估了它的意义。

Google 自己特别强调：

Google Search 实际支持的文件格式并没有发生变化。

变化的是文档。

过去 Google favicon 指南依赖一个会持续变化的外部文件格式参考，现在 Google 把 Search 真正接受的格式直接固定写进自己的官方文档，从而消除了一个长期存在的技术歧义。

所以，这不是一次算法更新，也不是 Google 突然增加或删除某种 favicon 能力。

更准确的理解应该是：

这恰恰是此次更新最值得 SEO、开发和企业网站运营团队关注的地方。

· · ·

Google Search Central 的 Documentation Updates 在 8 月 28 日明确记录：

"Updated the favicon documentation"。

Google 给出的"What"是：更新 favicon 文档，直接列出支持的 favicon 文件格式。

给出的"Why"则更加重要：此前文档链接到一个会随时间演变的外部参考，从而对"Google Search 究竟支持哪些 favicon 格式”造成歧义。因此 Google 决定直接在自己的 Search 文档中列明范围。

Google 随后再次强调：

Search 支持的文件格式本身没有发生改变。

目前最新版 favicon 文档明确写出的格式是：

BMP、GIF、ICO、PNG、JPEG、PPM、TIFF。

同时，当前文档最后更新时间已经标记为 2026-08-28 UTC。

这意味着我们首先应该把事件分类准确。

它不是：

"Google August Favicon Update"；

不是新的 ranking update；

不是 favicon ranking factor 上线；

不是 Google 图片抓取系统升级；

也不是 SVG、WebP 或 AVIF 被 Google“处罚”。

它应该被归类为：

Official Documentation Update。

这与本项目对 Google 更新事件的分类原则一致：只有 Google 明确确认的 Ranking Event，才能称为官方排名更新。

· · ·

过去 favicon 问题最大的技术误区之一，是把几个完全不同的问题混在一起：

浏览器是否可以显示这种图片？

HTML 标准是否允许这种资源？

WordPress 是否允许上传？

CDN 是否能够转换？

Google Images 是否能够索引？

Google Search 是否会把它作为搜索结果 favicon 处理？

这些并不是同一个问题。

这次文档更新最大的价值，就是把最后一个问题单独划出了技术边界。

Google 普通图片搜索目前支持的图片格式包括：

BMP、GIF、JPEG、PNG、WebP、SVG、AVIF。

但是 Google Search favicon 当前明确列出的却是：

BMP、GIF、ICO、PNG、JPEG、PPM、TIFF。

两个集合明显不同。

尤其值得注意的是：

WebP、SVG、AVIF 出现在 Google 普通图片支持列表中，却没有出现在当前 Search favicon 支持列表中。

反过来：

ICO、PPM、TIFF 出现在 favicon 列表中，却不是普通图片 SEO 指南当前列出的全部对应集合。

这说明一个非常重要的 Technical SEO 原则：

Search 中的不同产品表面可能都在处理“图片”，底层却可能拥有不同的抓取、解析、缓存、验证和展示管线。

因此，做 SEO 不能只问：

“这种格式 Google 支持吗？”

更准确的问题应该是：

"Google 的哪个产品、哪一个 Search Feature、在哪一种输入场景下支持这种格式？”

这是此次小型文档更新背后非常有价值的方法论。

· · ·

这很可能与今天的网站技术栈越来越复杂有关。

现代网站已经很少只是：

HTML + JPEG + favicon.ico。

现在一个普通 WordPress 企业站就可能同时存在：

WordPress Site Icon；

主题 favicon 配置；

SEO 插件输出；

CDN；

Cloudflare；

WebP 自动转换；

AVIF 自动转换；

SVG Logo；

缓存插件；

前端优化插件；

Head 标签优化；

第三方静态资源域名。

对于浏览器而言，一个 SVG 或 WebP favicon 可能完全能够正常显示。

于是开发人员很容易得出一个直觉判断：

“浏览器正常，所以 Google 也应该正常。”

但 Search 不是浏览器。

Google Search 结果中的 favicon 属于 Google 自己抓取、处理并重新展示的一类搜索资产。

如果官方文档继续依赖一个不断扩大的通用文件格式参考，就可能出现：

外部标准已经支持 → 浏览器已经支持 → 开发人员认为 Google Search 也支持

这样的错误推导。

8 月 28 日 Google 实际上切断了这条推导链。

从此以后，Search favicon 应该按照 Search favicon 自己的文档判断，而不是按照通用图片生态判断。

· · ·

这次更新最容易产生的另一个误解，是把所有 Search 变化都转化成“排名优化机会”。

目前没有 Google 官方证据表明：

使用 PNG 比 SVG 能够提高排名；

更换 favicon 能够增加页面权重；

favicon 尺寸能够影响 Core Ranking；

设置 favicon 能够提高 AI Overview 引用概率。

这些说法都超出了官方证据。

Google 当前的表述是：

如果网站拥有符合要求的 favicon，它可以被包含在该网站的 Google Search 结果中。

Google 同时明确强调：

即使完全符合指南，也不能保证 favicon 一定会出现在 Search 结果中。

所以 favicon 最准确的 SEO 定位不是：

Ranking Signal。

而是：

SERP Brand Asset。

它和站点名称、域名、标题、摘要、图片缩略图等一起，参与用户看到一个搜索结果时的来源识别。

这意味着它的主要价值发生在：

Recognition，而不是 Ranking。

对于企业站、品牌站和外贸独立站尤其如此。

当一个海外采购用户同时看到制造商官网、Alibaba 页面、Amazon 页面、行业目录、经销商和竞争品牌时，用户实际上正在快速进行一次“来源判断”。

favicon 不会决定 Google 把谁排第一。

但一个长期显示默认地球图标、模糊旧 Logo 或者完全错误品牌图标的网站，会降低搜索结果的品牌识别质量。

这更适合被定义为：

SERP Brand Hygiene——搜索结果品牌资产卫生管理。

· · ·

此次格式更新并不是孤立规则。

把最新版 favicon 文档整体放在一起看，Google 实际上已经形成了一套相当清楚的输入规范。

首先，favicon 必须是1:1 正方形。

最低允许尺寸为 8×8px，但 Google 强烈建议使用至少 48×48 级别的高分辨率 favicon，以保证它在不同 Search 界面上的显示质量。

对于企业网站而言，没有必要把 8×8 这种最低兼容门槛当成生产标准。

实际部署应优先使用清晰、高分辨率的正方形品牌图标。

第二，Google Search 按照hostname划分 favicon。

例如：

example.com

和：

news.example.com

属于不同 hostname，因此理论上可以分别拥有 favicon。

但：

example.com/en/

example.com/de/

example.com/products/

依然属于同一个 hostname 下面的不同路径。

Google 不会因此为每个目录维护一套独立的 Search favicon。

这对多语言外贸独立站尤其重要。

如果企业采用：

example.com/en/

example.com/fr/

example.com/de/

这样的语言目录架构，不应该期待 Google Search 给三个语言目录分别展示三种不同品牌图标。

而：

de.example.com

和：

us.example.com

因为是不同 hostname，则属于不同 favicon 边界。

但显然，不应该为了 favicon 而改变已经合理运行的国际 SEO 域名架构。

· · ·

Google 现在明确要求：

Googlebot-Image 必须能够抓取 favicon 文件。

同时：

Googlebot 必须能够抓取网站首页。

这里有一个非常重要的诊断思路。

当 Search 结果 favicon 异常时，不能只检查：

“图片 URL 浏览器能不能打开？”

应该同时检查两个对象：

首页；

favicon 资源。

也就是说，这是一个双入口问题。

例如：

首页可以正常抓取，但 Cloudflare 对图片路径设置了防盗链；

favicon 可以访问，但首页被 robots.txt 阻挡；

图片 CDN 对 Googlebot-Image 返回 403；

资源 URL 需要临时 Token；

WAF 错误识别 crawler；

favicon 最终返回的是 HTML 错误页；

源站返回 200，但 CDN 区域节点返回异常。

这些问题对于正常浏览用户可能完全不可见。

但对 Search favicon 处理流程而言，都可能造成失败。

所以一个成熟的 favicon 审核不能停留在：

“我自己浏览器打开正常。”

应该升级成：

Google 能不能持续、稳定地重新获取这个资源？

· · ·

Google 还特别要求：

favicon URL 应保持稳定，不要频繁修改。

这一点对现在大量自动化部署的网站尤其重要。

一些前端构建系统或媒体优化系统可能不断产生：

favicon-v11.png

favicon-v12.png

favicon-final.png

favicon-new-202608.png

甚至：

带 hash 的构建资源 URL。

对浏览器来说，这种版本化没有什么问题。

但 favicon 属于一个 Google 需要：

发现 → 抓取 → 处理 → 更新 Search 展示

的资源。

Google 明确表示，修改 favicon 后，重新抓取和处理可能需要数天到数周，取决于系统判断首页需要被重新刷新的频率。

因此：

今天修改 favicon，明天 Google 仍然显示旧图标，并不能证明配置失败。

反过来，如果自动部署系统每几天又换一个 favicon URL，就会持续增加 Search 重新发现和重新处理的不确定性。

这也是为什么：

稳定 URL 应该被视为品牌 Search 资产的一部分。

· · ·

Google 明确允许 favicon 使用绝对 URL，并且 favicon不需要与网站托管在相同域名。

例如完全可以使用 CDN。

这对于 Cloudflare、对象存储、静态资源 CDN 和 Headless 网站来说非常实用。

但是这项能力也容易被误用。

如果 favicon 放在：

短期签名 URL；

会过期的 Token URL；

需要 Cookie 授权的资源；

严格 Referer 防盗链；

动态生成 URL；

临时对象存储地址，

那么今天 Google 可能能够访问，下一次重新抓取时却可能失败。

因此生产环境更合理的设计不是：

"favicon 在哪都可以。”

而是：

· · ·

对于普通 WordPress 管理员来说，favicon 似乎只是后台“站点图标”上传一次的问题。

但真实环境往往比这复杂得多。

主题可能输出一套 favicon；

WordPress Core 可能输出 Site Icon；

页面构建器可能再次添加；

性能插件可能重写图片 URL；

CDN 可能转换格式；

缓存层可能保留旧 head；

开发人员可能同时保留：

rel="icon"

和旧的：

rel="shortcut icon"

甚至同时存在多个指向不同文件的 favicon 声明。

Google 目前支持的rel值包括：

icon

历史兼容的shortcut icon

以及：

apple-touch-icon

和：

apple-touch-icon-precomposed。

真正应该检查的，不是 WordPress 后台“看起来设置了没有”。

而是最终生产页面 HTML 里：

Google 实际能够发现什么。

尤其应该关注图片优化插件是否把唯一 favicon 自动改成了：

WebP；

SVG；

AVIF。

这里必须保持准确的事实边界：

不能因此写成：

"Google 禁止 SVG favicon。”

也不能写成：

"WebP favicon 一定不会显示。”

我们能够依据当前官方文档确认的是：

Google Search 当前明确列出的 favicon 支持格式中没有 SVG、WebP 和 AVIF。

因此从企业生产环境的风险管理角度，最稳妥的方法显然是：

使用 Google 明确列出的格式。

对于绝大多数网站，PNG 或者 ICO 已经足够。

· · ·

这是一个典型的“工程效率”和"Search 可靠性”取舍问题。

favicon 文件本身通常非常小。

因此把一个几十 KB 甚至更小的 favicon：

PNG → WebP → AVIF

所获得的实际性能收益往往极其有限。

但如果这种转换增加了：

Search 兼容性不确定性；

CMS 兼容问题；

CDN 转换风险；

缓存复杂度；

多浏览器 fallback；

Google 重新处理异常，

那么整个优化就是典型的：

局部最优，系统复杂度上升。

这也提醒 SEO 团队：

并不是所有资源都应该机械追求最新格式。

Hero 大图、产品图、内容图片和 favicon 的工程目标并不完全相同。

对于 favicon 而言：

稳定、可抓取、可识别、兼容性高

往往比多节省几 KB 更有价值。

· · ·

外贸独立站面对的是一个非常典型的 SERP 环境：

一个采购 Query 下面可能同时出现：

品牌官网、竞争企业、Alibaba、Amazon、行业目录、经销商、媒体以及搜索平台自身功能。

对于知名品牌，用户已经能够依靠品牌名称完成识别。

但对于大多数 B2B 制造商而言，品牌本身并没有那么强的认知基础。

用户实际上会同时依赖：

站点名称；

favicon；

域名；

页面标题；

摘要；

页面内容

判断某一个结果究竟是不是自己想找的供应商。

所以 favicon 虽然小，却是搜索结果中极少数直接代表网站身份的视觉资产之一。

如果一个制造企业投入大量预算建设：

品牌 Logo；

网站；

产品摄影；

展会；

Google Ads；

SEO 内容；

视频；

社交媒体，

却让 Google 自然搜索结果长期显示：

默认图标；

旧品牌；

模糊图标；

错误子品牌，

这显然属于品牌资产管理上的缺口。

因此此次更新给外贸企业的最佳行动不是：

“赶紧换 favicon 提升 SEO。”

而是：

把 favicon 纳入企业 Search Brand Asset 的常规技术检查。

· · ·

如果一个企业只运营一个网站，这个问题非常简单。

但今天不少企业同时运营：

企业官网；

产品品牌站；

国家站；

行业专题站；

内容站；

活动站；

旧站；

测试站。

这时候 favicon 问题就变成一个资产治理问题。

尤其容易出现：

新站复制了旧站模板，favicon 仍然是旧 Logo；

多个品牌使用同一个默认图标；

网站换品牌一年后 Search 仍出现旧视觉；

子域名沿用了错误业务 Logo；

staging 模板资源被部署到 production；

CDN 清缓存后 favicon 回退。

Google 用 hostname 作为 favicon 边界，实际上给企业提供了一个很清晰的治理单元。

企业完全可以建立：

Hostname → Brand → Favicon URL → File Format → Crawl Status → Last Verified

这样的 Search Asset Registry。

这就是此次更新可以进一步转化成自动化工作的地方。

· · ·

favicon 是一类非常适合自动检查的 Technical SEO 资产。

因为绝大多数条件都可以客观验证。

一个自动化 Technical SEO Agent 完全可以定期抓取首页，解析<head>中的 favicon 声明，然后检查资源最终 URL、HTTP 状态、文件类型、图片尺寸、宽高比、robots 访问规则、URL 变化历史，以及多个 hostname 之间是否出现异常重复。

这比让 SEO 人员每个月手工打开几十个网站确认 favicon 高效得多。

更重要的是：

自动化的目标不应该是“自动修改”。

而应该是：

自动发现 → 自动验证 → 生成证据 → 人工决定是否修改。

例如系统可以输出：

favicon_format_not_officially_listed

favicon_http_error

favicon_ratio_invalid

favicon_url_changed

favicon_blocked_by_robots

multiple_conflicting_favicon_declarations

然后进入 Technical SEO 审核队列。

这比简单写一句“检查 favicon"更具有实际运营价值。

· · ·

企业可以把这次 Google 更新直接转化成以下一次性审计，并进一步自动化：

1. 查看生产环境首页最终 HTML，确认<head>中存在有效 favicon 声明，而不是只检查 CMS 后台。
2. 解析最终 favicon URL，并确认其文件格式属于 Google 当前明确列出的 BMP、GIF、ICO、PNG、JPEG、PPM、TIFF。
3. 检查图像为 1:1 正方形，实际生产环境优先使用 48×48 以上的高质量版本。
4. 直接访问最终资源，确认持续返回有效图片资源，而不是 403、404、HTML 错误页、登录页或临时签名 URL。
5. 检查 robots.txt、CDN、WAF 和图片防盗链，确保 Googlebot-Image 可以抓取 favicon，同时 Googlebot 可以访问首页。
6. 检查 favicon URL 是否长期稳定，避免无必要的版本号、随机 hash 或频繁更换。
7. 对多站点企业按照 hostname 逐一检查，避免模板复制造成品牌 favicon 错误。
8. 修改后对首页进行 Search Console URL Inspection，并给 Google 数天到数周重新抓取和处理，而不是第二天就判断成功或失败。

如果以上项目都正常，就没有必要因为 8 月 28 日的文档更新重新部署 favicon。

· · ·

从 SEO 角度看，此次更新的直接影响非常明确：

它属于搜索结果外观与品牌资产可靠性。

但从 GEO 和 AI Search 角度，必须更加谨慎。

目前没有这次官方文档更新提供的证据可以证明：

favicon 影响 AI Overviews 排名；

favicon 影响 AI Mode 来源选择；

favicon 影响生成式回答引用；

favicon 影响品牌 Mention Rate；

favicon 影响 Citation Rate。

因此，不能因为今天强调 GEO，就强行给 favicon 增加一个"AI 搜索排名意义”。

更合理的项目判断是：

一个企业应当保持品牌名称、网站名称、Logo、favicon 和域名等品牌资产一致，这是良好的 Entity 与 Brand Governance。

但：

“品牌资产一致性是好的信息架构实践”与"favicon 会提升 AI 引用”是两件不同的事。

后者目前没有官方证据。

这正是 SEO/GEO 研究中必须长期坚持的边界。

· · ·

如果把这次更新继续向上抽象，会发现一个比 favicon 更重要的问题：

Documentation Change 不等于 System Change。

Google 经常会更新文档。

但文档更新可能代表完全不同的事情：

一种情况是产品真的发生变化；

一种情况是 Google 开始支持新的 Search Feature；

一种情况是政策发生改变；

还有一种情况只是——

原有行为终于被写清楚。

2026 年 8 月 28 日 favicon 属于最后一种。

Google 明确告诉我们：

系统支持范围没有变化，只是以前文档引用方式会导致歧义。

所以建立 SEO Intelligence 系统时，不应该看到：

"Google updated documentation"

就立即生成：

"Google 重大 SEO 更新！”

真正专业的自动化系统应该继续判断：

Behavior Changed？

Documentation Changed？

Policy Changed？

Eligibility Changed？

Ranking System Changed？

Only Wording Changed？

这比每天多抓几十条 Google 更新信息更加重要。

· · ·

这里还需要修正一个容易混淆的时间事实。

2026 年 8 月 28 日并不只有 favicon 文档变化。

Google Search Central 同日还更新了 Site Reputation Policy，并发布了对应博客文章，涉及欧洲经济区 EEA 的执法方式调整。

这与 favicon 不是同一个事件。

因此 8 月 28 日的 Google 变化至少应该拆成两个独立 Research Item：

favicon documentation clarification

以及：

site reputation policy update

前者属于低风险 Technical/Search Appearance 文档澄清；

后者属于 Spam Policy / Enforcement 层面的独立政策事件。

两者不能合并成所谓"8 月 28 日 Google 算法更新”。

截至当前核验时点，Google Search Status Dashboard 显示 No incidents，没有对应的 Crawling、Indexing、Ranking 或 Serving 事故。

· · ·

如果你的网站已经：

使用 PNG 或 ICO 等明确支持格式；

favicon 清晰；

Google 可以抓取；

URL 长期稳定；

Search 结果正确显示；

那么这次更新基本不需要任何动作。

不需要因此重写文章。

不需要修改页面标题。

不需要重新设计网站信息架构。

不需要增加 Schema。

不需要把整个网站重新提交索引。

更不能发布诸如：

"Google 更新 favicon 算法，网站必须立即整改”

这样的标题。

因为 Google 已经明确说明：

支持能力没有改变。

真正发生变化的，是官方文档终于把边界写清楚了。

· · ·

从 SEO 运营体系角度，我更建议把 favicon 重新定义为：

Search Brand Asset。

以后 Technical SEO 审核不应该只覆盖：

robots.txt；

canonical；

sitemap；

status code；

structured data；

hreflang；

Core Web Vitals。

还应该逐步覆盖搜索结果中真正暴露给用户的品牌资产：

favicon；

site name；

logo；

preferred image；

页面标题；

snippet；

品牌 hostname 一致性。

因为现代 SEO 已经不仅是在管理“一个页面能不能被索引”。

还需要管理：

favicon 只是其中很小的一部分。

但它非常适合作为"Search Asset Governance"的起点。

· · ·

Google Search Central 2026 年 8 月 28 日 favicon 文档更新规模并不大。

但它解决了一个真实存在多年的技术歧义。

Google 现在直接明确：

Google Search favicon 支持 BMP、GIF、ICO、PNG、JPEG、PPM 和 TIFF。

同时 Google 也明确：

实际支持格式没有改变。

因此它不是算法更新，不是排名系统变化，也不是新的 SEO 增长机会。

真正值得企业采取的行动只有一个：

借这次官方澄清，对自己的 favicon 进行一次标准化技术检查。

确认：

格式明确；

比例正确；

资源可抓取；

URL 稳定；

hostname 关系正确；

品牌表达一致。

如果已经全部正常，就什么都不用改。

如果存在问题，就把它修正。

SEO 成熟度不只体现在能不能追踪 Google 大型 Core Update。

也体现在面对这样一条很小的文档更新时，我们能不能准确判断：

什么变了。

什么没有变。

什么值得行动。

什么只是噪音。

这才是 SEO Intelligence 真正应该自动化的能力。

· · ·

本文以 Google 官方原始来源为主要证据，并对所提供研究底稿进行了二次核验。底稿已经正确识别此次更新属于 favicon 技术文档澄清，而非排名更新。

Google Search Central — Latest documentation updates，8 月 28 日记录"Updated the favicon documentation"，并说明实际支持格式没有变化。

Google Search Central — Define a favicon to show in search results，当前列出 BMP、GIF、ICO、PNG、JPEG、PPM、TIFF，以及 hostname、尺寸、抓取和 URL 稳定性规则。

Google Search Central — Image SEO Best Practices，用于区分普通 Google 图片索引支持格式与 Search favicon 支持范围。

Google Search Central Blog — Update to the Site Reputation Policy，用于确认 8 月 28 日同日存在另一项独立 Google Search 政策更新。