Favicon Checklist: the Link Tags a Site Needs, and How to Check Them

Two link tags are the core of a favicon setup, one for favicon.ico and one for an apple-touch-icon. Add one for the web app manifest if you want the site installable, and one for an SVG icon if you want a vector. Everything else on the long checklists is either a default the browser already applies or a platform that no longer exists. Which pixel sizes go inside those files is a separate question, answered in the favicon sizes guide; this page is about the markup around them.

Which link tags go in the head?

This is the set the favicon generator writes for you, with the SVG line present only when you start from a letter:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/manifest.webmanifest">

Four lines, each with a job. The first points at the .ico. The second offers a vector icon to browsers that can use it. The third is what iOS reads for the home screen, since, as MDN notes, iOS ignores the standard icon relation and the sizes attribute for that purpose. The fourth is where Android finds the 192 and 512 px PNGs. If you only ship an .ico and an apple-touch-icon, the site still has a working icon everywhere it matters for a browser tab.

Paths start with a slash. A relative path such as icons/favicon.ico resolves against the current page, so it works on the home page and breaks on /blog/some-post/, which is how a site ends up with the right icon on one section and a generic one on the rest.

Does the order of the tags matter?

Only when two icons are equally good candidates. MDN's description of rel="icon" says that when there are several, the browser uses media, type and sizes to pick the most appropriate one, that the last one wins if several are equally appropriate, and that if the best choice turns out to be unusable, for example an unsupported format, the browser moves on to the next best. That is the reason to list the .ico first and the SVG after it: a browser that understands both lands on the SVG, and one that does not falls back to the .ico.

That is the specification wording, not a test of every browser. Browsers have differed on how they weigh an .ico against an SVG, and the sizes="32x32" on the .ico line is the common hedge: it tells the browser what that file is best at rather than leaving it to guess. After any change, look at the tab in the browsers you care about instead of trusting the reasoning.

Which old tags can you leave out?

• rel="shortcut icon". MDN calls the shortcut keyword non-conforming and says authors must not use it any more. Google still accepts it, but plain icon does the same job.
• apple-touch-icon-precomposed. Google's documentation still lists it for earlier iOS versions. A current 180 px apple-touch-icon is the one to keep.
• A sizes attribute on every apple-touch-icon line. A single file does the job, so the six-line version is just six places to forget to update.
• The Windows tile tags and the Safari pinned-tab mask-icon, covered in the sizes guide as formats that have aged out.
• The manifest, if you do not care about installability. It is the one line you can drop without losing the browser-tab icon, because the tab never reads it.

Keep the favicon.ico file at the site root even if the tag points elsewhere. Browsers request /favicon.ico without being told to, so it catches pages where the head is missing or stripped.

How do you check that a live page is serving the right icon?

Four checks, in order of how often they find the problem:

1. Open each file by its URL. Paste /favicon.ico, /icon.svg and the rest into the address bar. You should see an image. If you see your 404 page, the file is not at the root; if you see your home page, a catch-all rule is answering for a missing file with a 200, and the browser will treat the HTML as a broken icon.
2. Read the head of the page that is actually served. View the source of a nested page, not just the home page, and search for rel="icon". Templates that build the head differently for different page types are a common cause of an icon that appears on only some pages.
3. Reload with the cache out of the way. Favicons sit in a cache separate from the page, so a hard reload often changes nothing. A private window, or the icon file opened directly and reloaded, shows what the server sends now.
4. Check that nothing blocks the files. Google says Googlebot-Image must be able to crawl the icon file and Googlebot the home page. A robots.txt rule that covers an assets folder can quietly hide the icon from search while the browser tab looks fine.

The browser's developer tools help with the first two. In the network panel, reload and filter for images, then look for the icon request and its status code. Chromium-based browsers also show the manifest and its icons in the application panel, including errors.

What does Google need for the icon beside your result?

As of October 2026, Google's favicon documentation asks for a link tag in the head of the home page, a square image at a stable URL, and crawl access for both the file and the page. Only one favicon is supported per hostname: a subdomain can have its own, but a subdirectory such as /news/ cannot. The formats the page lists are BMP, GIF, ICO, PNG, JPEG, PPM and TIFF, and SVG is not among them, so keep a raster icon even if your browser tab shows an SVG. The recommended size is larger than 48 px, and a change can take several days to several weeks to show up. Google also says that meeting every guideline does not guarantee the icon is shown. Requesting indexing of the home page in Search Console is the one lever it documents, and it does not make the process instant.

What the generator does not do for you

The generator draws the files and writes the tags. It does not publish anything, so the files still have to be uploaded to the site root. The manifest it writes has a placeholder name, Your site name, which you need to replace, and its icon entries carry no purpose field, so Android will not treat them as maskable artwork. The tag snippet assumes the files sit at the root; a site served from a subfolder needs the paths changed. And nothing in the tool checks a live site: the four checks above are still yours to run.

Last updated October 26, 2026