A reliable favicon needs a valid declaration and a valid image response
The report combines icon declarations from the page with a conventional /favicon.ico fallback, requests each candidate, checks the response and image dimensions, and compares Server HTML with the Rendered DOM. Fix transport and file validity first, then refine sizes, format coverage, and platform-specific assets.
- Declare at least one stable icon URL in the Server HTML head.
- Return a successful image response with the correct Content-Type instead of HTML or an error page.
- Use square artwork and provide dimensions that match the real file.
- Keep favicon URLs crawlable, cacheable, and consistent across templates and deployments.
What the favicon test checks
seoreport.ro collects icon links from Server HTML and the Rendered DOM, resolves their URLs against the final page URL, and also checks /favicon.ico as a conventional fallback. Each unique candidate is requested so the report can distinguish a declaration from a resource that actually works.
The summary separates declared, valid, and checked candidates. The detailed checks cover broken declared resources, square dimensions, declared-versus-actual sizes, Google-friendly multiples of 48, mixed content, and differences introduced only after JavaScript rendering.
- Declared Icon candidates found in link elements, plus the conventional fallback when applicable.
- Valid Candidates that return a successful response and can be recognized as an image.
- Checked Unique favicon URLs requested by the resource audit, including failed responses.
Declare icons in the document head
Use link rel="icon" in the head and keep the href stable. The type and sizes attributes are hints that help a user agent choose among candidates; they do not repair an incorrect response or resize the underlying file. Relative URLs are resolved against the document base URL, so an unexpected base element can redirect the request to a different location.
A compact set usually includes a scalable SVG or a well-sized PNG, with an ICO fallback when legacy coverage is important. Platform-specific assets such as apple-touch-icon or web app manifest icons serve different surfaces and should not be assumed to replace the standard favicon declaration everywhere.
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon-48.png" sizes="48x48" type="image/png">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
Choose formats and dimensions deliberately
Square artwork avoids distortion and unexpected cropping. Raster icons should remain legible at small sizes and use actual pixel dimensions appropriate to their declaration. SVG can scale cleanly, but the file still needs a valid image response and artwork that remains recognizable when reduced.
Google Search requires a square favicon and recommends dimensions that are a multiple of 48 pixels, such as 48×48, 96×96, or 144×144. Browser tabs can use smaller raster candidates, so one project can legitimately provide more than one size while keeping the visual identity consistent.
- PNG Predictable raster rendering and transparency; declare dimensions that match the file.
- SVG Scalable and compact for suitable artwork; test browser and platform support required by the project.
- ICO Useful as a conventional fallback and capable of containing several raster sizes in one file.
- Google Search Use a crawlable square icon with a stable URL, and prefer a size that is a multiple of 48 pixels.
Keep the icon available in Server HTML
A client-rendered application can insert or replace icon links after JavaScript executes. Browsers may notice that change, but crawlers, link unfurlers, and constrained clients may rely on the original response. Declare the primary icon in Server HTML and use JavaScript changes only for intentional state-specific behavior.
When the Server HTML and Rendered DOM values differ, inspect templates, head-management libraries, hydration, route transitions, and consent-dependent scripts. Duplicate declarations can also make different clients select different candidates according to format and size support.
Diagnose failures and stale icons
Open the exact icon URL from the final public page and inspect the status, redirect chain, Content-Type, response body, and intrinsic dimensions. Fix relative-path mistakes, blocked hotlink protection, authentication, mixed HTTP content, CDN rewrites, and applications that return a branded HTML 404 with status 200.
Favicons are cached aggressively by browsers, CDNs, and search systems. After publishing a corrected file, purge the relevant cache and use a versioned URL when the asset genuinely changed. Then rerun the report against production. Search-result changes are not immediate because Google must recrawl and reprocess the icon.
- 404 or 5xx Publish the asset at the declared path and verify every redirect ends at a successful image response.
- HTTP 200 with HTML Correct routing, authentication, or fallback behavior so the URL returns the actual image and media type.
- Mixed content Serve the icon over HTTPS when the page itself uses HTTPS.
- Stale preview Check browser and CDN caches first; allow time for external platforms to fetch the new URL.
Publish a favicon that works beyond one browser tab
- 01Add a stable link rel="icon" declaration to the Server HTML head.
- 02Request every declared URL and verify the final status, Content-Type, and image body.
- 03Confirm that raster files are square and their declared sizes match the intrinsic dimensions.
- 04Provide a crawlable square candidate whose size is a multiple of 48 pixels for Google Search.
- 05Remove mixed content, accidental duplicate declarations, and unnecessary Server HTML versus DOM differences.
- 06Purge relevant caches, rerun the production report, and allow external platforms time to recrawl.
Official references
The technical recommendations in this guide are aligned with these primary sources.