Hreflang

← Back to glossary · Category: Technical

What Hreflang Means, in Plain Language

Hreflang is an attribute that tells search engines which language and regional version of a page to show to which searchers. If a site has the same content in English and in Spanish, or in English for the United States and English for the United Kingdom, hreflang is the signal that connects those versions and says: these pages are variations of the same content, made for different audiences, and here is which audience each version is for. A searcher in Spain should be shown the Spanish version, a searcher in Mexico should be shown the version made for Mexico if one exists, and a searcher whose language does not match any version should be shown the fallback version the owner has nominated. Without that signal, a search engine must guess which version fits each searcher, and guesses about language are often wrong in ways that frustrate readers.

The attribute itself is small. In its HTML form it is a link element in the head of a page, carrying a rel value of alternate, an hreflang value naming the language and optionally the region, and an href naming the URL of that version. A page in English for the United States might carry a tag naming itself as en-US, a tag naming its British version as en-GB, and a tag naming its Spanish version as es, each pointing at the corresponding URL. Every version of the page carries the full set of tags, including a tag pointing at itself, so that each page declares the whole cluster it belongs to, not merely the other pages in it. That self-reference, and the requirement that the references run in both directions, are the two details most often missed, and both are essential to the signal working at all.

Hreflang can also be delivered in two other ways, which Google treats as equivalent. It can be sent as an HTTP header, which is the right form for non-HTML files such as PDFs, and it can be declared in an XML sitemap, where each URL carries its alternate versions as annotations. The three methods are equivalent from Google's perspective, and the documentation advises choosing the method that is most convenient for the site rather than using all three at once, which is harder to manage and easier to get wrong. For most small sites, the HTML form is the simplest to write, inspect, and debug, and it is the form this guide emphasises.

What Hreflang Is Not

Hreflang is not a translation tool, and it does not create language versions. It only describes versions that already exist, at distinct URLs, with their content already translated or localised. A site with a single English page cannot add hreflang tags and thereby acquire a Spanish version; it must first create the Spanish page, at its own URL, and then describe the relationship between the two. Site owners who add hreflang tags pointing at pages that do not exist, or at pages that are not actually translations of each other, are sending a signal about a relationship that does not hold, and search engines will eventually disregard it.

Hreflang is not a language detector, and it does not replace the work of deciding what each version should say. Google's documentation notes that it does not use hreflang or the HTML lang attribute to detect the language of a page; it uses its own algorithms for that. Hreflang tells Google which version to serve to which audience, once the versions exist and their languages are understood. A poorly translated page, or a page whose content is identical across versions except for its navigation, will not be rescued by correct tags, because the tags describe the relationship between versions, not the quality of any one version.

Hreflang is also not a canonical tag, and the two must not be confused, although they are often used on the same page. Canonical says which version of similar pages should be treated as the primary one for indexing purposes. Hreflang says which version should be shown to which audience. The correct combination, as Google's documentation describes it, is that each language version points to itself as canonical, not to a different language version, while also carrying the hreflang tags that name the whole cluster. Pointing every version's canonical at one master version contradicts the hreflang signal and can cause the annotations to be ignored, which is one of the most common and most damaging errors in multilingual work.

Finally, hreflang is not a guarantee that the right version will always be shown. It is a strong hint, and search engines generally honour it when it is correct and consistent, but a searcher's own settings, the availability of versions, and the search engine's understanding of the query can all lead to a different version being shown. Hreflang improves the odds substantially for a correctly implemented cluster; it does not remove the need for good content in each language, or for a language switcher that lets a reader correct a wrong guess with one click.

How Hreflang Works

The working unit of hreflang is the cluster: a set of URLs, each representing the same content for a different language or region, all naming each other. When a search engine crawls one page in a cluster and reads its hreflang tags, it learns the whole set, and it can then associate the set in its index, so that a search from a given language or region can be matched to the version made for that audience. For the association to hold, the references must be reciprocal: if page A names page B as its Spanish version, page B must name page A as its English version. A one-way reference is treated as unconfirmed, and the cluster may be ignored, which is why a missing return tag is one of the first errors an audit should look for.

Why Hreflang Matters

It matters first for the reader, whose experience is the point of the whole exercise. A Spanish-speaking searcher who is shown an English page, when a Spanish version exists on the same site, has been failed twice: once by being given content they cannot comfortably read, and once by being kept from the version that was made for them. That failure is not a minor inconvenience; for many readers it ends the visit, and for some it ends the relationship with the site, because the reader concludes, reasonably, that the site is not for them. Hreflang exists to prevent that failure at scale, by making the match between reader and version a declared fact rather than a guess.

It matters third for sites whose audiences span regions within a single language. English for the United States, English for the United Kingdom, and English for Australia may differ in spelling, pricing, shipping, legal details, and examples, and a reader in each region deserves the version written for their context. Hreflang with region codes is the tool for that distinction, and it is also the tool that prevents the regional versions from competing with each other in a way that leaves the search engine unsure which to show. The internal linking guidance applies here too: links within a language version should generally point to pages in the same language, so that a reader who starts in Spanish stays in Spanish as they explore, rather than being bounced back to English by a careless link.

Common Hreflang Mistakes

The first common mistake is missing return tags. Page A names page B, but page B does not name page A, because the second page was published later, or edited separately, or generated by a different template. The cluster is then unconfirmed from the search engine's perspective, and the annotations may be ignored entirely, which means the site has done most of the work of hreflang and received none of the benefit. The remedy is to generate hreflang tags from a single source of truth, such as a cluster list or a content system that writes the full set onto every version at once, rather than hand-writing tags page by page.

The second mistake is missing self-reference. A page names its other versions but forgets to name itself, which breaks the rule that every version declares the whole cluster, including itself. This error is easy to make when tags are written by thinking of them as links to other pages, rather than as a declaration of the cluster, and it is easy to miss in review, because the page's tags look complete at a glance. An audit that checks, for every page, that the page's own URL appears among its hreflang values, catches it immediately.

The fourth mistake is pointing hreflang at broken, redirected, or non-canonical URLs. A cluster that names a URL that returns an error, redirects elsewhere, or is itself canonicalised to another URL sends the search engine on a chase that ends nowhere useful, and the annotations for that version may be dropped. Hreflang URLs must be live, indexable, canonical versions of the pages they name, which means the cluster must be re-checked whenever a URL changes, a page is redirected, or a section is restructured. The sitemap discipline is a useful parallel here: both are lists of URLs that must be kept true, and both rot silently when they are not maintained.

How to Apply Hreflang Step by Step

Start by deciding which languages and regions you actually serve, and which pages exist in each. List the site's pages, and for each page, list the versions that exist, at their real URLs. Do not list versions you intend to create; list versions that exist today, because hreflang describes reality, not intention. If a page exists in English and Spanish but not in French, its cluster has two members, not three, and adding a French tag pointing nowhere helps nobody. This inventory is the foundation for everything that follows, and it should be written down, not held in anyone's head.

Next, choose a URL structure and a delivery method, and stick to them. Different URLs for different language versions are the requirement; whether those URLs use subdirectories, subdomains, or separate domains is a choice, with subdirectories the simplest for most small sites, because they keep the whole cluster under one domain and one set of tools. For delivery, choose one method, HTML tags, HTTP headers, or sitemap annotations, and use it consistently, rather than mixing methods, which Google's documentation warns is harder to manage. For most small sites, HTML tags in the head of each page are the right choice, because they are visible, inspectable, and debuggable with ordinary tools.

Then write the tags from the inventory, not from memory. For each page, write the full set: a tag for itself, a tag for every other version in its cluster, and an x-default tag naming the fallback, if one has been chosen. Use lowercase language codes and uppercase region codes by convention, joined with a hyphen, and double-check every URL against the live site, so that no tag points at a redirected, broken, or non-canonical address. Generate the tags from the inventory mechanically, with a template or a script, rather than typing them per page, because hand-typed clusters are where return-tag and self-reference errors are born.

Finally, maintain the cluster as a living list. Add a hreflang check to the publishing routine for any new translated page, and to the redirect and deletion routines for any page that moves or disappears, because a cluster that is correct today will rot the moment a page is renamed without updating its partners. Revisit the inventory when a new language is added, when a version is retired, or when the site's structure changes, and re-validate after each change. The guide to pillar pages and topic clusters describes a similar discipline for topical clusters, and the lesson transfers directly: a cluster, of topics or of languages, is only as good as its maintenance.

How Rankenza Handles Hreflang

Rankenza's articles are written for a defined audience in a defined language, and that discipline is the same one hreflang requires: know who the page is for, write it for them, and do not pretend a page serves an audience it was not written for. Each article starts from research into the top 10 pages for its keyword, filtered by what the searcher actually wants, and the draft is written in original words, reviewed by a human editor, and given internal links from the customer's own sitemap. For a customer expanding into another language, that research must be redone for the new language, because readers in different languages search with different words and different questions, and a translated keyword list is not the same as research in the new market. Rankenza's process, research first, original draft, human review, internal links, applies per language, not once for all languages.

How This Looks on Rankenza

The comparison below is method against method, without inventing traffic or ranking figures for either side.

Sources: What the Research Says

According to Google Search Central's documentation on localised versions of pages, site owners with multiple versions of a page for different languages or regions should tell Google about those variations, so that search results can point users to the most appropriate version by language or region, and the documentation lists three equivalent methods for doing so: HTML, HTTP headers, and sitemap. The same documentation states that Google does not use hreflang or the HTML lang attribute to detect a page's language, but uses its own algorithms, and that localised versions are only considered duplicates if the main content remains untranslated. Google's guide to managing multi-regional and multilingual sites adds the structural advice: use different URLs for each language version rather than adjusting content by cookies or browser settings, and use hreflang annotations to help search results link to the correct version. Ahrefs' beginner's guide to hreflang describes the same attribute from the practitioner's side, including the reciprocal-reference requirement and the complexity that led Google's John Mueller to call hreflang one of the most complex aspects of search work. Where this guide gives no number, that is deliberate: the sources describe rules and relationships, not a measured outcome that would apply to every site, and the one study figure Ahrefs reports about implementation errors is not repeated here as a general claim about any particular site.

• Google Search Central: Localized Versions of your Pages
• Google Search Central: Managing Multi-Regional and Multilingual Sites
• Ahrefs: Hreflang: The Easy Guide for Beginners
• Moz: The Beginner's Guide to SEO

Frequently Asked Questions

Do I need hreflang if my site is only in one language?

No. Hreflang describes the relationship between versions of the same content in different languages or regions, so a monolingual site with no regional variants has no cluster to describe. Hreflang becomes relevant the moment a second language or regional version exists, and it should be added as part of publishing that version, not as an afterthought.

Does each page need to list itself in its hreflang tags?

Yes. Each version should carry the full set of tags for its cluster, including a self-referencing tag pointing at itself, and the references must run in both directions: if page A names page B, page B must name page A. Missing self-references and missing return tags are among the most common hreflang errors, and either can cause the annotations to be ignored.

Can hreflang and canonical tags be used on the same page?

Yes, and for multilingual pages they should be used together correctly: each language version points to itself as canonical, not to a different language version, while also carrying the hreflang tags that name the whole cluster. Pointing every version's canonical at one master version contradicts the hreflang signal and can cause it to be ignored.

Should I use HTML tags, headers, or a sitemap for hreflang?

Choose one method, because Google treats all three as equivalent and warns that using all three at once is harder to manage. For most small sites, HTML tags in the head of each page are simplest to write, inspect, and debug. HTTP headers suit non-HTML files, and sitemap annotations suit very large sites where centralising the annotations is easier than editing every page.