You translated the site, added hreflang, and now the wrong URL is winning: a German query resolves to an English page, Search Console reports annotations that were not picked up, and a visitor in Spain cannot reach the English version at all. Every one of those failures comes from the same place — hreflang is treated as a ranking boost or a geo-targeting switch when it is neither.

This guide covers the decision that comes before any code (language or country, and which domain structure to use), the exact annotation rules, the failure modes that invalidate a whole set, how to verify your work, and what to do when the translated pages are not good enough to announce.

Decide first: language or country

The two are not interchangeable, and mixing them is the most common source of broken sets.

Language targeting serves everyone who speaks a language: es covers every Spanish speaker, pt covers Portugal and Brazil alike. Use it when the content is identical apart from spelling and wording.
Country targeting serves a market: es-ES against es-MX, en-GB against en-US. Justify it only when the offer genuinely differs by country — currency, shipping, returns, legal terms, product availability, pricing.

The rule is simple: add a region only when the region changes the answer on the page. If your UK and US pages differ solely in spelling, you are splitting one audience into two URLs for no benefit. Also decide the language of record for each market, then check that the on-page HTML lang attribute matches it — hreflang and the lang attribute disagreeing is a self-inflicted inconsistency.

Choose the domain structure before anything else

hreflang works across all three structures, so this is a business and operations decision, not an annotation decision.

ccTLD (example.de, example.fr): the strongest country signal and the clearest one to users. You pay for it with authority split across domains and much heavier operational overhead. The right call when the business is genuinely country-specific and you can fund separate sites.
Subdirectory (example.com/de/, example.com/fr/): one domain, one backlink profile, one set of tooling. The country signal is weaker, so hreflang and translated content have to carry it. This is the sensible default for most sites.
Subdomain (de.example.com): useful when teams, hosting, or stacks genuinely differ. Authority still fragments more than a subdirectory, and the configuration surface grows.

Avoid automatic IP-based redirects. They block crawlers from ever seeing your alternate versions, which makes every annotation you write unverifiable. If you already use them, a redirect check shows what a crawler in another country actually receives.

What hreflang is for — and what it is not

hreflang is a serving and clarity signal: "when this query is relevant to a French-speaking user, show that URL, and show this one to English speakers." It helps search engines select the right regional result and the right snippet for the searcher.

It is not a ranking boost, not a substitute for links or content quality, not geo-targeting in the old Webmaster Tools sense, and not a way to make a weak page compete. Two consequences worth internalizing:

Annotations do not override canonicalization, noindex, or robots blocking. If the target URL is not indexable, the annotation points at nothing.
Annotations do not fix a wrong-language page. They advertise which URL you want shown; they cannot make that URL deserve to be shown.

The implementation rules

A complete set — an English, French, and Spanish version plus a default — written as a full reciprocal matrix looks like this:

Those four lines must appear on all three URLs, in the head of each page — including the line that points at the page itself. The rules behind that:

Reciprocity is mandatory. Every URL in the set must list every other URL, plus itself. If /fr/ lists /en/ but /en/ does not list /fr/, the whole annotation is ignored. Half a set is worth nothing.
Self-referencing annotation. Each page includes a tag for itself. Skipping it is the single most frequent implementation error.
Valid ISO codes only. Language codes from ISO 639-1 in lowercase (en, fr, de, pt, ja) and, when a region is justified, ISO 3166-1 Alpha-2 in uppercase: en-GB, pt-BR, fr-CA. "en-UK" is invalid. Script tags such as zh-Hans and zh-Hant are allowed where the script genuinely differs.
Absolute, fully-qualified URLs. https, the final host, no query parameters, no fragments, no trailing-slash mismatch with the canonical. Relative URLs are rejected.
x-default as the fallback. Point it at the version you show users whose language you do not serve, and at the page that decides which version a visitor gets.
One placement, consistently. For HTML pages use link tags in the head. Non-HTML assets such as PDFs need an HTTP header instead. For large sites, the same set can live in the XML sitemap instead of the head — a valid sitemap is a prerequisite for that to work.

Head placement also means the annotations must survive rendering. If your head is built client-side, run the HTML lang checker against a fetched copy to confirm what actually ships.

Common failure modes

One-way annotations. A points to B, B does not point back. Invalid, silently ignored.
Mixed granularity. A set containing en, fr-FR, and de with no consistent logic. If you use region codes, use them for every member of the set; if you do not, use language-only for every member.
Pointing at redirects or non-canonical URLs. The annotation must resolve to a final 200 response whose canonical is itself. Annotating a URL that 301s elsewhere, or one that canonicalizes to a different page, invalidates the set. Check with the canonical tag checker.
Protocol or host mismatches. http against https, or www against non-www, across members of the same set.
Translated content, untranslated snippets. If the title tag, meta description, headings, image alt text, structured data, and the internal link anchors pointing at that page are still in the original language, users get a mismatched result even when the page itself is perfect.
Annotating blocked or noindexed pages. Nothing to serve.

How to verify

Never deploy a set without validating it. The sequence that catches almost everything:

Run the hreflang checker on one URL from the set. It reports missing reciprocity, bad codes, and non-absolute URLs with the exact line that failed.
Run the bulk hreflang audit across every URL in the cluster — single-page checks miss the member that was never updated.
Confirm canonicals and status codes for every annotated URL.
Review Search Console's international targeting reporting for annotations that were not used and the reasons given. Our walkthrough of Google Search Console covers where these diagnostics live in the current interface.
Spot-check from a target locale: view the result as a user in that country and confirm the expected URL appears with a correctly localized title.

Re-run steps one and two after every translation batch. Sets degrade one edit at a time.

Thin translations: do not annotate garbage

The tempting move is to machine-translate your whole archive and cross-link all of it overnight. hreflang then advertises a cluster of pages you would be embarrassed to show a human, and you have told search engines precisely which weak page to serve to each market.

When a translated page is a stub, a literal machine dump, or missing its own localized snippet, the honest options are, in order: finish the page, leave it out of the set, or noindex it. Our thin content checker finds the stubs before you link them, and the underlying problems are covered in the guide to identifying and fixing thin content.

Prioritize by demand: translate the pages that already earn impressions for that locale, complete every page you do translate — body, title, description, structured data, nav labels — and prefer three finished locales over nine half-built ones. An incomplete but accurate set beats a complete set of translated placeholders, because a half-built set is simply ignored, while a complete set of placeholders sends users to pages that bounce straight back to the wrong language.

Related Tools

Reviewed by TheLinksMaster

SEO Editorial Team

Our editorial team tests every tool and guide on this site against real websites. We update content when search algorithms change so you always get current, practical SEO advice.