Check a website favicon before release.

1. Start with the approved brand asset

Identify which existing icon is approved for this purpose and where its source file is maintained. Do not redraw or simplify a locked logo without authorization merely because the favicon is small. If no approved small-format asset exists, record that as a design decision to resolve.

ATN recommends checking recognizability at a small display size before implementation. Keep the proportions and intended colors intact, and avoid silently cropping away meaningful elements. An icon review can reveal a need for an approved variant, but it does not itself authorize a rebrand. This article does not alter ATN’s immutable logo or create a replacement asset.

2. Verify the file and its page reference

MDN describes the icon relationship on an HTML link element as an icon representing the current document. Google’s search documentation also shows a homepage link element pointing to the favicon file. Confirm that the reference points to the intended asset rather than an old filename or a development-only path.

Open the referenced file directly in the relevant environment and check that it is actually an image in a supported format. Inspect the generated page as well as the source template. A correct file sitting in a project folder will not help if the published page points somewhere else or the file was omitted from the deployment.

Sources: [1] [2]

3. Treat search eligibility as a separate check

Google’s current guidance requires a square favicon, with a minimum size of 8 by 8 pixels and a recommendation to use one larger than 48 by 48. It also calls for a stable URL and describes one favicon per hostname for Google Search. Meeting its guidelines does not guarantee display in search results.

Use the current documentation for the search surface you care about rather than carrying an old size rule forward from memory. Public search eligibility also depends on crawlability. Do not change a private site’s access or indexing policy merely to pursue an icon in search; that is a separate owner decision with a different purpose.

Sources: [2]

4. Check the delivered state in context

Review the icon in the browser contexts included in your release check, and record which browsers and devices were actually used. If an old image still appears, inspect the current page reference and delivered asset before assuming the design itself is wrong.

A local preview cannot establish what every browser, cached bookmark, or search result currently shows. Keep the result specific to the environment you inspected.

5. Keep the asset and release record together

Record the asset path, approved version, relevant page reference, and actual check date. If the icon changes later, update the release note and verify the affected environments again. Keep unrelated logos and social-preview images distinct so a future maintainer does not replace the wrong asset.

For Google Search, allow for its recrawl and processing cycle and avoid promising an immediate appearance. Report a successful website deployment separately from an observed search-result update. A clear record makes a small branding detail maintainable while preserving the larger site’s approved identity and audience settings. No search submission or favicon deployment is performed by this guide.

Sources: [2]