International SEO and Hreflang: Ranking a Multilingual Website Correctly

A website publishing in more than one language runs into a problem that a single-language site never has to think about: which version of a page should show up for a given searcher, in which country, in which language. Get it wrong and one of two things happens — either the wrong language version ranks for a search made in the right language, or search engines treat the different language versions as duplicate content competing against each other, which quietly drags down all of them at once.

Hreflang is the technical mechanism that solves this, and it has a reputation for being fiddly that’s mostly earned — not because the concept is complicated, but because a single mismatched code or a missing return tag can silently break the whole setup without throwing an obvious error anywhere.

What Hreflang Actually Tells Search Engines

An hreflang annotation is a signal, attached to a page, that says: “this page is written in language X for a reader in region Y, and here are the equivalent pages in other languages and regions.” It doesn’t translate anything and it doesn’t redirect anyone automatically — it’s a hint that helps Google’s index decide which URL to show a given searcher based on their language and location settings. Correctly implemented, it means a search made in French from France surfaces the French version of a page, and the same search made in French from Canada can surface a Canada-specific French version if one exists, without either version being treated as a duplicate of the other.

The Three Ways to Implement It

• HTML tags in the page head — a <link rel="alternate" hreflang="..."> tag for every language/region variant, including a self-referencing tag for the current page itself. This is the most common approach for a standard WordPress-based multilingual setup.
• HTTP headers — the same information sent in the response header instead of the HTML, mainly used for non-HTML resources like PDFs where head tags aren’t available.
• XML sitemap annotations — hreflang data included directly inside the sitemap rather than on every page, which can be easier to manage and audit at scale for large sites, though it requires the sitemap to be kept in sync with every content change.

Whichever method is used, the same underlying rule applies: every page in a language cluster needs to list every other page in that cluster, including itself, and every one of those references needs to point in both directions. A one-way reference — page A pointing to page B, but page B not pointing back to page A — is one of the most common and most silent hreflang failures, because nothing about it looks broken when you view a single page in isolation.

The Errors That Break It Most Often

Missing Return Tags

If the English version of a page references its Lithuanian counterpart, but the Lithuanian page doesn’t reference the English page back, search engines are instructed to disregard the entire relationship for both pages. This is by far the most common real-world hreflang failure, and it’s invisible unless the full set of pages is checked together rather than one at a time.

Wrong Language or Region Codes

Hreflang codes follow ISO 639-1 for language and ISO 3166-1 Alpha 2 for region, and mixing them up — using a region code where a language code belongs, or inventing a code that doesn’t exist in either standard — causes the annotation to be silently ignored rather than throwing a visible error. lt for Lithuanian is correct; lit or LT-lt in the wrong order is not.

Pointing to a URL That Redirects or 404s

An hreflang tag referencing a URL that no longer resolves directly — because the page moved, or because it goes through a redirect first — breaks the same way a broken internal link does. Every hreflang reference needs to point at the live, final URL, never at one that requires a hop to get there.

Conflicting Signals With the Canonical Tag

A page’s canonical tag and its hreflang tags need to agree with each other. If a Lithuanian page’s canonical tag points to the English version, that page is telling search engines “the English version is the real one,” which directly contradicts the hreflang cluster saying these are equivalent, independently rankable language versions. Each language version should canonicalize to itself, not to whichever version came first.

Hreflang Is Not the Same as a Redirect Based on Browser Language

Automatically redirecting a visitor to a different language version based on their detected browser language or IP location feels like a natural companion to hreflang, but Google has been explicit that forced redirects based on location or language can prevent its crawler from accessing and indexing the other language versions at all — since the crawler itself gets redirected before it can see the alternative content. The safer pattern is to detect and suggest — show a dismissible banner offering the visitor’s likely preferred language — while leaving every language version directly and permanently reachable by URL, both for human visitors who prefer a different language than the one detected and for search engine crawlers indexing every version independently.

Auditing an Existing Multilingual Site

Google Search Console’s International Targeting report (where available for the property) and a direct read of each page’s rendered HTML source are the two most reliable ways to confirm hreflang is actually working rather than just present. A quick manual spot check — pick five pages across different languages, open each one’s source, and confirm every listed alternate actually resolves directly and references back — catches most real-world breakage faster than waiting for a ranking drop to reveal the problem. For a site actively adding new languages over time, this is worth checking every time a new language is added, not just once at initial setup, since a new language cluster is exactly where a missing return tag is most likely to slip in unnoticed.

Google’s own documentation on localized page versions is the primary reference worth checking directly when something looks wrong, since implementation details (particularly around the sitemap-based method) are easy to get subtly wrong from memory. Getting the basics right also has a compounding effect on the parts of SEO that matter regardless of language — a technically clean hreflang setup means every language version gets a fair, independent chance to rank, instead of the versions quietly cannibalizing each other’s visibility the way a poorly planned website structure often does without anyone noticing until traffic numbers are pulled apart by language.

Translation Quality Still Matters More Than the Markup

Hreflang solves a routing problem — it doesn’t compensate for weak translation. A page translated mechanically, without adapting idiom, currency, measurement units or region-specific terminology, tends to underperform in its target market even with flawless hreflang, because search engines in that market still evaluate the page’s language quality and relevance on its own terms, and human readers notice awkward phrasing even faster than an algorithm does. A genuinely competitive multilingual page needs both pieces working: markup that correctly tells search engines the relationship between versions, and translation quality that gives each version a real, independent chance to earn trust with readers and rank on its own merits rather than as a diminished copy of the original.

This also affects keyword strategy per language. A term with strong search volume in English frequently has no direct one-to-one equivalent in another language — the natural phrasing a Lithuanian or German searcher would actually type is often structured differently, not just translated word for word. Treating each language version as its own keyword research exercise, rather than a translation pass over an English keyword list, is the difference between a page that merely exists in another language and one that’s actually positioned to rank in that market.

Hreflang and Canonical Together on Larger Sites

On a site with many products or many near-duplicate regional variants — the same product page localized for several countries that share a language, for instance — it’s tempting to canonicalize all the regional variants to one “master” version to avoid duplicate content concerns. That instinct actively conflicts with hreflang’s purpose: a canonicalized-away regional page effectively removes itself from being independently indexed and shown for its own region, undoing the benefit hreflang was meant to provide. The correct pattern keeps each regional version self-canonical, and relies on hreflang alone to manage the relationship between them, trusting the annotation to do the job it was built for rather than layering a second, conflicting signal on top of it.

FAQ

Does every page need a self-referencing hreflang tag?

Yes. Google’s guidance explicitly requires each page in a cluster to reference itself in addition to every alternate version — omitting the self-reference is a common and easy-to-miss mistake.

What’s the difference between hreflang and the “x-default” tag?

The x-default value marks the version to show when none of the specified languages or regions match the visitor — typically the international or primary-language homepage. It’s optional but recommended for sites with a clear default audience.

Can hreflang be used without separate URLs for each language?

No. Hreflang requires each language or region version to have its own distinct, crawlable URL. It can’t substitute for content that only changes dynamically based on browser settings without a corresponding unique URL.

Does having hreflang set up guarantee the correct language version ranks?

No — it’s a strong signal, not an absolute directive. Google can still choose a different version if it has stronger relevance signals overall, though a correct hreflang setup significantly increases the odds of the intended match.

How long does it take for hreflang changes to take effect?

There’s no fixed timeline; it depends on how frequently the pages involved are recrawled. Submitting an updated sitemap and using URL Inspection in Search Console for key pages can speed up the recrawl rather than waiting passively.

Is hreflang only relevant for fully translated content?

It’s most useful for genuinely separate language or regional versions of the same content. Using it to mark pages that are only nominally different, or serving near-duplicate content padded out per language, doesn’t solve the underlying content problem and can create its own duplicate-content confusion.

The Bottom Line

Hreflang is a small piece of markup with an outsized failure rate, almost entirely because its most common mistakes — a missing return tag, a wrong code, a reference to a redirecting URL — produce no visible error and no obvious symptom beyond a slow, hard-to-diagnose dip in how a language version performs. Getting the basics right once, and re-checking them every time a new language is added, is far cheaper than untangling a multilingual site’s rankings after months of a silent mismatch.