You've built a site with a US page and a UK page, or an English version and a Spanish version of the same product page. Then you notice something odd in Search Console: Google is showing your Spanish page to searchers in Madrid, but also occasionally to searchers in Mexico City who'd be better served by a page with Mexican pricing and spelling. Or worse, your US and UK pages are quietly competing with each other, and Google is only ever showing one.
This isn't a content problem. It's a signal problem — Google has no way to know these pages are intentional, region-specific counterparts of each other unless you tell it. That signal has a name, and it's simpler to implement correctly than most explanations make it sound.
Hreflang is an HTML attribute that tells search engines which language and region a page is written for, so the right localized version of a page can be shown to the right searcher. It's added as link tags in the page head, an HTTP header, or an XML sitemap, and every page in a set must link back to every other page, including itself, for it to be considered valid.
What is hreflang?
Hreflang is an annotation, most often written as a <link> tag, that
pairs a page's URL with a language and, optionally, a region code. It exists to solve one
specific problem: when the same content is published in multiple languages or for multiple
countries, search engines need a way to know those pages are alternates of each other
rather than duplicate or unrelated content.
- The tag itself is simple. A typical entry looks like
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />, placed in the<head>of a page. - Codes combine language and region. The language part uses ISO 639-1 (like
en,fr,es) and the optional region part uses ISO 3166-1 Alpha-2 (likeGB,CA,MX), joined with a hyphen. - x-default is the fallback. One entry in the set can be marked
hreflang="x-default"to catch visitors whose language or region doesn't match any specific entry. - Every page must reference every page. A set of three regional pages needs each one to list all three (including itself) — this is the "return tag" requirement that trips up most implementations.
Put simply: hreflang isn't a tag you add to one page. It's a relationship you declare across a whole cluster of pages at once.
Why hreflang matters
Skipping hreflang on a multilingual or multi-region site has consequences that are easy to miss until they show up in traffic data:
- The wrong page reaches the wrong searcher. Without hreflang, Google picks one version to rank based on its own signals, which may not match the searcher's actual language or country.
- Regional pages can cannibalize each other. Near-identical US and UK pages without hreflang can be seen as competing rather than complementary, splitting ranking signals instead of combining them.
- Click-through rate improves when the match is right. A searcher shown a page in their own language and currency is more likely to click and stay than one shown a mismatched version.
- It supports expansion, not just correction. Sites planning to launch new regional or language versions benefit from having the hreflang pattern already in place before the second version even exists.
Step-by-step: implementing hreflang
- Map out your page groups. List every set of pages that are the same content in different languages or for different regions — this is the cluster hreflang will connect.
- Choose an implementation method. Decide between HTML link tags in the page head, an HTTP header (useful for PDFs or non-HTML files), or entries in your XML sitemap.
-
Assign the correct codes. Use the ISO 639-1 language code alone for language-only targeting, or add the ISO 3166-1 country code when a page is region-specific, such as
deversusde-AT. - Add a full set of tags to every page. Each page in the cluster needs a complete list of alternates, including a self-referencing tag pointing to itself.
- Include an x-default entry. Point it to a sensible fallback, such as a language-selector page or your primary international version.
- Use absolute, canonical URLs. Every href value should be the full URL, including protocol, and should match the canonical version of that page exactly.
- Validate before and after publishing. Check the tags with a hreflang validator, then confirm in Google Search Console's International Targeting report that no return-tag errors appear.
Common mistakes that break hreflang
1. Missing return tags
If Page A lists Page B as an alternate but Page B doesn't list Page A back, search engines treat the whole annotation for that pair as untrustworthy and typically ignore it entirely.
2. Using the wrong or reversed code format
The format is always language-COUNTRY, such as en-US, never
US-en or a country code used alone — a country isn't a substitute for a
language in this syntax.
3. Conflicting with the canonical tag
Pointing a page's canonical tag at a different-language version while also hreflang-linking to it sends a contradictory signal — the canonical should point to itself when hreflang is being used to manage translated variants.
4. Using relative URLs
Hreflang href values need to be complete, absolute URLs with the protocol included; relative paths are a frequent cause of validator errors and silently ignored tags.
5. Forgetting to update the cluster when a page is added
Launching a new regional version means every existing page in that cluster needs its hreflang list updated to include the new page — otherwise the new version won't be linked back to properly.
Real-world examples
How hreflang plays out for different kinds of multilingual and multi-region sites:
The pattern across all four: hreflang isn't compensating for a translation problem, it's managing a routing problem — getting an already-correct page in front of the right person.
Hreflang implementation methods compared
Three valid ways to declare hreflang, and where each one is the more practical choice.
| Method | Setup effort | Best for | Watch out for |
|---|---|---|---|
| HTML link tags | Moderate, per page | Small to mid-size sites with templated pages | Return tags must be kept in sync across every page |
| XML sitemap | Low, centralized | Large sites, frequently added content, blogs | Sitemap must be regenerated whenever pages change |
| HTTP header | High, server-level | Non-HTML files like PDFs | Requires server or CDN configuration access |
Generate your hreflang tags right now — free
The Rebrixe Hreflang Generator builds a complete, return-tag-safe set of hreflang link tags for every page in your cluster, including x-default. No account, no watermark — enter your URLs and language codes, and copy the finished markup.