What Is Hreflang, and When Do You Need It?

Hreflang gets raised more often as a source of anxiety than as a genuinely understood tool. Commercial decision-makers hear it mentioned by developers or agencies, sense it is technical and important, and either over-invest in it prematurely or ignore it until something has already gone wrong — duplicate content warnings, the wrong country's page showing up in the wrong country's search results, or two language versions competing against each other.

The reality is more straightforward than the jargon suggests. Hreflang is a signal, not a strategy. It solves a specific, narrow problem, and it is only worth implementing once that problem actually exists.

What hreflang actually does

Hreflang is a piece of code added to a page — or its sitemap — that tells search engines: this page is the English (United Kingdom) version, and here is where the French version and the German version of the same content live. Search engines use that signal to decide which version to show a searcher based on their language and location, rather than guessing from the content alone.

What problem it solves

• Preventing a UK visitor from being shown the US version of a page, or vice versa, when both exist
• Reducing the risk that search engines treat similar content in different languages as duplicate or competing pages
• Making sure the right country's currency, spelling and contact details appear to the right searcher
• Consolidating signals so that near-identical country pages do not cannibalise each other's search visibility

When you do not need it

A single-language website with no other-country versions of its pages does not need hreflang — there is nothing for it to point between. Companies at the early testing stage of a new market, with only a translated section rather than a genuinely separate country structure, often do not need full hreflang implementation yet either; it becomes relevant once there are genuinely parallel versions of the same content to disambiguate.

When you do need it

Common mistakes

• Implementing hreflang incorrectly, which can actively confuse search engines rather than help them
• Forgetting to include a self-referencing tag, or missing return tags between paired pages
• Adding hreflang to pages that are not actually equivalent versions of each other
• Treating hreflang as an SEO strategy in itself, rather than one technical signal among several
• Delaying it until multiple country pages already exist and are already competing against each other

How it relates to URL structure

Hreflang works alongside the choice of subfolders, subdomains or country-code domains — it is not an alternative to that decision, it is part of implementing it correctly whichever structure is chosen. A well-chosen structure with poor hreflang, or a well-implemented hreflang tag set on a poorly chosen structure, both underperform a case where both have been thought through together.

Who should be responsible for it

Hreflang is a developer-level technical implementation, but the decision about which markets and language versions need it is a commercial one that should be made alongside the wider market entry and localisation plan, not left entirely to whoever builds the site.