We’re going to assume that you’ve decided which type of technical implementation you’re going to choose. There are a couple of other technical specificities you should know about before you start implementing hreflang.
There is a special hreflang attribute value that’s called x-default. The x-default value specifies where a user should be sent if none of the languages you’ve specified in your other hreflang links match their browser settings. In a link element it looks like this:
When it was introduced, it was explained as being for “international landing pages”, ie pages where you redirect users based on their location. However, it can basically be described as the final “catch-all” of all the hreflang statements. If the users location and language didn’t match anything else, that’s where they will be sent.
In the German example we mentioned above, a user searching in English still wouldn’t have a “fitting” URL. That’s one of the cases where x-default comes into play. You’d add a fourth link to the markup, and end up with these 4:
In this case, the x-default link would point to the same URL as the de one. We would not encourage you to remove the de link though, even though technically that would create exactly the same result. In the long run it’s usually better to have both as it specifies what language that de page is in and makes the code easier to read.
hreflang and rel=canonical
rel=”alternate” hreflang=”x”markup and rel=”canonical” can and should be used together. Every language should have a rel=”canonical” link pointing to itself. In the first example, this would look like this, assuming that we’re on the example.com homepage:
If we were on the en-gb page, not all that much would change other than the canonical:
Don’t make the mistake of setting the canonical on the en-gb page to http://example.com/, as this breaks the implementation. It’s very important that the hreflang links point to the canonical version of each URL. These systems should work hand in hand!
Useful tools when implementing hreflang
If you’ve come this far, you’ll probably be thinking “wow this is hard”, I know I thought that while learning about the topic. Luckily, there are quite a few tools available for people who dare to start implementing hreflang.
hreflang tag generator
Aleyda Solis, who has written quite a lot about this topic too, has created a very useful hreflang tag generator that helps you generate link elements. Even when you’re not choosing for a link element implementation, this can be useful to create some example code.
hreflang XML sitemap generator
The Media Flow have created an hreflang hreflang XML sitemap generator. You can feed it a CSV with URLs per language and it creates an XML sitemap. A very good first step when you decide to go this route.
The CSV file you feed this XML sitemap generator needs columns for every language. If you want to add an x-default URL to it as well, just create a column called x-default.
hreflang tag validator
Once you’ve added markup to your pages, you’ll want to validate that markup. If you choose to go the link element in theroute, you’re in luck, as there are a few validator tools out there. The best one we could find is flang, by DejanSEO.
Unfortunately, we haven’t found a validator for XML sitemaps yet.
Keeping hreflang alive: process
Once you’ve created a working hreflang setup, you need to set up processes. It’s probably also a good idea to regularly audit your implementation to make sure it’s still set up correctly.
Make sure that people in your company who deal with content on your site know about hreflang. This makes sure they won’t do things that break your implementation. Two things are very important:
When a page is deleted, check whether its counterparts are updated.
When a page is redirected, change the hreflang URLs on its counterparts.
If you do that and audit regularly, you shouldn’t run into many issues.