Hreflang is one of the most useful—and most frequently misconfigured—technical SEO signals on international websites.
Its job is relatively narrow. When a page has legitimate versions for different languages or regions, hreflang helps Google understand how those URLs relate so Search can serve an appropriate localized version to users.
Hreflang does not translate a page. It does not redirect visitors. It does not create a duplicate-content exemption, guarantee international rankings or tell Google that one company owns another.
It is simply a way to map localized versions of the same content.
The most important implementation rule: hreflang should connect real localized alternatives. Decide which international pages should exist first. Then use hreflang to describe those relationships accurately.
What is hreflang?
Hreflang is an annotation that identifies language or language-and-region alternatives of a URL.
Imagine that an ecommerce company has three versions of one product page:
- a U.S. English page;
- a U.K. English page;
- a German-language page.
The pages may describe the same product, but prices, spelling, shipping information and language differ. Hreflang gives Google an explicit map showing that the three URLs are localized versions of the same page.
Google can use that relationship when deciding which URL is most appropriate to show a searcher.
Hreflang is especially useful when localized pages are similar enough that their relationship would otherwise be unclear—for example, separate English-language pages for the United States and United Kingdom.
For the larger decision about which country and language pages should exist, see our international SEO and multilingual content strategy guide.
Is hreflang a meta tag?
No.
The phrase “meta hreflang” is commonly searched, but the normal HTML implementation uses a <link> element rather than a <meta> element.
A basic annotation looks like this:
<link rel="alternate" hreflang="en-US" href="https://example.com/us/product/" />The element tells Google that the linked URL is an alternate version intended for U.S. English users.
Where do hreflang tags go?
Google supports three implementation methods:
| Method | Where hreflang lives | When it is useful |
|---|---|---|
| HTML | Inside the page's <head> |
Common for ordinary HTML pages and CMS-driven websites |
| HTTP headers | The server's HTTP response | Especially useful for non-HTML files such as PDFs |
| XML sitemap | Inside sitemap entries | Useful when a large site wants to manage localization mappings centrally |
Google treats these three methods as equivalent for Search.
You can technically use more than one method at the same time, but there is no Google Search benefit to repeating the same mapping through all three. In practice, maintaining one reliable source of truth is usually easier and reduces the chance that different implementations contradict one another.
HTML hreflang belongs inside the <head>
If you use the HTML method, the hreflang elements belong inside a well-formed <head> section.
For example:
<head>
<title>Example Product</title>
<link rel="alternate"
hreflang="en-US"
href="https://example.com/us/product/" />
<link rel="alternate"
hreflang="en-GB"
href="https://example.com/uk/product/" />
<link rel="alternate"
hreflang="de"
href="https://example.com/de/produkt/" />
<link rel="alternate"
hreflang="x-default"
href="https://example.com/product/" />
</head>Do not place the tags in the visible page header, navigation or body and assume Google will treat that as the supported HTML implementation.
The phrase “HTML header” can be confusing here. The technical requirement is the document's <head> element.
How language and region codes work
An hreflang value begins with a language code and can optionally add a region.
Common examples include:
en
en-US
en-GB
fr
fr-CA
de
de-CHThe first value represents the language. The optional second value represents the region.
For Google's implementation, language codes generally use the ISO 639-1 format and region codes use ISO 3166-1 Alpha 2.
That creates a few rules worth remembering.
You cannot use a country code alone. US does not mean “United States English.” Use en-US.
Language comes first. Use en-GB, not GB-en.
Use the supported country code. The United Kingdom uses GB, so U.K. English is en-GB, not en-UK.
If geography does not matter, use a language-only version such as es or de.
Do you always need a country code?
No.
A language-only annotation can be entirely appropriate.
If one Spanish page serves Spanish-speaking users regardless of country, es may be the correct value. You do not need to invent country-specific pages merely because hreflang supports regional targeting.
Region-specific values become useful when the page genuinely targets a particular market.
For example:
en-USfor U.S. English;en-GBfor U.K. English;fr-CAfor Canadian French;de-CHfor German-speaking users in Switzerland.
The code should reflect the audience the page actually serves.
Each page should reference itself and its alternates
A correct hreflang cluster normally includes a self-reference as well as references to the other localized versions.
Suppose you have:
https://example.com/us/shoes/https://example.com/uk/shoes/https://example.com/de/schuhe/
The U.S. page should identify the U.S., U.K. and German versions. The U.K. page should identify the same set. The German page should do the same.
The mapping should describe one consistent localization cluster.
Return links matter
Hreflang relationships are reciprocal.
If page A identifies page B as an alternate, page B should identify page A as an alternate as well.
Google uses these return links to help verify that the relationship is intentional. A one-way hreflang reference may be ignored.
This is particularly important when a new country or language section is added to an established international site. Do not update only the new pages. Update the corresponding existing pages so the relationship works in both directions.
Use fully qualified URLs
Hreflang references should use complete URLs, including the protocol and hostname.
Use:
https://example.com/fr/product/rather than:
/fr/product/This becomes particularly important when alternate versions live on different domains or subdomains.
Can hreflang connect pages on different domains?
Yes.
Localized alternatives do not have to live on the same domain.
A company could legitimately connect:
https://example.com/product/
https://example.de/produkt/
https://example.fr/produit/if those URLs are genuinely localized alternatives of the same content.
Hreflang describes the relationship among the pages. It does not require one particular international domain structure.
What does x-default mean?
x-default identifies a fallback URL for users whose language or region does not match the localized versions you have specified.
It is often useful for a global landing page or country/language selector.
For example:
<link rel="alternate"
hreflang="en-US"
href="https://example.com/us/" />
<link rel="alternate"
hreflang="en-GB"
href="https://example.com/uk/" />
<link rel="alternate"
hreflang="de-DE"
href="https://example.com/de/" />
<link rel="alternate"
hreflang="x-default"
href="https://example.com/" />x-default is not a canonical tag and does not mean “this page should rank instead of the others.” It simply provides a fallback within the localization mapping.
Should you also provide a generic language version?
Sometimes.
Imagine you have separate English pages for:
- United States:
en-US - United Kingdom:
en-GB - Australia:
en-AU
A generic en version can serve English-speaking users who do not match one of those regional versions.
That is different from x-default. The generic en version targets the English language without specifying a country. x-default is a fallback when no declared language/region matches.
You may use one or both depending on the site's actual architecture.
How XML sitemap hreflang works
Large sites often prefer to manage hreflang centrally through XML sitemaps.
Each localized URL receives its own <url> entry, and each entry lists the complete applicable set of localized alternatives.
A simplified example looks like this:
<url>
<loc>https://example.com/us/product/</loc>
<xhtml:link
rel="alternate"
hreflang="en-US"
href="https://example.com/us/product/" />
<xhtml:link
rel="alternate"
hreflang="en-GB"
href="https://example.com/uk/product/" />
<xhtml:link
rel="alternate"
hreflang="de"
href="https://example.com/de/produkt/" />
</url>The corresponding U.K. and German sitemap entries should contain the same localization set.
Sitemap-based implementation can be especially useful when thousands or millions of localized pages would otherwise require complex template-level HTML management.
When HTTP headers make sense
HTTP headers are particularly useful for files that do not have an HTML <head>, such as PDFs.
A server can send a Link response header that identifies the alternate localized files.
Link: <https://example.com/en/guide.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/leitfaden.pdf>; rel="alternate"; hreflang="de"You can also use HTTP headers for HTML documents, but most ordinary sites find the HTML or sitemap method easier to manage.
Hreflang and canonical tags solve different problems
This is where many international implementations go wrong.
A canonical tag tells Google which URL should represent a set of duplicate or very similar URLs.
Hreflang tells Google which localized URLs are alternatives for different languages or regions.
They are not interchangeable.
A fully translated German page and an English page are not simply duplicate versions that need to be collapsed into one global canonical. They are legitimate language alternatives.
Likewise, pointing every regional page to one global canonical can undermine the very localization architecture you are trying to create.
For translated pages with genuinely distinct main content, a self-referencing canonical is generally a clean implementation.
Same-language regional pages require more judgment. A U.S. page and U.K. page may be nearly identical except for currency or a small amount of regional information. Google explicitly treats these situations as a case where canonicalization and hreflang can work together.
If canonicalization is necessary, use a canonical in the same language when possible. Do not mechanically canonicalize every country version to an unrelated global or different-language page.
For the broader decision, see our canonical tags and duplicate content guide.
Hreflang does not create a duplicate-content penalty exemption
Another persistent myth is that translated pages will be penalized as duplicate content unless hreflang is present.
That is not a useful way to think about the problem.
When the primary content is genuinely translated, Google does not simply treat the different language versions as duplicates because they discuss the same subject.
Same-language regional variants can be much more similar, which is why canonicalization may become relevant.
Use hreflang because you want Google to understand the localization relationship—not because you are trying to escape a mythical duplicate-content penalty.
Do you need hreflang on every page?
No.
Use hreflang when a page has a legitimate localized alternative.
If an English article has no French, German or region-specific equivalent, there is nothing to map. Adding a self-referencing hreflang element by itself does not create international targeting value.
Large websites should therefore generate hreflang based on actual translation or market relationships rather than adding the same global template indiscriminately to every URL.
Hreflang does not replace localization
A technically perfect hreflang implementation cannot make a poor localized page useful.
If the U.K. page shows U.S. dollars, U.S.-only shipping rules and U.S. legal language, adding en-GB does not turn it into a strong U.K. experience.
The content itself must serve the intended audience.
That broader work—translation, market research, pricing, product availability, regional search intent and content governance—is covered in our international SEO and AI search strategy guide.
Do not rely entirely on automatic redirects
Some international sites show different content at the same URL based on IP address, browser language or cookies.
Google warns that locale-adaptive pages can be difficult to crawl completely because Googlebot may not encounter every variation.
If localized content needs to be independently discovered and indexed, separate URLs are generally much easier to manage.
You can still suggest a region or language to users, but give them a way to choose another version rather than permanently trapping them behind an automatic redirect.
Hreflang during a site migration
International migrations require additional coordination because URLs may change in several markets at once.
When a localized URL moves:
- redirect the old URL directly to its true replacement;
- update the hreflang cluster to reference the new final URL;
- update canonicals to the intended current URLs;
- update internal links;
- update XML sitemaps;
- verify that none of the hreflang targets still redirect, return errors or point to retired URLs.
The hreflang cluster should represent the current live architecture rather than relying indefinitely on redirected historical URLs.
For broader migration planning, see our website migration guide.
Common hreflang errors
Most hreflang problems are implementation problems rather than strategy problems.
Missing return links
Page A references page B, but page B does not reference page A. Google may ignore the incomplete relationship.
Missing self-references
A cluster lists all the other localized pages but omits the current page itself.
Invalid language or region codes
Examples include using en-UK instead of en-GB, using a country without a language or inventing codes that Google does not support.
Pointing to redirected URLs
The hreflang target should ideally be the current final URL, not an obsolete URL that first has to redirect elsewhere.
Pointing to 404 or retired pages
Localization clusters frequently break after content pruning because old hreflang references survive in templates or sitemaps.
Mixing unrelated pages into one cluster
An English product page should be paired with its actual German equivalent—not merely the German homepage or a vaguely similar category page.
Canonicalizing localized pages incorrectly
If a country page is supposed to remain an independent search result, do not casually point its canonical to an unrelated global page.
Maintaining conflicting implementations
An HTML template might say the German alternate is one URL while the XML sitemap says it is another. Using one well-governed implementation method reduces this risk.
How to audit hreflang at scale
Start by crawling every localized section and exporting:
- page URL;
- HTTP status;
- canonical URL;
- hreflang values;
- alternate URLs;
- indexability;
- language or market folder;
- and redirect destination where relevant.
Then validate relationships as clusters rather than individual tags.
For every group of localized pages, ask:
- Does every URL exist?
- Does every intended page return a successful response?
- Do the codes describe the correct language and region?
- Do the pages reference themselves?
- Are the required relationships reciprocal?
- Do canonicals agree with the indexing strategy?
- Does each alternate actually contain the equivalent localized content?
Google no longer provides the old Search Console International Targeting report, so large sites typically combine crawling, targeted validation and Search Console inspection when troubleshooting international indexing.
How to test a smaller implementation
For a small set of pages, inspect the rendered source and confirm that the expected hreflang elements appear inside the <head>.
If hreflang is sitemap-based, inspect the actual sitemap output rather than assuming the CMS generated it correctly.
For HTTP headers, inspect the server response.
Then manually test several clusters:
- one simple two-language pair;
- one same-language multi-region group;
- one page using
x-default; - one recently migrated or redirected URL;
- and one edge case such as a page that does not exist in every language.
A small sample often reveals template-level problems before they affect thousands of pages.
What about JavaScript-generated hreflang?
Google can render JavaScript, but technical signals are generally easier to validate and maintain when they are available reliably in the page output rather than depending on fragile client-side behavior.
If your framework generates hreflang dynamically, test the rendered HTML Google receives and confirm that the complete intended cluster is present.
Do not assume that because the tags appear after a browser finishes loading, every crawler or external platform will process them identically.
Does hreflang improve rankings?
Hreflang should not be treated as a direct rankings booster.
Its value is localization: helping Google understand which version of a page is intended for which language or region.
That can improve the search experience because someone in the United Kingdom is less likely to be sent to a U.S.-specific page when an appropriate U.K. version exists.
The individual localized pages still need to earn visibility through normal SEO: useful content, crawlability, internal links, authority, relevance and a technically sound site.
Does hreflang help AI search?
Hreflang is a documented Google Search localization mechanism. It should not be rebranded as a special AI optimization signal.
Google's generative Search experiences still rely on its broader Search systems, so a technically sound international site remains important. But there is no separate “AI hreflang” implementation or documented rule showing that adding hreflang directly increases AI citations.
The better approach is to implement international SEO correctly and measure AI visibility separately by language or market when the measurement platform supports it.
A practical hreflang implementation checklist
- Confirm that the URLs are real localized alternatives. Do not connect unrelated pages merely because they share a topic.
- Choose one primary implementation method. HTML, HTTP headers and XML sitemaps are all supported.
- Use valid language and region codes. Language comes first; region is optional.
- Use complete URLs. Include protocol and hostname.
- Include the current page. Each localized version should identify itself within the cluster.
- Maintain reciprocal relationships. If one localized page identifies another, make sure the intended relationship works in both directions.
- Use x-default where a genuine fallback is useful. A selector or global landing page is a common use case.
- Align hreflang and canonical strategy. Do not accidentally canonicalize away pages you want Google to treat as localized search results.
- Reference final live URLs. Remove 404s, retired URLs and unnecessary redirect hops from the cluster.
- Reaudit after migrations and localization launches. International templates can break many URLs at once.
Hreflang works best when the architecture is already right
Hreflang cannot rescue an international website that has not decided which pages belong to which audiences.
First determine which language and regional experiences the business actually needs. Localize the content where meaningful differences exist. Give every important version a stable, crawlable URL. Decide how similar same-language pages should be canonicalized.
Then connect those pages with a clean hreflang implementation.
When that sequence is followed, hreflang becomes what it should be: a precise technical annotation rather than an attempt to solve every international SEO problem with one tag.
Need Help Auditing a Complex Hreflang Implementation?
LSEO helps international organizations diagnose hreflang, canonicalization, crawling, migrations and other technical SEO issues across large multilingual and multi-regional websites.
Explore LSEO's technical SEO services or talk with our team.
Frequently Asked Questions
Where should hreflang tags be placed?
If you use the HTML method, hreflang <link> elements belong inside the page's <head>. Google also supports hreflang through HTTP headers and XML sitemaps.
Is hreflang a meta tag?
No. In HTML, hreflang is normally implemented with a <link rel="alternate"> element. The phrase “meta hreflang” is common shorthand, but it is not technically a meta tag.
Can I use hreflang in both HTML and an XML sitemap?
Yes, but Google says there is no Search benefit to using multiple supported implementation methods simultaneously. Maintaining one accurate implementation is generally easier than keeping several versions synchronized.
Does every hreflang page need to reference itself?
Yes. Google's guidance says each language version should list itself as well as its applicable localized alternatives.
Do hreflang tags need return links?
Yes. Localized relationships should be reciprocal. If one page references another but the second page does not reference the first, Google may ignore that relationship.
What is hreflang x-default?
x-default identifies a fallback URL for users whose language or region does not match the localized versions specified in the hreflang cluster. It is commonly used for global landing pages or language and country selectors.
Should I use en-UK or en-GB?
Use en-GB. Hreflang uses a language code followed by an optional supported region code, and the ISO region code for the United Kingdom is GB.
Should every regional page be self-canonical?
Not as an automatic rule. Distinct translated or localized pages are often cleanly self-canonicalized, but same-language regional pages with substantially duplicate content may require a different canonicalization decision. Hreflang and canonical tags should be planned together.
Does hreflang increase rankings?
Hreflang is primarily a localization signal, not a direct rankings boost. It helps Google understand which localized URL is appropriate for a particular language or region. Each page still needs to perform through normal SEO fundamentals.
