Google SEO Favicon Setup for a Multilingual Export Website

A hostname-level decision guide for export operators whose English and Chinese pages share one domain: choose one brand favicon, keep it distinct from the corporate logo and product images, place the head link correctly, keep the icon URL stable, confirm Googlebot and Googlebot-Image access, and treat eligibility as separate from display. All factual claims come from Google Search Central’s favicon documentation; no ranking, citation or display outcome is promised.

One hostname, one favicon: the decision your English and Chinese pages share

If your export site serves English pages under one path and Chinese pages under another on the same domain, the favicon question is not a per-language question. It is a hostname question, and it has exactly one answer.

Google Search only supports one favicon per site, where a site is defined by the hostname. The documentation gives the example that https://www.example.com/ and https://code.example.com/ are two different hostnames and therefore can have two different favicons, while https://www.example.com/sub-site is a subdirectory of a site, and you can only set one favicon for https://www.example.com/, which applies to the site and its subdirectories (Google: Define a favicon to show in search results).

Read that against your own URL layout. If your English export pages live at a path such as /en/... and your Chinese pages at /zh/... on the same host, they are subdirectories of one site. You cannot give the English section one icon and the Chinese section another. Whatever favicon you set applies to both, and to every other path on that host.

Google’s guideline treats a different hostname as a separate site for favicon purposes. Choosing a subdomain purely to vary a favicon is almost never worth it, and this article does not recommend it. Decide the broader language architecture around the buyers you serve, not the icon alone.

So the first decision is not "what should the icon look like." It is "which single hostname am I setting this for, and does that hostname carry both language versions?" For most export sites the answer is yes, and the practical consequence is that the icon must read as your brand to an English-speaking buyer and a Chinese-speaking buyer at the same time. That constraint shapes the asset choice in the next section.

If you are still deciding how your language versions should be structured in the first place, the URL and hreflang layer is covered separately in Multilingual Website SEO: Language Signals and Acceptance. The favicon decision assumes that structure already exists and simply inherits its scope.

Favicon, corporate logo, product image: three different jobs

The favicon is the icon that represents your site. Google’s documentation describes it as "the icon that represents your site, as defined in the HTML standard," and says that to help people quickly identify your site when they scan through search results, the favicon should be visually representative of your website’s brand (Google: Define a favicon to show in search results).

That is a specific job, and it is not the same job as your corporate logo or your product images.

Your corporate logo is a page-level brand asset. It typically carries a wordmark, a full company name, or a lockup that only works at a certain size and against a certain background. It lives in the page header, in documents, and in signatures. A favicon is rendered tiny — Google’s own minimum is 8x8px, and the recommendation is to go larger than 48x48px so it looks good on various surfaces. A wide horizontal lockup with a long wordmark does not survive that reduction; what survives is a compact, recognizable mark.

Your product images are a different job again. They show what you sell, they belong on product and category pages, and they are chosen per item. A favicon is chosen once per hostname and represents the whole site, not one product line. Reusing a product photo as the site icon means your search-result identity changes meaning every time your catalog changes, and it tells a buyer nothing about who you are.

The favicon is therefore its own asset with its own requirements, and those requirements are technical as well as visual. It must be square, with a 1:1 aspect ratio, and at least 8x8px, with larger than 48x48px recommended. Google Search supports the following favicon file formats: BMP, GIF, ICO, PNG, JPEG, PPM, and TIFF (Google: Define a favicon to show in search results).

A practical way to decide: take your corporate logo, remove everything that is not the core mark, and check whether it is still identifiable as a square at small size. If it is, you have a candidate. If it is not, you need a simplified brand mark rather than a crop of the logo. Either way, the asset you place is a dedicated favicon file, not the logo file and not a product image.

One boundary worth stating plainly: this is a brand-representation guideline, not a design specification. Google does not tell you what your mark should look like, and nothing here guarantees that a well-designed icon will be displayed.

Placing the head link and keeping the icon URL stable

Implementation is small. To make your site eligible for a favicon in Google Search results, you create a favicon that follows the guidelines and add a <link> tag to the header of your home page, with syntax like <link rel="icon" href="/path/to/favicon.ico"> (Google: Define a favicon to show in search results).

Two attributes matter. The first is rel. Google supports the following values for specifying a favicon, and you use whichever fits your case: icon (the icon that represents your site, as defined in the HTML standard), shortcut icon (supported for historical reasons as an earlier alternative version of icon), apple-touch-icon (an iOS-friendly icon), and apple-touch-icon-precomposed (an alternative for earlier versions of iOS). If you are unsure, icon is the direct choice; the others exist for specific platform behaviour rather than for Google Search itself.

The second is href. The URL can be a relative path such as /smile.ico or an absolute path such as https://example.com/smile.ico, and it does not need to be hosted on your site — Google’s documentation explicitly notes that your favicon could be hosted on a content delivery network (CDN) (Google: Define a favicon to show in search results).

That CDN option is worth pausing on for an export site, because it is where a common mistake hides. If the icon is served from a CDN, the file still has to be crawlable by Googlebot-Image (covered in the next section). If a CDN blocks the relevant crawler, or an expiring signed icon URL is no longer fetchable when that crawler requests it, the access check has failed even though the head link is present. A signed URL is not automatically blocked: check whether the same URL remains accessible without a buyer session. Hosting the icon on your own hostname removes one moving part; hosting it on a CDN is allowed but adds an access check you must actually perform.

The stability requirement is the part teams underestimate. Google states that the favicon URL must be stable and should not change frequently. The useful implementation boundary is Google’s stated stable-URL requirement, not a claim that every URL change restarts a particular internal process. If your build pipeline hashes asset filenames on every deploy, your favicon URL changes on every release. That is the opposite of stable. Pin the favicon to a fixed path that does not carry a content hash, and change the file behind that path when the mark changes.

Finally, note where the tag goes: the header of your home page. For a hostname serving both English and Chinese pages, that is the home page of the host, not a language-specific landing page. If your home page redirects by language, fetch the hostname’s home page, follow the redirects and inspect the final HTML and icon URL. This is an implementation check, not proof of how Google will identify or display the favicon.

Crawl access: Googlebot and Googlebot-Image

Eligibility has an access precondition that is easy to miss because it involves two different crawlers. Googlebot-Image must be able to crawl the favicon file, and Googlebot must be able to crawl the home page; neither can be blocked for crawling (Google: Define a favicon to show in search results).

Read that as two separate checks, because they fail for different reasons.

The first check is the icon file. Googlebot-Image has to be able to fetch it. On export sites this fails in a few recurring ways: a robots.txt rule that disallows an image directory or a file extension; a CDN or WAF rule that challenges non-browser user agents; a hotlink-protection setting that only permits requests with a matching referrer; or a path that returns a redirect chain ending somewhere the crawler will not follow. Any of these can leave a correct <link rel="icon"> tag pointing at a file that is never fetched.

The second check is the home page itself. Googlebot has to be able to crawl it. If your home page is blocked, or if it is only reachable through a redirect that is itself blocked, the favicon information has no page to be extracted from. This is a distinct failure from the icon being unreachable, and it is worth testing separately rather than assuming that a reachable icon implies a reachable home page.

A practical diagnostic order follows from this. Confirm the home page is fetchable by Googlebot. Confirm the icon URL returns a successful response to Googlebot-Image. Confirm the <link> tag is present in the served HTML of the home page — not only in the rendered DOM after client-side execution, since the tag needs to be discoverable in the document Google processes. Only after those three are true is the access precondition satisfied.

If your site has broader crawl or indexation problems, this favicon check is a narrow slice of a larger diagnosis; the staged approach in Google Not Indexing Pages: Diagnose One Exact URL by Index-Status Stage is the right companion when the problem is not limited to the icon.

Eligibility is not a display guarantee

This is the expectation to set before anyone reports a bug. Google states plainly that a favicon isn’t guaranteed to appear in Google Search results, even if all guidelines are met (Google: Define a favicon to show in search results).

So the correct reading of everything above is: those steps make your site eligible. They do not make display happen, and no amount of correct implementation converts eligibility into a promise. If you are evaluating this work, judge it on whether the site is eligible and crawlable, not on whether an icon is visible in a result you happened to check.

There is one case where Google actively withholds an icon rather than simply not showing it. Google won’t show any favicon that it deems inappropriate, including pornography or hate symbols, and if that type of imagery is discovered within a favicon, Google replaces it with a default icon. For an export brand this is mostly a reminder that the icon is subject to a content policy, not just a technical one — and that a replaced icon is a policy outcome, not a caching glitch to be retried.

Timing is the other thing to plan for. Google advises allowing time for it to recrawl and process the new information on your home page, and notes that crawling can take anywhere from several days to several weeks, depending on how often its systems determine content needs to be refreshed. It also notes that you can request indexing of your site’s home page using the URL Inspection tool (Google: Define a favicon to show in search results).

Two cautions on that. The "several days to several weeks" range is Google’s own description of crawl timing in general, not a measured value for your site, and it is not a deadline you can hold anyone to. And requesting indexing is a request, not a guarantee of recrawl or of display. Treat it as the correct action to take once the tag, the file and the access checks are all confirmed — not as a fix for a problem you have not yet diagnosed.

A short decision rule closes this out. If the head link is present on the host’s home page, the icon URL is stable and returns a successful response to Googlebot-Image, the home page is crawlable by Googlebot, and the asset meets the size and format requirements, then you have done the work correctly and the remaining variable is Google’s, not yours. If any of those is false, fix that item first. What you should not do is change the icon URL repeatedly in the hope that a new URL will be picked up faster. Keep the URL stable, as Google’s guideline requires.