Favicon Audit Checklist for Developers (2026)

A favicon audit confirms your site ships every icon file browsers and mobile platforms expect, that HTML tags point to reachable URLs, and that /favicon.ico exists at the domain root. Run the checklist on production, not localhost, before every branding deploy or domain migration.

This is a developer-focused pass you can copy into PR templates, QA tickets, or CI scripts. Pair it with Favicon Check for automated discovery and Open Graph Check for share metadata.

When to run a favicon audit

Trigger an audit when:

• Launching a new site or subdomain
• Rebranding logo or colors
• Migrating frameworks (WordPress to Next.js, CRA to Vite)
• Adding PWA install support
• Users report wrong tab icons or blurry home screen shortcuts
• Merging head-tag changes from multiple teams

Skip a full audit for copy-only deploys unless your CMS touches the document head.

Phase 1: Inventory declared icons

Open Favicon Check, enter your canonical production URL, and export the mental inventory:

• Every link rel="icon" entry
• apple-touch-icon tags
• Linked web app manifest and its icon array
• HTTP status for each URL
• Whether /favicon.ico responds at the site root

Document findings in your ticket. Example table:

Automated scan first. Manual checklist second.

Phase 2: HTML head audit

View Page Source on the homepage (not DevTools Elements panel alone).

Required checks

• At least one link rel="icon" with correct type and sizes
• Icons use root-relative or absolute HTTPS URLs
• No duplicate conflicting rel="icon" from plugins or legacy templates
• apple-touch-icon present at 180×180
• link rel="manifest" present if PWA icons are required
• Tags appear in raw HTML without JavaScript execution

Red flags

• Staging domain in href (staging.example.com)
• Relative paths without leading slash (icons/favicon.png)
• HTTP URLs on HTTPS site (mixed content)
• Data URIs for large icons (hard to cache debug)

Reference: How to Add a Favicon (HTML).

Phase 3: File format and size audit

Download each icon from the scan and inspect pixels.

Master file should be at least 512×512. Never upscale small sources. See Favicon Sizes Guide and Favicon Looks Blurry.

Phase 4: Root fallback audit

Browsers and tools request https://yourdomain.com/favicon.ico even when HTML declares PNGs.

• /favicon.ico returns 200
• Content-Type is image/x-icon or image/vnd.microsoft.icon
• File matches current brand (not default host placeholder)
• Redirect chain is short (prefer direct 200)

If ICO is intentionally omitted, document the risk: email clients and legacy crawlers may show generic icons.

Phase 5: Web manifest audit

For PWAs and Android home screen branding:

curl -s https://example.com/site.webmanifest | jq .

• Valid JSON, no trailing commas
• icons array includes 192×192 and 512×512
• Each src resolves to 200 on production
• purpose values correct (any, maskable if adaptive icons needed)
• Manifest linked in HTML head

Tab favicon alone does not satisfy manifest requirements.

Phase 6: Cross-browser and device spot checks

Automated scans miss rendering quirks. In a clean browser profile or incognito:

• Chrome desktop tab at 100% and 125% zoom
• Firefox tab icon
• Safari macOS tab (and pinned tab if relevant)
• iOS Safari Add to Home Screen preview
• Android Chrome install or add to home screen
• Bookmark bar icon after saving site

Detailed steps: How to Test Favicons Before Launch.

Phase 7: Cache and CDN audit

After icon changes, stale cache causes false QA failures.

• Purge CDN HTML and static assets
• Confirm cache headers on icon URLs (Cache-Control reasonable)
• Version or rename files after rebrand (favicon-2026.ico)
• Verify incognito shows new icon on production

If users still see old icons post-deploy, see Favicon Not Showing.

Phase 8: Host and routing audit

• www and apex both serve correct icons (or 301 to canonical)
• Subpath deploys include base prefix in icon URLs
• Auth walls do not block /favicon.ico (some staging setups 401 icons)
• robots.txt does not block icon paths (uncommon but possible)

Phase 9: Framework-specific audit notes

Next.js App Router

Confirm app/icon.png, app/favicon.ico, or metadata.icons in root layout. No duplicate next/head tags. Guide: Favicon in Next.js.

WordPress

Site Icon in Customizer active, theme not overriding. Root ICO if host allows. Guide: Favicon in WordPress.

Vite / React SPA

Icons in public/, tags in index.html, correct base in vite.config. Guide: Favicon in Vite/React.

Phase 10: Open Graph separation audit

Favicons and OG images share branding but not files or tags.

• og:image points to 1200×630 (or platform-appropriate) share image
• Favicon tags do not reference OG image URL
• Both pass separate scans: Favicon Check and Open Graph Check

Explain the split to stakeholders: Favicon vs Open Graph Image and Open Graph Tags Explained.

Copy-paste developer checklist

FAVICON AUDIT - Production URL: _______________

[ ] Favicon Check scan - all icons 200
[ ] View Source - tags in raw HTML
[ ] /favicon.ico - 200 at domain root
[ ] 16x16 + 32x32 PNG declared
[ ] apple-touch-icon 180x180
[ ] Manifest icons 192 + 512 (if PWA)
[ ] No staging URLs in href
[ ] HTTPS, no mixed content
[ ] CDN/cache purged after change
[ ] Incognito tab test - Chrome + Safari
[ ] iOS home screen preview
[ ] Android shortcut icon
[ ] OG scan separate (Open Graph Check)
[ ] Documented exceptions: _______________

Sign off in PR description or release notes.

Automating parts of the audit

CI can assert:

# Example: fail if favicon.ico missing
curl -sf -o /dev/null -w "%{http_code}" https://example.com/favicon.ico | grep -q 200

Parse homepage HTML for required rel values. HEAD-request each icon URL.

Automation catches 404s, not blur or wrong crop. Keep manual spot checks for releases.

Common audit failures (ranked)

1. 404 on apple-touch-icon - iOS home screen looks broken
2. Missing /favicon.ico - email and legacy tools show generic globe
3. Client-only favicon tags - crawlers see nothing in View Source
4. Wrong base path on SPA - icons 404 on nested routes
5. Stale CDN cache - team thinks deploy failed
6. Duplicate tags - unpredictable browser pick
7. Upscaled tiny PNG - blurry tabs everywhere

Fix order: status codes first, dimensions second, cache third.

FAQ

How often should developers audit favicons?

Every deploy that changes icons, manifest, head markup, CDN config, or domain. Quarterly audit for stable sites is reasonable.

What tools do I need for a favicon audit?

Favicon Check for URL scan, browser incognito for visual check, curl or jq for manifest, image editor to verify pixel dimensions.

Does Lighthouse audit favicons?

Lighthouse may note missing icons but does not validate every size and manifest entry. Use a dedicated checklist plus Favicon Check.

Should favicon audit be in CI or manual QA?

CI for HTTP 200 and tag presence. Manual QA for visual quality and mobile home screen.

What is the minimum passing favicon audit?

/favicon.ico 200, one PNG icon tag, apple-touch-icon 180×180 if mobile audience matters. PWAs also need manifest 192 and 512.

How do I audit favicons after a merger of two codebases?

Scan production, diff View Source against both legacy templates, remove duplicate head output, re-run scan on canonical domain.

Audit favicon on staging or production?

Staging catches deploy bugs early if URLs are public. Final sign-off must be production with production CDN and DNS.

Who owns the favicon audit, design or engineering?

Engineering owns tag correctness and HTTP status. Design owns crop and legibility at 16×16. QA owns cross-browser spot checks.

Conclusion

A developer favicon audit is ten phases: automated scan, HTML source, file sizes, root ICO, manifest, browsers, cache, routing, framework specifics, and OG separation. Use the copy-paste checklist on every branding release.

Start with Favicon Check on production, fix 404s, then walk device spot checks. Add Open Graph Check when the same release touches share metadata.