A site that publishes several languages without correct hreflang markup runs into a quiet problem: Google indexes a version, but sometimes shows it to the wrong audience. A reader in Spain lands on the English page, a German reader on the French version. The content exists, it may even be well written, but it doesn’t reach the right audience. Hreflang is the mechanism built to fix that, and it leaves little room for approximation.
What the hreflang attribute actually does
The hreflang attribute tells search engines that a page has equivalents in other languages or for other regions, and specifies the URL of each one. It doesn’t translate anything and doesn’t directly affect a page’s ranking: it only steers which version gets shown to a given visitor, based on their interface language or the region they’re searching from.
Each declaration combines two parts: an ISO 639-1 language code (fr, en, es, de), optionally followed by an ISO 3166-1 region code (fr-ca for a French-Canadian version distinct from France’s French). Adding a region only makes sense when the content genuinely differs between markets; otherwise the language code alone is enough, and it limits the risk of mistakes.
Two methods, never both at once
| Method | Advantage | Limitation |
|---|---|---|
<link> tags in the <head> | Easy to check page by page, no separate file to maintain | Adds weight to the <head> on high-page-count sites |
| Entries in the XML sitemap | Centralizes every mapping, useful past a few thousand pages | Harder to eyeball, mistakes are harder to spot without a dedicated tool |
HTTP Link header | The only viable option for non-HTML content (PDFs in particular) | Rarely needed for a standard editorial site |
Google technically allows combining these methods but rarely recommends it: the moment two sources disagree on the same URL, the engine has to arbitrate, and the arbitration doesn’t always favor the site’s actual intent. Picking one method and sticking to it across the whole domain avoids that risk.
The rule that breaks most often: return links
Every page in a translation group must declare not only its equivalents but also itself. If the French page points to the English version, the English version must point back to the French one — and to every other language in the same group. A single missing link in one direction frequently invalidates the entire group in a search engine’s eyes, with no obvious error showing up on the site itself.
<link rel="alternate" hreflang="fr" href="https://example.com/fr/page/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="es" href="https://example.com/es/page/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
This exact block, with its full set of languages, needs to appear identically on each of the four pages. The x-default line designates the version shown to a visitor whose language or region matches none of the declared versions: a language-selector page, or failing that, the site’s most neutral version.
A one-way hreflang isn’t an incomplete hreflang — it’s a hreflang search engines simply ignore for the entire group.
Declared URLs must be reachable, not just correct
A URL listed in a hreflang block should never redirect, return a 404, or be canonicalized to a different address. These three cases show up often after a site redesign: old language URLs stay listed in a sitemap that was never regenerated, while the content has already moved to new addresses.
Each language version’s rel="canonical" tag must also point to itself, never to the French version treated as the “main” one. A cross-language canonical is effectively asking search engines to index only one version, which cancels out the entire point of hreflang.
An external validation tool (Merkle ICS, or Search Console’s URL inspection checked page by page) is more reliable than a manual read of the source code for catching a missing return link on a site with dozens of translated pages.
Subdirectories, subdomains, or separate domains
Hreflang works regardless of the architecture chosen to host the languages, but that architecture changes the maintenance effort. A subdirectory structure (/fr/, /en/) consolidates the domain’s authority on a single address and stays the simplest to maintain for a small team. Language subdomains separate technical configurations further, which helps mainly when each market has its own autonomous editorial team. Separate country domains (.fr, .de) generally only make sense for a legal or commercial local presence, rarely for translating editorial content alone.
Whatever architecture is chosen, none of the previous rules go away: complete return links, reachable URLs, self-referencing canonicals. A separate domain per country even adds a risk of its own — forgetting the cross-declaration between two distinct domains, which is more naturally visible between two subdirectories of the same site.
Code mistakes and checking after publication
A malformed language or region code shows no visible error on the site, but it gets the declaration ignored by search engines. The most common cases seen in audits:
| Mistake found | What’s expected |
|---|---|
Region code alone, no language (hreflang="ca") | Always language then region (hreflang="fr-ca") |
Country code confused with language code (hreflang="uk") | ISO 639-1 language code followed by ISO 3166-1 country code (hreflang="en-gb") |
| A page that doesn’t declare itself in its own block | Every page includes a hreflang line pointing to its own URL |
A single site-wide x-default, never updated | A consistent x-default per group of translated pages |
The expected format always places the lowercase language code before an optional region code; case doesn’t matter to search engines, but the lowercase convention avoids inconsistent copy-paste between teams.
A regular check, rather than a one-off at launch, remains the best protection against these mistakes: adding a language, a partial redesign, or a change of translation tool are the three moments when a return link most often gets lost. Structured data in JSON-LD is declared separately on each language version: an English Article or NewsArticle schema shouldn’t describe French content, even when both pages share the same structure. On the analytics side, each version should appear as a distinct property in the reporting tools, to check language by language whether organic traffic actually matches the intended geographic zone — a check that fits naturally into GA4 and Search Console reporting for a site already up and running.
Key takeaways
Hreflang doesn’t demand a complex setup, just an exact one: a single implementation method, complete return links checked in both directions, an explicit x-default, and every URL reachable without redirects or cross-language canonicals. Most issues found in audits come from a one-off oversight after a content update, not from a flawed initial design.
On the multilingual projects I’ve worked on, broken hreflang is almost never flagged by a client: it just shows up as unusually low organic traffic on one specific language, discovered months later while digging through Search Console reports by country. I recommend testing it with every translation published, not only at site launch. — Simon Janvier
Further reading: the official Google Search Central documentation on localized versions covers edge cases, including sites that combine several domains per language.
