A site replaces its logo and the WordPress preview shows the new Site Icon, but Chrome still displays the old mark while Safari shows none. Page source contains the current WordPress icon, an obsolete theme tag, and a manifest reference; one CDN node returns the new file while another serves a cached 404.
Keep the selected image stable while diagnosing. First identify which icon tag each browser can choose, then request that file directly and follow its response through the origin, CDN, service worker, and browser cache. Replacing the image again only adds another variable.
What it means
A missing or stale favicon is a problem of publication, retrieval, ownership, or caching. The WordPress setting may be correct while the theme omits head output, duplicate tags point to different images, the attachment returns an error, a CDN retains old bytes, or a browser remembers an earlier icon.
Diagnosis should follow the rendered link to the direct file before changing the source. Separate the administrator preview from public markup, markup from file retrieval, and current file bytes from cached responses.
A realistic WordPress example
The Site Icon preview and the first WordPress-generated link tag use the new image. A later theme tag still points to the old favicon, and the web app manifest uses a third URL. Direct requests also reveal that one CDN location has negatively cached an earlier 404 for the new file.
The team disables the obsolete theme output, confirms the intended manifest owner, and purges only the affected icon URL at the CDN. A clean browser profile then receives one valid icon chain, while the previous attachment remains available for rollback.
Why it matters and when to use it
Use this approach when the Site Icon setting and public browser result disagree, browsers show different marks, or a recent change does not propagate. The ordered trace identifies whether WordPress, the theme, a manifest, the network path, or the browser owns the stale result.
Without that separation, repeated uploads and broad cache purges can hide the original cause, remove a valid rollback image, or make one browser appear fixed while another continues to use a different owner.
A straightforward route for beginners
- Keep the current Site Icon and previous accepted attachment unchanged while collecting evidence.
- Open the public page source and list every
relicon tag in order, plus any manifest icon. - Request each icon URL directly and check its status, MIME type, dimensions, cache headers, and visible image.
- Choose one canonical owner and disable only the duplicate theme, plugin, or snippet output that conflicts with it.
- Fix a broken attachment or purge only the relevant page and icon URLs from caches.
- Retest in a clean browser profile, after a browser restart, with a bookmark, and on another device.
The advanced route
Capture one request chain for every candidate icon. Include the public page URL, tag order and size attributes, direct icon URL, HTTP and HTTPS hostname, redirects, response status, MIME type, dimensions, cache headers, content hash, and result from more than one CDN location.
- Confirm that the active theme calls the standard head hook and that the expected multisite blog owns the attachment.
- Compare ETag and Last-Modified values across the origin and edge, including cached 404 responses.
- Check whether a service worker or web app manifest intercepts or replaces the browser request.
- Distinguish page cache, CDN cache, service-worker cache, and the browser favicon database.
- When the same URL serves changed bytes, compare its behavior with a deliberately versioned filename without changing several owners at once.
Risks, common mistakes, backup, and rollback
Uploading a new file after every test, deleting an attachment that page source still references, hard-coding another link tag, changing several owners together, or clearing all site caches makes the fault harder to locate. An administrator session may also bypass the page cache that visitors receive.
Roll back if the canonical owner becomes unclear, direct icon requests fail after the change, head output disappears, another multisite site is affected, or cache invalidation spreads beyond the icon. Restore the previous Site Icon and competing output only as needed, then retest its direct response and public markup.
How AIOWS helps:
AIOWS Favicon Manager
AIOWS Favicon Manager gives the active WordPress Site Icon a clear place to be selected, previewed, replaced, and published. When an icon is missing or stale, use the module as the WordPress-side reference point: note the selected attachment and keep it unchanged while comparing the public markup and direct file responses.
Start with the rendered page source. List the WordPress icon tags, any theme or plugin tags, and manifest references in their actual order. Request each URL directly and compare its status, MIME type, dimensions, hostname, cache headers, and content. This shows whether the selected Site Icon is absent from the page, shadowed by another owner, or served incorrectly downstream.
Use a clean browser profile only after the public tag and direct response are correct. Compare another network path or device when a CDN may hold different bytes, and check service-worker or manifest behavior separately. If an old icon remains, diagnose the URL that the browser requests instead of repeatedly replacing the Site Icon.
Favicon Manager cannot force browsers to discard their favicon database, repair a missing theme head hook, purge every external CDN node, or control icons supplied by an external manifest. If duplicate markup or a broken response is introduced, restore the previous attachment and reverse only the identified owner or cache change. Record the selected attachment, rendered tags, direct-response hashes, cache layers, browser tests, and rollback image.
Related AIOWS articles
- How to Add a Favicon to WordPress Correctly
- When Should You Purge WordPress Cache?
- Elementor Changes Not Showing Because of Cache
Conclusion and recommended route
Keep one source stable, compare the active Site Icon with the rendered tags, and follow the chosen tag to its direct response. Repair the first layer that serves missing or stale output, then verify the result in clean browser contexts. Change the image itself only when the publishing path is already proven.
