Google listed every favicon format. The risky change is still the URL

Implementation brief · SEO

A favicon change is a release, not a file conversion

Google now names the formats it supports. The safer response is to control the two resources Google must process and change no more identity state than the release requires.

1. The August update clarified documentationGoogle explicitly says its supported formats did not change. A new list is not evidence that a format migration will improve rankings or trigger a fresh search feature.
2. Search must process two separate objectsGooglebot reads the home page declaration; Googlebot-Image must reach the referenced file. One successful fetch cannot prove that the other half is healthy.
3. Keep the URL stable unless versioning has a jobAn in-place byte change preserves the declared identity. A new URL also changes the home-page reference and creates another state to crawl, observe and roll back.

On 28 August 2026, Google changed its favicon documentation in a way that looks more dramatic than it is. The page now names the file formats supported in Search: BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. Google's changelog immediately narrows the meaning of that list: support did not change; the documentation became explicit because its previous external reference could evolve independently.

That distinction matters. A team that treats the update as a conversion order may change an icon that already works, introduce a new asset URL, purge a CDN and request reindexing—all without gaining a new capability. The real operational question is not which extension looks newest. It is how to move one tiny identity signal through two independent fetches while preserving a clean rollback.

The useful model is a two-object release. The first object is the home page and its rel="icon" declaration. The second is the image resource named by that declaration. Google processes both on its own schedule, and even a technically eligible favicon is not guaranteed to appear. That is enough to turn a cosmetic edit into a small but real release-management problem.

The format list did not change the system

Google's changelog is unusually precise: the August revision did not add formats. It replaced an unstable external reference with an explicit list inside Search documentation. The practical value is certainty. Teams can now test their Search-facing asset against a fixed documented set rather than infer support from what a browser happens to render.

This is also a boundary. SVG and WebP do not appear in Google's listed Search favicon formats. That does not mean a browser cannot display either format in a tab or that every existing implementation will immediately fail. It means a team cannot use the updated Google documentation as support for those formats in Search results. Browser acceptance, HTML validity and documented Search eligibility are different claims.

Format is only one eligibility condition. Google also requires a square icon, at least 8 × 8 pixels, and recommends using an image larger than 48 × 48 pixels so it remains legible across surfaces. The file must represent the site's brand and avoid imagery Google considers inappropriate. Meeting every condition still does not create a display guarantee.

A favicon release has two independently crawlable objects

The home page tells Google which resource represents the site. Google accepts rel="icon", the historical shortcut icon, and Apple's touch-icon relations documented on the page. The href may be relative or absolute, and the image can live on another host such as a CDN.

The declaration is not the image. Googlebot must be allowed to crawl the home page, while Googlebot-Image must be allowed to crawl the favicon file. A successful browser request made from an editor's laptop does not test either crawler path. Nor does a valid link element prove that the image URL returns a usable response to Googlebot-Image.

Two-object release matrix

Test the declaration and the file separately

Object	Required access	Release evidence	Typical false confidence
Home page	Crawlable by Googlebot	Rendered source names the intended icon URL	The CMS settings screen shows the new image
Favicon file	Crawlable by Googlebot-Image	Final URL returns the intended square asset in a listed format	The browser tab displays a cached copy
Search result	Google must recrawl and process both states	The expected icon appears for the hostname over repeated checks	A single immediate search still shows the old icon

This separation prevents the most common debugging mistake: changing the file again because Search still shows the previous icon. The lag may sit in the home-page recrawl, the image fetch, processing, or display selection. A second uncontrolled edit erases the clean comparison and starts another observation window.

The hostname owns the icon, not the section

Google supports one favicon per site, and defines the site at hostname level. A root domain and a subdomain can have different icons. A subdirectory cannot. An editorial team may see example.com/news as a distinct publication, but Google's documented favicon unit remains example.com. The same icon applies below that host.

This turns favicon governance into information architecture. If two sections genuinely require independent identities in Search, CSS, a folder-specific theme or a second link element cannot create them. Separate hostnames can. That is a much larger architectural decision than changing an image, and it should not be smuggled into a branding ticket.

A stable URL reduces the number of moving parts

Google explicitly asks site owners not to change the favicon URL frequently. The instruction does not ban versioning. It tells us that the URL is part of the identity state, not disposable cache noise. If a team replaces the bytes at the existing location, the home page can keep declaring the same resource. Only the content behind that coordinate changes.

A versioned path—such as moving from /favicon.ico to /favicon-2026.png—can still be rational. Immutable CDN caching may make an in-place replacement unreliable. A regulated brand rollout may require an instant rollback to the previous file. Different technical owners may need an explicit asset version for change control. In those cases, the extra moving part performs a real job.

The mistake is to version by habit and then interpret the delay as a Google defect. A new path means the home page must expose a new declaration and the image crawler must fetch a new resource. The safe plan records the old declaration, the old asset and the intended rollback before release.

Use a preflight, release and observation window

• Preflight the host: confirm which hostname owns the Search identity and remove any assumption that a folder can have its own favicon.
• Preflight the file: verify a listed format, 1:1 dimensions, sufficient size, correct response and representative artwork.
• Test crawler access: confirm the home page is not blocked for Googlebot and the image is not blocked for Googlebot-Image, including on a CDN.
• Choose the URL policy: prefer the existing stable URL unless caching, rollback or governance provides a concrete reason to version it.
• Capture the release state: save the declaration, image URL, response details, dimensions, checksum and deployment time.
• Request home-page indexing: use URL Inspection after the live source and file have been verified.
• Wait without thrashing: Google says recrawling and processing can take several days to several weeks. Observe the declared state before starting another change.

This resembles the origin-acceptance discipline in our analysis of Google's direct-host AMP change: once an intermediary disappears or a resource boundary becomes explicit, the publisher has to test the actual origin objects rather than infer health from a surface preview. It also complements our Search Profiles identity-governance model. The profile article concerns a multi-editor identity record; the favicon problem is narrower and more mechanical, but both punish teams that mistake a visible symbol for a single owned field.

Diagnose the layer that failed before changing the icon again

Failure isolation

Four different problems can look like one stale favicon

Observed state	Likely layer	Next check
Live source declares the previous URL	Template, cache or deployment	Fix the home-page output before requesting indexing
New URL returns an error or wrong bytes	Image origin or CDN	Correct the asset response and crawler access
Both live objects are correct, Search is stale	Recrawl or processing delay	Preserve the release and observe within Google's stated window
Eligible icon never appears consistently	Search display selection	Reconfirm guidelines; do not claim eligibility guarantees display

The smallest icon on the result page deserves a small, disciplined process. Google's new list removes ambiguity about formats. It does not remove hostname scope, crawler separation, processing latency or display discretion. A good migration changes the fewest independent states, preserves the old state long enough to roll back and waits for evidence before touching the asset again.

Questions about Google Search favicons

Primary sources

Google and standards material checked 4 September 2026

1. Google Search Central: Latest documentation updates — the 28 August 2026 entry states that the favicon format list is an explicit documentation clarification and support did not change.
2. Google Search Central: Define a favicon to show in search results — implementation, hostname scope, crawler access, dimensions, formats, URL stability, processing time and non-guaranteed display.
3. HTML Living Standard: link type icon — the web-platform semantics behind rel="icon".