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 is called hreflang (sometimes written href lang, or referred to loosely as langhref), and despite its reputation, it's simpler to implement correctly than most explanations make it sound. The reputation, though, is earned: even Google's own Search Advocate has called this one of the trickier corners of technical SEO, and the data on real-world implementations backs that up.
Hreflang (also written href lang) 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.
- Hreflang routes searchers to the right language/region page — it is not a ranking factor by itself.
- Every page in a cluster must link back to every other page, including itself, or Google may discard the whole set ("return tag" rule).
- Codes follow the format
language-COUNTRY, e.g.en-GB, using ISO 639-1 and ISO 3166-1 standards. - Hreflang can be declared in HTML tags, an XML sitemap, or an HTTP header — sitemaps scale best for large or frequently updated sites.
- Bing treats hreflang as a weak signal; Google treats it as strong. Don't rely on it as your only international signal.
What is hreflang?
Hreflang is an annotation 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. You'll see it referred to a few different ways in the wild — hreflang, href lang (as two words), or even shorthand like langhref — but they all point to the same attribute.
Below is a single hreflang entry broken into its three working parts — the relationship it declares, the language and region it targets, and the URL it points to.
Marks this as an alternate version of the current page — the same instruction used for AMP pages or print stylesheets, just applied to language instead.
The language and region this specific URL is written for: English, targeted at Great Britain. This is the part that actually routes the searcher.
The full, absolute URL of the page being described — not the page the tag lives on, but the destination it's pointing to.
Four things are worth understanding clearly before implementing anything:
- 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 "return tag" requirement is covered in detail further down, and it's the single most common reason hreflang silently fails.
- A URL can only be declared once per language. Search engines expect one page per language (or language-region pair) in a set — pointing the same hreflang value at two different URLs on the same page creates a contradiction that gets the whole annotation discarded.
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 — which is exactly what makes it easy to get subtly wrong, and exactly why that 67% error rate exists in practice rather than in theory.
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.
- Correctly linked pages share ranking signals. A well-formed hreflang cluster lets search engines treat the group as connected variants of one asset rather than isolated pages competing from zero.
How Google actually processes hreflang
It helps to think of hreflang less as a tag and more as a cluster map. Google crawls each URL in a set independently, reads its list of alternates, and only accepts the cluster as valid once every page's list agrees with every other page's list. The diagram below shows a healthy three-page cluster next to a broken one where a single missing link invalidates the whole group.
en-AU is referenced by the other pages but never returns the favor, so
Google discards the annotation for that URL.
A few mechanical details follow from this model:
- Hreflang doesn't create a canonical group by itself. Each URL in the cluster is still indexed and ranked on its own; hreflang only affects which one gets surfaced for a given searcher.
- Discovery happens per-crawl. If Google hasn't recrawled a page since you added a new alternate to the cluster, that page's copy of the annotation is still the old one — this is why changes can take time to fully propagate.
- Google, not the tag, makes the final call. Hreflang is treated as a strong hint rather than a strict directive, so it's usually followed but can be overridden if other signals on the page strongly disagree with it.
- The declared language should match the visible content. If a page's
<html lang="...">attribute says one language but its hreflang entry declares another, that mismatch is itself a flaggable error and weakens confidence in the whole set.
Google vs. Bing: is hreflang treated the same way?
This is worth separating out because it changes how much weight to put on hreflang depending on which search engine you're optimizing for. Google treats a correctly implemented hreflang cluster as a strong signal for routing searchers to the right localized page. Bing does not weight it nearly as heavily.
Hreflang is a well-documented, actively supported signal. Return tags, x-default, and valid ISO codes are all checked, and errors are surfaced directly in Search Console's International Targeting report.
Bing has publicly described hreflang as a weak signal for its systems, leaning more on a page's actual content language, server or hosting location, and explicit country-targeting settings to decide what to serve.
The practical takeaway: implement hreflang correctly for Google, but don't rely on it as
your only international signal. Clear on-page language, consistent <html
lang> attributes, and straightforward URL structure (subfolders or ccTLDs per
region) still matter for engines that treat hreflang as secondary.
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.
- Match the HTML lang attribute to the hreflang value. A page whose visible content is declared as one language shouldn't carry a self-referencing hreflang entry for a different one.
- 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.
Here's what a complete, valid three-page cluster looks like once every step above has been applied — this is the exact block that would go on each of the three pages, with only the self-referencing entry order changing:
Notice that the US page includes an entry pointing to itself — that self-reference is what most implementations forget, and it's required, not optional.
Common mistakes that break hreflang
These account for the large majority of hreflang errors flagged in Search Console and by third-party site audit tools — each is small on its own, but any one of them can invalidate an entire cluster.
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.
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, and codes that aren't valid ISO 639-1 / ISO 3166-1 values get ignored outright.
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.
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.
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.
Declaring the same language for more than one URL
A single page's hreflang set should reference one URL per language (or language-region pair) at most — pointing hreflang="en" at two different pages from the same source page is a direct contradiction that gets the whole set discarded.
Mismatched HTML lang and hreflang values
When a page's <html lang="..."> declaration doesn't match the language it uses to reference itself in hreflang, that inconsistency undermines confidence in the whole annotation for that page.
Why IP-based redirects aren't a substitute
A common workaround people reach for instead of hreflang is auto-detecting a visitor's country from their IP address and redirecting them straight to the matching regional page. It's tempting because it feels automatic, but it causes two real problems.
- IP-based location detection isn't reliable. VPNs, corporate networks, and mobile carriers routinely place visitors in the wrong country, sending real users to the wrong version of a site.
- It can look like cloaking to search engines. Most crawler traffic originates from a small set of locations, so if crawlers are redirected differently than a typical user would be, that's treated as showing search engines something different from what visitors see — a guideline violation, not just a UX issue.
The safer pattern is to let hreflang (or explicit visible links to alternate versions) do the routing for search engines, and — if you still want to nudge human visitors toward a better-matching page — use a small, dismissible banner suggesting the alternate version rather than a forced redirect. It should stay unobtrusive enough that it doesn't function as an interstitial blocking the page.
Real-world examples
Hreflang looks different depending on how a site is structured — by subfolder, by subdomain, or by fully separate domain. Here's how the same underlying signal plays out across four common site setups, with the actual URL pattern each one uses.
store.com/us/shoes, /uk/shoes, /au/shoes — same product copy, different currency and shipping details, linked so each country sees its own version in search.saas.com/de/pricing style paths — fully translated landing pages linked as language alternates, with x-default pointing to the English version.news.in, news.com, news.co.uk — same English-language story, three regional editions, hreflang prevents the editions from cannibalizing each other's rankings.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, regardless of whether that site uses subfolders, subdomains, or entirely separate domains.
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 |
A sitemap entry for the same three-page cluster used earlier looks like this — one
<url> block per page, each carrying the full set of alternates:
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.