Why Your SitecoreAI Favicon Doesn't Show in Google

The favicon showed in the browser tab. The HTML was valid. Google Search still showed the grey default globe.

When Google can't use the icon from the <link> tag, it falls back to /favicon.ico on the domain. That works for a single site. In a multisite setup, where every site shares one frontend repo, you can't ship a different /favicon.ico per site, so the fallback doesn't save you.

I hit this across several SitecoreAI (XM Cloud) implementations for different customers. Each one is a multisite setup, with several sites sharing one Next.js Pages Router repo. Some customers are hosted on Vercel, others on Netlify, and the problem was the same on both.

What I checked first

Each site stored its favicon in a Sitecore Image field, and the frontend rendered the Experience Edge media URL in a <link rel="icon"> tag. Favicon.im found it. Bing showed it for most sites. Google didn't.

Then I looked at other live SitecoreAI multisite implementations. The pattern was consistent: every one that served its favicon from Experience Edge had the same problem in Google, whether it was hosted on Vercel or Netlify. The ones serving the favicon from a CDN were fine.

That ruled out the hosting provider and pointed at where the file was served from.

I ruled out the boring causes. The ICO contained 16, 24, 32 and 48px images. robots.txt blocked nothing. The URL Inspection live test was clean.

The header

So I took the href from the <link rel="icon"> tag, the edge.sitecorecloud.io favicon URL, and requested it directly to look at the response headers. The favicon file itself came back with this:

X-Robots-Tag: noindex

The header is on the favicon response, and it comes from Experience Edge, not from the frontend or the host. It's added to media served through the default edge.sitecorecloud.io domain, on purpose. Media served through a registered custom hostname, using the /v1/media/edge/images/ path, doesn't get it. It's documented in Resolving a custom hostname during a request, and Sitecore Support reproduced it and confirmed it.

Is that why Google ignores the icon? Google doesn't say so. Its favicon guidelines only require that Googlebot-Image can crawl the file, and nothing there mentions noindex. But the header is the one real difference between the sites that fail and the sites that work, and I don't want a noindex on a file whose whole job is to appear in search results.

The fix

I added a Single-Line Text field to the site settings for the public favicon URL, and the frontend renders that instead of the Image field's URL. For our sites it's a public link from our DAM, reachable by Googlebot and served without the X-Robots-Tag header.

I picked this over the custom hostname route because several sites share one repo. I didn't want hostname-specific logic in the frontend, or a code change every time someone swaps a favicon. Each site just stores its own URL. The custom hostname option is valid too if it suits your setup better.

<Head>
  <link key="site-favicon" rel="icon" href={publicFaviconUrl} />
</Head>

Make sure no other layout renders a second rel="icon" tag. Two competing declarations will undo the whole thing.

Does it work?

Yes. The new URLs resolve, serve the right file and carry no noindex header. I'm confident this fixes it.

The Google result takes time. It has to recrawl the homepage and process the new file, which can take days to weeks. Requesting reindexing in Search Console helps but doesn't make it instant. I'll update this post once it refreshes.

The lesson for me: a favicon that works in the browser says nothing about how a search engine treats it. Check the response headers, not just the markup.