Why Google's Favicon Crawler Is Completely Separate From ...

Why Google's Favicon Crawler Is Completely Separate From Its Page Indexer (And Why That Matters)

The symptom: ProToolTrack's favicon in Google Search results was wrong for six months. The file on the server was correct. Re-indexing the page 5 times did nothing.

The root cause: Google has two separate crawl systems—one for pages, one for favicons. They don't talk to each other.

The fix: Change the favicon filename to trigger a fresh cache.

This is how we debugged it.

Testing the Obvious Wrong Guesses

Guess 1: The favicon file is corrupted.

We pixel-sampled the image via canvas to count actual RGB values instead of eyeballing it:

const img = new Image();
img.crossOrigin = 'anonymous';
img.src = '/favicon.png?cb=' + Date.now();
img.onload = () => {
  const c = document.createElement('canvas');
  c.width = img.width; c.height = img.height;
  const ctx = c.getContext('2d');
  ctx.drawImage(img, 0, 0);
  const data = ctx.getImageData(0,0,img.width,img.height).data;
  let orange = 0, pink = 0;
  for (let i=0; i<data.length; i+=4) {
    const [r,g,b] = [data[i], data[i+1], data[i+2]];
    if (r>200 && g>80 && g<160 && b<80) orange++;
    if (r>200 && g<150 && b>150) pink++;
  }
  console.log({orange, pink});
};

Result: 98% orange, 0% pink. File is correct. Guess 1 wrong.

Guess 2: Re-indexing the page will re-fetch the favicon.

User had already re-indexed 5 times. Nothing changed. Google's page indexer and favicon crawler are separate systems. Re-indexing pages doesn't trigger favicon re-crawls. Guess 2 wrong.

The actual answer: Google's favicon-fetcher only re-fetches when the filename changes or response headers change. Filenames hadn't changed. No one had told Google "hey, new favicon."

The Fix

Deploy new favicon files with new filenames:

<!-- Old -->
<link rel="icon" href="/favicon.png">

<!-- New -->
<link rel="icon" sizes="32x32" href="/favicon-32.png">
<link rel="icon" sizes="192x192" href="/favicon-192.png">
<link rel="icon" href="/favicon.ico">

New files on server: /favicon-32.png, /favicon-192.png, /favicon.ico.

AI Builder Hallucinated the Deploy

After the prompt, Lovable reported: "Done. Deployed. Build passed."

We didn't assume. We fetched the live HTML and checked the <head>:

GitHub source:

<link rel="icon" sizes="32x32" href="/favicon-32.png">
<link rel="icon" sizes="192x192" href="/favicon-192.png">

Live site:

<link rel="icon" href="/favicon.png">
<link rel="icon" href="/favicon.png">
<link rel="icon" href="/favicon.png">

Lovable hallucinated it. The build never ran. Re-prompted with screenshots, second attempt worked.

Companion Issues

While auditing, we found:

Duplicate og:image tags (apex + www variants, different URLs)
Two <link rel="manifest"> tags
Schema.org missing logo field
og-image.png was 635KB, compressed to 46KB JPG
manifest.json declaring 512×512 for a 1024×1024 icon

All fixed in one consolidated Lovable prompt.

The Lesson

When you've got an issue that spans multiple systems (browser, server, Google), verify each boundary separately. Don't assume one system's success means another's. Google's favicon pipeline is orthogonal to page indexing. That's not obvious from the docs. The favicon will take days/weeks to re-crawl and update in search results, but the actual fix is already deployed.

推荐订阅源

DEV Community