Why Your Favicon Isn't Showing in Google Search

Google shows a small icon beside your site's name on mobile search results and in some desktop layouts. It is one of the few pieces of visual branding you get in a SERP, and it is chosen by a separate process from the one your browser uses for the tab icon. A site can therefore have a perfectly working tab favicon and no search favicon at all, which is why this problem is so common and so confusing to debug.

The requirement that catches the most sites is size. Google's documented guidance is that the icon it uses must be a square whose dimensions are a multiple of 48 pixels — 48x48, 96x96, 144x144, and so on. A traditional favicon.ico containing only 16x16 and 32x32 entries contains nothing eligible. It renders fine in the tab and is invisible in search, and no amount of waiting fixes it.

The rest of the causes are more mundane: the icon URL is not crawlable, the link element is missing or malformed, or the change is simply newer than Google's next visit. Work through them in the order below, because the size problem is both the most likely and the only one you cannot detect by looking at your own site in a browser.

Google states that the favicon it selects should be a square with dimensions that are a multiple of 48 pixels. The reason is practical rather than arbitrary: it renders the icon at a size that needs more detail than 16 pixels can carry, and it would rather skip a site's icon than display a blurry upscale of one.

This is where the classic favicon.ico falls down. An ICO file is a container holding several images at different sizes, and the conventional recipe — the one most generators still produce and most tutorials still recommend — packs 16x16 and 32x32, occasionally 48x48. Neither 16 nor 32 is a multiple of 48. If those are the only entries, there is nothing in the file Google will use, and because browsers pick the 16 or 32 happily, nothing looks broken from where you are standing.

The fix is to make sure at least one eligible icon exists and is declared. A 48x48 entry inside the ICO satisfies the letter of the rule; a separate 96x96 or 192x192 PNG is a better answer, because it also serves mobile home-screen shortcuts and looks correct where Google renders larger.

Google reads the link elements in your document head to find candidate icons. Each candidate should carry a sizes attribute, because that is how a crawler knows which file meets the multiple-of-48 rule without fetching and measuring all of them. A bare link with no sizes attribute is a candidate with unknown dimensions.

This is also why the convenience conventions some frameworks offer can work against you. Dropping an icon file into a magic path gets you a link element, but frequently one without a sizes attribute, and there is no way to add one because the file name is the entire configuration. Declaring the icons explicitly — a link per size, each with its own sizes value — is more verbose and is the version that works.

A minimal set that covers browsers, Google and mobile home screens is a multi-size ICO at the root, plus PNGs at 48, 96, 192 and 512 pixels. The 48 is for Google, the 192 and 512 are what Android uses for an installed shortcut, and the ICO is what older browsers and Windows expect.

Google has to fetch two things: the page carrying the link elements, and the icon itself. A robots.txt rule that blocks either one removes your favicon from search, and this happens more often than you would expect — a Disallow on an assets or static directory is a common way to accidentally block every icon on a site.

The home page matters specifically. Google associates one favicon with a whole site and normally takes it from the home page, so a home page that is blocked, redirecting oddly, or returning anything other than a 200 can cost you the icon sitewide even when individual pages are fine.

Check the fetched icon serves a sensible content type and a 200 status directly, with no redirect chain. Then use Search Console's URL inspection on your home page to confirm Google sees the head you think it does — a client-rendered head is a head a crawler may see empty, which is the same failure in a different costume.

A favicon is displayed somewhere between 16 and 48 pixels. A full wordmark scaled into that space becomes a grey smudge, and a detailed logo becomes noise. The icons that read well at that size are a single letter, a simple mark, or one recognisable shape, with high contrast against both light and dark backgrounds.

Two practical points follow. First, generate the icon from a large, clean square master — ideally vector — rather than from a small raster, because every size is downscaled from that master and detail you never had cannot be invented. Second, check it on a dark background as well as a light one: an icon with a dark outline and a transparent interior disappears entirely in a dark-mode tab strip.

Padding matters too. Browsers do not add any, so a mark that fills its square edge to edge looks cramped beside icons that leave a small margin. Around 10% clear space on each side is a reasonable default.

Favicons are cached aggressively and re-crawled on Google's schedule rather than yours. Days is normal, and a few weeks is not unusual for a low-traffic site. There is no way to request a favicon refresh specifically; requesting indexing on the home page is the closest available nudge.

The trap here is impatience. Changing the icon again resets the clock and makes it impossible to tell which version Google was evaluating, so a site can spend months in a loop of edits with nothing to show. Once you have verified the size rule, the link elements and the crawlability, stop touching it — those three are the entire checklist, and everything after them is waiting.