SEO Tools·4 min read

Hreflang Explained: Pairs, Return Tags, and x-default

You'll want hreflang explained properly before you launch a second language, because this is the markup SEOs get wrong more than any other. The idea is simple: annotations that tell Google which URL serves which language and region, so a searcher in Madrid gets your Spanish page instead of the English one. The execution is where sites stumble, since every annotation must exist in pairs that point at each other. One missing return tag and Google discards the relationship. This guide covers the codes, a worked set with x-default, and the errors that break the whole arrangement.

Open the tool All insights

One catalog, three markets: the job hreflang was built for

Same content, different audiences.

A SaaS company runs example.com in English, example.com/es/ in Spanish, and example.com/fr/ in French. Without annotations, Google treats these as three loosely related sets of pages. Spanish users sometimes land on English pages, and the French pricing page competes against the English one in Canadian results. Nobody is penalized; users are just routed badly, and conversion rates show it.

Hreflang fixes the routing. Each page announces its own language and lists its siblings, so the search engine can swap in the right variant for each searcher. It matters just as much when the language is identical but the market isn't: en-GB and en-US pages showing different currencies would otherwise look like duplicates fighting over the same queries.

Hreflang explained at the tag level

Codes first, everything follows.

Each annotation is a link element: rel="alternate", an hreflang attribute holding the language code, and an href holding the URL. The code is ISO 639-1 for language, optionally followed by a hyphen and an ISO 3166-1 region: es is Spanish anywhere, es-MX is Spanish for Mexico. Region alone is invalid, and the classic trap is en-UK, which means nothing; the United Kingdom's code is GB.

The rule that governs everything else: the complete set of annotations must appear on every page in the group, including a reference to the page itself. Hreflang is reciprocal by design, which is what stops another site from claiming to be the French version of yours.

A worked hreflang set with x-default, four lines total

Copy the shape, swap the URLs.

In the Hreflang Tags Generator, the default rows produce exactly this block: <link rel="alternate" hreflang="en" href="https://example.com/" />, then <link rel="alternate" hreflang="es" href="https://example.com/es/" />, then <link rel="alternate" hreflang="fr" href="https://example.com/fr/" />, and finally <link rel="alternate" hreflang="x-default" href="https://example.com/" />.

These four lines go into the head of all three pages, identically. The English homepage carries the block, and so do /es/ and /fr/, each one listing itself and its siblings. That sameness is the point: paste one block everywhere in the group and the return tag requirement is satisfied automatically. Add a market with the + Add language button, say en-GB pointing at /uk/, and the new five-line block replaces the old one on every page at once.

X-default explained: the row for everyone else

Your international fallback.

The x-default value isn't a language. It marks the URL to serve when no listed language matches the searcher, a visitor from Japan in the example above. You'll usually point it at your global homepage or a language selector page. Notice it can share an href with a real language row, as it does with en in the default set; that's normal and correct.

Skipping x-default doesn't invalidate the rest, but it leaves unmatched users to Google's guesswork. One extra row buys deterministic behavior for the whole rest of the world, which is the cheapest win in international SEO.

Hreflang return tag errors and the other pair breakers

How annotation sets fall apart.

Search Console has a dedicated report for hreflang return tag errors because they're endemic. Page A lists page B, page B forgets to list page A, and Google drops the link between them. The recurring causes:

A new language shipped with its own annotations while the existing pages' blocks were never updated to include it.
URLs in annotations that redirect or differ from the page's canonical, so the pairing never resolves.
Invented codes like en-UK or eu, which fail silently instead of erroring.
Templates that render annotations on the English site but not on the translated ones.
Relative hrefs that resolve differently per domain and break every pair at once.

Keeping a growing hreflang set maintainable

Two locales are easy. Twelve aren't.

First tip: generate the full block once per page group and paste it everywhere unchanged, rather than letting each page compose its own list. Identical blocks can't disagree, and disagreement is the root of return tag errors. The generator's output is built for exactly this copy-once pattern.

Second, re-verify after every locale launch, because that's the moment existing pages silently fall out of sync. Third, once you pass roughly a dozen locales, consider moving annotations into your XML sitemap, where one file defines every pairing instead of hundreds of templates each doing it locally.

Hreflang Tags Generator next to the rest of the international kit

Which tool for which half.

The Hreflang Tags Generator handles language targeting; it deliberately doesn't decide which URL variant of each page is real. That's canonical territory, so pair it with the Canonical Tag Generator and make sure every hreflang href matches that page's canonical exactly, since mismatches there are the second biggest source of ignored annotations. If you move annotations to a sitemap later, the XML Sitemap Generator builds the URL list, and the Meta Tag Analyzer confirms each language version declares the head elements you think it does.

Try it now

Open Hreflang Tags Generator

The tool is one click away. No sign up, no upload, no payment.

Open Hreflang Tags Generator

Write a review