Google Site Names for Export Brands Sharing One Hostname

Google’s site name is the name of the site a page comes from, and it is separate from the per-page title link and from the favicon. Google Search supports only one site name per domain or subdomain and does not support site names at the subdirectory level, so an export brand serving /en/ and /zh/ paths from one hostname cannot give each language path its own site name. The WebSite structured data must sit on the domain or subdomain root home page, with name and url required and alternateName optional, and the chosen name should match how the home page refers to the site elsewhere. This article explains the naming decision, the placement rule, the fallback behavior, and a bounded diagnostic sequence for when the preferred name is not shown.

The site name is not your article title or your favicon

When an export brand’s search result shows a brand name above a product title, two different displayed elements are on screen, and they are controlled by different systems. Google describes the site name as the name of the site the page comes from, and states that it is different from the per-page title links, because title links are specific to each web page whereas the site name is for the entire site (https://developers.google.com/search/docs/appearance/site-names).

That distinction decides what you are actually fixing. If the brand line above a result reads as a domain name or an unexpected string, the object to change is the site name. If the clickable headline reads as a truncated or rewritten product title, that is the title link, which is generated from page content and references to the page. Changing the site name will not rewrite the headline, and rewriting the headline will not change the brand line.

The favicon is a third object. It is the small icon shown alongside the result, and it has its own hostname-level rule that is covered separately in Google SEO Favicon Setup for a Multilingual Export Website. This article is about the name only.

For an export brand, the practical reason to separate these three is that a single result can look wrong in three independent ways at once. A buyer scanning a result sees an icon, a brand line, and a headline. Only one of those is the site name, and only that one is governed by the WebSite vocabulary described below.

One hostname means one site name, even across /en/ and /zh/

This is the constraint that most often surprises export operators, and it is stated plainly in Google’s technical guidelines: Google Search only supports one site name per site, where a site is defined by the domain or subdomain, and it does not support site names at the subdirectory level (https://developers.google.com/search/docs/appearance/site-names).

Read that against a typical export layout. If English pages live under a path such as /en/ and Chinese pages under /zh/ on the same host, those are subdirectories of one site. Google’s own example marks a subdirectory-level home page such as https://example.com/news as not supported for its own site name. So there is no supported way to give the English path one site name and the Chinese path another while both remain paths on the same hostname.

The boundary is the hostname, not the folder. Google’s documentation lists a domain-level home page, a www host, and an m host as supported, and notes that subdomain names starting with www or m are generally considered equivalent to the domain-level home page. A separate subdomain such as news.example.com is treated as its own subdomain-level site and can carry its own site name. That is a real architectural option, but it is a language-architecture decision with consequences well beyond the brand line, and it should not be made for the sake of a label.

The consequence for the single-hostname export case is direct: the one name you set has to read as your brand to buyers in every language served from that host. If your English and Chinese buyers know the company by different names, you cannot resolve that by assigning two site names to two paths. You resolve it by choosing one name and using alternateName to give the automated system other options to consider, which is covered below.

Where the WebSite markup has to live

The placement rule is as strict as the scope rule. Google states that the WebSite structured data must be on the home page of the site, and defines home page as the domain or subdomain level root URI. Its example is explicit: https://example.com is the home page of the domain, while https://example.com/de/index.html is not the home page (https://developers.google.com/search/docs/appearance/site-names).

For an export site, this rules out the tempting shortcut of putting the markup on a language landing page. A /en/ or /zh/ index is a path, not a root URI, so markup placed there is not on the home page for this purpose. The markup belongs on the root of the hostname that carries your language paths.

Two further rules explain behavior you may already have observed. First, if there is no structured data on a subdomain’s home page, the domain-level site name may be used for the subdomain as a fallback. That is why a subdomain can appear to inherit the main brand name without any markup of its own. Second, the home page must be crawlable by Google; if Google cannot access the content on your home page because it is blocked, it may not be able to generate a site name at all. A robots.txt block, a noindex directive, or a login requirement on the root URL is therefore not a neutral condition for this feature.

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

Choosing the name and the alternateName list

The required properties are short: name, which is the name of the website, and url, which must be set to the canonical home page of your site’s domain or subdomain (https://developers.google.com/search/docs/appearance/site-names). Everything else is a judgment call about what to put in name.

Google’s guidance for that judgment is worth reading as a set of constraints rather than preferences. Use a concise, commonly-recognized name; the documentation’s own example is "Google" rather than "Google, Inc." There is no stated length limit, but long site names may be truncated on some devices. Avoid a generic name, because a generic name is unlikely to be selected unless it is an extremely well-recognized brand name. And use a name that accurately reflects the site’s identity without being misleading.

For an export brand, the truncation point matters more than it first appears. A name that reads well in a desktop result may be cut on a smaller screen, and the part that survives truncation is the part a buyer actually reads. A short, distinctive brand token is more robust than a full legal entity name with a country suffix.

There is also an availability constraint that export brands run into more often than domestic ones. Google states that its system generally will not use the same site name for two different sites that are global in nature, and that in other cases it might determine a site is more commonly recognized by an acronym than by a full name. If your brand name is close to another global brand’s, or if your buyers already refer to you by an acronym, the preferred name may not be the one that gets used.

That is what alternateName is for. It is an optional recommended property for an alternate version of the site name, such as an acronym or shorter name, and you can list more than one alternative, specified in order of preference with the most important listed first. A practical export configuration is the full brand name in name, then the acronym and any widely used short form in alternateName, ordered by which one you would rather see displayed. Providing alternatives does not guarantee any particular one is chosen; it gives the automated system options to consider if your primary preference is not selected.

Making the home page agree with itself

Choosing a name in structured data is only half of the signal. Google’s guidance is to use the site name consistently across the home page, and to make sure that whatever you use as the site name in structured data is consistent with how you refer to your site in other sources on the home page that the system considers (https://developers.google.com/search/docs/appearance/site-names).

Those other sources are named in the documentation: the system will also consider content in og:site_name, the title element, heading elements, and other text on a home page. WebSite structured data is described as the most important signal if you want to specify a preference, but it is not the only one being read. A home page whose structured data says one thing while its title, its main heading, and its og:site_name say something else is sending a mixed signal about its own identity.

For an export site, the consistency check has a specific shape. The home page often carries a language switcher, a translated tagline, and a heading that may differ between language versions of the root. If the structured-data name is the brand token, the visible brand references on the home page should use that same token rather than a longer legal name or a translated variant.

Two structural rules complete the setup. If you already have WebSite structured data on your site, nest the site name properties in the same node rather than creating an additional WebSite structured data block on the home page. And if you have duplicate home pages for the same content, such as HTTP and HTTPS versions or www and non-www versions, use the same structured data on all page duplicates, not just on the canonical page. The duplicate-home-page rule matters for export sites that have accumulated redirect layers over time, because a duplicate that carries different or missing markup is a second, conflicting statement about the same site.

When the preferred name is not shown

Google states that its system generally tries to use a preferred site name from WebSite structured data when indicated, but that if it is less confident in a name you provided, it may sometimes generate site names using other sources or show a domain or subdomain name (https://developers.google.com/search/docs/appearance/site-names). A domain name appearing in the brand line is therefore a documented fallback, not necessarily a sign that your markup is absent.

The diagnostic sequence below follows the order in Google’s own troubleshooting guidance, adapted to the single-hostname export case.

First, confirm the markup itself. Validate it with a schema testing tool such as Schema Markup Validator to check for syntax errors. Note that site names are not supported in the Rich Results Test, so a clean result there does not validate this feature.

Second, confirm placement and scope. Check that the WebSite structured data is on the root home page and not on a language path, and confirm that you are not attempting to set a site name for a subdirectory. Google states that a subdirectory-level home page such as https://example.com/news is not supported for its own site name. This is the check most likely to explain a persistent mismatch on an export site, because the /en/ and /zh/ paths are exactly the URLs an operator is tempted to mark up.

Third, confirm that other sources on the home page use the preferred name, as described in the previous section.

Fourth, check redirects. Google states that if your page redirects to a page that is visible to Googlebot, the site name will reflect the redirect target. If your root URL redirects somewhere unexpected, the name shown will follow the destination rather than the URL you typed.

Finally, allow time. Google notes that after updating site name structured data, crawling and processing can take anywhere from several days to several weeks. A change that is correct but recent may simply not have been processed yet.

None of these steps guarantees that a specific name will be displayed. They are the checks that determine whether your preference is being expressed correctly and consistently, which is the part you control.