hreflang Tags Explained: Serving the Right Language Version
Imagine you run a shop that sells the same products to people who speak different languages. A visitor types a search, lands on your site, and is greeted by a page written in a language they don't read. Within seconds, they're gone. Now imagine the opposite: every visitor automatically sees the version written for them, in their language, with the right spelling and the right prices. That second experience is what a small piece of code called hreflang is designed to make happen.
If you've ever wondered how big international websites manage to show the British spelling to one reader and the American spelling to another, or Spanish to one and Portuguese to the next, this guide is for you. We'll explain what hreflang is, why search engines care about it, and how to use it without getting tangled in technical knots. No prior coding knowledge required.
What hreflang actually is
hreflang is a small annotation you add to your web pages that tells search engines, “this page has other versions for different languages and regions, and here is where to find them.” The word itself is a mash-up of “href” (the part of a link that points to a web address) and “lang” (short for language). Put together, it's an instruction about which language a particular link is meant for.
Think of it like the signage in an international airport. The same gate information appears in several languages so every traveller can find their flight. hreflang is the airport announcement system for your website: it quietly points each searcher towards the version of a page that fits them best.
Crucially, hreflang is a hint, not a hard command. Search engines use it as a strong signal to decide which version to show, but they still make the final call. That distinction matters, because it means hreflang works best when the rest of your site sends consistent signals too. If you're new to the broader topic of how search engines read your site, our overview of technical SEO basics is a friendly place to start.
Language and region are two different things
This is the idea that trips most people up, so let's slow down. hreflang can target a language on its own, or a language paired with a region. “en” means English in general. “en-gb” means English as used in one region, while “en-us” means English as used in another. The language part is required; the region part is optional and only worth adding when the content genuinely differs, such as different prices, spelling, or shipping details.
Why search engines reward getting this right
Search engines have one stubborn goal: send each person to the most useful result. If your site has a German page and an Italian page covering the same product, the search engine wants to show the German one to German speakers and the Italian one to Italian speakers. Without hreflang, it has to guess, and it sometimes guesses wrong, sending a reader to a page they can't comfortably use.
There's a second, quieter benefit. When you publish the “same” content in several languages, those pages can look suspiciously similar to a search engine, especially when two versions share a language, like English for two different regions. hreflang explains that these aren't accidental copies competing with each other; they're deliberate variations, each for a specific audience. That helps you sidestep the headaches we cover in our guide to duplicate content.
It protects the rankings you've already earned
Picture this. You've worked hard to rank well, then you launch a second regional version of a popular page. Suddenly both versions compete for the same searches, and the search engine, unsure which to favour, splits its confidence between them. Both can slip. hreflang prevents that tug-of-war by clarifying who each version is for, so the authority you've built stays focused rather than scattered.
The three places hreflang can live
You don't have to choose a complicated method. hreflang can be implemented in one of three spots, and you only need one of them. The right choice usually depends on how your site is built and how many pages you have.
| Method | Where it goes | Best for |
|---|---|---|
| Page tags | In the head section of each page | Smaller sites; the most common, visible approach |
| Sitemap entries | Inside your XML sitemap file | Large sites with many language versions |
| HTTP headers | In the server's response | Non-HTML files like PDFs |
For most websites, the page-tag method is easiest to understand because you can see it. Each language version of a page lists every version, including itself. If you decide to use the sitemap approach, our walkthrough of XML sitemaps explains how that file works in the first place.
The golden rule: hreflang must be a return ticket
Here's the single most important thing to remember, and the one most often broken. hreflang links must point both ways. If your English page says “here is the French version,” then your French page must say “here is the English version” in return. If only one side declares the relationship, search engines tend to ignore the whole thing, because a one-way claim looks unreliable.
A handy way to picture it: hreflang is a return ticket, never a one-way trip. Every version must acknowledge every other version, and each must also reference itself. Miss a return link and the connection quietly fails, often without any obvious warning on the page.
Don't forget the “everyone else” option
There's a special value, x-default, that means “use this version for any searcher we don't have a specific match for.” If you have English and Japanese pages and someone searches in French, x-default tells the search engine which page to fall back on. It's often pointed at a language selector page or your most widely understood version. It's optional, but it's a thoughtful safety net.
Common mistakes that quietly break everything
Most hreflang problems aren't dramatic. The page still loads, nothing looks broken, and yet the wrong version keeps showing up in search results. Here are the usual culprits, in plain terms.
Mixing up codes
Region codes and language codes aren't interchangeable, and using the wrong one is a frequent error. The language always comes first, the region second, and they follow recognised standards. Inventing a code, or putting the region where the language should go, makes the annotation invalid. When in doubt, keep it simple: a plain language code with no region is safer than a guessed-at region code.
Pointing at pages that redirect or don't exist
hreflang should point to the final, live address of each version. If it points to a page that then bounces the visitor elsewhere, or to one that no longer exists, the signal weakens or breaks. This often happens after a site move. If you've been changing addresses, our guide to 301 and 302 redirects will help you keep everything pointing where it should.
Letting hreflang fight your canonical tags
A canonical tag tells search engines which version of a page is the “master” copy. If your French page's canonical tag points at the English page, you've effectively told the search engine the French page shouldn't exist on its own, which contradicts your hreflang. Each language version should treat itself as its own master. Our explainer on canonical tags shows how to keep these two systems working in harmony.
How hreflang fits into your wider SEO
It's tempting to treat hreflang as a one-and-done technical task, but it lives inside a bigger picture. Each language version still needs to earn its place: clear titles, useful content, and a sensible structure. Translating a page word for word isn't always enough; sometimes the phrasing people actually search for differs between languages, which is really a content question as much as a technical one. Pairing hreflang with genuinely localised content is what separates sites that merely exist in multiple languages from sites that perform in them.
It also helps to keep your overall site tidy. A clean, logical structure makes it far easier to manage multiple language versions without losing track of which page maps to which. If your site is growing in several directions at once, our guide to SEO site structure is worth a read, and internal links between related pages, covered in our piece on internal linking for SEO, help search engines understand how your versions relate.
Do you even need hreflang?
Be honest about your situation. If your site is in a single language and serves a single audience, you don't need hreflang at all, and adding it would only create work and risk. It earns its keep when you have genuinely different versions for genuinely different audiences: different languages, or the same language tailored to different regions. If that's not you yet, file it away for the day it becomes one.
A simple way to get started
If you're ready to implement hreflang, resist the urge to do it everywhere at once. Start with a handful of your most important pages, the ones that already attract searchers in more than one language. Set up the return-ticket links between every version, double-check that each page references itself, and then watch what happens in your search reports over the following weeks. Once you're confident it's working on a few pages, roll it out more widely. If the technical side feels daunting, it's perfectly reasonable to get a hand from someone who sets these up regularly rather than risk a tangle.
The payoff is quiet but real: visitors who land on a page that simply feels made for them, in their language, with the details that match their world. They don't notice the code behind it, and that's exactly the point.
Frequently asked questions
Will hreflang make my site rank higher on its own?+
Do I need a separate page for every region, or just every language?+
What happens if I make a mistake in my hreflang setup?+
Is hreflang the same as redirecting people based on their location?+
References
- Google Search Central. “Tell Google about localized versions of your page.” developers.google.com.
- W3C. “Language tags in HTML and XML.” w3.org.
- W3Techs. “Usage statistics of content languages for websites.” w3techs.com.