Hreflang for international SEO
When a website operates in multiple languages or countries, a single translated version of pages isn't enough. Search engines need to be informed about which URLs belong to the same group and the intended audience for each version.
Hreflang is used for this task. It links language and regional variations of pages and helps Google select the appropriate URL based on the user's language and region. Google determines the page's language based on its content, and uses hreflang as a signal for the relationship between localized URLs.
What is hreflang and why is it needed for international SEO?
Hreflang is used on multilingual and multiregional websites where a single content, category, product, or service has multiple local versions. For example, an online store might have a Ukrainian page for Ukraine, a Polish page for Poland, and an English page for users in other countries.
Without such markup, search engines can still detect localized pages, but it's more difficult to understand their exact purpose. This is especially noticeable when several URLs contain nearly identical content in the same language, but the terms and conditions vary by country.
How does Google use hreflang?
Google views hreflang as a link between alternative versions of a single page. If a user searches for a product in English from the UK, the search engine might choose a URL with en-GB, while for a user in the US, it might use a page with en-US.
Markup doesn't guarantee that the specified URL will always be shown. Other signals influence search results, but a proper hreflang group provides search engines with additional information about language and regional variations. Google also allows linking pages located on different domains.
When is hreflang really needed?
Markup is necessary when a single project serves multiple languages or markets. A typical example is a multilingual website where the same section is available in Ukrainian, English, Polish, and German.
Hreflang is also needed when the language is the same but the markets are different. For example, pages for the US and UK might be written in English but differ in currency, shipping, pricing, purchase terms, and local semantics.
Main application scenarios:
- the site is fully translated into several languages, and each original page corresponds to several localized URLs;
- one language is used for different countries, but the commercial conditions, contacts or product range differ;
- separate language versions are hosted on different domains, subdomains or in subfolders;
- An international online store uses different currencies, shipping, and prices for each market;
- Some of the content has been translated, while some pages remain common across several countries.
Hreflang should be used between equivalent pages. Avoid using it to link different services, products, or articles just because they're on a similar topic.
When is hreflang not needed?
If a website exists in a single language and targets a single market, there's no point in adding such markup. It's also unnecessary between pages that differ in purpose and aren't localized versions of each other.
For example, a Russian-language service page and another Ukrainian-language article with a similar keyword do not form a hreflang group. For proper linking, the pages must match each other in content and purpose.
Answers to your questions
How to write hreflang correctly?
Hreflang is specified via <link rel="alternate">, where the language or language and region are specified separately, along with the full address of the corresponding page. For example:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" />.
Each localized page must contain its own URL and links to other versions. Interconnections between pages must be maintained, otherwise some markup may be ignored by search engines.
What does the hreflang parameter mean?
The hreflang parameter specifies the language or language/region combination for which the alternative URL is intended. For example, en means English without any regional restrictions, and en-US means English for users in the United States.
The language is listed first, with the region added if necessary. For the Ukrainian version, uk is used, as UA refers to the country code and is not a language code.
Where should hreflang be placed?
For HTML pages, tags are typically placed within the <head> element. Google also supports the transfer of the same data via HTTP headers and XML Sitemaps.
These methods are considered equivalent for Google Search. You should choose the option that's easiest to manage on a specific site, rather than duplicating the same markup in all three places.
Do I need to add hreflang to the current page?
Yes, the current page must be included in its own hreflang group. For example, a Ukrainian URL points to the Ukrainian, English, and Polish versions, including a link to itself.
The same rule applies to other localizations. This self-reference is included in Google's recommendations for all implementation methods.
How is hreflang different from canonical?
Hreflang links language and regional variations of a single page. Canonical is used to select the preferred URL among identical or very similar pages.
If localized versions need to be indexed separately, each usually has its own canonical. Sending canonicals for all languages to a single URL without a good reason is not recommended.
What is hreflang x-default?
x-default designates a fallback page for users for whom no other language or regional version fits. This is most often the global homepage or country selection screen.
Google recommends using this value for fallback scenarios. Adding x-default to all groups without a real fallback page is optional.
Which hreflang should I use for the Ukrainian language?
For the Ukrainian language, the value uk is used. For example:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/" />.
The value “ua” cannot be used in place of the language. The country code and language code serve different purposes, so the Ukrainian language version is designated with “uk”.
Can hreflang be used across different domains?
Yes, alternative versions can be located on different domains. For example, one page can be located on the main international domain, and another on a separate national domain.
The main requirement remains: URLs must be part of the same logical group and link to each other. Google explicitly states that alternative pages do not need to be on the same domain.
How to write hreflang correctly?
To understand how to write hreflang, just understand the basic markup string. In HTML, it looks like this:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" />This tag informs the search engine that the specified URL is a Ukrainian alternative version of the current page. The markup combines rel, the hreflang parameter, and the page address in href.
What parameters does the hreflang tag consist of?
Each line contains three main elements. rel="alternate" specifies an alternative version of the document, hreflang specifies the language or language/region combination, and href contains the full URL of the corresponding page.
Example for several localizations:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/service/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/service/" />For href, it's best to use an absolute URL with the protocol and domain. Google explicitly requires fully qualified URLs for alternative versions.
What does rel="alternate" mean?
The alternate value indicates that the link leads to an alternative version of the current document. When combined with hreflang, search engines understand that this is a language or regional version of the page.
Each localized version must contain its own set of such links. If a website has Ukrainian, English, and Polish pages for the same service, all three URLs must be linked.
What does the hreflang parameter mean?
The hreflang value specifies the language and, if necessary, the region. For example, hreflang="en" denotes English regardless of country, while hreflang="en-GB" specifies that the page is intended for an English-speaking audience in the United Kingdom.
The language code always comes first. The country code can be added second, separated by a hyphen, but you cannot use a country without a language. Google supports ISO 639-1 language codes and ISO 3166-1 Alpha-2 region codes.
What is specified in href?
The href specifies the absolute URL of the corresponding language or regional version. It's best to specify a final URL that immediately responds with a 200 status code and doesn't go through a redirect chain.
For example:
href="https://example.com/en/catalog/"The /en/catalog/ option for hreflang should not be used. The full URL simplifies markup processing and eliminates ambiguity when working with multiple domains.
How to specify language and country in hreflang?
For basic localization, simply specifying the language is sufficient. If a single language version covers several different markets, you can add the region to the language.
This approach is especially useful for countries that use the same language but have different prices, currencies, product ranges, contact details, or delivery policies.
ISO 639-1 language codes
The two-letter language code used is the ISO 639-1 standard. For the Ukrainian version, use “uk”, for English, “en”, for Polish, “pl”, and for German, “de”.
| Language | hreflang value |
|---|---|
| Ukrainian | uk |
| English | en |
| Polish | pl |
| German | de |
| French | fr |
A common mistake on Ukrainian websites is the use of “ua”. UA is the country code, and the Ukrainian language code in hreflang is “uk”.
ISO 3166-1 Alpha-2 region codes
If a page needs to be linked to a specific market, the region code is added after the language. For example, en-US refers to the English version for the US, and en-GB refers to the English version for the UK.
| Hreflang | Purpose |
|---|---|
| en-US | English for the USA |
| en-GB | English for Great Britain |
| de-DE | German for Germany |
| fr-CA | French for Canada |
| pl-PL | Polish for Poland |
The region code is written after the language, separated by a hyphen. A standalone value like US, GB, or UA does not comply with the hreflang format.
Do I always need to specify the region?
No, in many cases a common language code is sufficient. If an English page is relevant to users in different countries, the value “en” would be more logical than binding to a single market.
If you have multiple regional versions, you can add a common page for other users of that language. For example, en-US, en-GB, and en-CA can be used together with the country-neutral version of en. Google recommends this approach for geographically unspecified audiences of a single language.
What is x-default in hreflang?
x-default specifies a fallback URL for users for whom none of the explicitly specified language or regional versions fits. It's most often used on the global homepage or the country and language selection page.
Example:
<link rel="alternate" hreflang="x-default" href="https://example.com/" />This URL can be used as a fallback if the site isn't localized for the user's language. Google recommends x-default for such scenarios but doesn't require it to be added to every hreflang group.
When to use x-default?
A practical option is an international store with Ukrainian, Polish, German, and English versions. Users with languages for which there isn't a dedicated page can access the general international section or country selection screen.
x-default is also suitable for a global homepage where visitors can select their region. It shouldn't be considered a replacement for a general language version if such a page is already included in the site's structure.
How to set up hreflang on a website?
Google supports three methods for transmitting information about alternative pages: HTML, HTTP headers, and XML Sitemap. From the search engine's perspective, these methods are equivalent, so duplicating a single group in all three places is not necessary to boost the signal.
The choice depends on the project architecture. HTML is often suitable for a typical corporate website, HTTP headers are more convenient for PDFs, and a large online store with tens of thousands of localized URLs may find it easier to manage groups via a sitemap.
Hreflang in the page's HTML code
Tags are added inside a valid <head>. Each page version must contain a full set of alternatives, including a link to itself.
<link rel="alternate" hreflang="uk" href="https://example.com/uk/service/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/service/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/service/" />If there are many such languages, the block size increases significantly. Therefore, on large projects, it is sometimes more convenient to store the links centrally in an XML Sitemap.
Hreflang via HTTP headers
HTTP headers are appropriate for documents that don't have an HTML <head>. A typical example is a PDF file published in multiple language versions.
Example:
Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/file.pdf>; rel="alternate"; hreflang="de"The principle remains the same: each version must be part of a group, and the URLs must be fully qualified. This method typically requires control at the server or application level.
Hreflang in XML Sitemap
On large sites, alternative URLs can be specified in the XML Sitemap. For each primary URL, add an xhtml:link with all versions inside the <url> tag.
<url>
<loc>https://example.com/en/service/</loc>
<xhtml:link rel="alternate"
hreflang="en"
href="https://example.com/en/service/" />
<xhtml:link rel="alternate"
hreflang="uk"
href="https://example.com/uk/service/" />
</url>This option is convenient when the sitemap generation is already linked to the database of pages and localizations. The main thing is to update the sitemap along with the URLs, otherwise, after migrating or deleting pages, the old links will remain.
Which hreflang implementation method should I choose?
For a standard website, it's easier to start with HTML. If the project contains many languages or millions of URLs, an XML sitemap can reduce the amount of technical markup within each page.
| Method | When it suits | Advantage | What to consider |
|---|---|---|---|
| HTML | regular websites | easy to check in code | the block grows with the number of languages |
| HTTP headers | PDF and other non-HTML files | works without <head> | server control is needed |
| XML Sitemap | large projects | centralized control | You need to sync the map with the URL |
Implementing all three methods simultaneously without technical necessity is not recommended. The more sources generate hreflang, the higher the risk that they will diverge after a site update.
What hreflang rules should not be violated?
Working markup is built as a whole group, not as a single link from one page to another. For each localization, you need to check its own link, return links, URL accessibility, and the absence of conflicts with other SEO tags.
In practice, most errors appear after migrations, structure changes, or the launch of a new language. Therefore, hreflang should be checked simultaneously with canonical, HTTP status, and page indexability.
Each page should link to itself
The Ukrainian page should contain hreflang="uk" with its address, and the English page should contain hreflang="en" with its own. Each page should also list the other versions of the group.
Google explicitly states that a language version should list itself and any alternatives. This self-referencing hreflang helps maintain an unambiguous group structure.
Hreflang must be reciprocal
If a Ukrainian URL contains a link to an English URL, the English URL should link back to the Ukrainian one. Such return links are often called return links or reciprocal links.
Google checks this reciprocity. If two pages don't link to each other, the corresponding annotations may be ignored.
Graphic diagram of the group:
Ukrainian version ←→ English version
↕ ↕
└────→ Polish ←───┘Each page belongs to a single group and has its own URL. When adding a new localization, the links must be updated on all relevant pages.
All hreflangs must point to working indexable URLs
The alternative version must be crawlable and indexable. If the link leads to a deleted page, a redirect, a closed URL, or a noindexed document, the structure becomes inconsistent.
During the audit, teams check for HTTP 200, meta robots, Googlebot accessibility, the final URL, and the absence of unnecessary redirects. Additionally, it's worth checking whether the page content matches the declared language.
How should hreflang work with canonical?
Canonical and hreflang serve different purposes. Canonical helps determine the preferred URL among duplicates, while hreflang links localized versions so they remain accessible in search results.
For full-fledged Ukrainian, English, and Polish versions, self-canonical links are typically used on each page. An error occurs when all localizations are canonically linked to a single language page, even though they should be indexed separately.
Lead SEO specialist — Gennady
I check hreflang as a group of related URLs, not as a single tag in the source code. Most often, the syntax is correct, but one version is missing, a return link is lost after migration, or the canonical is pointing to a different language. Therefore, during an audit, I always simultaneously look at hreflang, canonical, HTTP codes, indexability, and page consistency.
Hreflang and the structure of an international website
The markup doesn't require a single URL format. Language versions can be located in subfolders, subdomains, or on separate national domains, if such a structure suits the project's objectives.
The architecture is chosen separately from hreflang. Afterwards, a clear mapping between all language and regional variants is created for each group of pages.
Subfolders, subdomains or individual domains?
Common options look like this:
| Structure | Example |
|---|---|
| Subfolder | example.com/uk/ |
| Subdomain | uk.example.com |
| Separate domain | example.ua |
Hreflang can link all these formats. Google doesn't require alternative URLs to be located on the same domain.
For SEO, a stable structure, correct indexing, and a consistent logic for generating localized pages are more important. If URLs change, hreflang and canonical tags should be updated along with them.
Why are translation and localization not the same thing?
Translation changes the language of the text, and localization takes into account the specifics of a specific market. A commercial website may have different currencies, prices, units of measurement, contact information, delivery, payment methods, and legal information.
Therefore, two English-language pages may have different regional versions. For example, one is intended for the US and the other for the UK, even though most of the text remains similar.
Common hreflang errors
Most problems stem not from syntax complexity, but from URL inconsistency. A single incorrect URL within a large group can disrupt connections between several localizations at once.
It's more convenient to check for errors using a table, especially when conducting a mass audit of an online store or a website with dozens of languages.
| Error | Why does it arise? | How to fix |
|---|---|---|
| ua instead of uk | they confuse the country and the language | use uk |
| US or GB only | the region without language is specified | write en-US, en-GB |
| no return link | the versions were not updated simultaneously | restore reciprocal link |
| lack of self-reference | The current URL has been excluded from the group. | add your own version |
| the link leads to 404 | URL removed or changed | replace with a working URL |
| the link goes through 301 | the old URL remains | specify the final page |
| URL closed noindex | indexing settings conflict | check page purpose |
| canonical leads to another language | incorrect template logic | configure canonical for the local version |
After migration, such errors are especially common. Old URLs remain in the template or sitemap, even though the pages themselves are redirected to the new structure.
How to check hreflang on a website?
First, you can open the source HTML and look for rel="alternate". For a small group, this is enough to check the codes, the full set of localizations, and the page's own link.
For a large project, manual verification isn't enough. You need an SEO crawler that will collect hreflang from all indexed URLs and reveal missing return links, incorrect language codes, redirect links, and other technical discrepancies.
Checking all language URLs
The same set of parameters should be checked for each group. This approach is more convenient than one-time corrections to individual tags because it demonstrates the integrity of the international structure.
Minimum checklist:
- each language version is present in the group and contains a self-referencing link;
- mutual links are set up between alternative URLs without missing pages;
- the correct language and regional codes are used;
- all addresses are fully specified and respond with code 200;
- canonical does not conflict with the localized version;
- the pages are accessible to search robots and are not closed from indexing;
- x-default points to the appropriate fallback page if used.
After the list, you need to check several groups manually. The automatic report is good at identifying common issues, but manual checking helps ensure that the pages actually match each other in meaning.
When to retest?
An audit is necessary after launching a new language, migrating, changing a slug, switching to a different CMS, or a massive catalog rebuild. Any operation that changes page addresses can leave old URLs in hreflang.
It's also worth repeating the check after changing templates and sitemap generators. On large websites, markup is usually generated automatically, so a single error in the logic can affect thousands of pages simultaneously.
An example of correct hreflang for a multilingual website
Let's say a service page exists in Ukrainian, English, and Polish. For users without suitable localization, the site uses a common language selection page.
The <head> of each of the three localized pages will contain the same set:
<link rel="alternate" hreflang="uk"
href="https://example.com/uk/seo/" />
<link rel="alternate" hreflang="en"
href="https://example.com/en/seo/" />
<link rel="alternate" hreflang="pl"
href="https://example.com/pl/seo/" />
<link rel="alternate" hreflang="x-default"
href="https://example.com/" />The Ukrainian page contains a link to itself and the other versions. The same rule applies to the English and Polish URLs, so the links within the group remain mutual.
Hreflang Configuration Checklist
Before publishing a new language version, it's best to run the same set of checks. This takes less time than trying to figure out the cause after hundreds of errors appear in the international section.
| Check | Requirement |
|---|---|
| Language code | ISO 639-1 |
| Region | ISO 3166-1 Alpha-2 |
| URL | full address with protocol |
| Self-reference | present |
| Return link | present |
| HTTP status | 200 |
| Indexability | allowed |
| Canonical | does not conflict |
| x-default | added if necessary |
| Localizations | correspond to each other |
After checking one page, you need to check the remaining URLs in the group. Fixing only the original version won't solve the problem if the alternate pages continue to return the old hreflang set.
Correct hreflang is built around four things: correct language codes, a complete set of alternative URLs, reciprocal links, and the absence of canonical and indexing conflicts. If these rules are built into the site template, new languages can be added without manually editing each page.
For an international project, markup should be checked after migrations, the launch of new regions, and URL structure changes. If the site already has multiple language versions, a technical SEO hreflang audit will help identify missed links, outdated URLs, and template generation errors before they affect a large section of the site.
