Favicon Not Updating? Fix Browser, CDN, and Search Cache Problems

Favicons are cached aggressively and retrieved through several paths, so replacing one file does not guarantee every surface changes together. Your active tab, bookmark, home-screen shortcut, PWA installation, and search result may each use a different asset or refresh schedule.

Troubleshoot from the deployed URL outward. Randomly clearing local data first can hide the cause without fixing what visitors and crawlers receive.

Confirm what the page declares

View the server-delivered HTML and find every icon link. A basic declaration looks like:

<link rel="icon" href="/favicon-v2.png" sizes="32x32" type="image/png">

Check that the href points to the file you changed, resolves on the production hostname, returns status 200, and has a matching image content type. Open it directly in a new tab and inspect its actual dimensions.

Do not assume client JavaScript will repair the head in time for all consumers. Put stable icon declarations in the initial HTML. If multiple declarations exist, make sure an older entry is not being preferred for its size or format.

The HTML standard also allows browsers to request /favicon.ico when no declared icon is available. Many crawlers and legacy tools probe that root path anyway. Update or intentionally retain the root fallback instead of leaving an unrelated old mark there.

Change the URL when the artwork changes

If the new file uses the same URL, a browser or intermediary can reuse a cached response. A versioned filename creates a new cache key:

/assets/favicon-2026-04.png

Update the HTML reference and deploy both together. A query parameter can help in some systems, but a new filename is easier to reason about across CDNs and user agents. Keep the URL stable after the change; frequently rotating it makes crawler processing harder and defeats long-lived caching benefits.

Inspect every cache layer

Use the network panel with cache disabled and reload the page. Confirm which icon requests occur and whether they come from memory cache, disk cache, a service worker, or the network. Then check:

• CDN cache status and purge rules for the icon and HTML;
• static-site or server-rendered HTML caches containing the old link;
• service-worker precache manifests and update lifecycle;
• web app manifest icons used by installed experiences;
• bookmarks or installed shortcuts that may retain a snapshot;
• alternate hostnames such as www and the bare domain.

An incognito window is useful as a clean comparison, not proof that every public layer is correct. If incognito still receives the old file from the same URL, the stale response is probably upstream of the normal browser profile.

Separate browser icons from search icons

A correct favicon in your browser does not mean search results will update immediately. Google reads the home page icon declaration, applies its own eligibility rules, and updates after recrawling and processing. Its documentation says this can take several days to several weeks.

The search favicon must be square, crawlable, representative of the site, and served at a stable URL. Google recommends a source larger than 48 by 48 even though its documented minimum is smaller. Make sure neither the home page nor icon is blocked from the relevant crawler.

Request home-page indexing when appropriate, then wait for the crawler path rather than repeatedly changing the file. Search caches are external state; a local hard refresh cannot purge them.

Verify the whole package

Once the tab icon is current, inspect 16- and 32-pixel browser rendering, the root ICO, Apple touch icon, manifest regular and maskable icons, installed PWA, and at least one fresh browser profile. Test light and dark browser chrome for contrast.

The durable solution is a coherent asset package with explicit declarations and observable caching rules. When every layer points to the intended version, the remaining differences are refresh schedules—not a mystery in the artwork.