- Hreflang seamlessly delivers your content to users in their own language.
- Use hreflang clusters to share ranking signals among all language versions of a page.
- Hreflang tags function differently than canonical tags.
- Learn the proper hreflang format and where to put the tags in an HTML document.
Think about the level of complexity it takes for your company to operate globally: you have offices all over the world. Executives from different markets must communicate with each other across languages, time zones and cultural norms. You need to build out unique content for each market, as well as translate existing content, including knowledge bases, resources, blog posts and FAQs.
More importantly, you need to serve the right content to the right customers in the right locations. How? The hreflang tag.
Once described by Google’s John Mueller as “one of the most complex parts of international SEO,” the hreflang tag is the cherry on top of the complicated global sundae.
What is hreflang?
Hreflang is an HTML attribute tag that specifies the language and geographical region for each URL.
For instance, the hreflang tag is responsible for ensuring your customers in Australia read the Australian English version of your web page rather than the US English or German. (This applies only to pages that contain the same content in different language, not pages that contain content unique to a specific country.)
Both Google and Yandex actively use href language tags to determine which version of translated content is most appropriate to show to their users. Baidu and Bing use the content-language HTML attribute. So before we go any further, here’s your friendly reminder to know the most popular search engine(s) within your target markets. (It’s not always Google!)
For most markets outside of China, Google’s whopping 81.5% of global market share makes the search engine we know and love your top concern. Yandex is the most popular search engine in Russia, Baidu is the most popular in China. And Yahoo is the most used in Japan. The most likely scenario is that you’ll end up using both types of tags.
It’s important to note that Google won’t use language-specific subdomains to automatically serve the correct content versions to your users. So, hreflang annotations are still the most effective way to signal to Google which language version to show your users.
Hreflang SEO impact
Let’s start with the obvious hreflang SEO concern: User experience. Imagine landing on a page written in Spanish when you only speak English. That’s precisely what could happen to your customers if you don’t signal to Google which language versions to serve. As a result, your bounce rate will go through the roof, and users may stop clicking on your results in the SERPs.
The less-obvious technical SEO impact of hreflang tags has to do with hreflang clusters. The reason hreflang implementation can be logistically complicated is because it’s not enough to just drop the tag on the page. Properly-implemented hreflang annotations establish hreflang clusters: a list of the equivalent pages for the other languages or regions.
Each urlset shares ranking signals. So, if you accidentally leave a page out of its appropriate cluster, it will not benefit from the authority of the other pages. Furthermore, a page without a reciprocal reference will trigger a return tag error.
What about duplicate content?
Well the good news is, translated pages aren’t considered duplicate content by Google. However, if you have multiple English language pages for the US, Australia, and the UK, then search engines will consider those duplicate content. The hreflang tag ensures the search engines don’t pick the wrong version.
How to add hreflang tags
Before we talk about how to use hreflang tags, let’s clear up the hreflang canonical conflict.
Difference between canonical and hreflang
The hreflang attribute is similar to canonicalization in that they both help Google understand the relationship between pages. However, there are some key differences between canonical and hreflang tags.
Canonical tags point to the source or priority version of duplicate pages as the “preferred” page. When you set a preferred page on canonical urls, that means the other versions don’t get indexed or served in the SERPs. They simply exist on the site as part of basic UX functionality. A good example of this would be product page URLs with parameters.
Hreflang tags, on the other hand, tell search engines that you have several different language versions of the same page, and they should serve the appropriate one based on a user’s region and language. In this case, each page in your hreflang cluster is indexed, and can get served in the search results. But the search engine will pick the one marked for the right language and location.
And that’s why the ease of implementation is so different for the two tags. A canonical’s directive is fairly binary: this is our preferred page, this one is not. An hreflang’s tag offers a much more detailed set of instructions: these pages are all translations or location-based versions of each other. Use this one here, and this one here, and this one here…
Because of that extra layer of complexity, you can’t automate hreflang tags quite as swiftly as canonicals. Additionally, you should never use them interchangeably.
X-default hreflang values
Hreflang tags use the following syntax:
<link rel=“alternate” hreflang=“x” href=“https://www.example.com/new-page” />
What that is telling us is: the page linked is an alternate version of our current page, translated in language x.
You’ll replace the x with the two-letter ISO 639-1 code that demarcates the country/language you want. You can find a full list of ISO 639-1 language and region codes here.
Google highly recommends that you set an “x-default” page. This establishes one URL as the default version that doesn’t target a specific region or language for visitors that fall outside of your specified regions.
How to construct an hreflang tag
For translated web pages, constructing an hreflang tag is as simple as replacing that x with your country code. If we wanted to translate our example link into French, it would look like this:
<link rel=“alternate” hreflang=“fr” href=“https://example.com/french-version” />
If you want to target a locale instead of (or in addition to) the language, you’re going to use a two-letter code in the ISO 3166-1 alpha-2 format. Let’s look at the different tags we could use to target English speakers in various regions.
- EN-UK: <link rel=“alternate” hreflang=“en-gb” href=“https://example.com/uk/our-page” />
- EN-US: <link rel=“alternate” hreflang=“en-us” href=“https://example.com/us/our-page” />
- EN-CA: <link rel=“alternate” hreflang=“en-ca” href=“https://example.com/ca/our-page” />
- EN-AU: <link rel=“alternate” hreflang=“en-au” href=“https://example.com/au/our-page” />
Note that this link uses both ISO codes: first to set the language, then to direct the search engine to the correct version of the page.
Where to put hreflang tags
You can set href tags in three ways: HTML, HTTP and XML. HTML is the easiest option but the XML sitemap method is more scalable.
If you only have one other market to worry about (let’s say you target Canada and Germany), then the only implementation-related takeaway you need is this: hreflang annotations are bidirectional. That means they only work in pairs. If your tag on the English version of a page points to the German version, then the German version must point to the English version for the tags to count. This proves to Google that:
- Your pages actually have a relationship with each other.
- You have control over both.
And if you’re all over the world? Let the fun begin! This is the part where you’re going to need to establish your hreflang clusters on each group of pages.
The good news is that at this stage your translated pages should already be set up. And you should have a list of them, so you won’t have to pull country codes out of thin air. Instead, use a spreadsheet to group your URLs by cluster, then assign each one its respective country code and create its hreflang link. Then you’re going to grab all of the link elements in the cluster and paste them into the head of each page in your cluster.
Your page must reference itself, too – so if you’re currently on the French version of the home page, do not delete that link from your cluster. That actually makes the whole tag easier to implement, because it becomes a simple copy-paste job.
Here’s what this looks like in action.
Let’s say we want translated language versions of our “hello” page to render properly in the following countries: U.S., Germany, France, Russia, Spain and China. (Remember that for China, you will also want to include the Baidu-supported language codes. But a significant number of Chinese customers will be using Google too, so use both).
Our hreflang cluster would look like this:
For non-HTML documents (like pdfs), you obviously won’t be able to write your directive in HTML. In this case you’d use the http header. If you’re translating a pdf from English to French, you’d put this into the http header of each file:
<https://example.com/blog/englishversion.pdf> rel=“alternate” hreflang=“en”>
<https://example.com/blog/frenchversion.pdf> rel=“alternate” hreflang=“fr”>
Finally, you can specify your hreflang clusters directly in your sitemap using the xhtml:link attribute. Using the six countries we chose for our html example, that would look like this:
…And so on for the remaining four country pages.
The result may look like a monstrosity. But it’s actually easier and much more scalable to implement than HTML because you can work with everything in one file, not page by page.
Common hreflang issues
Even though you can automate hreflang tag creation fairly easily, issues can arise. Here are some common mistakes:
It may not be easy to spot or troubleshoot, but human error is the most common cause of hreflang failure. Maybe a page changes and you link to a 404. Maybe you mistyped a URL or forgot to close a tag. It happens!
The Fix: Automate as much as you can to reduce this possibility. And conduct periodic crawls to check for broken links or 404s. Consider taking the XML sitemap route instead of the HTML route. That way, if you encounter many issues, you can simply edit your sitemap and upload a clean version of the file instead of updating the HTML on individual pages.
If you do mistype a tag, the search engines will simply ignore that version of the page. That means it’ll probably pull your default page instead, serving an English site to your German speakers.
The fix: Many site crawlers — the one from Ahrefs, for example — will note whether your hreflang tags are valid or not. You’re going to start seeing a theme in all of our troubleshooting tips: crawl, crawl, crawl. Once your crawler notices the error, it’s easy to address.
One page is referenced for multiple languages
Your English language and French “hello” pages should look like this:
<link rel=“alternate” hreflang=“en” href=“https://example.com/hello” />
<link rel=“alternate” hreflang=“fr” href=“https://example.com/salut” />
If they look like this, you have a problem:
<link rel=“alternate” hreflang=“en” href=“https://example.com/hello” />
<link rel=“alternate” hreflang=“fr” href=“https://example.com/hello” />
The fix: Perform a site crawl to identify errors and correct them.
Hreflang points to non-canonical URLs
It is shockingly easy to leave off a trailing slash, leave out the www when you shouldn’t, or otherwise neglect to point to the true canonical version of a page.
The fix: A site crawl will identify the issue so you can correct it. However, prevention is key here. That starts in the earliest stages of your automation system. Know exactly what your standard canonical link looks like and use that rubric as you build out your system.
Additional errors are all variations on the same theme: a site crawl will spot it and prevention is key.
Forgot to make sure you tag self-references? Missing a reciprocal tag? A mismatch between what’s in the sitemap and what’s in the HTML? See theme.
In the end, hreflang tags are easy to understand. Their reputation for complexity comes in the implementation. But build an automation-based system that works for you and your team and implementation will be a breeze. Then crawl, crawl, crawl, address any errors and repeat. Before long, your customers all over the world will be reading the content that’s perfect for them.