Hreflang tags are HTML link elements that tell search engines which language and regional version of a page to serve a given user. They prevent duplicate-content conflicts across localized pages and route each visitor to the right URL. Google and Yandex use them; Bing relies mostly on content signals.
If you run a site that targets more than one country or language, hreflang is one of the highest-leverage technical SEO investments you can make. It is also one of the most misunderstood. A single misconfigured tag can cause carefully translated pages to disappear from search, or send German users to your English pricing page and watch them bounce.
This guide is written for growth and marketing leaders and the technical SEO owners who support them at startups and scaleups. You will learn what hreflang is, how the syntax works, how it interacts with canonical tags, and how to avoid the mistakes that break most multilingual deployments.
TL;DR: What Are Hreflang Tags?
- Hreflang tells search engines which language and region a page targets.
- It is a signal used by Google and Yandex, not a ranking factor by itself.
- Every URL in a set must reference every other URL, including itself.
- x-default covers users who do not match any specific language or region.
- You can implement it in the HTML head, HTTP headers, or an XML sitemap.
- Canonical and hreflang must agree or your signals will conflict.
- Validation with a checker catches most deployment errors before they ship.
What Is an Hreflang Tag and What Does the Syntax Look Like?
An hreflang tag is a link element placed in the HTML head that points to an alternate version of the current page for a different language or region. Each value combines an ISO 639-1 language code with an optional ISO 3166-1 Alpha 2 region code, separated by a hyphen. For example, en-GB means English as used in the United Kingdom, while es-MX means Spanish as used in Mexico. A script subtag such as zh-Hans is valid for written script, not a country.
The most common implementation uses a link rel="alternate" element for each variant. Here is a minimal, correct example with escaped angle brackets:
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/mx/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Each line names one version of the page and points to its own URL. Notice that every variant, including the default, is listed on every page in the set. This is not optional. The rule of bidirectional confirmation is the single most violated part of hreflang, and it is covered in a later section.
Why Does Hreflang Matter for SEO?
Without hreflang, search engines guess which version of a page to show. That guess is often wrong. A user searching in Spanish may land on your English page, read three words, and leave. That bounce sends a weak negative signal, and the translated page you invested in stays buried.
Hreflang solves three problems at once. First, it prevents duplicate content penalties by clarifying that similar pages are intentional translations, not spam. Second, it improves user experience by serving the correct language and currency from the start. Third, it protects the rankings of each localized page by keeping link equity cleanly separated by audience. For teams running a technical SEO audit checklist, hreflang is a standard line item once the site goes international.
How Do Hreflang Tags Work with Return Links?
The return-link rule is simple but strict: if page A lists page B as an alternate, then page B must list page A as an alternate. Google calls this bidirectional confirmation, and it ignores the entire hreflang set if any return link is missing. Self-reference is also required, so every page must include its own hreflang line.
Think of hreflang as a handshake. Page A says "my Spanish version is at /mx/." Google then visits /mx/ and checks that /mx/ says "my English version is at /." If that handshake is not completed, Google drops the annotations for both pages. This is why a single broken URL in a 40-page cluster can silently disable hreflang everywhere in the set.
What Is the X-Default Value and When Should You Use It?
The x-default value is a special hreflang token that points to a page for users whose language or region does not match any specified alternative. It is most often used for a global landing page, a language selector, or a region picker.
You should always include x-default when you have a catch-all page. If a German user in your cluster has browser settings of fr-CA but you only ship en, en-GB, and es-MX, the x-default page catches them instead of leaving Google to guess. Note that x-default is not a fallback ranking signal; it only controls which URL is shown when no language matches. Pair it with strong internal linking so users can still navigate to their preferred locale.
Where Should Hreflang Be Implemented?
There are three supported places to declare hreflang: the HTML <head>, the HTTP Link header, and an XML sitemap. All three are valid, and you should pick based on your stack and who owns the deployment.
| Method | Best for | Tradeoff |
|---|---|---|
| HTML head | Sites where marketing or CMS can edit templates | Adds bytes to every page; easy to forget on generated routes |
| HTTP header | PDFs, non-HTML files, or edge-injected tags | Harder to debug; needs server or CDN access |
| XML sitemap | Large sites with many language pairs | One file to manage, but slower to propagate changes |
The HTML head is the most common choice for content sites because it is visible and easy to validate. The HTTP header is the only option for non-HTML documents. The XML sitemap scales best when you have hundreds of locale combinations, since you maintain the mapping in one file rather than editing every page. Whichever you choose, never mix methods for the same URL set in a way that contradicts itself.
How Do Hreflang and Canonical Tags Work Together?
Canonical and hreflang answer different questions. Canonical tells search engines which URL is the primary version of a page when duplicates exist. Hreflang tells them which version to show to which user. They must agree, or the signals conflict.
The key rule: each URL in an hreflang set should canonicalize to itself, not to another language version. If your Spanish page canonicalizes to the English page, you are telling Google the Spanish page is duplicate and should be folded into English, which defeats the hreflang annotation. The correct pattern is for /mx/ to carry both hreflang="es-MX" and canonical="https://example.com/mx/". This is a frequent source of keyword cannibalization confusion across locales. For a deeper look at the canonical side, see our guide on canonical tags.
What Are the Most Common Hreflang Mistakes?
Most hreflang failures come from a short list of repeatable errors. Here are the ones we see most often, with the fix for each.
- Missing return links. Every page must list every other page, including itself. Fix by generating the full set programmatically rather than hand-editing.
- Wrong language or region codes. Using
ukfor Ukrainian orGBas a language breaks matching. Fix by validating against ISO 639-1 and ISO 3166-1 Alpha 2. - Canonical points to another locale. This overrides hreflang. Fix by self-canonicalizing each language version.
- Conflicting methods. Declaring hreflang in both head and sitemap with different URLs confuses crawlers. Fix by choosing one source of truth.
- Pointing x-default at a 404. The default must resolve. Fix by routing x-default to a real landing or selector page.
These mistakes are preventable, but only if someone owns the audit. Too many teams set hreflang once and never revisit it after a redesign or a new locale launch. Treat it like crawl budget optimization: a system to maintain, not a task to tick off.
How Do You Audit and Validate Hreflang Tags?
Validation should happen before and after every deployment. Start with a crawler that reports hreflang return-link errors, missing self-references, and conflicting canonicals. Then confirm with a dedicated robots.txt-aware checker that the alternate URLs are actually indexable and not blocked.
A practical audit loop looks like this: export your URL and locale map, generate the expected hreflang set, run a checker against the live pages, and diff the results. Any page missing a return link or using an invalid code should block the release. Free browser extensions and command-line validators both work; the important part is that the check runs automatically in CI rather than relying on someone to remember.
Key Takeaways
- Hreflang routes users to the correct language and regional page, reducing bounce and duplicate content risk.
- Every URL in a set must reference all others, including itself, or Google ignores the whole set.
- Use x-default for users who match no specific language or region.
- Canonical and hreflang must agree; self-canonicalize each locale version.
- Validate with a checker in CI on every deploy to catch return-link and code errors early.
Frequently Asked Questions
Does Bing Support Hreflang Tags?
Bing does not use hreflang the way Google and Yandex do. It relies primarily on content-language signals and metadata to determine the intended audience of a page. If your strategy depends heavily on Bing traffic in specific markets, focus on clear language declaration in your content and HTML, and treat hreflang as a Google and Yandex optimization rather than a universal one.
Can I Use Hreflang on a Single-Language Site?
You generally should not need hreflang if you only have one language and one region. Hreflang is designed for sites with multiple language or regional versions of the same content. Adding it to a single-version site creates unnecessary annotations with no alternates to point to, which can confuse crawlers and adds no user benefit. Keep it simple until you actually launch a second locale.
How Many Alternate URLs Can One Page List?
There is no hard fixed limit from Google on the number of alternate URLs a page can declare, but each additional link element adds page weight and crawl overhead. In practice, clusters of dozens to a few hundred variants are common on large international sites, usually managed through XML sitemaps. Keep the set complete and accurate; a missing return link hurts more than a large but correct set helps.
Is Hreflang a Ranking Factor?
Hreflang is not a direct ranking factor in the sense of boosting position. It is a signal that controls which already-indexed version of your page appears for a given user. By serving the right language and region, it improves engagement and reduces bounce, which can indirectly support performance. The real value is relevance and user experience, not a direct rank increase from the tag itself.