Google's official guidance on hreflang and localized versions

Google Search Central's guidance on multilingual and multiregional websites centers on one key determination: the search system needs to identify the language or regional audience targeted by each URL and confirm that these pages are equivalent localized versions, rather than multiple copies caused by duplicate content, automatic redirects, or confusing parameters.hreflang is a signal that declares the relationship between alternate versions to search engines; it is not a directive that determines indexing, rankings, or mandatory page switching.

Therefore, before implementation, the first question should not be "which language codes should be added?" but rather how the pages relate to one another. If English, German, and Japanese product pages respectively serve the reading needs of different languages, and their core products, feature descriptions, and conversion paths correspond to one another, they are suitable for establishing hreflang relationships. If multiple URLs for the same-language page are generated solely by ad tracking parameters, filter conditions, pagination, or session identifiers, they should not be marked as localized versions of one another.

What does Google mean by "localized versions"?

Localization is not the same as mechanical translation. Google's related documentation distinguishes language versions from regional versions: language versions address "which language the page uses," while regional versions address "which country or region a page in the same language targets." For example, English pages targeting the United States and the United Kingdom can both use en, but when there are material differences in currency, delivery coverage, tax information, contact details, inventory, specifications, or legal notices, en-US and en-GB may be used respectively.

Conversely, if two pages have exactly the same content, prices, and service terms, differing only in domain name or path, forcibly separating them by country may not produce clearer signals. Regional codes should reflect actual differences in content or services, rather than being used to create a large number of similar pages solely based on intended target markets. For B2B websites, product specifications, minimum order quantities, inquiry form fields, and delivery scope often determine whether pages genuinely belong to different market versions; for cross-border online stores, currency, sales regions, and logistics rules are more likely to constitute identifiable localization differences.

Google also emphasizes that the visible body text of a page should match the declared language. Replacing only the navigation bar, footer, or a few button labels while leaving the main descriptions, technical materials, and purchase information in another language does not constitute a reliable language version. The language determination for search results relies primarily on page content. The lang attribute helps browsers and assistive technologies understand the document, but it cannot replace readable body text in the target language.

Three conditions for hreflang

First, the alternate relationship must be bidirectionally complete. When page A declares that B is its German version, page B should also declare that A is its English version; without a return link, the search system has difficulty confirming that this is a maintained corresponding relationship. Multiple language versions should reference one another within the same group, and each page should include its own hreflang entry. Self-referencing is not decorative; it ensures that each URL consistently defines the language group to which it belongs.

Second, the codes must use valid language and region combinations. The language component uses ISO 639-1 codes, such as de, ja, and zh; the region component uses ISO 3166-1 Alpha 2 codes, such as DE, JP, and CN. The language comes first, followed by the region, with a hyphen between them. de-DE can represent German for Germany, while de represents German without a specified region. Using a country code alone as a language code, using custom market abbreviations, or reversing the positions of language and region will cause the declaration to lose its intended meaning.

Third, target URLs must be canonical pages accessible to users and crawlers. If hreflang points to a URL that redirects, returns an error, is blocked from crawling by robots rules, or has a canonical pointing to another address, the signals will conflict. Common rework occurs after launch: the content team changes a product page path while development retains the old language mapping; or an online store redirects out-of-stock pages to the homepage after switching inventory by region. These changes will break the original alternate group.

Three implementation methods: choose one that can be maintained reliably

Google supports adding <link rel="alternate" hreflang="..." href="..."> in the HTML <head>, as well as using HTTP response headers or submitting through an XML Sitemap. The three methods express the same type of relationship, and it is generally sufficient to choose the one that best fits the publishing architecture. For standard HTML pages, head tags can be generated conveniently from page templates; non-HTML documents such as PDFs are better suited to HTTP headers; when there are many language versions maintained by a centralized content system, a Sitemap can reduce repeated output in page templates.

It is not recommended to treat multiple sources as mechanisms for compensating for one another. If the URL sets or codes in HTML, Sitemaps, and response headers are inconsistent, troubleshooting loses a clear basis. Regardless of the method used, a page-level mapping table should serve as the single source of truth: the original URL, canonical URL, language code, region code, corresponding version, and retirement status should be updated in sync. When products are discontinued, directories are migrated, or domain names are changed, this mapping table is more reliable than temporarily replacing code in bulk.

The role and boundaries of x-default

x-default is used to specify the default page when no more suitable language or regional match exists. It is commonly used for language selection pages, global entry pages, or default versions that allow visitors to choose a market themselves. It is not a fixed label for an "international website homepage," nor should it replace the hreflang declaration for each specific language page.

Particular caution is required when marking automatically geolocated pages as x-default. Google explicitly recommends avoiding forced redirects of crawlers and users to different pages based on IP addresses or browser languages. Automatic redirects can make it difficult for users to access a specified URL and may also prevent crawlers from consistently retrieving the content of each version. A more reliable approach is to retain accessible version URLs and provide visible language or region switching options on the page; save preferences only after users make an explicit selection.

canonical and hreflang cannot be configured independently

canonical addresses "which is the preferred version among multiple similar URLs," while hreflang addresses "how different language or regional versions correspond to one another." The two are often confused. Even if English and French pages have identical structures, the French page should not be canonicalized to the English page simply because the content is similar; this tells search engines that the French page is not an independent preferred page, contradicting its declaration as a French alternate version.

A more appropriate configuration is for each language or regional page to use a self-referencing canonical, with hreflang linking to other equivalent versions. Only when the same-language version has URL parameters, letter case variations, trailing slashes, print pages, or duplicate paths should a canonical be selected within that language. Organizing canonicalization first and then establishing internationalization mappings avoids mistaking URL cleanup issues for language-version issues.

Signals to monitor after publication

Validation should not only check whether tags appear in the source code. First, spot-check a group of pages: verify whether each href returns a successful indexable response, directly reaches the final canonical URL, contains a return link, and uses language codes consistent with the body text and market conditions. Then check the sitemap, template rendering, and cache layers to confirm that visits from different regions do not produce different hreflang sets.

International targeting-related issues in Search Console, alternate pages that have been discovered but not correctly processed, and canonical page selection results can all be used to identify problems. Two phenomena need to be distinguished here: if search results do not display the page for the target region, it does not necessarily mean hreflang has failed, as query language, user location, page relevance, and indexing status all affect display. In contrast, alternate pages that cannot be crawled for a long time, missing reciprocal references, or canonicals pointing to cross-language pages are signals of configuration issues that should be prioritized for correction.

The value of hreflang lies in reducing the search system's need to guess the relationships between language versions. The prerequisite is not having enough tags, but ensuring that URLs, content language, canonicalization strategy, and the website's actual service scope all point to the same fact.