Getting Your Favicon to Show in Google Search Results

Forty-eight pixels. Not “at least 48” either, but a multiple of it: 48, 96, 144, 192. That one number is why a favicon in Google search results can be missing from a site whose tab icon works perfectly in every browser you own.

A favicon.ico produced by a typical build script holds a 16x16 frame and a 32x32 frame. Both are ideal for tabs. Neither is a multiple of 48, so Google looks at the file, finds nothing at a qualifying size, and moves on. You get a grey globe beside your domain while every competitor in the list has a small logo, and a missing icon reads as either “this site is broken” or “this site is not a real brand”. Neither is what you want in a list of ten blue links.

Google renders the site icon at a fixed display size and wants clean integer downscaling, which is where the base unit comes from. SVG is exempt from the size rule. The second requirement is quieter and catches modern deployments: the icon has to sit on the same host as your home page and be reachable by Google’s crawler.

Then there is the feedback loop. No submit button. No favicon report in Search Console. You fix it, you push, and you wait for Google to recrawl your home page, which may be tomorrow or may be in a month.

Everything below describes Google’s documented behaviour at the time of writing, August 2026. Google changes search features regularly and this particular documentation has been revised more than once, so check the Google Search Central documentation on defining a favicon before you take any of it as current gospel.

The short answer

Google will show your favicon in search results when all of the following hold:

• Your home page has a <link rel="icon"> (or shortcut icon, apple-touch-icon, or apple-touch-icon-precomposed) element that Google can find in the crawled page.
• The icon is square and its dimensions are a multiple of 48 pixels: 48x48, 96x96, 144x144 and so on. SVG is exempt from the size rule.
• The icon file is on the same host as the home page.
• Neither the home page nor the icon URL is blocked in robots.txt, and both return a 200.
• The image is in a format Google Images supports, which covers ICO, PNG, SVG, JPEG, GIF, BMP and WebP.
• The icon does not breach Google’s content policies.

Then you wait for Google to recrawl the home page. That recrawl is the trigger for the update, there is no way to submit a favicon, and the delay is measured in days to weeks depending on how often Google crawls you.

The 48-pixel rule, and why your .ico probably fails it

This is the requirement that catches nearly everyone, and it is the one that browser testing will never reveal.

Google asks for a square icon whose side length is a multiple of 48. Not “at least 48”. A multiple: 48, 96, 144, 192, 240. The reason is that Google renders the site icon at a fixed display size and wants clean integer downscaling, and 48 is the base unit it picked.

Now think about what your icon set actually contains. A favicon.ico produced by a typical build script holds a 16x16 and a 32x32 frame. Both are perfect for tabs. Neither is 48. Google looks at that file, finds nothing at a qualifying size, and moves on.

Two ways to fix it, and I would do both.

First, rebuild the .ico so it contains a 48x48 frame alongside the 16 and 32. Remember that ICO is a container: one file, three images inside it, and Google can pick the 48 while your browser still picks the 16. If you are not sure what your current file holds, run file favicon.ico and read the frame list, or open it in the ICO Converter. Packing new frames is what PNG to ICO is for.

Second, declare a larger PNG explicitly, because it removes all ambiguity about what Google is being offered:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="icon" type="image/png" sizes="96x96" href="/icon-96.png">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

A 96x96 PNG of a simple flat mark is around 3 KB. It costs you nothing, browsers ignore it in favour of whichever icon they prefer, and Google has an unambiguous qualifying file to read.

One caution on the sizes attribute: it is a declaration, not a measurement. If you write sizes="48x48" on a file that contains only 16 and 32 pixel frames, you have lied to the crawler rather than fixed anything. Make the file match the claim.

Same host, crawlable, and the CDN trap

Google’s second hard requirement is that the favicon lives on the same host as the home page it belongs to.

This is where modern deployment setups quietly break. You put all your static assets behind cdn.example.net or assets.example.com because that is what you do with static assets. Your tab icon still works, because a browser does not care what host an icon comes from. Google does care, and the result is a blank globe on a site that looks completely healthy in every browser test you run.

The fix is boring: serve the icon from your own origin. Put favicon.ico at the root of https://example.com/ and let your CDN sit in front of that URL rather than replacing it. If your platform makes root-path files awkward, a rewrite rule or a proxy path on the same host is fine, so long as the URL a crawler sees begins with your own scheme and host.

Crawlability is the companion requirement. Both the home page and the icon URL have to be fetchable by Google. The two ways people break this:

A robots.txt rule that disallows the directory the icon sits in. Disallow: /assets/ is extremely common and perfectly reasonable for other purposes, and it takes your icon out of Google’s reach if the icon is at /assets/favicon.png.

Then there is the redirect chain. A 302 from /favicon.ico to /static/favicon.ico will usually work in a browser and is an unnecessary risk with a crawler. Serve a 200 at the URL you declare.

Google has historically used a distinct fetcher for favicons in addition to its main crawlers, so a robots.txt written to allow only Googlebot by name can produce odd results. I would not build a robots file that allows crawlers by explicit name at all, but if yours does, make sure the icon path is not caught by a catch-all disallow.

Data URI favicons deserve a specific mention because they are a genuinely useful development trick and a total failure here. <link rel="icon" href="data:image/svg+xml,..."> has no URL for Google to crawl, so it can never appear in search results. Perfect for a red icon on your staging environment. Never on production.

The link element Google looks for, and where it looks

Google reads the favicon declaration from your home page and applies it to every result from that site. Not the page that ranked. The home page.

That has a few consequences worth internalising. If your home page is a redirect to /en/ or /home, make sure the destination carries the icon declaration. If your home page is a client-rendered application that injects the <link> tag with JavaScript after hydration, you are depending on Google’s rendering stage to catch it, which usually works and is a fragile place to be. Put the tag in the server-delivered HTML.

Supported rel values, at time of writing, are icon, shortcut icon, apple-touch-icon and apple-touch-icon-precomposed. Modern markup should use rel="icon". The others are accepted for compatibility with older sites.

If no link element exists at all, Google falls back to looking for /favicon.ico at the root, in the same way browsers do. This is another argument for keeping a real file at that path regardless of what your tags say, which I have made at more length in the piece on what to actually ship: .ico, PNG or SVG.

Google’s guidance also asks that the favicon URL stay stable. Changing the path on every deploy, which happens when a build system fingerprints the filename, gives the crawler a moving target. Keep the icon at a fixed URL and version it by changing the file contents rather than the name.

Requirements, checks and failures

The recrawl reality, and the button that does not exist

Here is the part that generates the most frustrated forum posts. You have fixed everything. The icon is 96 pixels, on your own host, returning a clean 200, declared in the server HTML. You search for your site. Grey globe.

Google refreshes the site icon when it recrawls your home page. Not when you deploy, not when you ask, not on a schedule you control. If Google crawls your home page daily, the change can appear within a few days of the crawl. If Google crawls your home page every three weeks because the site is small and rarely updated, that is roughly your wait, plus indexing time on top.

There is no favicon submission form. There is no favicon section in Search Console. There is no API. The only lever is the URL Inspection tool: inspect your home page URL, click Request Indexing, and Google queues a recrawl. That queues the page, which carries the declaration. It is indirect, it is not a guarantee, and it is genuinely the whole toolkit.

I want to be plain about the timing, because everyone wants a number and I do not have a defensible one. Google publishes no service level for favicon refresh. Reports from site owners range from a couple of days to over a month, and the variable that seems to matter most is home page crawl frequency, which you can read yourself in URL Inspection under the last crawl date. Use that date as your estimate and stop refreshing the search results page.

One practical consequence: fix everything at once. If you ship the size fix on Monday and the host fix on Thursday, you have two independent crawl cycles to wait through and no clean signal about which change did what.

Verifying what Google sees

Do this in order. It takes about five minutes and it eliminates guesswork.

1. Fetch the home page HTML exactly as a crawler would, without your browser’s JavaScript: curl -s https://example.com/ | grep -i 'rel="icon"'. If nothing comes back, your tag is client-side only and that is your bug.
2. Read the href in that output. Confirm it is root-absolute and on your own host. A protocol-relative or CDN URL is a finding.
3. Request the icon itself: curl -sI https://example.com/favicon.ico. You want HTTP/2 200, a sensible Content-Type such as image/x-icon, and no Location header.
4. Confirm the file is genuinely the format it claims and contains a qualifying size. file favicon.ico will list the frames; for a PNG, check the reported dimensions.
5. Open https://example.com/robots.txt and read it. Look for any Disallow that matches the icon’s path. Remember that Disallow: /assets matches /assets/favicon.png.
6. Run the home page URL through the URL Inspection tool in Search Console. Check the page is indexed, check the last crawl date, and view the crawled HTML to confirm the icon link element is present in what Google actually received.
7. Search site:example.com on both a desktop browser and a phone, in a private window, and note which surfaces show the icon.
8. If everything above is clean and the icon is still missing, note today’s date and the last crawl date, and check again after at least one full crawl cycle before changing anything else.

Step eight is real advice, not filler. The most common self-inflicted wound here is changing four things in a week and losing the ability to tell what worked.

If you would rather not hand-build a .ico with the right frames in it, the ToolFiddle favicon generator takes one square source image and produces a multi-resolution icon including a 48-pixel frame, the larger PNGs, and the link tags to paste. It runs entirely on your own device, which is worth knowing if the artwork belongs to a client who has not launched yet, and there is no account or upload involved.

Worked example: Braisedly loses its icon

Say Tomas runs Braisedly, a recipe site on braisedly.com that gets around 40,000 sessions a month. The favicon shows perfectly in Chrome, Safari and Firefox. In Google results it is a globe.

He works the checklist.

Item one, size. file favicon.ico reports two frames: 16x16 and 32x32. Neither is a multiple of 48. That is failure number one.

Next, the host. The home page HTML contains <link rel="icon" href="https://cdn.braisedly.net/assets/favicon.ico">. Different host entirely, on a different domain his CDN provider gave him. Failure number two.

Then robots. braisedly.com/robots.txt contains Disallow: /assets/, added two years ago to keep an old media library out of the index. Even if he moved the icon to braisedly.com/assets/favicon.ico, it would still be blocked. Failure number three, latent.

So Tomas fixes all three in one deploy. He rebuilds the .ico with 16, 32 and 48 pixel frames, adds a 96x96 PNG for good measure, puts both files at the site root rather than under /assets/, and updates the head:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" type="image/png" sizes="96x96" href="/icon-96.png">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

He verifies with curl -sI https://braisedly.com/favicon.ico, gets a 200 and image/x-icon, and confirms curl -s https://braisedly.com/ | grep -i icon shows both tags in the server HTML.

Then he opens URL Inspection on https://braisedly.com/. The last crawl date is four days old, which tells him the home page is on a reasonably frequent cycle. He requests indexing and stops touching it.

In this scenario the icon appears in results a little over two weeks later. Do not take two weeks as a number you can plan around. It is what this particular site’s crawl rate produced, and yours will differ. The point of the example is the sequence: fix everything together, verify each item mechanically, note the crawl date, then leave it alone.

Desktop shows it, mobile does not

This pattern comes up constantly and I am going to be honest with you: I cannot give you a clean explanation, because the behaviour is not documented and it is not consistent.

What I can offer is the set of things worth ruling out. If you run a separate mobile host such as m.example.com, that host has its own home page and its own favicon declaration, and Google may be reading a different page than you think. If your mobile home page is served by a different template or a different cache layer, confirm the link element is present in that response specifically, not just in the desktop one.

Beyond that, search features roll out unevenly across surfaces and regions, and icon caching does not appear to be shared uniformly between them. A difference that persists for a day or two is unremarkable. A difference that persists past a full recrawl cycle, with identical HTML confirmed on both, is worth raising in a Google Search Central community thread rather than continuing to change your own markup.

If the icon is missing everywhere rather than on one surface, that is a different problem, and it is more likely a browser-side or server-side fault than a search one. The ordered debugging routine for that lives in the nine causes of a favicon not showing.

The content policy nobody reads

Google reserves the right to refuse to display an icon, and it does exercise that right. At time of writing the documentation is explicit that icons containing pornography or hate symbols will be replaced with a default icon.

This is a genuine and under-discussed cause of a blank result for sites that have done everything else correctly. It usually catches two groups. Sites whose mark contains a symbol that resembles something on the prohibited list, even coincidentally, since the assessment does not depend on your intent. And sites using imagery that could be mistaken for an official emblem, where flags are the case people report most often. I cannot point you at a documented rule about national flags specifically, so treat that as a caution rather than a requirement, but if your icon is a flag and everything else checks out, it is a reasonable thing to change and retest.

There is no appeal process for this and no notification. The icon just does not appear. If you suspect this is your situation, change the artwork to something unambiguous and wait for the next recrawl.

Other things that go wrong

An SVG-only icon set. SVG is a supported format and is exempt from the size rule, which sounds ideal. In practice I would still ship a raster at 96 or 144 alongside it, because a single-format dependency on the least-consistently-handled format is not where you want to be for something you cannot debug directly.

A noindex on the home page that arrived with a staging configuration. If the home page is not indexed, its favicon is not being read.

Multiple conflicting declarations. Six link elements pointing at five different files, three of which 404, is a common state for a site that has been through two rebrands. Google applies its own heuristics to choose, and you have no visibility into which one it took. Prune the list.

An icon that is technically 48x48 but was upscaled from a 16x16 source. It qualifies on dimensions and looks terrible at display size. Generate the larger sizes from a proper master, or from vector artwork, rather than enlarging a tiny raster. Image Resizer handles the downscales; nothing handles a bad upscale.

Assuming Search Console will tell you. It will not. There is no favicon status, no error, no warning. The absence of information is not a signal that things are fine.

Finally, the caveat that matters most. All of this describes Google’s stated behaviour and my reading of it as of August 2026. Google revises search features and their documentation without much fanfare, sizes and supported formats have changed before, and the only authority on what is required today is the Google Search Central documentation itself. Read it before you rebuild anything, and treat any article, this one included, as a starting point rather than a specification.

Frequently asked questions

Why is my favicon not showing in Google search results?

The usual causes are an icon smaller than 48 pixels square, an icon hosted on a different host from the home page such as a CDN subdomain, a robots.txt rule blocking the icon path, a missing link element on the home page itself, or simply that Google has not recrawled your home page since you fixed it. Work through those in that order.

What size does Google need my favicon to be?

At time of writing Google asks for a square icon whose dimensions are a multiple of 48 pixels, so 48x48, 96x96, 144x144 and upward. SVG icons are exempt from the size rule. A classic favicon.ico containing only 16 and 32 pixel frames does not meet it, which is why so many older icon sets quietly fail.

How long does it take for Google to update my favicon?

Google refreshes the icon when it recrawls your home page, so the wait tracks your home page crawl frequency. Busy sites can see a change within days. Small or rarely updated sites can wait weeks. Google publishes no guaranteed timing and there is no way to speed it up beyond requesting indexing of the home page.

Can I submit my favicon to Google directly?

No. There is no favicon submission form, no Search Console favicon report, and no API. The only lever available is requesting indexing of your home page URL in the Search Console URL Inspection tool, which asks Google to recrawl the page that carries the favicon declaration. Everything else is waiting.

Does the favicon have to be on the same domain as my site?

Google requires the favicon and the home page to be on the same host, so serving the icon from a CDN on a different subdomain or a separate domain is a documented way to lose it. Keep the file on the same origin as the home page, ideally at the root path, and let your CDN cache it at that URL instead.

Why does my favicon show on desktop but not mobile?

Honestly, this one is hard to pin down. The usual explanations are separate caching per surface, a distinct mobile host such as an m. subdomain whose home page declares a different icon, or a staged rollout. Confirm both versions of the home page serve the same link element and the same crawlable icon URL, then wait a full recrawl cycle before assuming a bug.

Where to spend your effort

Two checks account for most missing icons: whether your file contains a frame that is a multiple of 48 pixels, and whether the URL in your home page’s link element is on your own host and unblocked. Run file favicon.ico and read your robots.txt. That is ten minutes and it usually ends the investigation. If the 48 frame is missing, the Favicon Generator will rebuild the file with it included.

After that, the discipline is patience. Fix everything in one deploy, verify each item with a request rather than a browser, note the last crawl date from URL Inspection, and then genuinely leave it alone for a full cycle. Repeatedly changing markup while waiting is how people turn a two-week wait into a two-month one.

And check Search Central before you trust any of this. Google moves the goalposts quietly, and the documentation is the only thing that counts.