Your new site icon appears in the browser tab, but Google still shows a blank globe or your old branding. Before uploading another image, check whether the website is actually serving the wrong icon. A correct browser tab and a correct search result are separate checkpoints.
Start with the homepage address shown by the search result, then inspect the icon that homepage supplies. Changing an article’s featured image, installing another SEO plugin or repeatedly renaming the icon is not a useful first response.
This guide helps a WordPress business owner collect the right evidence, make a narrow correction when needed and know when further website changes should stop. It does not promise that Google will display an icon or that an icon repair will improve rankings.
Check which image is actually wrong
A favicon is the small site identifier beside a browser tab or search result. It is not the large photograph in a shared-link card, the logo inside your page header or your Google Ads business logo. If a messaging app shows the wrong photograph, use our separate WordPress link-preview image guide.
Save a screenshot of the search result, its destination URL and the icon you expected. Open the result and note the final address after redirects. Compare like with like: the main website and a separate shop subdomain may not use the same configuration.
| What you observe | Next check | Avoid for now |
|---|---|---|
| The browser tab also has the wrong icon | Compare the saved Site Icon with a fresh public homepage view | Requesting another Google crawl before fixing the website |
| The tab looks right, but the public homepage supplies an old icon address | Ask the developer which component generated that address | Adding competing icon markup in the header |
| The address looks right, but its file is old or unavailable | Open that exact file while logged out and check delivery | Replacing unrelated images across the Media Library |
| The homepage and file are correct, but Google differs | Review Google’s eligibility guidance and the latest homepage crawl | Repeatedly changing a configuration that already passes |
Use WordPress Site Icon, not the page logo
WordPress’s official Site Icon instructions put the control under Settings > General in WordPress 6.5 and later. Prepare a square image at least 512 by 512 pixels; WordPress recommends PNG. Older versions from 4.3 to 6.4 use Appearance > Customize > Site Identity.
Before saving, record the current selection and keep its original asset so you can restore it. Select the intended icon through the native control, save, and check the public homepage. Do not also change the site address, search visibility or business name just because those settings are nearby.
If the saved icon is already correct, leave it alone while you investigate the output. A theme, older customization or another component may be supplying different markup. Ask the person responsible for that component to reconcile ownership instead of layering on another snippet.
Inspect the homepage and the exact icon file
You do not need to edit code to collect a useful repair brief. Ask a developer to inspect the homepage’s served HTML and identify its icon links, then follow each relevant image address. The question is simple: does the public website supply the same asset you selected?
Several icon links can represent different sizes; their presence alone is not a fault. The concern is conflicting branding, inaccessible files or output that changes unexpectedly between requests. Preserve the observed values before changing anything.
Open the supplied file in a logged-out browser. Check that it is the intended square artwork, not an error page, login screen or obsolete logo. If an asset was replaced at the same address, ask the cache owner to check that particular file as well as the homepage HTML.
Use the site’s supported cache-refresh process after an actual correction, then test the normal URL again. A special uncached URL may help diagnose a difference, but it is not the address ordinary visitors or crawlers will necessarily receive. Our guide to WordPress changes not showing covers that distinction.
Separate Google’s requirements from WordPress’s upload size
According to Google’s favicon documentation, the homepage must identify the icon with a supported link element. Googlebot needs access to the homepage and Googlebot-Image to the file. Google supports one favicon per hostname, not a separate one for every subdirectory.
Google’s image minimum is a square 8 by 8 pixels, with a size larger than 48 by 48 recommended. That is different from WordPress’s 512-pixel source-image requirement. Keep the icon URL stable. Eligibility does not guarantee that Google will show it.
A successful browser load is useful evidence, but it does not establish how a crawler request is handled. If access is uncertain, have the hosting or security owner inspect the relevant request and rule. Do not disable protection across the site or expose a private staging copy to diagnose a public icon.
When to request a crawl, and when to wait
Google says processing a changed homepage can take days to weeks and identifies homepage URL Inspection as the place to request indexing. An accepted request is not confirmation that the icon has changed in search.
After a verified correction, record the public homepage URL, time, icon address and request outcome. Do not treat repeated submissions as progress. Compare the next observed result with the same hostname and keep the website configuration stable while checking what Google has actually processed.
If nothing changed on the website because every check already passed, say that explicitly in your repair record. A developer can confirm the site’s output without being able to certify Google’s eventual presentation. Avoid paying for repeated icon replacements without a new finding that explains why the last one was unsuitable.
A practical acceptance and stop checklist
| Checkpoint | Evidence to keep | Stop or escalate when |
|---|---|---|
| Saved configuration | Intended Site Icon and recoverable previous selection | The proposed change also alters unrelated site settings |
| Public homepage | Final address and the icon links served to a logged-out visitor | Conflicting components or stale output remain unexplained |
| Image delivery | Exact file URL, artwork and successful public response | The file is missing, private, blocked or unexpectedly replaced |
| Google follow-up | Inspection or request outcome and later observed search appearance | Someone promises an immediate display or ranking improvement |
| Unrelated behaviour | Header logo, navigation and enquiry path still work | An icon repair changes the wider website experience |
For example, suppose your selected icon is green but the homepage still supplies an old monochrome asset. That is a website-output issue to resolve before asking Google to revisit it. If the homepage supplies the green asset and the exact file loads correctly, replacing it again has no demonstrated benefit. These are diagnostic examples, not reported client results.
When Webless can help
A focused investigation is useful when the saved setting and public output disagree, multiple components generate icon links, or the image behaves differently for outside requests. Share the public homepage, expected icon and observed mismatch. Keep passwords and private logs out of a general enquiry.
Our WordPress development services provide a relevant route for discussing a controlled repair. The scope should be to establish ownership, correct the demonstrated fault and verify the public output, not to promise control over Google’s search presentation.