What Is Hreflang and How Does It Work for International SEO

Hreflang is an annotation that tells search engines which language and, optionally, which regional version of a page to show a given user. If you run an English-language page for the United States and a separate English-language page for the United Kingdom, plus a French page for France, hreflang is the mechanism that tells Google “these pages are equivalent versions of the same content, here’s how to match them to the right audience.” Without it, search engines are left to guess based on content language, server location, and other indirect signals, and the wrong version can end up ranking in the wrong market.

It’s worth being precise about what hreflang actually does, because it’s commonly oversold. According to Google’s own documentation on localized versions of pages, hreflang is a signal Google uses, not a directive it is obligated to follow. Google can and does choose a different page than the one indicated by hreflang if other signals (content quality, redirects, user behavior) suggest it should. Getting hreflang technically correct dramatically improves the odds that the right version surfaces in the right market, but it isn’t a guarantee, and that distinction matters when you’re troubleshooting why a page still isn’t showing up where you expect.

What Hreflang Looks Like

Hreflang is implemented as a value pair: a language code, and optionally a region code, separated by a hyphen. For example, en-GB means English as used in the United Kingdom, es-MX means Spanish as used in Mexico, and fr alone (with no region) means French generally, not tied to a specific country.

The codes are not arbitrary. The language portion uses ISO 639-1 two-letter language codes, and the optional region portion uses ISO 3166-1 Alpha-2 country codes. Using a non-standard or invented code (a common error) means search engines simply won’t recognize the value, and the annotation is effectively ignored.

x-default

x-default is a reserved hreflang value that tells search engines which page to serve when none of your other language/region targets match a visitor’s settings, for instance, a generic landing page or a language-selector page shown to a first-time visitor whose locale you haven’t built a dedicated version for. Google’s Search Central team has written specifically about how x-default can help international sites, describing it as a way to provide a sensible fallback rather than leaving Google to guess. It’s optional, not required, but it’s good practice on any multi-region site, particularly ecommerce sites that route by country.

Implementation Methods

Google supports three equivalent ways to implement hreflang. They are not ranked in effectiveness by Google; the right choice depends on your site’s structure and how many language versions you’re managing, not on a fixed number of versions where one method supposedly stops working.

Method	How it works	Best suited for
HTML <!–INLINECODE4–> tags in <!–INLINECODE5–>	Each page lists itself and every alternate version directly in its own HTML head	Sites where you can edit page templates directly and want signals visible in page source
HTTP headers	Used instead of HTML tags, declared in the server response header	Non-HTML content such as PDFs, where there's no <!–INLINECODE6–> to place a link tag in
XML sitemap entries	All hreflang relationships declared centrally in the sitemap rather than on each page	Larger sites where centralizing the annotations is easier to generate and maintain programmatically than editing every template

Whichever method you choose, the underlying requirement is the same: hreflang relationships must be bidirectional. If Page A declares itself as related to Page B via hreflang, Page B must also declare itself as related back to Page A, and both pages should also reference themselves. This “return tag” requirement is explicit in Google’s documentation, and it is the single most common source of hreflang errors in practice. A one-way reference, where A points to B but B doesn’t point back, is typically disregarded by Google rather than partially honored, because Google can’t confirm the relationship is mutual.

There’s no fixed rule from Google about when a site “must” switch from HTML tags to HTTP headers or sitemaps; the honest framing is that as the number of language/region versions grows, centralizing the declarations (HTTP headers or sitemap) tends to become easier to manage and audit than maintaining a long list of link tags by hand inside every individual page template. Treat that as a maintainability tradeoff to weigh for your own site and CMS, not a hard technical threshold.

Common Errors

The errors that show up most often in hreflang audits include:

• Missing return tags. Page A references Page B, but Page B doesn’t reference Page A back. This breaks the bidirectional requirement and the annotation is typically ignored.
• Incorrect or invalid codes. Using a country code where a language code is expected, inventing a code that doesn’t exist in ISO 639-1 or ISO 3166-1, or using an underscore instead of a hyphen.
• Conflicting signals. Hreflang pointing to one URL while a canonical tag on the same page points to a different URL, or while a redirect sends users somewhere else entirely. When signals disagree, Google has to decide which one to trust, and the outcome is unpredictable.
• Non-canonical or non-indexable target URLs. Pointing hreflang at a URL that is itself canonicalized elsewhere, blocked by robots.txt, or returning a noindex tag. The target needs to be a clean, indexable URL in its own right.
• Relative URLs instead of fully-qualified ones. Hreflang values need complete URLs, including the protocol (https://), not relative paths.
• Self-reference omitted. Every page in a hreflang set should also list itself as one of its own alternates; leaving this out is a frequent template-generation mistake.

These errors are common enough that auditing hreflang on any multi-region site on a recurring basis, not just at launch, is generally treated as standard practice rather than optional extra diligence. There’s no need to attach a specific frequency or error rate to that recommendation; the practical point is that hreflang tends to break quietly when templates change, new locales are added, or a migration touches URL structure, so periodic re-validation catches problems before they affect rankings.

How to Validate Hreflang

It’s worth knowing that Search Console used to have a dedicated International Targeting report with a language tab built specifically for hreflang error reporting, but Google deprecated and removed that report in September 2022, stating that country-targeting via Search Console had little ongoing value while reaffirming that hreflang itself remains fully supported. Practical guidance written before that date that points readers to the International Targeting report is out of date.

Today, the most direct validation path inside Search Console is the URL Inspection tool, used to spot-check individual pages and see how Google is currently processing a specific URL, paired with the Page indexing report to confirm the target pages are themselves indexable rather than excluded.

For broader, page-by-page validation outside Search Console, Aleyda Solis’s hreflang tags generator is a widely used free tool for producing correctly formatted hreflang markup from a list of URLs, and hreflang.org is a companion testing tool built specifically to validate hreflang implementations across larger batches of URLs by uploading a sitemap or URL list. Between the two, you can both generate clean markup up front and check it for errors after deployment.

A Practical Checklist

Before treating a hreflang implementation as finished, it’s worth confirming each of the following:

1. Every page lists itself as one of its own hreflang alternates.
2. Every alternate relationship is bidirectional (return tags are present on both sides).
3. Language and region codes follow ISO 639-1 and ISO 3166-1 standards exactly.
4. URLs in hreflang values are fully-qualified, including protocol.
5. Hreflang targets are canonical, indexable URLs, not redirected, blocked, or noindexed pages.
6. An x-default value is set if the site serves a meaningful international audience without a perfect locale match for everyone.
7. Hreflang doesn’t contradict canonical tags or redirect behavior on the same URL set.

Why Hreflang Gets Treated as Higher-Risk Than It Needs To Be

A lot of the anxiety around hreflang comes from the fact that errors are silent. There’s no broken page, no 404, no obvious visual symptom; the failure mode is simply that the wrong country gets the wrong page, or no page benefits from the signal at all, and you only find out by checking Search Console or watching international traffic underperform. That’s exactly why validation tools and periodic re-checks matter more here than on most technical SEO elements: small, easy-to-make errors (a missing return tag, a malformed code) tend to fail quietly rather than loudly, and the only way to catch them is to look. If you’ve never run a hreflang validation pass, start with the seven-item checklist above against your highest-traffic international URL first, that single page will usually surface whatever pattern of error is present sitewide.