Hreflang helps Google understand equivalent language or regional versions of a page. It works best when URLs, language codes and reciprocal links are consistent. Hreflang does not guarantee rankings, indexing or that a particular version will appear.

Key points

  • Use separate URLs for each language or regional version.
  • Each version should list itself and every other equivalent version.
  • Check canonicals, language codes, internal links and live URLs after publishing.

What is hreflang and why does it break?

Hreflang is an annotation that connects equivalent pages intended for different languages or regions. It can help Google Search select a more suitable version for a user. Google still determines page language from visible content; lang and hreflang attributes do not replace translated content.

If a site keeps one URL and changes content only through cookies or browser settings, crawlers may not find every version. Separate URLs are easier to crawl and review.

Illustration of hreflang on a multilingual website.

Basic implementation rules

1. Each version references itself

If a page has English, Malay and Simplified Chinese versions, each version should list all three URLs, including its own. Keep the same set on every version.

2. Use absolute, accessible URLs

Each href value must include the protocol and domain, such as https://example.com/ms/page/. Use the canonical URL that loads successfully and does not redirect to another page.

3. Keep the relationship reciprocal

If the English page points to the Malay page, the Malay page should point back to the English page. Without matching return links, Google may ignore the annotations. Connect only equivalent pages, not every article to the other language’s homepage.

Choose the method that fits

Google supports three equivalent methods: HTML tags, HTTP headers and XML sitemaps. Choose the method that is easiest to maintain. Using more than one does not provide an extra Search benefit and can add conflicting data if the sets differ.

Method A: Tags in the HTML head

Place one tag for every version in the <head> of each relevant page:

<link rel="alternate" hreflang="en-GB" href="https://example.com/page/" />
<link rel="alternate" hreflang="ms-MY" href="https://example.com/ms/halaman/" />
<link rel="alternate" hreflang="zh-Hans-MY" href="https://example.com/zh-cn/insights/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

This example uses English for the United Kingdom, Malay for Malaysia and Simplified Chinese for Malaysia. Choose region codes for the intended audience. x-default is optional for users whose language is not listed; it is most useful for a language selector or suitable default page.

Method B: XML sitemap

A sitemap can list all versions of each URL through xhtml:link annotations. Each URL entry needs the complete set of alternate links, including a link to itself. Validate the generated XML so no URL is missing or paired incorrectly.

Method C: HTTP headers

The Link header can describe alternate versions of non-HTML files such as PDFs. Include all language or regional URLs in the response header for each version. This can be harder to maintain when files change often, so inspect the actual response after implementation.

Keep canonical separate from hreflang

A canonical identifies the preferred URL among duplicate or very similar pages. Hreflang connects equivalent pages intended for different languages or regions. Each translated page should generally have a canonical pointing to its own URL, while hreflang connects the versions.

Do not canonicalise a Malay page to the English page simply because it is translated. That signal conflicts with the purpose of the localised page and can lead Google to select a URL that does not match the user.

Check common implementation problems

  1. Crawl the site and list the hreflang tags rendered in the HTML.
  2. Confirm each URL serves the intended page, not a 404, unnecessary redirect or page in another language.
  3. Check that every page has a return link and includes itself in the same set.
  4. Validate language and region codes, including spelling and case.
  5. Review each version’s canonical and check that it does not conflict with its language page.
  6. Ensure internal links take readers to the matching local version where available.
  7. Test the published HTML, sitemap or HTTP headers, not just the template or source file.

Google’s localized versions guidance supports ISO 639-1 language codes, optional ISO 3166-1 Alpha 2 region codes, and ISO 15924 script codes such as zh-Hans. Use supported values that describe the actual content. x-default does not require a language code.

Conclusion

Hreflang signals a relationship between equivalent versions; it does not make Google index or display a particular page. Start with clear URLs, consistent canonicals and complete localised content. Then inspect the annotation set on published pages and monitor Search results.

Common questions

How long after implementation will I see a result?

There is no fixed period. Google needs to crawl and process the URLs and annotations. Visible changes depend on indexing and Search results, so do not promise a specific date.

Does hreflang guarantee search visibility?

No. Hreflang helps Google understand the relationship between language or regional versions. It does not guarantee indexing, rankings or traffic.

What should I monitor?

Check status codes, canonicals, indexing of each version, reciprocal links and Search queries by country and language. Use URL Inspection and relevant Search Console reports to investigate individual pages.

Sources checked on 20 October 2026: Google Search Central’s localized versions documentation and managing multilingual sites guidance.