Troubleshooting: Favicon and Logo in Google Search Results (Supported Formats and CDN Gotchas)

Check 1: SureRank doesn’t set the favicon

SureRank doesn’t have its own favicon uploader. It reads the Site Icon that WordPress itself manages, wherever it needs one, such as in your schema markup. SureRank doesn’t add the favicon tag to your pages either. That comes from WordPress core.

Fix: The favicon is set in Settings → General → Site Identity → Site Icon (WordPress core), not SureRank.

Check 2: WebP site icon

Favicons should be square and in a standard format (PNG, ICO, or static GIF). Google doesn’t publish a hard format blacklist, but non-square images, oversized/undersized files, or edge-case formats can cause Google to silently fall back to a generic globe icon instead of showing your favicon.

Favicon must also be square (1:1 aspect ratio), at least 8×8px, though Google recommends larger than 48×48px for it to display well.

Fix: re-export the site icon as PNG or ICO, re-upload under Site Identity.

Check 3: CDN rewriting the icon URL

Image CDNs (Cloudflare Polish, Jetpack Photon, Bunny Optimizer, etc.) can rewrite the favicon to a different domain or force WebP based on request headers, which can break for Googlebot specifically.

How to verify: run curl -A “Googlebot-Image” -I. It should return 200 and Content-Type: image/png or image/x-icon, not a redirect or WebP swap.

Check 4: Propagation delay

Favicon changes in live search results can take days to weeks even after a successful re-crawl via Rich Results Test or Search Console URL Inspection. This is normal, not a bug.

Also confirm the logo image is at least 112×112px; this is Google’s stated minimum for the logo field in Organization structured data, and undersized logos are a common reason the field gets ignored even when the file format and URL are otherwise fine.

Logo Missing or Wrong in Organization/Website Schema

Check 1: Where the logo comes from

Your Organization schema logo defaults to your site icon. Your Website schema logo defaults to the logo you set during SureRank onboarding, falling back to your theme’s Custom Logo if you haven’t set one.

Fix: update via SureRank onboarding/Settings → Organization → Logo, or Appearance → Site Identity → Logo.

Check 2: No format/CDN validation on this field

Unlike your social share image, the schema logo field doesn’t check the file format, file type, or domain before it’s used. A WebP or CDN-rewritten logo URL goes into your page’s structured data as-is, which can fail Google’s structured data expectations silently.

Fix: check your page’s raw structured data (view source, look for the ld+json script tag) for the logo value. Confirm it’s PNG/JPG served without redirects.

og:image / Social Preview Wrong When Using a CDN

Check 1: Fallback chain

Your per-post social image (if it has a valid file extension) is used first, then your featured/content image, then your global default (Settings → Social).

Check 2: Extension allowlist breaks with CDN URLs

SureRank checks the URL’s path extension to confirm it’s a valid image (allowed: jpg, jpeg, png, gif, webp, avif), plus a 200 to 2000px dimension check. It does not check the domain.

Many CDNs rewrite images to extensionless paths or query-string formats (?format=auto, ?w=1200). If the final URL doesn’t end in an allowed extension, SureRank treats the per-post image as invalid and silently falls back to the featured image or default. This is why a custom social image “disappears” after moving to a CDN.

Fix: view source, find og: image, confirm the path ends in a recognized extension. If not, configure the CDN to preserve the file extension in rewritten URLs (most CDNs support this).

[Screenshot: Page source with the og:image meta tag highlighted, showing a URL missing its file extension]

Check 3: Cache

Re-scrape after fixing: Facebook Sharing Debugger / Twitter Card Validator.

Quick Reference

If That Doesn’t Work

If the URL is valid, correctly formatted, and reachable by Googlebot, but the tag still isn’t populating, escalate to engineering with the affected page URL and the raw tag value from view-source.