hreflang, which is also referred to as rel="alternate" hreflang="x", is a method in multi-language websites for marking pages that contain identical content but are intended for different languages and/or regions. It acts as a signal for search engines, telling them which language and geographic region your content targets.
When a page has multiple language versions, hreflang helps Google show the right one in search results based on the user’s browser language. If you run a multilingual site without it, the wrong version can show up – or worse, Google may treat your pages as duplicate content.
Some people refer to hreflang as an attribute, while others consider it a tag. The meaning is the same in both cases.
So what is hreflang exactly? It’s a snippet of code you can embed in your site in three different ways. It tells search engines that different URLs on your site contain the same (or equivalent) content – either in a different language, or in the same language but intended for different geographic regions.
Hreflang only influences search engine behavior. It does not redirect users to a different language version – you’ll need to implement geolocation or browser language detection separately for that.
Here’s what the basic syntax looks like:
<link rel="alternate" href="http://example.com/" hreflang="en-us" />Note that even if you don’t specify different variations of a specific page, Google might still find alternative versions for that page. However, the best practice is to explicitly specify the specific pages intended for a language or region.
Scenarios where Hreflang Feature is Necessary
Here are three common scenarios where you should use the hreflang feature:
- When there is content in the same language but with “regional variations,” for example, content intended for the UK (en-gb) and content for the US (en-us).
- When there is content in completely different languages, for example, Hebrew, English, and French.
- Combination of both – content intended for different languages and different regions.
The hreflang feature signals translated page versions – Credit: contentkingapp.com
Hreflang Tag – Benefits for SEO
From the perspective of ranking and Technical SEO, there are two main reasons to implement hreflang:
- Better user experience and engagement. If you’ve created a page version optimized for a specific language and region, you want that user to actually land there. Serving the right version improves UX and leads to lower bounce rates – which in turn signals quality to search engines.
- Preventing duplicate content issues. If you have the same English content on different URLs for the UK and the US, the difference between them might be minimal – different prices, a different currency. Without hreflang, Google may treat these as duplicates.
The hreflang attribute clarifies to search engines that the content is mostly identical but optimized for different audiences. I’ve seen this firsthand on my own bilingual site – without proper hreflang tags, Google kept indexing the Hebrew version for English queries.
How to Use the Hreflang Tag?
There are three ways to tell Google that a page has multiple language or region versions:
- Adding an HTML
<link>tag in the<head>of the page. - Using HTTP response headers (mainly for non-HTML content like PDF files).
- Declaring it in your XML Sitemap.
Let’s go through each one:
1. As <link> Tag Added to the <head> of the Page
The hreflang feature is written as follows:
<link rel="alternate" href="(url here)" hreflang="x" />rel="alternate" indicates to search engines that an alternative version of this page exists. The hreflang value specifies the language and region code of that alternative page, while the href URL points to its address.
For the language code, follow the ISO 639-1 standard (e.g. en, he, fr). If you also need to target a specific country, add a country code using the ISO 3166-1 alpha-2 standard (e.g. en-us, en-gb).
Note that when you write the language code and country code in the hreflang attribute, the language code should appear before the country code.
Here’s an example – if you want to display the homepage of example.com to English and Spanish speakers in the United States, you should use the following tags in the <head> of the page:
<link rel="alternate" href="http://www.example.com/" hreflang="en-us" />
<link rel="alternate" href="http://www.example.com/es/" hreflang="es-us" />If you want to display the homepage to Spanish speakers in Venezuela and Mexico, the hreflang tags should look like this:
<link rel="alternate" href="http://www.example.com/ve/" hreflang="es-ve" />
<link rel="alternate" href="http://www.example.com/mx/" hreflang="es-mx" />You can use a hreflang tags generator to help create hreflang tags for different languages and countries.
Since each variation needs a link to every other variation, this method gets heavy fast. A site with 25 languages would need twenty-five <link> tags on each page.
If you’re using a CMS, each tag may also trigger additional database queries – all for markup that only search engines read. For this reason, the HTML <link> method is best suited for sites with a small number of languages.
If you’re running WordPress, plugins like Polylang and WPML handle hreflang output automatically. They generate the correct tags for each language version without any manual markup on your part.
2. Implementation through HTTP Headers
The second option is using HTTP response headers. This approach is designed for non-HTML content – PDF files, documents, and anything you can’t embed a <link> tag into.
The syntax looks like this:
Link: <https://es.example.com/document.pdf>;
rel="alternate"; hreflang="es",
<https://en.example.com/document.pdf>;
rel="alternate"; hreflang="en",
<https://de.example.com/document.pdf>;
rel="alternate"; hreflang="de"Like the HTML method, HTTP headers scale poorly for sites with many languages – each additional language adds more header data to every response.
3. Implementation through Sitemap
The third option is implementation through XML Sitemap. To add the required annotations, you need to use the xhtml:link attribute in the XML file, and it looks like this:
<url>
<loc>http://www.example.com/uk/</loc>
<xhtml:link rel="alternate" hreflang="en"
href="http://www.example.com/" />
<xhtml:link rel="alternate" hreflang="en-au"
href="http://www.example.com/au/" />
<xhtml:link rel="alternate" hreflang="en-gb"
href="http://www.example.com/uk/" />
</url>The advantage of using XML Sitemap is that no extra HTML is added to the page itself – page weight stays the same and there are no additional database queries. It’s also far easier to update all pages at once using scripts, making this the most scalable option for sites with many languages.
Common Hreflang Implementation Mistakes
Studies estimate that 65-75% of international websites have significant hreflang errors. Here are the most common ones to watch out for:
Missing return tags. Hreflang annotations must be bidirectional. If page A points to page B as an alternate version, page B must point back to page A. Without this reciprocal link, Google ignores the hreflang entirely.
No self-referencing tag. Every page must include an hreflang tag pointing to itself, in addition to pointing to all other language versions. Skipping the self-reference can cause search engines to disregard all your hreflang annotations on that page.
Invalid language or country codes. Using uk instead of the correct en-gb, or jp instead of ja – these break the entire implementation. Always verify your codes against the ISO 639-1 and ISO 3166-1 standards.
Conflicts with canonical tags. If your canonical URL points to a different page than what the hreflang tag references, Google gets mixed signals. The canonical and hreflang URLs for each page must match.
Mixing implementation methods. Pick one method and stick with it. Placing hreflang tags in both the HTML <head> and the XML Sitemap creates conflicts that confuse crawlers.
Using relative URLs. Hreflang tags require absolute URLs (starting with https://). Relative paths will be ignored.
Additional Technical Aspects of Hreflang Implementation
After choosing your preferred implementation method, there are a few more technical details to consider:
Hreflang x-default
x-default is a special hreflang value that defines the fallback page – the one Google should show when none of your defined language/region tags match the user’s settings. In an <link> element, it looks like this:
<link rel="alternate" href="http://example.com/" hreflang="x-default" />This is typically your main/default language page. Google strongly recommends always including x-default in your hreflang setup.
Hreflang and Canonical URLs
rel="canonical" and hreflang="x" must work together. Each language version needs a canonical URL that points to itself. Here’s an example – assuming we’re on the home page of example.com:
<link rel="canonical" href="http://example.com/">
<link rel="alternate" href="http://example.com/" hreflang="en" />
<link rel="alternate" href="http://example.com/en-gb/" hreflang="en-gb" />
<link rel="alternate" href="http://example.com/en-au/" hreflang="en-au" />If we were on the en-gb page, the only thing that would change is the canonical URL, as shown in the following example:
<link rel="canonical" href="http://example.com/en-gb/">
<link rel="alternate" href="http://example.com/" hreflang="en" />
<link rel="alternate" href="http://example.com/en-gb/" hreflang="en-gb" />
<link rel="alternate" href="http://example.com/en-au/" hreflang="en-au" />A common mistake is setting the canonical on the en-gb page to point to http://example.com instead of itself. This breaks the implementation. The hreflang URL and the canonical URL for each page must always match.
Here’s a comprehensive guide on canonical URLs and the canonical tag.
FAQs
Common questions about hreflang implementation:
hreflang attribute is an HTML annotation that tells search engines which language and regional version of a page to serve to users. Use it whenever your site has pages with equivalent content in different languages, or the same language targeting different countries (e.g. en-us vs. en-gb).x-default is a special hreflang value that specifies the fallback page for users whose language or region does not match any of your defined hreflang tags. It typically points to your main language page or a language-selection page. Google recommends always including it.<link> tags, HTTP headers, or XML Sitemap. Mixing methods creates conflicting signals and can cause search engines to misinterpret or ignore your hreflang annotations entirely.rel="canonical" tag pointing to itself and hreflang tags pointing to all versions (including itself). The canonical URL and the hreflang URL for each page must be identical. If they conflict - for example, if the canonical on the en-gb page points to the en page - the hreflang implementation breaks.wp_head hook.Summary
Here are the key takeaways for implementing hreflang correctly:
- Always include a self-referencing tag on every page, along with tags for all translated versions.
- Make sure the reference is bidirectional – if page A links to page B, page B must link back to page A.
- Use valid ISO 639-1 language codes and ISO 3166-1 country codes.
- Always set a fallback URL using
hreflang="x-default". - The hreflang URL and the canonical URL for each page must match.
- Use absolute URLs only – no relative paths.
- Pick one implementation method (HTML, HTTP headers, or Sitemap) and stick with it.
- Choose a clear URL structure (subdirectories, subdomains, or ccTLDs) for your language versions.
Here are some tools that can help during the implementation:
- Aleyda Solis’ Hreflang Tags Generator for creating or modifying hreflang tags.
- Hreflang Testing Tool for validating hreflang tags on a live page.
Hreflang is just one piece of the international SEO puzzle. If you’re also dealing with paginated content across languages, check out the guide on using rel=next and rel=prev for pagination.
I hope this guide helps the next time you build a multilingual site.
