A favicon that stays blank or keeps showing your old logo is not one single problem. The page may point to the wrong file, a cached page may still advertise yesterday's icon, or Google may not have processed your change yet. Start by identifying which of those layers is wrong. Re-uploading the same picture repeatedly makes the evidence harder to follow.
This guide uses a three-part check: the icon file, the page declaration, and the surface displaying it. It gives you a stopping point for each stage, so you can tell when to fix a URL, when to clear a relevant cache, and when to leave a working configuration alone. The examples are illustrative; they are not measurements of your website or a promise about search-result timing.
First, name the place where the icon is wrong
Open your homepage in a new browser session and compare it with the place where you noticed the problem. A browser tab, an existing bookmark, a phone's saved home-screen shortcut, and a Google result can preserve different information. A correct tab icon therefore does not prove that every other surface has refreshed. Equally, a wrong search-result icon does not prove that your image upload failed.
Write down the exact hostname, the affected surface, the expected picture, and the date of your last change. Include whether the problem affects your homepage or only an article. This small record prevents a common diagnostic mistake: testing the bare domain while the failing page actually lives on a different subdomain or hostname.
| What you observe | Check next | What would justify a change |
|---|---|---|
| The icon URL itself shows the old artwork | Compare the uploaded file with the served response | The public asset is stale or the wrong file was deployed |
| The icon URL works, but a fresh browser tab is wrong | Inspect the page's icon declarations | The page points elsewhere or supplies conflicting artwork |
| A fresh session works; your usual session does not | Compare the same page and icon URLs in both sessions | A browser-local difference remains after delivery is verified |
| Browser tabs work, but Google does not | Check the homepage declaration and crawler access | A search eligibility issue exists, rather than a general upload failure |
| Only an old phone shortcut is wrong | Compare a newly saved shortcut with the existing one | The saved shortcut retains older icon information |
Check the file before changing the website
Find the actual icon URL in your page's HTML and open that address directly. Do not substitute a guessed /favicon.ico address unless the page uses it. An installation can legitimately point to an image in a media directory or on a CDN. The important question is whether the declared address delivers the intended image to a visitor.
Use the browser's Network panel to inspect the request. Look at the final URL, response status, content type, and preview. A response marked 200 is not enough: an application can return its normal HTML page for an unknown image path. If the preview contains a login screen, challenge page, or your homepage, fix that delivery problem before touching icon markup.
Check capitalization and deployment paths carefully. A file saved as Site-Icon.png does not necessarily exist at site-icon.png. Also distinguish your project's source folder from the public address. A framework may publish files from a local public directory at the website root; including the word public in the visitor-facing URL can then produce a missing file.
For an optional command-line check, replace the example address below with the exact URL copied from your page. This downloads a response into a temporary local file for inspection; it does not modify the website.
curl --location --dump-header favicon-headers.txt \
--output favicon-response.bin \
'https://example.com/favicon-96x96.png'
file favicon-response.binA recognizable PNG or ICO file is useful evidence. HTML or an empty response points to a delivery problem. If a redirect occurs, inspect its destination instead of assuming that redirects are inherently broken. Keep the response headers alongside your observation so you can distinguish a changed file from a changed cache response later.
Inspect every icon declaration, not just the first one
View the homepage source and search for rel="icon". Also inspect the live document's head in developer tools, because scripts or framework metadata can alter the result. Record each URL and its declared type and sizes. Repeat this on an affected inner page if its behavior differs from the homepage.
MDN's icon link reference explains that browsers consider attributes including media, type, and sizes when choosing among candidates. If candidates are equally suitable, the last one wins; an unsuitable format can cause another candidate to be tried. Consequently, a working PNG declaration does not establish which candidate your browser actually selected.
Multiple declarations are not automatically an error. Supplying different formats or sizes can be intentional. The suspicious case is multiple systems advertising different artwork: a theme setting, WordPress Site Icon, and a manually inserted header snippet may each describe a separate logo. Identify which component owns each declaration before removing anything. Keep one coordinated icon set under a clear owner.
For a manually maintained static page, a minimal PNG declaration might look like this:
<link rel="icon"
type="image/png"
sizes="96x96"
href="/favicon-96x96.png">This example assumes that the file really is a 96-by-96 PNG at that address. The sizes attribute describes the resource; it does not resize a different image. Put the declaration inside the document head through your site's supported template or metadata mechanism. Pasting it into an article body is not equivalent to updating the site's head.
Generate a coherent replacement only if you need one
If the artwork is blurry, inconsistent between files, or missing a usable export, rebuild the set from one master design. Start with a simple square mark and inspect it at small sizes. Thin lettering, tiny outlines, and a detailed full-width logo may become unrecognizable in a tab even when the underlying image is technically valid.
Favicon Generator offers text, emoji, image, and SVG inputs, with a downloadable set that includes PNG and ICO variants, an SVG icon, Apple touch artwork, and manifest assets. Use its small-size previews to choose a readable design, then inspect the downloaded files and the generated HTML before deploying them. These are documented product capabilities, not a cross-browser performance benchmark.
Keep a copy of the original master and name the exported files clearly. Compare the small PNG with the larger source: the same color scheme is not enough if cropping has removed a distinguishing part of the symbol. Check both light and dark surroundings. An icon that looks blank against a dark tab may simply have insufficient contrast rather than a delivery failure.
Install only the pieces your site uses. A manifest icon and an ordinary tab icon are separate declarations; adding a manifest does not prove that the tab now references the right file. Similarly, generating a ZIP file does not upload it to your hosting account. Verify the public URLs after deployment rather than treating the download step as completion.
For WordPress, check the Site Icon setting and its output
WordPress calls the favicon a Site Icon. Its documentation places this control under Settings → General in version 6.5 and later. Older versions use Appearance → Customize → Site Identity. Prepare a square image at least 512 pixels on each side; PNG is the documented recommendation. Save the setting and then inspect the public homepage.
Use the built-in setting as your starting point rather than editing a parent theme file. A saved setting is only the first check: the output HTML must reference existing images. If a generated size returns an error, record the missing URL and ask your administrator to inspect image generation or file delivery. Do not assume that installing another favicon plugin will repair a missing derivative.
If a theme has its own icon control, compare that setting with WordPress's Site Icon. Remove a redundant declaration only after identifying its source and preserving a rollback copy of the relevant setting or snippet. Change one owner at a time and reload the public page. Otherwise, a theme change and cache purge performed together can hide which step actually fixed the problem.
Separate a cached page from a cached image
There are two independent things to compare: the HTML containing the icon address and the image returned at that address. If the HTML still names your old file, replacing the new file again cannot help. If the HTML names the correct address but that address returns old pixels, focus on the asset response instead.
Begin with a fresh private session or another browser and use the identical URL. Treat this as a comparison, not proof of the cause: extensions, login status, and browser behavior can also differ. If both sessions receive different page declarations, investigate page caching or personalized output. If they receive the same declaration but different image content, inspect asset caching and the actual network requests.
Purge only the relevant cache layer when you have evidence that it holds stale content. A WordPress page cache, hosting cache, CDN cache, and browser storage are separate controls. Record what you purged and retest the same two URLs. Clearing every cache at once may restore the icon, but it leaves you without a reliable explanation if the problem returns.
A temporary versioned filename can help you compare a genuinely new asset with an old one during a controlled deployment. Once the correct configuration is live, keep a stable final URL. Continually renaming the icon to chase search-result changes creates new variables and works against Google's guidance to keep the icon address stable.
If only Google is wrong, use the search-specific checks
According to Google's current favicon guidelines, the homepage must declare the icon, Googlebot must be able to crawl the homepage and its relevant redirects, and Googlebot-Image must be able to fetch the image. A browser that can see the icon while logged in is not sufficient evidence of crawler access.
As checked on November 6, 2026, Google requires a square icon at least 8 by 8 pixels and recommends one larger than 48 by 48. Its listed formats include PNG and ICO; SVG is not in that current list. A 96-by-96 PNG is therefore a practical choice, not a special mandatory Google size. Older advice requiring multiples of 48 should not override the current documentation.
Google treats hostnames separately and does not provide independent favicons for subdirectories. After a valid change, recrawling and processing may take days to weeks. You can request homepage indexing through Search Console, but meeting the guidelines does not guarantee display. Leave a verified installation stable while waiting.
For a useful handoff to a developer, preserve the exact homepage URL, its icon declarations, the fetched image address, and the date the configuration became correct. That gives them something concrete to compare against crawl restrictions and deployment history. A screenshot of the search result alone does not reveal which layer needs attention.
Stop when the evidence shows the installation is correct
Your local installation is in good shape when the intended public image loads, the homepage and affected inner page advertise the correct set, and a fresh browser session displays recognizable artwork. Save those observations as your baseline. If only a previously saved shortcut or search result differs, investigate that surface without repeatedly changing the working website.
The most useful habit is to make each change answer one question. Fix a broken file URL, verify it, then inspect the declaration. Fix conflicting declarations, verify them, then compare sessions. This order turns a vague “favicon will not update” complaint into a small, testable chain and keeps an otherwise harmless icon repair from becoming an unnecessary site-wide configuration change.
