Favicons and Logos in Search Results: The Images Nobody Owns

Every image discussion on a site is about the pages: the hero, the product shots, the diagrams. Meanwhile there is one image Google shows beside your business name on every mobile search result, and in most organisations nobody can tell you who last touched it.

It is a 16-pixel file called favicon.ico that was committed in the first week of the project, and it is the reason a competitor's result looks like a brand and yours looks like a default.

Four surfaces, four different images

The confusion here is genuinely structural rather than careless. There are several small brand images, they live in different places, and each is consumed by something different.

Surface	Image it uses	Where it is declared	Rough requirement
Mobile search result, beside your name	Favicon / site icon	<link rel="icon"> in the head	Square, multiple of 48px, crawlable
Knowledge panel, brand entity	Organisation logo	Organization structured data	Larger, legible, brand-accurate
Social share card	og:image	Open Graph meta tags	Landscape, roughly 1200px wide
Google Images results	Page images	<img> in the page body	Large original, indexable
Browser tab and bookmarks	Favicon, plus apple-touch-icon	Head links, manifest	Multiple sizes, convention-driven

Most sites get the third and fourth rows right because a marketing team owns them. The first two rows fall between design and engineering, which is exactly why they rot. The distinction between the favicon and the knowledge panel logo is the one worth internalising: Open Graph images and search images are already separate concerns, and the brand marks add a third and fourth axis to that.

What Google actually asks of a favicon

The documented requirements are short, and nearly every failure is a violation of one of them.

Square, with dimensions that are a multiple of 48 pixels. Google downsamples from what you give it, so supply 96x96 or 144x144 rather than the historical 16x16. This is the requirement that catches most sites: a 16-pixel icon is perfectly valid for a browser tab and simply too small to be used in a search result.

A stable URL. The icon should live at a path that does not change between deploys. A hashed filename regenerated on every build gives Google a moving target and repeatedly invalidates what it has already fetched.

Crawlable. This is the failure that feels impossible until you check it. A blanket Disallow on an assets directory, or a rule written for a different purpose, can block the icon while leaving every page crawlable. Googlebot fetching your icon is subject to the same rules as Googlebot fetching anything else, which is the same class of problem as images that never appear in Google Images because something upstream blocks them.

Declared in the HTML head with a rel that Google recognises. An icon referenced only from a web app manifest, or inlined as a data URI, is not reliably picked up. The manifest is for installable app behaviour; the head link is what search reads.

Consistent across the site. One icon per site, declared from a shared layout so no section can drift onto an old file.

Why yours is not showing

Work through these in order, because the list is roughly ordered by how often each is the actual cause.

1. It is too small. Open the file and check its pixel dimensions, not its filename. If it is 16x16 or 32x32, that is the answer.
2. The home page is not indexed. Google associates the icon with the site through the home page. If that page has a problem, the icon inherits it.
3. robots.txt blocks the path. Fetch the icon URL as Googlebot would, and read the robots file rather than assuming it.
4. It only exists in the manifest. Add a head link.
5. It changed recently. Fetching happens on its own slower schedule. A week of patience is reasonable; a month is a bug.
6. Multiple conflicting declarations. A page declaring three icons at three sizes from two directories invites Google to pick one you did not intend.

The pattern across all six is that the favicon is fetched and evaluated as its own resource, by its own crawler, on its own timetable. It behaves much less like part of the page and much more like the separately-crawled asset it actually is — which is the same mental model that explains how Google discovers and indexes images generally.

The organisation logo is a different job

A knowledge panel, and increasingly an AI-generated answer that names your business, wants a real logo rather than a 96-pixel icon. That comes from Organization structured data, where a logo property points at a proper image file.

Two things make this worth doing carefully. The image should be the actual brand asset, legible at the size a panel renders it, on a background that survives both light and dark presentation. And the declaration should agree with everything else you publish — a logo in structured data that differs from the one in your header and the one in your directory listings is a consistency problem for anything trying to establish that these all describe the same organisation. The broader mechanics of declaring image properties in structured data, including where the URL fields belong, are covered in ImageObject markup and the licensable image fields.

The mark is not an AI image job

This one deserves stating plainly because the temptation is real, particularly for a new business standing up a site quickly.

A logo has to be flat, reproducible in one colour, legible at 16 pixels, and identical on every surface forever. That is vector work with exact spacing and colour values. Photorealistic image generation is genuinely excellent for the photographic content of a page — the hero, the service illustrations, the city-specific imagery — and genuinely wrong for a mark that must be crisp at thumbnail size. The two jobs only look similar because both produce an image file.

Where generation earns its place is everything else on the page, and there the constraint is usually consistency rather than realism: getting a whole site's imagery to feel like one brand is a prompting discipline, covered in keeping AI-generated images visually consistent.

The other icons, and why they multiply

Part of why this area rots is that four different conventions accumulated over twenty years and none of them replaced the previous one. A modern site head can legitimately declare all of the following:

• rel="icon" — the standard site icon. This is the one search reads.
• rel="apple-touch-icon" — used when someone adds the site to an iOS home screen. Conventionally 180x180, no transparency, and it ignores rounded corners because the operating system applies its own.
• Icons in a web app manifest — used for installable app behaviour and Android home screens, declared in JSON rather than the head.
• favicon.ico at the root — no declaration needed; browsers have looked there by convention since long before any of the above existed.

They are not alternatives to each other and they are not interchangeable. The common failure is a modernisation that moves everything into the manifest, deletes the head link as redundant, and quietly removes the site from search results while every browser tab still looks correct — because browsers fall back to the root convention and Google does not.

Keep the head rel="icon" declaration regardless of what else you ship.

Dark mode

One genuinely modern consideration: an icon designed for a light browser chrome can disappear against a dark one. A dark navy mark on transparency looks deliberate in light mode and invisible in dark mode.

An SVG favicon can carry a prefers-color-scheme media query internally and adapt, which is the neatest solution where you control the artwork. Failing that, the pragmatic answer is a mark that works on both — an outline with sufficient contrast either way, or a small opaque background shape behind the glyph. Search results are not the main beneficiary here, since Google renders the icon in its own context, but browser tabs and bookmark lists are where most people actually see it.

A ten-minute audit

Do this once and it stays fixed for years.

• Open your icon file. Confirm it is square and at least 48x48, ideally 96x96 or larger.
• Confirm it sits at a stable path that survives a deploy.
• Request the icon URL directly and confirm it returns 200, not a redirect chain or a 403.
• Read robots.txt and confirm nothing blocks that path.
• Confirm a <link rel="icon"> exists in the head, emitted from a shared layout.
• Search your brand name on a mobile device and look at what actually appears.
• Confirm Organization structured data on the home page declares a logo pointing at the real brand asset.
• Add the icon path to whatever site-wide image audit you already run, so a future redesign cannot silently drop it.

As of September 2026 none of this has changed materially in years, which is precisely why it gets neglected: there is no announcement to react to, just a small file that either meets a short list of requirements or does not.

---

SEOpix handles the photographic images on your pages — generated with SEO-ready filenames, alt text and EXIF metadata written in at generation time, from $0 on the free plan through to $99/month for agency use. See the full feature list or start on the free plan. The logo, get that drawn properly.