Favicon in Google Search: Why It's Wrong and How to Fix It

Search for your own site and something looks off next to the result: there's no icon at all, it's someone else's icon, or the bold text above the URL isn't your brand name. None of this is a ranking penalty, and none of it is random. Google builds that result line out of three separate signals, sourced from three different places on your site, and each one can break independently of the other two.

This covers all three failure modes in order: no favicon, the wrong favicon, and the wrong site name, with the exact technical requirement behind each and a realistic timeline for what changes once you fix it, and what doesn't.

How Google Actually Sources a Favicon

The icon shown next to a search result isn't pulled from your logo, your Open Graph image, or anything you upload to a CMS media library. Google's crawler fetches it the same way a browser tab does: it looks for a <link rel="icon"> reference in the homepage's HTML head, and if that isn't present or resolvable, it falls back to requesting /favicon.ico at the domain root.

For that fetch to succeed and for Google to be willing to display the result, the file has to clear a short list of conditions. Miss any one of them and Google simply omits the icon rather than showing a broken image.

• Square aspect ratio — not a rectangular logo cropped by CSS on your site but served uncropped
• Ideally a multiple of 48 pixels per side (48x48, 96x96, 144x144), since Google selects the largest usable size it finds
• A standard raster format Google reliably parses: PNG, GIF, ICO or JPEG; SVG is used by some sites but is not treated as a safe universal default
• Reachable by the crawler — not blocked by robots.txt, not gated behind a login, not served only after a client-side redirect
• Returned as a real 200 image response, not a 404 or a multi-hop redirect chain

Why No Favicon Shows Up at All

The most common cause is an overly broad robots.txt rule. A blanket disallow on a folder like /assets/ or /wp-content/ is written to keep low-value files out of the crawl budget, but if the favicon happens to live inside that folder, it gets blocked along with everything else. Google has been explicit that it needs to crawl the icon file itself, separately from the page that references it — blocking the folder blocks the icon.

A second, easy-to-miss cause is a gap between what a browser accepts and what Google actually looks for. Plenty of sites define their icons only inside a web app manifest.json (for PWA install prompts), and never define a plain <link rel="icon"> at all. Browsers are forgiving about this: several will quietly keep showing a cached icon in the tab, so the owner checks their own browser, sees an icon, and assumes search will show the same thing. Google's favicon logic doesn't read the manifest — it looks for an icon link in the homepage head (rel="icon", or apple-touch-icon, which Google also supports), so a site whose icons live only in the manifest can have a correct app icon for installs and still have nothing for Google to fetch.

Beyond those two, a favicon that's smaller than a practical minimum or non-square because it was generated from a rectangular logo without cropping first will also get skipped, as will a <link rel="icon"> tag pointing at a URL that 404s or that only resolves through JavaScript Google's renderer doesn't execute on every pass. And upstream of all of this: if the homepage itself carries a noindex directive or is otherwise excluded from the index, the entire result card is suppressed, icon included, so a missing favicon is sometimes a symptom of an indexing problem rather than an icon problem.

• Check robots.txt for a rule that unintentionally covers the icon's path, not just the page
• Check the homepage's raw HTML source for a <link rel="icon"> tag — an icon defined only in the manifest does not substitute for it
• Confirm the icon file itself returns 200 when fetched directly, with no redirect
• Confirm it's square and not undersized
• Confirm the homepage is indexable — a suppressed result has no icon to fix

Why the Wrong Favicon Shows Up

This is a different failure than showing nothing, and it usually traces back to more than one icon existing across the site's history. A rebrand that swaps the icon file but leaves the old file reachable at its old path can leave Google referencing whichever version it last crawled successfully, not whichever one is current. Multi-subdomain setups have a similar issue: a marketing subdomain, an app subdomain, and the root domain can each carry a different icon, and Google's association between a given URL and a given icon is built from what it crawled for that URL, not from an assumption that the whole domain shares one icon.

CDN-fronted sites add another wrinkle. If the icon is served through a CDN and the origin file changes but the edge cache doesn't invalidate, the CDN will keep returning 200 with the old bytes, and Google has no way to know the underlying file changed. The practical implication in every one of these cases is the same: Google refetches icons on its own schedule, not on your deploy schedule. A fix that's live on your server can take real time, commonly measured in weeks, to be reflected in the visible result.

The Site Name: What Actually Controls It

Google moved away from showing the raw URL breadcrumb next to results in favor of a human-readable "site name," first on mobile and later extended more broadly. That name is not simply your registered domain and it is not automatically your homepage's <title> tag — Google documented that it derives the name from a small hierarchy of signals, and it prefers the ones you control directly over the ones it has to guess.

At the top of that hierarchy is structured data: the name (and optionally alternateName) property on a WebSite schema block. Below that, Google will use the og:site_name meta tag if structured data isn't present. Failing both, it falls back to heuristics built from the homepage title tag and the domain itself, and heuristics are where things go wrong — a title tag written for click-through ("Best Project Management Tool for Teams | Sign Up Free") gives Google a phrase to guess from, not a brand name, and it can surface a fragment of that phrase instead of your actual brand.

Fixing the Site Name with WebSite Schema

The direct fix is adding a WebSite structured data block to the homepage with an explicit name. This is the same schema type once used for the now-retired sitelinks search box, and the name property is the strongest signal you can hand Google for the site name display specifically.

A minimal, correct block looks like this in JSON-LD form: a @context of https://schema.org, @type of WebSite, a url pointing to the canonical homepage, and a name set to the exact brand string you want shown. If your legal or registered name differs from the name you're commonly known by — a full corporate name versus a shorter consumer-facing brand — add alternateName for the secondary form rather than trying to cram both into name. Google is explicit that alternateName exists precisely for this kind of shorter or informal variant, not as a place to list keywords or a slogan.

This block belongs on the homepage's actual canonical URL, not on every page with slightly different values. If different templates on the site output different name values through inconsistent schema generation, you've reintroduced the same ambiguity you were trying to remove.

Keeping Homepage Signals Consistent

Structured data is the strongest signal, but it isn't the only one Google reads, and when signals disagree, you're leaving the outcome to Google's judgment instead of stating it. The homepage title tag, the og:site_name meta tag, and the WebSite schema name should all resolve to the same brand string, or at least not contradict each other.

In practice this means trimming the boilerplate that accumulates on a homepage title over time — taglines, year stamps, a stacked list of service keywords appended after the brand name — since any of that is a candidate for Google's fallback heuristics to latch onto if the stronger signals are ever missing or momentarily unavailable during a recrawl. It also means checking this after any rebrand or CMS migration, since a theme change or plugin update is a common, easy way for og:site_name to silently revert to a default value while the schema block and title tag are updated by hand and the meta tag is forgotten.

Getting Google to Pick Up the Fix

There's no control that forces an immediate refresh of either the favicon or the site name in live results. What you can do is make sure Google has a reason to recrawl the homepage soon rather than waiting for its normal schedule: submit the homepage URL through Search Console's URL Inspection tool and request indexing after the fix is live. This prompts a recrawl of the page, and a page recrawl is generally what triggers Google to re-evaluate the associated icon and structured data as well, since both are read from what's on that page or reachable from it.

Search Console's Live Test is useful for confirming the structured data itself parses correctly — it will flag a malformed WebSite block immediately — but it isn't a reliable preview of how the result will actually render, since favicon and site-name display logic runs on Google's indexing and serving side, not in the live-rendering test. Expect the visible change in actual search results to lag your fix by a period of days to a few weeks, and treat a request-indexing submission as nudging the timeline, not resetting it to zero.

A Practical Checklist

Working through favicon and site-name problems in order tends to be faster than jumping straight to structured data, since a blocked or malformed icon and a missing schema block are both common enough that either one alone explains most cases.

• Confirm robots.txt doesn't block the favicon file's actual path, including if it's served from a subfolder covered by a broader disallow rule
• Confirm the favicon returns 200 directly, is square, and is at least 48x48
• Confirm the homepage itself is indexable, not noindexed or excluded
• Add or correct a WebSite schema block on the homepage with an explicit name, and alternateName if you have a shorter brand form
• Align the homepage title tag and og:site_name with the same brand string used in schema
• Check for a stale icon still reachable at an old path from a prior rebrand or migration
• If behind a CDN, confirm the edge cache was invalidated after any icon file change
• Request indexing on the homepage through Search Console after fixing the underlying issue, then allow real time for it to reflect