If your browser tab has the right icon but Google still shows a globe, a generic symbol, or an old logo, do not keep clearing your browser cache. Google Search has its own discovery and processing path.
The practical fix is to make sure your homepage declares one stable, square, crawlable icon, verify that both the homepage and image return valid responses to Google, then request a recrawl of the homepage. Google says processing can take several days to several weeks, and meeting every requirement still does not guarantee that an icon will appear.
Start with these checks:
- Open the exact hostname that appears in Search, such as
https://www.example.com/rather thanhttps://example.com/. - Confirm its rendered
<head>contains a valid<link rel="icon">. - Open that link's resolved URL in a private window and confirm it returns the image, not an HTML error page.
- Use a square file that is at least 8x8 pixels; Google recommends a file larger than 48x48 pixels.
- Allow Googlebot to crawl the homepage and Googlebot-Image to crawl the icon.
- Keep the icon URL stable after publishing.
- Inspect and request indexing for the homepage in Google Search Console.
Those rules come directly from Google's current favicon documentation for Search results. The rest of this guide shows how to prove each one instead of guessing.
This guide is for site owners and developers whose public Google result is missing or showing the wrong icon. If the problem exists only in a browser tab, start with the live favicon test instead; browser cache troubleshooting and Google reprocessing are different jobs.
Why the tab icon and Google icon can disagree
A browser can reuse an icon it cached weeks ago. It may also request /favicon.ico automatically even when the page has no icon declaration. Neither behavior proves that Google's crawler found a valid declaration on the correct homepage.
Google evaluates a longer chain:
A crawlable page declares the icon in its rendered head.
The href resolves to a stable, public URL on the same host or a CDN.
The file returns 200, a valid image type, and square pixels.
Google recrawls both resources, then decides whether to show it.
This distinction prevents the most common debugging mistake: changing image files repeatedly when the real problem is the homepage, hostname, response headers, or crawl access.
Google's requirements, translated into tests
| Requirement | What it means in practice | How to verify it |
|---|---|---|
| Declaration on the homepage | Put the icon link in the <head> of the root page for that hostname. | View the rendered HTML and find rel="icon". |
| One icon per hostname | example.com and shop.example.com can have different icons. /store/ and /blog/ on one hostname cannot. | Test the exact hostname shown in the result. |
| Crawlable resources | Googlebot must reach the homepage; Googlebot-Image must reach the file. | Check robots.txt, authentication, WAF rules, and server logs. |
| Square image | Width and height must match. The minimum is 8x8; larger than 48x48 is recommended. | Inspect the actual file dimensions, not the filename. |
| Supported image | Serve a real favicon image in a supported format. | Fetch the URL and inspect Content-Type and file bytes. |
| Stable URL | Do not rotate fingerprinted icon URLs on every build. | Use a durable path such as /favicon.png. |
| Representative artwork | The icon should visually represent the site and comply with Google's policies. | Preview it at small sizes and avoid misleading imagery. |
An older rule often repeated online says dimensions must be multiples of 48. That is not the wording in Google's current guidance. The current recommendation is simply larger than 48x48 pixels, while the image must remain square.
Step 1: diagnose the exact Search hostname
Write down the URL shown under the result. These are different favicon owners:
https://example.com/https://www.example.com/https://docs.example.com/
Google supports one icon per hostname, not one icon per URL path. A declaration on example.com/blog/ does not create a separate blog icon, while a declaration on docs.example.com/ can.
If http://example.com/ redirects to https://www.example.com/, perform every remaining check on https://www.example.com/. Also make sure the redirect ends on a page that contains the declaration; a perfect icon tag on an abandoned origin does not help the final host.
Step 2: put a clear declaration on the homepage
A dependable PNG declaration looks like this:
<head>
<link rel="icon" type="image/png" sizes="64x64" href="/favicon-64x64.png" />
</head>
An ICO fallback can coexist with it:
<link rel="icon" href="/favicon.ico" sizes="any" />
<link rel="icon" type="image/png" sizes="64x64" href="/favicon-64x64.png" />
Use rel="icon", not the obsolete rel="shortcut icon" spelling. The HTML standard's icon link type and MDN's rel reference explain how browsers select among multiple candidates.
Three details matter:
hrefmust resolve from the final homepage URL. A leading slash starts at the host root.typeshould match the file you actually return, such asimage/png.sizesdescribes the intrinsic pixels inside the file. It does not resize an image.
Do not rely exclusively on a JavaScript click handler or a tag inserted only after user interaction. Put the declaration in the server-rendered or statically generated homepage <head> whenever your stack allows it.
See what the delivered page contains
Browser “View Source” is useful for server-rendered markup. DevTools Elements shows the post-JavaScript DOM. Check both when a framework or tag manager modifies metadata.
From a terminal:
curl -Ls https://www.example.com/ | grep -iE 'rel=["'"'](shortcut )?icon|apple-touch-icon'
If that command returns nothing but DevTools shows an icon, the tag is client-injected. That may work in browsers, but server-rendering it removes a needless discovery dependency.
Step 3: resolve the URL exactly as a crawler does
Relative paths are resolved against the page URL, not your project folder. On https://example.com/guides/setup/:
| Markup | Resolved URL |
|---|---|
href="/favicon.png" | https://example.com/favicon.png |
href="favicon.png" | https://example.com/guides/setup/favicon.png |
href="../favicon.png" | https://example.com/guides/favicon.png |
href="https://cdn.example.net/favicon.png" | The exact CDN URL |
Google allows relative or absolute icon URLs. A CDN URL is fine when both resources are publicly crawlable, but it adds another DNS, access-control, and caching surface. For most sites, a root-relative path is easier to keep stable.
Paste the resolved icon URL directly into a private window. Then inspect it without relying on a HEAD request alone:
curl -sS -D - -o /tmp/site-favicon.png https://www.example.com/favicon-64x64.png
file /tmp/site-favicon.png
You want:
- A final
200 OKresponse - An image content type, not
text/html - File bytes that
filerecognizes as the expected image format - Equal width and height
A server may reject HEAD while serving GET correctly, so a failed curl -I is a clue, not a verdict. Test the same request method a real fetch uses.
Step 4: rule out soft 404s and SPA fallbacks
The most deceptive failure is a URL that returns 200 with your app's HTML shell. In a browser tab it may look blank; in a network panel the request looks “successful.” Check the response body and header together.
Bad response:
HTTP/2 200
content-type: text/html; charset=utf-8
<!doctype html><html>...
Good PNG response:
HTTP/2 200
content-type: image/png
Good ICO response:
HTTP/2 200
content-type: image/x-icon
Common sources of a soft 404 include an SPA catch-all rewrite, an asset omitted from the production build, case-sensitive filenames on Linux, and a CDN rule that routes unknown files back to /index.html.
Step 5: check robots, authentication, and firewalls
Google's documentation names two crawl requirements:
- Googlebot must be able to crawl the homepage.
- Googlebot-Image must be able to crawl the favicon file.
Review https://www.example.com/robots.txt. A broad rule such as this blocks the entire site:
User-agent: *
Disallow: /
A more subtle rule can block an asset folder:
User-agent: Googlebot-Image
Disallow: /assets/
Also check controls outside robots.txt:
- Staging authentication accidentally left on the production homepage
- A WAF challenge shown to crawlers or unfamiliar regions
- Hotlink protection on the CDN host
- Signed URLs that expire
- Geo-blocking or IP allowlists
- A
noindexdirective on the homepage
Do not imitate Googlebot with a user-agent string and assume the result is conclusive. WAFs evaluate more than one header. Search Console's URL Inspection result and origin/CDN request logs are better evidence.
Step 6: inspect the artwork, not just the filename
Google requires a square file. It does not make a wide wordmark readable by squeezing it into a square canvas.
A durable search icon usually has:
- A simple symbol or one-letter monogram
- Strong contrast on light and dark result backgrounds
- Enough internal spacing that edges do not blur together
- No tiny tagline or thin hairline detail
- A transparent or intentional solid background
Preview the file at 16, 32, 48, and 64 pixels. If it only becomes recognizable when enlarged, simplify it before debugging the crawler. Our square logo design guide includes a practical safe-area workflow, and the transparent versus solid background guide covers edge cases around contrast.
Step 7: stop changing the URL while Google processes it
Hashed assets are useful for application bundles, but an icon path that changes from /favicon.a19c.png to /favicon.4d02.png on every deploy gives crawlers a moving target. Prefer a stable URL such as:
https://www.example.com/favicon.png
When the artwork truly changes, update the file at that stable path and purge the CDN. You may temporarily add a version query while testing in browsers, but Google's guidance specifically asks for a stable URL, so do not keep rotating query strings as a long-term search fix.
Caching still matters at the origin and CDN. Check the live response:
curl -sS -D - -o /dev/null https://www.example.com/favicon.png
Look for age, cache-control, etag, last-modified, cf-cache-status, or an equivalent vendor header. A CDN can correctly return 200 while still serving yesterday's pixels. Purge the single asset after a redesign, then leave its URL alone.
Step 8: request a homepage recrawl
Once the live checks pass:
- Open Google Search Console for the exact property and hostname.
- Use URL Inspection on the homepage URL.
- Review whether the page is indexable and the live test can fetch it.
- Choose Request indexing.
- Wait without repeatedly replacing the icon or declaration.
Google states that favicon processing can take several days to several weeks. A recrawl request is not an instant refresh button, and submitting the image URL in a sitemap is not a substitute for the homepage declaration.
If Google still shows the old icon
Use this order; it separates cached observations from live evidence.
- Download the icon URL with a fresh query locally. Compare the bytes or checksum with the intended file.
- Check the CDN and origin separately. An edge purge may not update an origin that still contains the old image.
- Inspect the final homepage after all redirects. Confirm its tag references the intended stable URL.
- Check Search Console's last crawl date. If the homepage has not been crawled since the change, the old result is expected.
- Wait through the documented processing window. A correct implementation can remain visually stale while Google reprocesses it.
Avoid adding five duplicate tags that all point to different versions of the logo. More declarations make selection harder to reason about. Keep a deliberate set: usually one ICO fallback, one clear square PNG or SVG for browsers and Search, and an Apple touch icon for saved iOS shortcuts.
Browser works, Google fails: a decision table
| Observation | Most likely explanation | Next action |
|---|---|---|
| Tab works, source has no icon link | Browser guessed /favicon.ico or used cache. | Add an explicit homepage declaration. |
Tab works on www, result uses apex | You tested a different hostname. | Audit the hostname displayed by Google. |
| Icon URL opens, but reports HTML | An app fallback returned a soft 404. | Exclude static assets from the fallback rewrite. |
| File and markup are correct, changed yesterday | Google has not reprocessed it. | Request homepage indexing, then wait. |
| PNG is square but logo looks blank | Artwork is too fine or has weak contrast. | Simplify and preview at small sizes. |
| Search Console live test is blocked | Robots, authentication, or WAF is interfering. | Fix crawl access before touching artwork. |
| Different pages appear with different icons | Cached results or multiple hostnames are involved. | Compare result hostnames and declarations. |
Framework and platform checkpoints
The search requirements stay the same; only the place you configure them changes.
Next.js App Router
Use the App Router file conventions (app/favicon.ico, app/icon.png, and app/apple-icon.png) or the Metadata API. Do not mix several systems until you understand the tags each emits. See the tested Next.js icon setup.
Plain HTML and static-site generators
Place files in the published output, use root-relative paths, and put declarations in the shared layout's <head>. The complete HTML installation guide includes a file tree and manifest example.
WordPress
Set the Site Icon in the platform UI first, then inspect the final homepage for theme or caching-plugin overrides. Follow our WordPress favicon guide rather than editing a theme file that an update may replace.
Shopify, Squarespace, and Wix
Use each platform's icon setting, publish the change, then inspect the public custom domain rather than an editor preview. We maintain separate guides for Shopify, Squarespace, and Wix.
A five-minute release check
Run the site's URL through the Favicon Checker, but treat any automated score as a starting point. Then verify the Google-specific items manually:
- The final Search hostname's homepage returns 200 and is indexable.
- Its rendered
<head>contains a validrel="icon"link. - The resolved image URL returns 200 to a normal GET request.
- Response bytes are an image and
Content-Typematches the format. - Intrinsic dimensions are square and comfortably larger than 48x48.
- Googlebot can crawl the homepage.
- Googlebot-Image can crawl the file.
- The artwork is recognizable at small size.
- The URL is stable and the CDN has the current file.
- The homepage was submitted for recrawling after the fix.
For a broader prelaunch pass that includes Apple icons, manifests, and caching, use the favicon launch checklist.
Frequently asked questions
How long does it take Google to update a favicon?
Google documents a range of several days to several weeks after it crawls the relevant resources. There is no guaranteed refresh time, and eligibility does not guarantee display.
Does the image have to be 48x48?
No. It must be square and at least 8x8 pixels. Google currently recommends an image larger than 48x48 pixels. A 64x64 PNG is a straightforward candidate, while larger source images remain useful for other platforms.
Can I use SVG?
Google says any valid favicon format is eligible, which includes SVG. Browser and platform support varies, so many production packs still include ICO and PNG fallbacks. Make sure an SVG has a valid square viewBox, renders without external dependencies, and is publicly fetchable.
Can the icon live on a CDN?
Yes, the href can be an absolute URL. The homepage and image both need to be crawlable. A same-host stable path is simpler to debug, but a correctly configured public CDN is valid.
Should I add shortcut icon?
No new site needs it. MDN identifies shortcut icon as a nonconforming historical alternative. Use rel="icon".
Does changing the filename force Google to refresh?
It creates a new resource but conflicts with Google's advice to keep the URL stable. First fix the response, purge caches, request a homepage recrawl, and wait. Change the URL only when there is a genuine deployment reason, not as a daily troubleshooting ritual.
Why does the checker pass while Search still shows no icon?
A checker can prove that markup and files are reachable at one moment. It cannot force Google to crawl, process, approve, or display the icon. Search Console and time are still part of the workflow.
Primary references
- Google Search Central: Define a favicon to show in search results
- WHATWG HTML: Link type
icon - MDN: HTML
relattribute and icon behavior - Google Search Console: URL Inspection tool
The reliable path is not clever: declare one good icon on the right homepage, prove that the file is a public square image, make crawl access boring, and give Google time to process it.
