What is the purpose of hreflang tags in SEO?

Hreflang tags tell Google which language or region version of a page to show a searcher. The right localized page then competes in the right market, instead of guesswork deciding it. Without them, Google falls back to its own signals to judge relevance per locale.

How do I implement hreflang tags?

You implement hreflang tags with an HTML link element, an HTTP Link header, or an XML sitemap entry, picking one method and using it consistently. Every version must list every other version, including itself, or Google can disregard the whole set.

Why is my hreflang tag not working?

Your hreflang tag usually fails for one of three reasons. The most common: a missing return link, an invalid language or region code, or a target page that no longer returns a 200, which breaks the return link the same way a missing tag does. Check each alternate’s response and its reciprocal tag before assuming the markup itself is wrong.

What is x-default in hreflang?

x-default is the reserved hreflang value for a visitor whose language doesn’t match any version you’ve built. It’s used mainly on language selectors and auto-redirecting homepages, and needs no language code of its own, since it targets whoever is left over.

Does hreflang directly affect my rankings?

Hreflang does not directly affect your rankings. It’s a routing signal, not a ranking factor. Google still decides relevance and position for each query independently, using the same algorithms it applies everywhere else; hreflang only determines which of your eligible pages gets shown to a given searcher’s locale.

Do I need hreflang if I only have one language?

You don’t need hreflang if your site has exactly one language and one region, since there’s no alternate version for it to route between. A self-referencing tag anyway causes no harm, but it isn’t a meaningful task for a single-locale site.

How do you pronounce hreflang?

There’s no official pronunciation guide for hreflang. Most practitioners say “aitch-ref-lang,” reading its parts: HTML’s href attribute plus language. It isn’t an acronym with its own spoken form, so people typically read the letters and the word together as written, the same way they’d read rel or alt aloud in conversation. Section ID: cta

What is hreflang, and how do you implement it?

One tag, three ways to get it wrong

Hreflang is one tag that can silently send a French visitor to your English homepage, and most multi-language sites get at least one pair wrong. If you run a multi-region site, you’ve probably added hreflang tags once and set them aside, trusting the markup to keep working on its own.

It mostly doesn’t announce when it breaks. A single missing return tag can cancel out an entire set, and nothing in the rendered page or your analytics tells you which pair failed. This guide covers what hreflang does and the return-tag rule everyone forgets. It also covers how x-default fits in, and how to write a correct tag set across all three ways Google reads it.

What is hreflang?

Hreflang is an HTML, HTTP header, or XML sitemap attribute that tells Google which page on your site serves a specific language or region. It takes the form hreflang="lang_code", paired with the URL of that version. No guesswork from the page’s own content required: a search engine reads the attribute and matches the searcher’s locale to the right page directly.

The name itself is a contraction of HTML’s href attribute and language. One nuance trips people up immediately: declaring hreflang on a page does nothing by itself until every version in the set declares it back.

The attribute is formally defined for the HTML <link> element, as MDN’s reference on the hreflang attribute confirms. That’s exactly why a non-HTML file needs one of the other two declaration methods below instead.

Declaring hreflang in HTML

The most common method adds a <link> element to each page’s <head>, one for every version in the set, including the page itself:

<link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Every page in the set carries this same block, including the one you’re looking at.

Declaring hreflang in an HTTP header

A PDF or any non-HTML file can’t carry a <link> tag, so the same information goes in the response header instead:

Link: <https://example.com/en-us/file.pdf>; rel="alternate"; hreflang="en-us",
      <https://example.com/en-gb/file.pdf>; rel="alternate"; hreflang="en-gb"

Every version still needs the full set listed in its own header. It’s the same rule as the HTML method, just moved from the page’s markup to the server’s response.

Declaring hreflang in an XML sitemap

A large site can skip per-page markup entirely and declare every locale in one sitemap file:

<url>
  <loc>https://example.com/us/</loc>
  <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
  <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" />
</url>
<url>
  <loc>https://example.com/uk/</loc>
  <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/us/" />
  <xhtml:link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" />
</url>

Each <url> block still lists every version of that page, itself included. Same requirement as the other two methods.

Why does hreflang matter for multi-language and multi-region sites?

Hreflang matters because, without it, a French visitor can land on your English homepage with no clear path to the version meant for them. A multi-region brand that ships translated content with no routing signal leaves Google to guess which page fits which searcher instead. Google decides locale relevance through its own signals, not the page’s visible content alone.

A translated page with no hreflang pointing to it can sit invisible to the exact audience it was built for. That gap is a localization-strategy problem as much as an SEO one. The translation work and the routing work are two separate jobs, and finishing only the first leaves the second undone.

The user-experience cost of getting it wrong

A visitor who lands on the wrong language version usually does one of two things:

Bounces immediately, back to the search results or wherever they came from.
Hunts for a language switcher that may not even be visible above the fold.

Either way, the page you built for them never gets read. The signal you’re left reading in analytics, a high bounce rate on a translated page, looks like a content problem when it’s actually a routing one.

A separate job from translation itself

Two checklist items, not one. Shipping a translated page and shipping its hreflang tags are separate jobs, and finishing the first is easy to mistake for finishing both. A site can have flawless Spanish copy and still send every Spanish searcher to the English homepage, because nothing told Google the Spanish page exists as an alternate.

How do you implement hreflang tags?

Implementing hreflang means choosing one of the three declaration methods above. Then list every version of a page alongside every other version, including the page itself. Add the return pointer on each version so the set confirms itself in both directions.

One method. Every version. Pointing both ways.

Add an x-default fallback too, if the page is a language selector or an auto-redirecting homepage. Pick HTML tags for a typical site, the HTTP header for non-HTML files, or the sitemap method when per-page markup isn’t practical at scale.

Choose one method: HTML <link> tags, an HTTP Link header, or XML sitemap entries.
List every version of the page in the set, including the page’s own URL.
Confirm every version points back to every other version (the return-tag rule).
Add an x-default tag if the page is a language or country selector, or one that redirects automatically by locale.

The return-tag rule

The return-tag rule is simple once it’s stated plainly: every page in a hreflang set must link to every other page in that set, including itself, or Google can disregard the whole group. Google’s own documentation puts it just as directly: if page A names page B as an alternate but B doesn’t name A back, the annotation on both may be ignored. That’s why a single missing tag, on just one page, breaks more than the one pair it sits on.

Using x-default correctly

x-default is the fallback value for a visitor whose language doesn’t match any version you’ve built. It needs no language code of its own, since it targets whoever is left over. Add it to a language selector, a country selector, or a homepage that redirects automatically by locale:

<link rel="alternate" href="https://example.com/en-gb" hreflang="en-GB" />
<link rel="alternate" href="https://example.com/en-us" hreflang="en-US" />
<link rel="alternate" href="https://example.com/country-selector" hreflang="x-default" />

Every other version in the set still needs this same x-default line added to its own markup, exactly like any other alternate.

Method	Where it lives	Best for
HTML `<link>` tag	The page’s own `<head>`	Most sites with per-page template control
HTTP `Link` header	The server response	Non-HTML files: PDFs, downloads
XML sitemap	A separate sitemap file	Large sites where per-page markup isn’t practical

What are the most common hreflang mistakes?

Most hreflang mistakes share one consequence: Google quietly drops the signal rather than throwing an error. No warning. The page keeps working while the intended routing simply doesn’t happen.

A handful of specific errors account for most of it, and several have nothing to do with the return-tag rule covered above. So catching them usually takes a direct look at the markup itself, since nothing in a rendered page reveals that a locale signal failed.

Mistake	Why it breaks	The fix
`en_US` instead of `en-US`	Hreflang codes use a hyphen, not an underscore; the malformed code is disregarded	Use a hyphen between language and region
Relative instead of absolute URLs	A relative path depends on the base URL resolving correctly, which isn’t guaranteed	Write every hreflang URL in full, including `https://`
Missing self-reference on a paginated series	Google’s rule applies to every version of a URL. A paginated page is its own version, so it needs the same self-referencing tag as page one	Add a self-referencing tag to every page in the series, not only page one
A target that later redirects	A redirect breaks the return link Google requires: the URL you named no longer serves the matching self-reference back	Recheck hreflang targets after any redirect or URL change, not only at launch
All three methods used on one page	No extra benefit in Search, and three systems to keep synchronized instead of one	Pick one method per site and use it consistently

One documented anti-pattern

Running hreflang through all three methods on the same page is its own mistake, not a belt-and-suspenders safeguard. Google says plainly that combining HTML tags, the HTTP header, and a sitemap entry for the same URLs adds nothing in Search. It’s just more surface area to keep synchronized every time a page changes.

How does hreflang work alongside canonical tags?

Hreflang and canonical tags both tell Google which URL to prefer, but they solve different problems: canonical consolidates near-duplicate URLs onto one address, while hreflang keeps multiple genuinely different localized pages live and routes each searcher to the right one. A canonical tag fits when the alternate URL serves no one on its own, a tracking-parameter version or a duplicate you’d rather fold into a single indexed page. Hreflang fits when every alternate serves someone real, a German page for German speakers, an en-GB page for UK pricing, so each version needs to stay reachable and indexed in its own right.

A single page can and usually should carry both at once: a self-referencing canonical confirming its own URL, plus a hreflang set naming its siblings in other languages or regions. Both tags exist for the same underlying reason, telling Google which version of overlapping content deserves the credit, just along different axes: duplication versus locale.

Using both at once

A typical multi-region page pairs a self-referencing canonical with a full hreflang set. The canonical confirms the page isn’t a duplicate of anything, while the hreflang set tells Google which other locales exist alongside it.

See Sprout SEO’s Canonical Tag Checker if you’re setting up both signals on the same site for the first time.

	Canonical tag	Hreflang
What it solves	Duplicate or near-duplicate URLs	Multiple genuine language or region versions
Other URLs stay reachable	Not necessarily the point	Yes, by design
Typical use case	Tracking parameters, filtered views	Translated or region-specific pages

How do you check if your hreflang tags are working?

Checking your hreflang setup means confirming every alternate resolves, matches its declared code, and points back to the page you started from. The fastest way is an inline check as you browse, rather than re-deriving the rule set by hand on every page you publish. A single-URL tool is the more thorough option once you suspect something specific is wrong.

Install the Sprout SEO extension and its Page Info tab shows this inline on whatever page you’re viewing, including the same back-reference check. For a single URL you want to verify on demand, there’s Sprout SEO’s Hreflang Checker. It’s free, and it reads the full cluster and flags any alternate that doesn’t link back.

Check your hreflang setup before you assume it works

Every language or region version you’ve built is only doing its job if the hreflang set naming it is complete and reciprocal. And that’s not something a glance at the rendered page can confirm.

Check the whole cluster free with Sprout SEO’s Hreflang Checker. Or install the Sprout SEO extension to see the same table inline on every page you browse, with nothing to paste.