Hreflang is an annotation that tells search engines which language and, optionally, which region a page is meant for, so the right version shows to the right user. Hreflang does not boost rankings on its own. What it does is stop the wrong-language page from outranking the correct one in a given market, which is the actual problem most international sites are trying to solve. I think of it less as an optimization and more as a disambiguation signal: you are telling Google that several pages are equivalents of each other, just localized, so it should serve the appropriate one rather than treat them as competitors or duplicates competing for the same query.

How Hreflang Actually Works

Every page in a language set has to reference every other page in that set, including itself. That self-reference trips people up constantly. If you have English, French, and German versions, each of those three pages needs three hreflang entries pointing at all three URLs. The relationship has to be bidirectional and complete, or search engines quietly discard the whole cluster and fall back to guessing which version to serve.

This completeness requirement is what makes hreflang operationally difficult at scale. On a site with five languages and two thousand pages, that is ten thousand language alternate relationships to maintain. Any page that goes live without the full set of return links breaks the cluster for every other page in that set — not just for itself. One missing entry silently invalidates the whole group.

  • Values use a language code such as en, or a language plus region code such as en-GB, following ISO 639-1 and ISO 3166-1 Alpha 2
  • Region without language is invalid — there is no such thing as a standalone region target like hreflang='uk'
  • Use x-default for a fallback page when no listed version fits the user, such as a country selector or a global homepage
  • The codes are not case sensitive, but keeping them consistent makes audits significantly easier to read and diff

Where to Implement Hreflang

You have three options. Pick one and stick to it. Mixing implementations across the same pages creates conflicts that are difficult to debug and produce unpredictable outcomes.

  • HTML head using link rel='alternate' tags. Simplest approach for small sites with a handful of languages and a manageable page count.
  • HTTP headers, which are the only practical option for non-HTML files such as PDFs that have localized equivalents. Not useful for standard web pages.
  • XML sitemap entries. My preference for large sites — it keeps the markup off individual pages and lets you audit the entire language cluster in one file.

What the Markup Looks Like

Here is the HTML head implementation for a three-language cluster (English, French, German). Each language version carries all three annotations, including the self-referential one. The x-default points to a language selector page:

<!-- On the English page: -->
<link rel='alternate' hreflang='en' href='https://example.com/page/' />
<link rel='alternate' hreflang='fr' href='https://example.com/fr/page/' />
<link rel='alternate' hreflang='de' href='https://example.com/de/page/' />
<link rel='alternate' hreflang='x-default' href='https://example.com/page/' />

<!-- On the French page (identical set, same targets): -->
<link rel='alternate' hreflang='en' href='https://example.com/page/' />
<link rel='alternate' hreflang='fr' href='https://example.com/fr/page/' />
<link rel='alternate' hreflang='de' href='https://example.com/de/page/' />
<link rel='alternate' hreflang='x-default' href='https://example.com/page/' />

The set is identical on every page in the cluster. The only thing that changes is the page that is rendering it. This symmetry is what Googlebot checks when it validates the annotation.

How to Check Hreflang Implementation

Screaming Frog has a dedicated hreflang tab that shows every alternate URL per crawled page, the language codes detected, whether return links exist, and whether the target URLs are valid. Run a full site crawl, then filter to the hreflang tab and sort by error type. Missing return links and non-200 target URLs account for the majority of implementation failures I have seen.

Google Search Console does not have a dedicated hreflang report, but the Index Coverage report will show pages that are excluded or not indexed — which can surface the downstream effect of broken hreflang clusters even if it does not name hreflang as the cause. If you are seeing unexpected indexation patterns in a specific language region, that is a signal to run the Screaming Frog check.

For large sites, pull the XML sitemap hreflang entries into a spreadsheet and use a lookup to verify bidirectionality. Every URL listed as a hreflang target should itself list the source URL as an alternate. Any row without a confirmed return link is broken. This check is tedious to do manually but straightforward to script if your sitemap is well-structured.

Hreflang, Crawl Budget, and Rendering

Hreflang does not exist in isolation from the rest of your technical setup. For sites using client-side rendering, hreflang annotations placed inside JavaScript-rendered markup may not be seen by Googlebot on the first crawl pass — Googlebot renders JavaScript in a deferred second wave, which means your language signals may arrive late or be missed entirely. If you are on a JavaScript-heavy framework, implement hreflang via the XML sitemap or ensure your server-side rendered HTML includes the annotations in the initial response, not injected by a script.

Crawl budget is also relevant at scale. A site with ten languages and ten thousand pages has one hundred thousand language alternate URLs for Googlebot to validate. If those alternates include pages that return 302 redirects, carry noindex tags, or resolve to a canonical pointing elsewhere, Googlebot has to crawl all of them to discover that the annotation is broken. That is crawl budget spent on validation overhead rather than on indexing your content. Keeping your hreflang targets clean — canonical, indexable, returning 200 status codes — is not just correct, it is efficient. Reviewing how log files expose these crawl patterns is part of any thorough audit, and is covered in detail in the article on technical SEO audits.

The Mistakes I See Most

Most broken hreflang setups fail for a handful of reasons, and they are almost always mechanical rather than strategic. The strategy is usually fine. The implementation leaks.

  • Missing return links — the annotation is ignored entirely and silently, with no error surfaced anywhere in Search Console
  • URLs in hreflang that return 301 redirects, are canonicalized to a different URL, or carry a noindex tag — all of which break the equivalence the annotation is trying to establish
  • Conflicting canonical tags pointing language versions at one master URL, which effectively cancels the hreflang setup because you are telling Google that only one URL is canonical while simultaneously telling it the others are valid alternates
  • Wrong or invented region codes — a language paired with a continent, a two-letter country code used without a language prefix, or an ISO code that does not exist
  • Implementing hreflang in the HTML head on some pages and the XML sitemap on others, creating a split implementation that is difficult to audit and prone to divergence

How Hreflang Fits into a Technical SEO Audit

Hreflang is one of the more labor-intensive items to audit correctly because the errors are silent and the data to verify is voluminous. When I am auditing an international site, I check hreflang early — before spending time on content or link analysis — because a broken implementation can suppress entire language markets regardless of how good the underlying pages are. Fixing it does not require new content or new links. It requires getting the annotation right.

The issues that break hreflang most often — redirect chains, canonical conflicts, noindex on target URLs — are the same issues covered in a full technical review. I cover the broader fundamentals in what is technical SEO and the canonical side of this in canonical tags. If you want a structured check of your existing language clusters, a website audit is the right place to start.