A favicon rebrand is more than exporting a new icon. This checklist helps you inventory every favicon and app icon, update HTML and manifest references, manage cache layers, verify the result across browsers and devices, and maintain a rollback plan when an old icon continues to appear.
Overview
When a company changes its logo, the favicon is easy to overlook because it is a small asset with several delivery paths. A website may expose an ICO file, one or more PNG files, an SVG favicon, an Apple touch icon, and icons declared in a web app manifest. Browsers can also retain previously fetched assets in local caches, while bookmarks, home-screen shortcuts, installed web apps, search previews, and third-party tools may update on different schedules.
The practical goal of a favicon migration is therefore consistency: the new visual identity should be available at every intended URL, declared with the correct markup, delivered through the expected CDN and hosting layers, and recognizable at small sizes. The checklist below is designed for a logo redesign, domain migration, major application refresh, or any change where the old favicon must be retired deliberately.
Before changing production, create a small record of the current implementation. Save the existing files, HTML tags, manifest, deployment configuration, and CDN paths. This makes comparison and rollback much easier than trying to reconstruct the previous state after release.
What to track
1. Build an asset inventory
List every identity asset that may display a browser or application icon:
- Document icons: favicon.ico, PNG favicons, and any SVG favicon references.
- Platform icons: Apple touch icons and other mobile shortcut assets used by your project.
- Web app icons: each icon entry in manifest.webmanifest or manifest.json, including its URL, format, and declared sizes.
- Framework locations: static, public, app, or metadata directories that generate head tags automatically.
- Environment copies: production, staging, preview, regional, and subdomain versions.
- Brand references: documentation, screenshots, design-system packages, templates, and tests that still use the old mark.
Record the old URL and the planned replacement URL for each asset. Keeping the same filename can reduce configuration changes, but a versioned filename or query string can be useful when you need a clear cache-busting signal. Whichever approach you choose, update all references consistently rather than mixing old and new paths.
2. Inspect the actual HTML and manifest
Do not rely only on source files. Inspect the rendered page in production or a production-like environment. A basic favicon HTML setup might look like this:
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon-32.png" type="image/png" sizes="32x32">
<link rel="apple-touch-icon" href="/apple-touch-icon.png" sizes="180x180">
<link rel="manifest" href="/site.webmanifest">The exact set of tags depends on your browser and platform requirements. Keep the implementation intentional: remove obsolete references, confirm every path resolves, and make sure the icon files are served with suitable content types. For broader format and dimension guidance, see the favicon size, format, and HTML guide.
Then inspect the web app manifest. Confirm that every icon URL points to the new artwork and that the declared sizes and formats match the files being served. If an installed web app continues to show the old icon, the manifest or the installed application state may be involved rather than the page head alone.
3. Check visual quality at real sizes
Review the new icon at its smallest practical display size, not only on a large design canvas. Remove fine detail that collapses, test contrast against light and dark browser surfaces, and verify that transparent padding does not make the mark appear unexpectedly small. If the logo includes text, consider whether a simplified symbol will work better as a favicon. A logo-to-favicon export workflow can help separate the full brand mark from the compact icon used in browser tabs.
Cadence and checkpoints
Use a staged migration sequence instead of replacing files without a record. The following checkpoints work for most websites:
- Before release: archive the old assets, create the new exports, compare filenames and dimensions, and search the codebase for every old favicon reference.
- In a test environment: validate the rendered HTML, manifest, response status, content type, and redirects. Test both the root domain and important application routes.
- At deployment: publish the new assets, update markup and manifest references, and invalidate the relevant CDN or reverse-proxy objects if your delivery setup supports that operation.
- Immediately after release: request the asset URLs directly, inspect the page source or rendered head, and confirm that the new files are returned from the expected host.
- After propagation: test a fresh browser profile, a normal browser session, a private window where appropriate, a mobile browser, and an installed or bookmarked shortcut if those are part of your audience's workflow.
- After one review cycle: check analytics, support reports, screenshots, and internal tools for lingering references to the old icon.
Avoid assuming that clearing your own browser cache proves the migration is complete. Browsers and intermediary caches can behave differently, and users may have saved icons before the redesign. If the new icon uses a new filename, keep the old file available temporarily when a rollback or gradual transition is important. If you remove it immediately, confirm that no active HTML, manifest, shortcut, or application package still requests it.
For sites with several domains or environments, maintain a small matrix of hostnames, icon URLs, manifest URLs, and expected brand versions. The guide to favicons across domains, subdomains, and environments provides a useful structure for that inventory.
How to interpret changes
When an old favicon appears after deployment, classify the problem before changing more files. If a direct request to the icon URL returns the old image, inspect the origin, CDN, proxy, or service-worker cache. If the direct request returns the new image but a tab shows the old one, the browser may be reusing a previously stored resource. Test a fresh profile and compare results across browsers before adding unnecessary markup.
If browser tabs show the new icon but a phone shortcut does not, inspect the Apple touch icon, manifest icons, and the shortcut's saved state. Removing and recreating a test shortcut can distinguish a stale installed asset from a missing or incorrect file. If an installed web app is affected, check the manifest and its icon URLs as a separate path from the normal document favicon.
If only one route displays the old icon, look for route-specific layouts, server-rendered metadata, framework defaults, or an older cached HTML document. A favicon can appear correct on the homepage while a nested application route still emits a different tag. Search generated HTML as well as source code.
Keep a rollback plan that names the previous asset set, deployment revision, manifest version, and cache actions. A rollback is safer when it restores a known-good combination of markup and files rather than copying individual assets back under pressure. For more troubleshooting patterns, use the favicon not showing checklist.
When to revisit
Review the favicon implementation at least quarterly and whenever the website undergoes a visual, technical, or hosting change. A recurring review is especially useful after a logo update, framework migration, CDN change, service-worker release, domain move, new subdomain launch, or introduction of an installable web app.
At each review, repeat four quick checks: search the repository for old icon filenames, request the production assets directly, inspect the rendered HTML and manifest, and compare the icon on a desktop browser, mobile browser, bookmark, and installed shortcut where relevant. Also verify that staging does not accidentally publish production branding and that production does not retain a framework-generated default icon.
Keep this checklist with the brand or release documentation. When a future rebrand begins, duplicate the inventory, mark each asset as unchanged, replaced, or retired, and assign an owner for final verification. This turns favicon maintenance from a last-minute visual fix into a repeatable part of the identity release process.
For the next migration, start with three actions: export the new icon set, create the before-and-after URL inventory, and schedule a post-release check across browser and app surfaces. Those steps catch most inconsistencies before the old favicon becomes a persistent part of the new brand.
